If your WordPress site was hacked and is now showing pharmaceutical spam, redirecting visitors to somewhere unpleasant, or has been flagged by Google as deceptive, start here rather than with a plugin. The instinct is to install a security scanner and click clean. That removes the visible symptom and leaves the way in, which is why so many sites get reinfected within days and their owners conclude that WordPress is simply insecure.

It is not. Almost every compromise arrives through an out-of-date plugin, and almost every failed cleanup happens because someone removed the malware without removing the access.

First hour: Take the site offline or into maintenance mode. Change the hosting control panel password, the database password, all administrator passwords and the FTP or SSH credentials. Do not restore a backup yet, and do not delete anything yet. You need the current state to work out how they got in, and a restore destroys that evidence while very likely reinstating the same vulnerability.

What to Do in the First Hour

Order matters here, and the common mistakes are all impatience.

Take the site down. A maintenance page or a temporary block at the hosting or CDN level protects visitors and stops the site distributing malware while you work. If the site is serving malicious redirects, every hour it stays up compounds the reputational damage.

Rotate every credential, not just the WordPress admin password. That means hosting panel, database user, FTP and SSH keys, and any API keys stored in the site’s configuration. Attackers routinely create a second administrator account or leave a key behind, so changing one password achieves nothing.

Preserve the evidence before changing anything. Take a full copy of the files and database as they are now, and download the server access logs covering at least the last thirty days. Those logs are how you find the entry point, and many hosts rotate them within days.

Then, and only then, work out what happened.

How Your WordPress Site Got Hacked: Finding the Entry Point

Cleaning without diagnosis is why reinfection is so common. Four checks find the cause in most cases.

Check plugin and theme versions against known vulnerabilities. Out-of-date plugins are far and away the leading cause. Note every plugin, its version, and whether a security release exists that you have not applied. Pay particular attention to anything with an expired licence, because premium plugins stop receiving updates when the licence lapses while continuing to appear installed and active.

Read the access logs around the first sign of trouble. You are looking for POST requests to unusual paths, requests to files that should not exist, and a burst of activity from one address shortly before the defacement. This is usually where the answer is.

Look for files that do not belong. Recently modified PHP files in the uploads directory are a strong signal, because nothing should ever execute there. So are files with names designed to look plausible, and modifications to wp-config.php or .htaccess.

Check for added administrator accounts and scheduled tasks. Attackers commonly create a user to return through, and register a scheduled task that reinstalls the payload after you clean it. A site that keeps reinfecting on a regular cycle almost always has a scheduled task nobody looked for.

Why “Just Restore a Backup” Usually Fails

It is the first suggestion everyone receives and it is right about a third of the time.

Restoring works when you know the compromise date, have a backup from before it, and have identified and fixed the vulnerability. Without all three it fails predictably. Restore a backup from last week and you may be restoring a site that was already compromised two weeks ago and merely quiet. Restore without patching the vulnerable plugin and you have rebuilt the door you were locked out of.

There is also the problem of what a restore costs you. On a store or a membership site, rolling back means losing every order, registration and comment since the backup. That is often unacceptable, which pushes you towards cleaning the live site rather than replacing it.

The reliable approach is a rebuild rather than a restore. Install WordPress core fresh, install clean copies of every plugin and theme from their official sources rather than from the compromised site, and carry across only the uploads directory and the database — both inspected first. That guarantees the executable code is clean, which file-by-file cleaning never quite does.

Cleaning the Database

The database is where incomplete cleanups leave things behind, because scanners concentrate on files.

Injected content usually appears in post content as hidden links or iframes, in the options table where redirect scripts get stored, and in user metadata. Search for script tags, base64-encoded blocks and unfamiliar domains across the content and options tables.

Check the users table by hand. Look at every account with administrator privileges and confirm you recognise each one, then check registration dates against your own records.

Look at scheduled tasks, which in WordPress live in the options table. An entry pointing at a function you do not recognise is how a site reinfects itself on schedule long after the files were cleaned.

Take particular care with anything encoded. Attackers obfuscate payloads specifically so a search for obvious strings misses them, so decode anything suspicious rather than assuming it is a legitimate plugin doing something clever.

Getting Unflagged and Recovering Rankings

Cleaning the site is not the end, because the warnings persist until you ask for them to be reviewed.

If Google has flagged the site, the security issues report in Search Console tells you what was detected and lets you request a review once you have fixed it. Only request the review after the site is genuinely clean, because a failed review lengthens the process.

Check whether the domain has landed on blocklists used by browsers and email providers. Being clean is not enough on its own; each maintains its own list and its own removal process.

Then look at the damage. Search visibility usually recovers once warnings are lifted, but a site that spent weeks serving spam pages may have had those pages indexed. Check for indexed URLs that were never yours, remove them, and confirm the clean versions are being crawled. Our website security audit guide covers the verification steps in more detail.

What Professional Recovery Costs

Prices reflect typical UK rates and vary with how long the compromise went unnoticed.

A straightforward cleanup on a small site caught quickly, with a known cause, generally runs £400 to £1,200 and takes a day or two. This is the common case when someone notices within a week.

A full incident response — log analysis to establish entry point and timeline, clean rebuild, database inspection, credential rotation, hardening and blocklist removal — typically runs £1,500 to £5,000. This is what a store or a site holding customer data should expect, because you also need to establish whether data was accessed.

Sites compromised for months, or hosting several sites on the same account, cost more, because cross-contamination between sites on shared hosting is common and each one must be checked.

If personal data may have been accessed, there are obligations beyond the technical cleanup. UK GDPR requires notifying the ICO within 72 hours of becoming aware of a qualifying breach, and that clock starts at awareness, not at cleanup. Take advice early rather than after you have finished tidying. Our guide to GDPR technical compliance covers the engineering side of that.

Making Sure It Does Not Happen Again

Recovery without hardening just resets the clock.

Update discipline is the whole game. The overwhelming majority of compromises exploit a vulnerability with a patch already available, so the fix is a routine that applies security releases promptly and a policy of removing anything unmaintained. Premium plugins with lapsed licences should be renewed or replaced, never left in place.

Reduce what can execute. Nothing in the uploads directory should ever run as PHP, file editing from the admin interface should be disabled, and administrator accounts should be few and individually named.

Add multi-factor authentication on every administrator account and rate-limit the login endpoint. Most credential attacks are automated and stop being viable the moment a second factor exists.

Finally, back up properly and test it. A backup you have never restored is a hypothesis. Keep several generations, because the newest one may already contain the compromise. Our WordPress security hardening checklist sets out the full configuration, and our WordPress performance audit guide covers the plugin discipline that reduces the attack surface as a side effect.

Get It Cleaned Properly

Mecanik provides WordPress security audit and incident recovery work: establishing how the compromise happened, rebuilding cleanly rather than patching over it, inspecting the database, and hardening the site so the same route closes behind you.

We work from the server logs rather than from a scanner’s output, because a scanner tells you what it recognises and the logs tell you what actually happened. Where the site handles customer data we will also tell you plainly whether you appear to have a notifiable breach, rather than leaving you to discover that later. Ongoing maintenance is available through our WordPress development service , which is generally cheaper than a second incident.

If your site is compromised right now, take it offline, rotate the credentials, keep the logs, and get in touch.

Related reading: API Security: How to Protect a Public API in 2026 , OWASP Top 10 Explained for Business Owners , Server Security Audit Checklist: What Actually Gets Checked and Website Security Audit Guide for UK Businesses in 2026 .

Frequently Asked Questions

What should I do first if my WordPress site is hacked? Take the site offline, rotate every credential including hosting, database, FTP and all administrator accounts, and preserve a copy of the current files, database and server logs. Do not restore a backup or delete files yet, because that destroys the evidence needed to find the entry point.

Why does my WordPress site keep getting reinfected? Almost always because the cleanup removed the malware but not the access. Look for administrator accounts you do not recognise, backdoors in the uploads directory, and scheduled tasks in the options table that reinstall the payload. Reinfection on a regular cycle usually indicates a scheduled task.

Can I just restore a backup to fix a hacked site? Only if you know when the compromise happened, have a backup from before it, and have fixed the underlying vulnerability. Without all three you risk restoring an already-compromised site or reopening the same hole. A clean rebuild with fresh core, plugins and themes is more reliable.

How much does WordPress malware removal cost? A straightforward cleanup on a small site caught early typically costs £400 to £1,200. A full incident response with log analysis, clean rebuild, database inspection and hardening generally runs £1,500 to £5,000, and long-running or multi-site compromises cost more.

How do I get my site unflagged by Google? Clean the site fully, then request a review through the security issues report in Search Console. Only request it once the site is genuinely clean, since a failed review lengthens the process, and check separately for browser and email blocklists which each have their own removal procedure.