SEO spam can exist in Google even when WordPress shows no corresponding posts or pages. That usually means the response is being generated outside the normal content list: by rewrite rules, injected PHP, database-driven cloaking, a compromised plugin/theme or an edge/cache layer.
Start with a URL that Google has actually indexed
Request several affected URLs directly and record status, HTML title, canonical, redirect chain and response headers. Compare logged-in and logged-out requests. If the spam appears only to crawlers or referrals, preserve both variants before changing anything.
Map the response back to a source
- Check whether WordPress resolves the URL to a real object.
- Inspect rewrite and routing behaviour for unexpected catch-all rules.
- Review recently changed PHP and database options capable of injecting output.
- Check CDN or server caches for stale compromised responses.
Pharma spam is one common variant, not the only one
If the indexed pages are drug-related, use the more specific WordPress pharma-hack recovery path. If the response is tied to repeated core or root-file changes, compare index.php reinfection and persistence.
Remove generation logic before cleaning the index
- Preserve representative responses and logs.
- Remove the confirmed writer or routing rule.
- Restore trusted application code and rotate affected credentials.
- Return the correct status for spam URLs and verify canonical pages.
Why mass URL removal is not a fix
Search-engine removals can hide results temporarily, but the URLs can return if the compromised origin still generates them. The durable fix is deterministic clean output from WordPress and the web server.
Verification
Test old spam URLs, new random variants and legitimate content. The unwanted pattern should stop being generated, caches should remain clean and search coverage should decline as crawlers revisit the site.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
The gap between wp-admin and the public response is evidence. Start from affected URLs, not from the post list, and trace the code path that returns 200.
Collect a sample across different spam patterns and dates.
Fetch each URL logged out and as a crawler, recording status, headers and body.
Inspect rewrite rules, auto-prepended files, mu-plugins and active theme entry points.
Search database options and transients for encoded templates or keyword lists.
What must be verified
- Spam samples no longer return malicious content to any tested user agent.
- Unexpected URLs are no longer added to sitemaps or Search Console.
- No hidden loader or database payload returns after cron and restart.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Why don't the spam URLs Google is showing appear anywhere in my WordPress post list?+
These pages are frequently not real WordPress posts at all. The request can be intercepted before the normal template loads, generated on the fly from query strings, or served only to crawlers, so there is no corresponding entry in the dashboard to find.
Is redirecting all the spam URLs to the homepage a reasonable quick fix?+
No. Mass-redirecting to the homepage can preserve bad indexing signals and makes it harder to confirm whether the underlying generator has actually been stopped. The safer path is closing the actual execution point and returning accurate status codes.
Could my hosting or PHP configuration be involved even if my WordPress files look untouched?+
Yes. An auto-prepend compromise works by having the PHP configuration itself load malicious code before WordPress even runs, which means server configuration needs to be checked in addition to WordPress files, themes, and plugins.
How can an admin be sure they're not just missing the spam because they're logged in?+
Conditional cloaking is common in this scenario: administrators are shown normal pages while crawlers and logged-out visitors receive spam content. Fetching each affected URL both logged out and as a simulated crawler, and comparing status, headers, and body, is the only reliable way to see what the public actually gets.