Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Visible Symptoms Initial Triage

Google Shows Spam Pages That Do Not Exist in WordPress

Trace indexed spam URLs that are absent from WordPress through cloaking, rewrites, database injections, cached responses and deleted payloads.

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

Check the HTTP status and response body as a clean visitor. Then compare an authorised request with a search-engine-style user agent and referrer. Do not impersonate services to access systems you do not own.

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 404 or 410;
  • 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.

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.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident