We Found 21,819 Spam Pages After a WordPress Hack. Here's How We Cleaned Up Search

This one is personal. Before we launched our new website in October 2026, agencoder.com ran on WordPress, and while auditing it we found it had been hacked. Its sitemap listed 21,819 injected posts about gambling and casinos, written in many languages, and the homepage carried hidden links to casino and steroid shops. None of it was ours. Here is what we found, what we did, and what Google's own documentation says about each step.

What the hack looked like

• Thousands of spam posts at root-level addresses, each with a long, keyword-stuffed slug.
• Spam links injected into the homepage.
• Endless query-string URLs, such as addresses ending in ?o= followed by a long number, and fake script pages, the pattern often called a Japanese keyword hack.
• A Search Console page report counting roughly 195,000 known URLs, including about 104,500 crawled but not indexed, 48,700 duplicates pointing to another page, and 28,500 not found.

Step 1: Secure everything first

Cleaning pages is pointless if the attacker can come back. Change every password connected to the site (hosting, FTP, database, admin users and email), remove unknown admin accounts, update or remove old plugins and themes, and check other sites on the same hosting account. Google's own guide for hacked sites starts with the same advice: contain the damage before fixing it.

Step 2: Remove the spam content

You can clean an infected WordPress install or replace it entirely. We rebuilt the site from scratch on a new stack, which guaranteed no injected files survived. If you clean instead, compare files against fresh copies and look for unfamiliar PHP files and database entries.

Step 3: Tell search engines the spam is gone, on purpose

A deleted page normally returns 404 Not Found. We went further and returned 410 Gone for anything shaped like the spam: long or keyword-heavy slugs, encoded non-Latin addresses, WordPress system paths and the spam query strings. Google's documentation says it doesn't use the content of URLs that return 4xx codes and stops using them over time, so either code works; 410 states the intent clearly. We made sure the rule didn't catch real mistyped addresses, which get a normal 404 page instead.

Step 4: Keep the genuine pages

The old site also had a handful of real pages, such as About, Services and a portfolio. Each one now redirects with a single 301 to its new equivalent, so any links and history pass to the new site, with no chains of redirects.

Step 5: Use Search Console carefully

• Check the Security issues and Manual actions reports for warnings, and request a review only after the site is clean.
• Remove the old WordPress sitemap and submit the new one.
• Don't click Validate fix on the spam rows; they disappear as Google recrawls and sees the 410s.
• Use the Removals tool only to hide urgent URLs temporarily, and never enter a prefix that matches your whole site.
• Look at the Links report for spam domains, but use the disavow tool only if there is a manual action for unnatural links.

Step 6: Monitor and be patient

With tens of thousands of URLs involved, clean-up is not instant. Expect the counts in Search Console to fall over weeks as Google recrawls, with the long tail taking longer. Meanwhile, keep an eye on new URLs appearing, server logs and file changes, which would suggest the attacker still has access.

How to lower the risk next time

• Keep the platform, plugins and themes updated, and remove anything unused.
• Use strong, unique passwords and two-factor authentication everywhere.
• Give each person only the access they need.
• Take regular backups stored away from the server.
• Check Search Console regularly; it often shows spam before anyone notices on the site.