What matters first: Google can index malicious pages that do not exist as WordPress posts. The request may be intercepted before the normal template, generated from query strings or cloaked from logged-in administrators.
What this symptom actually tells you
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.
Capture evidence before changing anything
- 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.
Most common causes
- Rewrite interception: Malicious rules route arbitrary paths to a hidden loader.
- Auto-prepend compromise: PHP configuration loads malicious code before WordPress.
- Option-based payload: An autoloaded option stores code or a remote endpoint.
- Conditional cloaking: Administrators see normal pages while crawlers receive spam.
Safe diagnostic and repair sequence
- Preserve server configuration as well as WordPress files.
- Remove the earliest malicious execution point and every persistence mechanism.
- Compare core, plugins and themes with trusted upstream packages.
- Clean sitemaps, return accurate statuses and monitor new indexed URL patterns.
How to choose between the likely causes
Do not treat Rewrite interception and Auto-prepend compromise as interchangeable. Malicious rules route arbitrary paths to a hidden loader. By contrast, pHP configuration loads malicious code before WordPress. Use two checks to separate them: Collect a sample across different spam patterns and dates; and fetch each URL logged out and as a crawler, recording status, headers and body. Those observations usually show whether the next safe move is to preserve server configuration as well as WordPress files or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not redirect every spam URL to the home page. It can preserve bad index signals and hide whether generation has actually stopped.
How to verify the repair
- 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.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.