Your site is redirecting visitors to a pharmacy page. Or Google is showing a warning under your listing. Or your host suspended the account. Or a customer emailed to ask why your checkout asked for their card details twice.
Here’s the fastest path back, in order — the same sequence we run on client emergencies.
Rather not do this yourself? We clean and recover hacked WordPress sites. Get in touch — phone, email, live chat, whatever’s fastest for you. Or see what WordPress repair covers first.
Everyone else: start here.
First, the mistake almost everyone makes
The instinct is to clean. Install a security plugin, run a scan, delete what it flags, change the passwords, breathe out.
Then three days later it’s back.
That happens because a malware scan finds files. It does not find the way in. If you remove the payload but leave the entry point open — an outdated plugin with a known exploit, a stolen FTP credential, a backdoor in a directory the scanner doesn’t read — you have cleaned a symptom and left the cause running.
The second instinct is to restore a backup. Also usually wrong, and for a related reason: you don’t know when the compromise happened. Most breaches are discovered days or weeks after the initial access. Restoring last night’s backup restores the backdoor along with everything else, and now you’ve also destroyed the evidence you needed to find it.
Order matters more than tools here. Isolate, investigate, close the hole, then clean. In that sequence.
Step 1: Take the site offline — properly
Every minute a compromised site stays public, three things get worse: visitors get infected or phished, Google’s crawler collects more evidence for a blacklist entry, and the attacker keeps whatever access they have.
Put the site into maintenance mode at the server or host level — not with a WordPress plugin. A plugin runs inside the application you no longer trust. If your host has a “suspend site” or holding-page option, use it.
If you can’t do that, the next best thing is an .htaccess rule allowing only your own IP:
Order Deny,Allow
Deny from all
Allow from YOUR.IP.ADDRESS.HERE
Two things to be aware of: this is exactly the kind of file attackers modify, so check what’s already in it before you add anything. And if the compromise is at server level rather than site level, .htaccess will not save you — that’s a call to your host.
Do not delete anything yet. Not the suspicious file, not the unknown admin user. Right now those are your only evidence.
Step 2: Tell your host — before you touch anything
This is the step people skip because it feels like admitting fault. Do it anyway, and do it early.
Your host can see things you can’t: server-level access logs, whether other accounts on the same server were hit, whether the intrusion came through FTP, SSH, the WordPress login, or a neighbouring site on shared hosting. Many hosts will also take a forensic snapshot before you start changing things, and some will run a server-side scan you can’t run yourself.
If your site was suspended, they’re also the only ones who will unsuspend it — and they’ll want to see what you did before they do.
On shared hosting, ask one specific question: was the entry point this account, or another account on this server? If it’s the latter, everything you do inside WordPress is beside the point.
Step 3: Find the entry point
This is the actual work, and it’s the step that decides whether the fix holds.
Check the timestamps
The single most useful thing you have is when files were last modified. Over SSH:
find /path/to/site -type f -mtime -14 -ls | sort -k8
That lists everything changed in the last fourteen days. On a site where nobody has published or updated recently, the modified files are a very short list — and the attacker’s files are usually in it, clustered within a few minutes of each other.
Pay attention to modification times inside wp-includes and wp-admin. Core files should only ever change when WordPress updates. A recently modified file in there, on a site that hasn’t updated, is a finding.
Look where payloads actually live
Attackers rarely hide in index.php. The recurring locations:
/wp-content/uploads/— should contain media, nothing executable. Any.phpfile in here is a red flag, full stop/wp-content/plugins/in a folder that isn’t a plugin you installedwp-config.php, at the very top or the very bottom.htaccessin the root and in/wp-content/uploads/mu-plugins— the must-use plugins directory, which loads automatically and appears nowhere in your plugin list. A favourite hiding place precisely because most site owners have never opened itYour theme’s
functions.php, usually at the end, after a lot of blank lines
Compare core against the original
Everything in WordPress core should be byte-identical to the official release. WP-CLI checks it in one command:
wp core verify-checksums
Anything reported as modified in core is either a hack or something a previous developer did that they shouldn’t have. Both are worth knowing.
The same works for plugins from the repository:
wp plugin verify-checksums --all
Read the access logs
Once you know roughly when — from the file timestamps — the logs tell you how. Look at requests immediately before the first modified file. What you’re looking for: repeated POST requests to a single plugin endpoint, requests to /wp-login.php from one IP in rapid succession, or POST requests to a file in /uploads/.
That last one is often the whole story: an upload vulnerability let them place a file, then they executed it.
Check the users table
SELECT ID, user_login, user_email, user_registered
FROM wp_users ORDER BY user_registered DESC LIMIT 20;
An administrator account created at 3 a.m. with an email address on a domain you don’t recognise is not subtle, but it’s remarkably common — and it’s the mechanism by which they get back in after you’ve cleaned everything else.
Don’t delete it yet. Note it. It’s evidence, and it tells you the compromise reached the database, not just the filesystem.
Step 4: Close the hole
Only now, with a plausible entry point identified.
Update everything. Core, plugins, themes, PHP. The known-vulnerable plugin is the most common way in, and the fix is usually a version that’s been available for months.
Delete what you don’t use. Deactivated plugins still sit on the server, and their files are still reachable. An inactive plugin with a known exploit is exactly as dangerous as an active one. Same for unused themes — keep one default theme, remove the rest.
Rotate the credentials, in the right order. All WordPress admin passwords. The database user password (and update wp-config.php). FTP and SFTP. SSH keys. Hosting control panel. If the same password was reused anywhere else, that too.
Rotate the salts. This is the step that’s almost universally missed. WordPress logs users in with cookies signed by the secret keys in wp-config.php. Changing a password does not invalidate an existing session — an attacker with a valid cookie stays logged in after your password change.
Generate new ones at api.wordpress.org/secret-key/1.1/salt/ and replace the whole block in wp-config.php. Everyone gets logged out, including whoever shouldn’t be there.
Block PHP execution in uploads. Nothing in your media library should ever run. Add to /wp-content/uploads/.htaccess:
<Files *.php>
deny from all
</Files>
Disable file editing in the admin. Add to wp-config.php:
define('DISALLOW_FILE_EDIT', true);
It removes a convenient way to inject code through a stolen login.
Step 5: Now clean
With the entry point closed, cleaning finally means something.
Replace core wholesale rather than editing individual files. wp core download --force overwrites core with clean copies and leaves wp-content and wp-config.php alone.
Reinstall plugins and themes from source rather than cleaning them file by file. For anything from the repository, delete and reinstall. For premium plugins, get a fresh download from the vendor. For custom code, you need a clean copy from version control — and if there isn’t one, that’s the real lesson from this incident.
Then run a scanner — Wordfence, Sucuri, or your host’s. It’s a verification step, not a strategy. It confirms you didn’t miss something obvious.
Clean the database separately. Injected content typically lives in wp_posts (spam links appended to post content), wp_options (malicious values in autoloaded options), and wp_users. Check for admin accounts you didn’t create, and for options with names you don’t recognise that load on every page.
Remove the evidence you preserved — now, not earlier. The rogue admin user, the payload files, the modified .htaccess.
Step 6: Verify from the outside
Your own browser is the least reliable place to check. You’re logged in, you’re cached, and much of this malware deliberately behaves differently for logged-in users and for visitors arriving from Google.
Test in a private window, logged out. Then test arriving from a search result, because redirect malware often triggers only on that referrer.
Check what Google sees. Search site:yourdomain.com and look for pages you never published — pharmaceutical spam, casino pages, foreign-language listings. If they’re there, they’re indexed, and you’ll need to request removal.
Request a review if you were flagged. Google Search Console has a Security Issues section; once you’re clean, request a review there. It typically takes a few days. The same applies to any host or browser blacklist you landed on.
Clear every cache. Page cache, object cache, CDN. A CDN happily serving a cached malicious page for hours after you cleaned the origin is one of the most frustrating ways to think you’ve failed when you’ve succeeded.
Step 7: Make the next one not happen
A site that was hacked once is a target. The address is on a list now.
Get updates onto a schedule — with staging, so an update never breaks production. The overwhelming majority of WordPress compromises exploit a vulnerability that was patched before the attack.
Backups off-site, and tested. A backup on the same server as the site is not a backup. And an untested backup is a hypothesis. Restore one to a staging environment occasionally and see whether it actually works.
Two-factor authentication on every admin account. Not optional on a site that handles orders or customer data.
Fewer administrators. Most people with an admin account need Editor. Every admin account is a full compromise waiting for a reused password.
File change monitoring. The value isn’t prevention, it’s detection speed. Finding out in an hour instead of three weeks changes everything about the clean-up — including whether your backups from before the breach still exist.
The uncomfortable part: what was taken
If your site handles customer data, cleaning it is not the end of the job.
A WooCommerce store holds names, addresses, email addresses, order histories, and sometimes partial payment data. If the compromise reached the database, you have to assume it was read. Depending on where your customers live, you may have a legal notification obligation with a deadline measured in hours — the GDPR’s 72-hour rule is the one most people have heard of, and several US states have their own.
Card-skimming malware on checkout pages is a specific and growing category on WooCommerce. It rarely breaks anything visibly — it copies card details as they’re typed and sends them elsewhere. If your checkout was compromised, contact your payment provider before you do anything else.
This is the point where a hacked site stops being a technical problem and becomes a business one. If you’re unsure what your obligations are, get advice quickly rather than after.
The short version
Isolate first. Tell your host. Find how they got in before you clean — file timestamps and checksums will usually tell you within the hour. Close the hole, rotate every credential and the salts, then replace core and plugins from clean sources rather than editing them. Verify logged out and from Google, not from your own logged-in browser. Then fix the process that let it happen.
The cleaning is the easy part. The order is what stops it happening again next week.
Site compromised right now? We clean and recover hacked WordPress and WooCommerce sites — including finding the entry point, which is the part that determines whether it stays clean. Get in touch: phone, email, or live chat, whichever is fastest.
And once you’re back up, our Maintenance Package is the reason this doesn’t happen twice: every update staged and tested before it touches your live site, off-site backups, and security monitoring.
Related: The WordPress White Screen of Death: A Diagnostic Order — because sometimes a blank page isn’t a plugin conflict.
WPerizo.com — WordPress & WooCommerce. Nothing else. 🦔
