Emergency · Hacked
Hacked WordPress site: recovery and cleanup
If your site is serving malware, redirecting visitors, or flagged by Google, the clock matters. Here's how to tell what you're dealing with, what to do in the next ten minutes, and how professional remediation differs from running a scanner.
Fix My SiteHow to tell if your WordPress site has been hacked
Seven signs, roughly in order of how often we see them:
01
Search results don't match your site.
Google shows pharmaceutical, casino or replica-goods keywords under your domain. This is a spam injection targeting search engines specifically — it often stays invisible to you while logged in.
02
Visitors get redirected, but you don't.
Malicious redirects commonly exclude logged-in users and repeat visitors, which is why the client sees it and the owner doesn't.
03
A browser or Google warning appears.
"Deceptive site ahead," or a Search Console security issue notification.
04
Admin users you don't recognise.
Check Users → All Users, and check for users with no posts and a recent registration date.
05
Your host emails you about outbound spam
Or suspends the account.
06
Files modified at times you weren't working.
Especially in wp-includes/, wp-content/uploads/, or a .php file inside the uploads directory — nothing legitimate puts executable code there.
07
The site slows dramatically with no traffic increase.
Cryptominers and spam mailers consume the resources you're paying for.
One of these is worth investigating. Three of these is a compromise.
What to do in the next ten minutes
Do
Take the site offline or into maintenance mode if you're serving malware to visitors. Reputational damage compounds.
Change your hosting password and your WordPress admin password. From a different device if you suspect a keylogger.
Screenshot everything before you touch it.
Check Google Search Console → Security & Manual Actions.
Don't
Don't restore a backup yet. You'll likely restore the compromise, and you'll destroy the evidence needed to find the entry point.
Don't delete the suspicious files. Quarantine, don't delete.
Don't install three more security plugins. Scanners conflict, and a compromised site can produce false clean reports.
Why a scanner isn't a cleanup
A security plugin scan tells you which files don't match the official checksums. That's useful and it's roughly 20% of the job.
It doesn't tell you how they got in. And if you don't close the entry point, you get reinfected — usually within days, often through the same abandoned plugin, a reused password, or a backdoor sitting in a file the scanner considers legitimate because it isn't part of core.
Scanner does
Flags modified core files
Finds known malware signatures
Remediation also does
Verifies core against official checksums and repairs from source
Finds obfuscated and novel payloads by behaviour
Identifies the entry vector — plugin CVE, credential reuse, host-level, or supply chain
Audits every admin user, application password, and API key
Checks scheduled tasks for persistence
Removes injected content from the database, not just the filesystem
Requests review with Google to clear a security flag
Hardens the specific weakness that let it happen
What you get from us
Containment snapshot before any change
Full malware removal — filesystem and database
Entry-point identification, in writing. If we can't determine it, we say so rather than guessing.
Every credential, user, application password and integration audited
Hardening applied to the specific vector
Google Search Console review request where a flag exists
A written post-mortem you can show your board, your insurer, or your client
Then what?
Most compromises we see aren't sophisticated. They're a plugin that stopped being maintained eighteen months ago and nobody noticed. Ongoing monitoring is not upselling — it's the only part of this that's actually preventive.