Google is indexing spam pages from my website - how do I stop it?

If Google is indexing spam pages from your website that you never created, the problem is probably not an ordinary SEO mistake. Your WordPress installation may be compromised, allowing an attacker to serve fake pages to search crawlers or redirect visitors through your trusted domain.

The first sign is often a site:example.com search filled with casino, pharmaceutical, cryptocurrency, adult or foreign-language results. Google shows your domain, but the titles and descriptions are unrelated to your business. Clicking a result may open a spam website, while visiting your homepage directly appears normal.

Removing URLs from Google is not the first step. You must stop the server from producing the spam, identify the entry point and remove persistence. Otherwise, deleted URLs will return and new ones will continue to appear.

Symptoms of a WordPress SEO spam infection

Common indicators include:

• unfamiliar results in a site:example.com search,
• Japanese, Chinese or unrelated English titles under your domain,
• casino, pills, loans or cryptocurrency keywords,
• hundreds or thousands of new URLs in Search Console,
• unknown paths such as /product/cheap-pills-123,
• redirects that happen only when arriving from Google,
• a sitemap containing pages you did not create,
• Google Ads suspending the destination for malicious software,
• sudden crawl activity and increased server load,
• search snippets that differ from the page visible to you.

The infection may be conditional. Attackers frequently show spam only to Googlebot, mobile visitors, first-time users or traffic with a search-engine referrer. This cloaking makes the incident difficult to reproduce from an administrator's usual browser.

How attackers create indexed spam pages

The attacker wants to borrow the reputation of an established domain. A legitimate business website may rank and get crawled faster than a newly registered spam domain. Malware therefore creates dynamic pages, hidden links, fake sitemaps or conditional redirects under the compromised domain.

Typical techniques include:

• generating HTML based on any requested URL,
• inserting thousands of posts into the database,
• submitting a malicious sitemap,
• returning different output to Googlebot,
• loading page content from a remote command server,
• using a stolen admin account to publish real WordPress pages,
• scheduling a cron task that recreates deleted spam,
• modifying .htaccess to route missing paths through a malicious PHP file.

Conditional redirects use similar techniques. Our guide to WordPress redirect malware explains how referrer and user-agent checks hide malicious behavior.

Indicators of compromise to inspect

Suspicious files may appear in locations such as:

wp-content/uploads/2026/07/index.php
wp-content/cache/sitemap-cache.php
wp-content/mu-plugins/seo-helper.php
wp-includes/class-feed-old.php
.well-known/cache.php

Potentially dangerous PHP patterns include:

base64_decode(...)
gzinflate(...)
eval(...)
file_get_contents('https://unknown-domain/...')

These functions are not proof on their own. Context matters: the file location, package origin, surrounding code, owner, timestamp and requests reaching the file.

In the database, inspect:

• unexpected records in wp_posts,
• unusual slugs and post types,
• scripts or encoded values in wp_options,
• administrator accounts,
• active plugin settings,
• cron events,
• sitemap configuration.

Server access logs can reveal when the first spam URL appeared, which PHP endpoint created content and whether a vulnerable plugin route received suspicious POST requests.

How to investigate step by step

1. Run a site:example.com search and save representative spam URLs.
2. Open them normally, in private browsing and with a mobile user agent.
3. Use Search Console URL Inspection to compare Google's rendered version.
4. Review the Pages, Sitemaps and Security Issues reports.
5. Check every submitted sitemap and robots.txt.
6. Find PHP files in uploads, cache and mu-plugins.
7. Verify WordPress core files against official checksums.
8. Audit plugins, themes, users, options and cron events.
9. Search access logs around the first appearance of the spam.
10. Identify whether the entry point was a vulnerable component, stolen password or hosting account.

A scanner reporting clean does not close the investigation. Read why Wordfence can report a clean site while malware remains.

Removing the infection safely

Create a forensic backup of the current state before changing files. This copy preserves evidence for comparing timestamps, database records and logs. It is not necessarily a safe restore point.

Then:

• quarantine suspicious files,
• replace WordPress core with an official clean package,
• reinstall required plugins and themes from trusted sources,
• delete unused components,
• remove spam records and injected scripts from the database,
• remove unknown administrators,
• inspect .htaccess, wp-config.php and must-use plugins,
• rotate WordPress, hosting, SFTP, database and API credentials,
• regenerate WordPress salts,
• clear application, server, CDN and browser caches.

Do not delete every file containing base64 or eval without review. Some legitimate packages use similar functions. Blind deletion can break the website while leaving the actual backdoor untouched.

Removing spam URLs from Google

Clean the infection first. Spam URLs should then return an honest 404 or 410 status. Avoid redirecting thousands of meaningless paths to the homepage; Google may treat those responses as soft 404s.

After cleanup:

• generate a clean sitemap,
• submit it in Search Console,
• request indexing for important legitimate pages,
• use the Removals tool only for urgent temporary hiding,
• monitor whether new spam URLs appear,
• verify response codes and canonical tags,
• keep checking server logs for requests to removed paths.

Search Console removal does not delete content from your server and is temporary. If a malicious URL still returns 200 OK, it can be indexed again.

Common mistakes that prolong the incident

Blocking spam paths in robots.txt is a common mistake. It prevents Google from recrawling those URLs and seeing the new 404 or 410 response. A robots rule does not remove indexed content and does not stop the malware generating it.

Redirecting every spam URL to the homepage is also counterproductive. It gives search engines no clear signal that the unwanted content is gone, can create soft 404s and may add unnecessary load. It can also hide the fact that malicious routing still handles arbitrary paths.

Other frequent mistakes include:

• relying only on the Search Console Removals tool,
• trusting one malware scanner as a final verdict,
• deleting a malicious sitemap without finding its generator,
• removing every recently modified file without analysis,
• ignoring server cache and CDN output,
• rotating only the WordPress password,
• deleting access logs to free disk space,
• restarting paid traffic before conditional behavior is tested.

Before reactivating advertising, test the destination from different networks, devices and referrers. Conditional malware may activate only with advertising parameters, a mobile user agent or a first-time visitor cookie.

How long does Google take to remove the spam?

There is no universal deadline. Important URLs may refresh within days, while thousands of low-value spam paths can take weeks to disappear. Crawl frequency, consistent HTTP responses and whether the infection continues creating URLs all influence the process.

Track the estimated number of spam results, newly discovered Search Console pages, 404 and 410 responses, suspicious paths requested by Googlebot and legitimate sitemap processing. A site: query is useful sampling, not a complete inventory.

Recovery is becoming stable when no new spam paths appear, old paths consistently return a removed status, and file, user and database monitoring shows no new compromise activity.

Preventing the spam from returning

A durable setup includes:

• timely managed updates,
• vulnerability monitoring,
• strong password rules and multifactor authentication,
• a minimal number of admin accounts,
• file and user-change monitoring,
• HTTP request logging,
• frequent off-site backups,
• removal of unused plugins and themes,
• regular Search Console reviews.

Backups are essential for recovery but do not block an attacker. The WordPress security FAQ explains how backup frequency, monitoring and active protection serve different purposes.

When to call an incident responder

Get expert help when thousands of URLs are involved, spam returns after deletion, Google Ads or Safe Browsing flags the domain, important sales pages are affected, or the original entry point remains unknown.

WebShield investigates files, database records, users, cron events and HTTP logs to find both the visible spam and the compromise path. For a business-critical incident, review the SOS recovery options.

Final validation checklist

Close the incident only after malware and backdoors are removed, the entry point is patched, every affected credential is rotated, spam URLs return an appropriate removed status and a clean sitemap is submitted. Continue monitoring newly discovered URLs, file changes and suspicious HTTP requests for several weeks. One clean search result is not proof that the generation mechanism cannot return.

Conclusion

When Google indexes spam pages from your domain, fix the compromised website before trying to clean the search results. Remove persistence, close the entry point, make fake URLs return 404 or 410, submit a clean sitemap and monitor for recurrence. Search Console can accelerate recrawling, but it cannot disinfect WordPress.

• Google
• WordPress
• SEO spam
• malware