How to Fix a Hacked WordPress Site

If your WordPress site has been hacked, the fix follows a fixed order: contain it, preserve a copy, change every password, clean or restore, find and close the way in, then clear any warnings Google or your host has raised. Doing these in the wrong order — especially cleaning before changing passwords, or restoring without closing the hole — is why so many sites get hacked again within weeks.

This is the step-by-step version. If you are not comfortable with SFTP, the hosting control panel and a database tool, read it to understand what should happen, then get help.

How do you know a WordPress site has been hacked?

Common signs:

• Google shows "This site may be hacked" or the browser shows a red warning page
• visitors on mobile, or arriving from Google, are redirected to spam or scam sites — while you, logged in, see nothing wrong
• pages in Google's results for your domain that you never created, often in another language or selling pharmaceuticals
• new administrator users you do not recognise
• your host has suspended the site or emailed about malware or outbound spam
• unfamiliar PHP files in the uploads folder, or core files with recent modification dates
• the site is suddenly slow, or the server's resource usage has jumped

Hacks are often designed to hide from the site owner. Check from a logged-out browser, on a phone, and with a search for site:yourdomain.co.uk in Google.

Step 1: Contain it

Stop it getting worse while you work.

1. Put the site in maintenance mode, or ask the host to restrict access, if it is actively harming visitors (redirecting them, serving malware).
2. Tell the host. They may already know, and they can sometimes see server logs you cannot.
3. Do not delete anything yet.

Step 2: Take a copy of the hacked site

Download the full files and an export of the database exactly as they are now. This feels backwards, but you need it to work out how they got in and when, and it protects you if the clean-up goes wrong.

Keep this copy separate and clearly labelled. Never restore it.

Step 3: Change every password and key

Assume every credential connected to the site is known to the attacker:

• hosting control panel
• SFTP and SSH accounts
• the database user (and update wp-config.php to match)
• every WordPress administrator account
• any connected services: email sending, payment gateways, API keys stored in the site

Then regenerate the WordPress security keys and salts in wp-config.php. This logs everyone out, including any attacker holding a valid session cookie.

Change passwords from a device you trust. If a computer used to manage the site is infected, the new passwords leak too.

Step 4: Decide: restore or clean?

Infections often sit unnoticed for weeks, so "last night's backup" may be infected too. This is where retention matters: a backup strategy with 30 or more days of history gives you options. Website backups: what a proper strategy looks like covers retention properly.

Step 5: Clean the site

If you are cleaning rather than restoring, work through every layer.

WordPress core

Replace the wp-admin and wp-includes folders entirely with fresh copies from wordpress.org of the same version. Do not try to clean core files; replace them.

Plugins and themes

Delete every plugin and theme folder and reinstall from the official directory or the vendor. Any plugin or theme from an unofficial source — especially a "nulled" copy of a premium product — goes and does not come back.

If a theme has custom code, compare it file by file against a known-good copy from version control or the developer.

The uploads folder

Uploads should contain images and documents, never PHP. Search for any .php files there and remove them. Look also for files with double extensions or odd names.

wp-config.php and .htaccess

Check for injected code at the top or bottom, unfamiliar includes, and redirect rules you did not write. Hacks love .htaccess because a single rule can redirect search visitors only.

The database

Look for:

• unknown administrator accounts in the users table
• script tags or obfuscated JavaScript injected into posts, widgets or options
• spam posts or pages created in bulk
• altered site URL settings

A malware scanner such as Wordfence or Sucuri's scanner helps find what to look at, but read what it flags rather than trusting a green tick.

Step 6: Find and close the way in

This is the step most clean-ups skip, and the reason re-infection is common.

Use the copy you took in step 2 and the server logs to answer:

1. Which plugin or theme versions were installed? Check them against a vulnerability database such as WPScan, Patchstack or Wordfence Intelligence.
2. When were the first malicious files created? File dates and access logs often point to a specific request.
3. Were there admin logins from unfamiliar places? That points to a stolen password rather than a vulnerability.

Then close it: update or remove the vulnerable component, enforce two-factor authentication, remove unused accounts, and apply the hardening in the WordPress security guide.

Step 7: Clear Google's warnings

If Google has flagged the site:

1. Open Search Console and go to Security & Manual Actions, then Security issues.
2. Confirm every listed issue is fixed, including spam URLs.
3. Make sure spam pages now return a 404 or 410, not a soft redirect to the homepage.
4. Click Request review and explain what you found and fixed.

Reviews can take days. While waiting, the Google Search Console guide explains the other reports worth watching as the site recovers. Spam URLs can linger in Google's index for a while after the review; they drop out as Google recrawls them.

If your host suspended the account or your domain was added to email blocklists, contact each separately once the site is clean.

Step 8: Consider whether personal data was exposed

If the site stores enquiries, customer accounts or orders, ask whether the attacker could have accessed them. If a breach of personal data is likely to pose a risk to people, UK GDPR generally requires reporting it to the ICO within 72 hours of becoming aware of it. The ICO's breach reporting pages explain how to decide and how to report. Keep notes of what you found and when — you will need them either way.

Step 9: Watch it closely for a month

After a clean-up:

• run a scan daily for the first week, then weekly
• keep file change alerts and new-user alerts on
• check Google for site:yourdomain spam pages
• watch the server's access log for repeat attempts against the same entry point

If the infection returns, something was missed — usually a backdoor file or a second compromised account.

Common mistakes during a clean-up

These are the errors that turn one hack into two:

• Cleaning before changing passwords. If the attacker still has a valid login, they simply come back in and re-infect the clean site.
• Deleting the obvious malware and stopping. Attackers usually leave backdoors — small, innocent-looking files that let them return. One visible infection often hides several quiet ones.
• Restoring the newest backup without checking it. The infection may predate it.
• Leaving the vulnerable plugin in place. If a plugin let them in and is still installed at the same version, the clean-up is temporary.
• Trusting a scanner's all-clear. Scanners match known patterns. New or custom malware can pass a scan.
• Redirecting spam URLs to the homepage. It looks tidy, but it tells Google those URLs still lead somewhere. Let them return 404 or 410 so they drop out of the index.
• Forgetting about email. Hacked sites are often used to send spam. Check whether the domain or the server's IP address has been listed on email blocklists, or your normal email may start landing in spam folders.

Working with your host

Your hosting company can be a useful ally here. Ask them for:

1. Access logs covering the period before the infection was noticed
2. Any malware scan reports they have run
3. Server-level backups older than your own, if theirs go back further
4. Confirmation of whether other sites on the same account are affected

If you run several sites on one hosting account, check all of them. A compromised site can be used to infect its neighbours on the same account, and cleaning one while leaving another infected means the problem returns.

Preventing it next time

The prevention list is short and boring, which is exactly why it works: prompt updates, fewer plugins, two-factor authentication, few administrators, off-site backups with long retention, and monitoring that tells you before Google does. The website maintenance guide covers how those fit together, and for a quick triage of other faults, common WordPress problems and fixes is the companion piece.

If you are dealing with a compromise now and would rather hand it over, get in touch through the website maintenance service — the clean-up starts with a copy of the site exactly as it is, and ends with the hole closed, not just the symptoms removed.