Why Cleaning WordPress Malware Does Not Remove Spam Pages From Google

A website can be malware-free today while Google continues showing hacked pages for weeks or months.

This confuses many website owners.

They clean the WordPress installation, run another malware scan, open the homepage, and see that everything looks normal.

Then they search Google and find:

• Japanese product titles
• Gambling pages
• Pharmaceutical keywords
• URLs they never created
• Content that is not visible in WordPress
• Random parameters such as ?p=23932 or ?q=98237492

The natural reaction is:

If the malware is gone, why is Google still showing the spam?

Because malware cleanup and Google index cleanup are two different processes.

I recently handled a case involving approximately 242,000 unwanted URL variations. The complete investigation is available in my WordPress SEO spam recovery case study.

Here is the most important lesson from that cleanup.

Problem one: the hacked website

The first problem exists on the server.

The attacker may have added:

• Malicious PHP files
• Backdoors
• Fake plugins
• Hidden administrator users
• Database injections
• Modified .htaccess rules
• Malicious cron events
• PHP files inside the uploads directory
• Scripts that fetch spam from an external server

This is the active security incident.

Until it is fixed, the website may continue producing new spam URLs.

Problem two: Google already knows the URLs

The second problem exists in Google’s crawl and index systems.

Google may have already discovered the hacked URLs through:

• Internal links created by malware
• Malicious XML sitemaps
• External spam links
• Generated archive pages
• Search-engine cloaking
• Previous crawls of the infected site

Cleaning the malicious code does not erase Google’s memory of those URLs.

Google needs to revisit them and receive an appropriate signal.

That signal may be:

• 404 Not Found
• 410 Gone
• A legitimate redirect to a relevant replacement
• A valid noindex response in cases where the page still exists

For completely fake hacked URLs, I normally prefer 404 or 410 rather than redirecting everything to the homepage.

Why the website can look normal

SEO spam often does not affect every visitor equally.

Malicious code may change its response based on:

• User agent
• Referrer
• Cookie
• IP address
• Device
• Search-engine crawler
• Requested URL pattern

For example, the owner may open:

https://example.com/

and see the real homepage.

Googlebot may request:

https://example.com/jp/fake-product/

and receive a generated product page.

The owner may never see that route inside WordPress admin because the page does not exist as a normal post.

It may be dynamically generated by PHP.

Why fake product pages appear

Japanese keyword hacks commonly promote products through compromised domains.

A hacked result may contain:

• Japanese product names
• Prices
• Review text
• Shopping descriptions
• Product structured data
• Unrelated images

The website may not sell any of those products.

The attacker is borrowing the domain’s reputation and crawl history.

This is why searching only the WordPress Posts screen is not a complete investigation.

Step 1: stop new spam from being created

I always begin with the server and application.

The investigation normally includes:

• Comparing WordPress core files with clean originals
• Checking plugins, themes, and must-use plugins
• Inspecting root and nested .htaccess files
• Searching the database
• Reviewing WordPress administrators
• Checking scheduled tasks
• Examining access logs
• Rotating compromised credentials

The site should not be considered clean simply because one scanner reports no malware.

Scanners are helpful, but manual investigation is often needed to find persistence mechanisms.

Step 2: collect examples of the hacked URLs

After stopping the infection, I collect URLs from multiple sources.

Google searches

site:example.com
site:example.com inurl:jp
site:example.com filetype:html
site:example.com casino

These searches do not provide an exact index count, but they can reveal visible patterns.

Google Search Console

Useful reports include:

• Indexing → Pages
• Performance → Search results
• Security Issues
• Manual Actions
• Sitemaps

Server logs

Logs can reveal URLs that bots continue requesting even when they no longer appear prominently in Search Console.

Search Analytics API

The API can help export pages and queries that received impressions.

It is useful performance data, but it should not be treated as a complete list of every URL Google knows.

Step 3: look for patterns, not individual URLs

The incident I investigated included patterns like:

/?a=839472938
/?q=739284729
/?p=23932
/pages/random-product.html
/jp/fake-category/
/products/23860

Removing these one by one would not scale.

Instead, I grouped them by:

• Directory
• Query parameter
• Numerical range
• File extension
• Spam keyword
• URL structure

A few repeatable patterns explained a large part of the 242,000 URL variations.

Step 4: return a real removal status

Once a pattern was confirmed to be malicious, the server returned 410 Gone before WordPress loaded.

A simplified Apache example:

ErrorDocument 410 "<h1>410 Gone</h1><p>This spam URL has been permanently removed.</p>"

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{QUERY_STRING} (^|&)(?:a|q)=[0-9]{5,}(&|$) [NC]
RewriteRule ^ - [G,L]

RewriteRule ^(?:pages|jp)(?:/|$) - [G,L,NC]
RewriteRule ^products/[0-9]+(?:/|$) - [G,L,NC]

</IfModule>

These rules are examples, not universal signatures.

A rule must be based on patterns verified on the affected site.

Why I did not redirect everything to the homepage

A fake Japanese product page does not have a meaningful replacement on the website.

Redirecting it to the homepage would communicate that the unrelated resource moved there.

It may also result in soft-404 behaviour.

My general decision process is:

• Relevant replacement exists: use 301
• Resource never existed or no longer exists: use 404
• Confirmed malicious resource deliberately removed: 410 can be appropriate
• Page still exists but should not appear in search: consider noindex

The response should match what actually happened.

Step 5: use Search Console removals carefully

Google Search Console can temporarily hide urgent results.

For a single URL, submit a specific request.

For an entirely malicious directory, use:

Remove all URLs with this prefix

Examples:

https://example.com/jp/
https://example.com/pages/
https://example.com/products/

Do not submit a broad prefix if it includes legitimate pages.

Search Console removal is temporary. It does not replace the server response.

Step 6: submit a clean sitemap

After the cleanup, the normal sitemap should contain only URLs that should appear in Google.

That generally means:

• Canonical URLs
• HTTP 200 pages
• Real content
• Preferred HTTPS versions
• Preferred hostname versions

It should not contain:

• Hacked URLs
• Redirects
• 404 pages
• 410 pages
• Internal search pages
• Random query parameters

The clean sitemap helps Google focus on the legitimate website structure.

Step 7: allow Google to recrawl the spam URLs

It can be tempting to block the hacked paths in robots.txt.

That can be counterproductive if Google needs to see their 404 or 410 response.

Googlebot should be able to request the URL and confirm that it is gone.

The spam URLs should be removed from the legitimate sitemap, but not hidden from the removal response.

How long does recovery take?

The malware cleanup and the Google cleanup do not follow the same timeline.

The security work may be completed quickly.

Google still needs to:

1. Revisit the affected URLs
2. Observe the new status
3. Process the changes
4. Update search results

The time varies based on:

• Number of URLs
• Crawl frequency
• Internal and external links
• Sitemap history
• Server stability
• Whether new spam continues appearing

This is why I avoid promising that hundreds of thousands of URLs will disappear immediately.

Signs that the recovery is working

I monitor:

• Declining spam-query impressions
• More hacked URLs reporting 404 or 410
• Correct titles returning
• Legitimate pages recovering visibility
• Googlebot requesting the old spam paths
• No new spam patterns
• No returning malicious files
• No new unauthorized users

An increase in reported 404 or 410 URLs is not always bad after a hack.

It may show that Google is revisiting the malicious URLs and receiving the intended response.

Final takeaway

A successful WordPress SEO spam cleanup has two parts:

Security recovery

• Remove malware
• Remove backdoors
• Close the entry point
• Secure accounts
• Stop new URLs

Search recovery

• Collect unwanted URLs
• Identify patterns
• Return 404 or 410
• Use temporary removals when needed
• Submit a clean sitemap
• Monitor recrawling

Stopping after the malware scan leaves half the job unfinished.

The full investigation—including the URL patterns, .htaccess firewall, Search Console removals, and sitemap strategy—is documented in my complete 242,000-URL recovery case study.