We Cleaned a 880,000 URL WordPress Hack: The 410 Recovery Playbook

In August 2025 a network of WordPress sites under one roof got hit at the same time. Not one site. The whole estate, sharing a server. Our founder was head of web development on that estate and sat in the recovery room for it, alongside the internal SEO team and an external technical SEO consultant brought in specifically for the Google side of the damage.

The numbers are the part people do not believe. The main property had grown to roughly 880,000 indexed URLs. Almost half of that was not real content. It was injected spam, published under query string URLs, ranked quietly, and then monetised. When the cleanup finished, the index count settled back to around 469,000. That gap is the size of the hack.

The injected pages were served under plain query string URLs, in the shape of a post ID parameter appended to the domain. No pretty permalink, no menu entry, no post in the dashboard. From inside WordPress the site looked normal. From Google's side there were hundreds of thousands of pages about products and services the business had never touched.

This is the standard shape of a parasite injection. The attacker does not want to break your site. A broken site gets fixed on day one. They want your domain authority quietly rented out for as long as possible, so they hide the payload behind conditional serving: real visitors get the real page, crawlers get the spam.

• Search Console shows a sudden climb in indexed pages with no publishing activity behind it.
• Impressions rise for queries that have nothing to do with your business.
• Your real pages start slipping, because crawl budget is being spent on junk.
• A site: search on your own domain returns titles you have never written.

There was a rogue administrator account on the estate. We deleted it. It came back. We deleted it again, rotated every administrator password, and it came back again. That loop is the single most useful diagnostic signal in a WordPress compromise, because it tells you something conclusive: you are removing symptoms, not the cause. Code is still executing on every request and recreating the account.

Where that code sits is predictable. The persistence layer on this estate included a file dropped into the must use plugins folder, disguised with a security sounding filename so a tired engineer scrolling a file list would read it as legitimate hardening. Files in that folder load automatically, before regular plugins, and they do not appear in the normal plugin screen where you would deactivate them.

The rest of the payload followed the usual pattern: a modified blog header file, a tampered core class file in the admin area, and a scattering of randomly named PHP files with heavily obfuscated contents. Every one of them rebuilt its function calls at runtime from character indexes of junk strings, which is how they slip past signature scanners looking for the literal words eval or base64_decode.

The instinct of every developer handed a list of dead URLs is to redirect them to the homepage. It feels tidy. On a hacked site it is the worst available option, and it was the first thing the consultant flagged when he reviewed our work.

A 301 says the content permanently moved to the new location. Point a hundred thousand spam URLs at your homepage and you have told Google, in the clearest language the protocol has, that your homepage is the new home of a hundred thousand spam pages. You have merged the attacker's payload into your most valuable asset.

There is a second layer to this. Part of the injected estate had been deliberately switched to a 302 by the attacker. That is an old affiliate trick, not an accident. A temporary redirect keeps the original URL in the index for far longer than a removal would, so the ranked spam URL keeps earning while the site owner believes it has been dealt with. If you find 302s on hacked URLs, treat them as evidence of an active operator rather than leftover debris.

Serving 410 is only half of it. Google has to come back and see the 410 before anything changes, and it has no reason to prioritise recrawling a hundred thousand low value URLs it discovered months ago.

The move that broke the deadlock was counterintuitive: build a temporary sitemap containing only the hacked URLs, submit it in Search Console, and leave it live for a few weeks. You are explicitly asking Google to go and look at the pages you want removed. Each crawl hits a 410, each 410 drops a URL, and the index count falls in visible steps rather than drifting.

1. Export the full list of injected URLs from Search Console and your server logs, not just the ones you can see.
2. Confirm every one of them returns 410 before you publish anything.
3. Publish a separate sitemap file containing only those URLs.
4. Submit it in Search Console as its own sitemap so you can watch it drain.
5. Remove the sitemap once the index count stabilises. It is a tool, not a permanent fixture.

Sequence is most of the skill here. On the estate we cleaned the same sites more than once because parts of the work happened out of order, on a shared server where a clean site could be reinfected by a neighbour that had not been touched yet.

1. Contain at the server, not the site. On shared infrastructure, one dirty neighbour reinfects everything you just cleaned. Isolate before you clean.
2. Find and remove the persistence layer. Must use plugins folder, modified core files, unfamiliar PHP in the web root. Nothing else counts until this is done.
3. Delete every rogue account and rotate all administrator credentials, database passwords, hosting logins, and the authentication salts. Rotating passwords without rotating salts leaves active sessions alive.
4. Verify with a clean scan and a 48 hour watch window. If the rogue account respawns, go back to step two.
5. Apply 410 to every injected URL. Audit for attacker placed 302s while you do it.
6. Publish the temporary sitemap of hacked URLs and monitor the index count weekly.
7. Patch what let them in. Cross reference every installed plugin against a public vulnerability database and remove anything abandoned.

"If the rogue admin comes back after you delete it, you have not finished step two. Everything after that is wasted effort until you do."

Post incident, the monitoring model on that estate flipped from reactive to proactive, and those habits are now baked into how we run every site under a care plan.

• Index count is monitored as a security metric, not a marketing one. An unexplained jump in indexed pages is treated as a possible compromise.
• The must use plugins folder is fingerprinted, so any new file there raises an alert the same day.
• Backups are retention checked. A single day of retention, which is what that estate had at one point, is useless against a hack you discover on day three.
• Every administrator account is inventoried monthly. Accounts nobody can name get removed.
• Plugin inventory is cross referenced against public vulnerability data rather than trusting the update badge.