Search results show casino, pharmaceutical or counterfeit-product pages on your domain, but WordPress Posts and Pages contain nothing similar. The content may be generated only for search crawlers, created through rewrite rules, stored outside normal post types or already removed while the search index remains.
Separate a current infection from an outdated search result before requesting mass removals.
Preserve examples from search
Record several exact result URLs, titles, snippets and the date they were seen. Use Search Console exports where available rather than clicking every suspicious result.
Do not search only with site:example.com and treat the approximate count as an inventory. It is useful for discovery but not a complete or stable measure.
Avoid opening spam destinations on a normal logged-in browser. Use a controlled analysis environment.
Request each URL under different conditions
Record the request method, status, body and time for an authorised visitor comparison. A synthetic user-agent or referrer variation is a test condition, not proof of what Google received.
Possible outcomes include:
- spam content still returns
200; - normal homepage content is served for every unknown URL;
- the URL redirects selectively;
- the payload is gone and returns
404or410; - a CDN serves an old infected response.
These outcomes require different cleanup and indexing actions.
Inspect rewrite and routing layers
A request can be transformed before WordPress finds a post. Review .htaccess, Nginx configuration where accessible, hosting-panel redirects, Cloudflare rules and unexpected PHP files in the document root.
Search for conditions based on user agent, referrer, query string or requested path. Preserve suspicious rules before removing them.
Do not replace .htaccess with a generic file until you record legitimate redirects, security rules and multilingual routing.
Search beyond ordinary posts
Inspect custom post types, trashed content, database options, widgets, menus and plugin tables. Review unexpected administrator accounts and recent database changes.
Malware may generate responses directly from an injected plugin or wp-config.php without creating a WordPress post at all. Compare core files with the matching official WordPress release and inspect unknown must-use plugins.
Do not run a blind database search-and-delete for words such as “casino.” A legitimate article, order note or translation could contain the same term.
Determine whether the infection is historical
If every recorded spam URL now returns a clean 404 or 410, the active payload may already be gone. That does not prove the site is safe. Review files, database, users, scheduled tasks and logs for the original entry and persistence.
Check Search Console security issues, manual actions, indexed pages and crawl activity. A removed infection can remain visible in results until recrawled.
Do not create empty WordPress pages for each spam URL. That turns invalid paths into more 200 responses.
Return honest status codes
Removed spam URLs with no replacement should usually return 404 or 410, not redirect to the homepage. A global soft-404 response can keep confusing search engines and visitors.
Keep legitimate URL patterns and translations intact. If a malicious rewrite captured a broad prefix, test normal pages under the same prefix before removing it.
Submit clean sitemaps and use Search Console validation/removal tools according to the current situation. Temporary removal is not a malware cleanup.
A missing URL and an old search result are different observations
We ran an original local HTTP exercise on 25 October 2026. Two deliberately simple pages returned identical “page not found” text, but different statuses. These are benign fixtures on a loopback server, not infected pages or observations of Google’s index.
GET /missing → 404; page-not-found body
GET /friendly-error → 200; identical page-not-found bodyThe text alone could not distinguish the responses. The second example illustrates an error page delivered with a success status; it does not establish that Google has classified a particular URL as a soft 404. Google’s HTTP status documentation explains the indexing distinction. Save the status with the body and collection time.
For each reported spam URL, keep three observations separate: the result seen in Search, the indexed inspection and its last crawl, and the current response collected under documented conditions. Google’s URL Inspection guide distinguishes indexed information from a live test. A successful live test is not a whole-site security audit or an indexing guarantee.
A useful incident row contains the exact URL, search observation date, indexed crawl date if available, current request method/time, first status, redirect destination as restricted text, response source and unresolved checks. If the URL now returns 404, record that bounded fact. It does not prove the entry route or persistence has been removed elsewhere.
Keep technical cleanup and search visibility as separate workstreams. Google’s Removals documentation describes a temporary search block, not a way to disinfect the server. Do not submit a broad prefix without checking which legitimate pages it would cover.
If the response changes with visitor conditions, continue with the guide to WordPress redirects affecting visitors but not the administrator. To request a WordPress SEO spam assessment, send a few exact public URLs, dates and redacted evidence. The assessment should define current exposure, persistence review, legitimate-content protection and the separate search follow-up.
Verify content and index recovery
After cleaning confirmed payloads and closing the entry route, retest example URLs as ordinary visitors and crawler-like requests. Confirm no new spam URLs appear in logs or Search Console.
Monitor indexed-page patterns over subsequent crawls. Search recovery takes time; avoid repeatedly changing status codes and redirects.
When specialist cleanup is appropriate
Request an assessment when spam content appears only to crawlers, URLs are generated without WordPress posts or index growth continues after deletion. Provide sample public URLs and Search Console screenshots without passwords.
The work should prove whether content is live, remove code and database persistence, return correct statuses and support search recovery without deleting legitimate material.
To coordinate the cleanup and search follow-up, use the WordPress SEO spam report and URL inventory template to connect each candidate with evidence, an approved decision, an owner and a later check.