How to Remove Injected Spam Pages from Google Search

You cleaned the WordPress infection, but Google is still showing Japanese spam, fake product pages, casino URLs, or other pages you never created.

That does not necessarily mean the site is still infected. Google may still know about URLs it discovered before the cleanup and has not recrawled yet.

1. Make Sure the Infection Is Gone

Do not use Search Console removals to hide an active infection.

Before working on Google’s results, confirm that the affected URLs no longer serve spam, redirect visitors, or regenerate after cleanup.

If you are still trying to find or remove the infection, start with our Japanese keyword hack cleanup guide.

Also check Google Search Console for unknown owners and spam sitemaps. Remove anything the attacker added before continuing.

2. Decide What Each Affected URL Should Do

3. Check What the URL Returns Now

Test several affected URLs after cleanup.

If you have terminal access, this command shows both the final URL and HTTP status after redirects:

curl -sS -L -o /dev/null \
-w "HTTP %{http_code}\nFinal URL: %{url_effective}\n" \
https://example.com/hacked-url/

A fake spam URL that no longer exists should normally end with:

HTTP 404

or:

HTTP 410

If it redirects to your homepage and ends with HTTP 200, the hacked URL has not really disappeared.

Also watch for soft 404s: pages that display a “not found” message but still return HTTP 200.

4. Find the Spam URLs and Their Patterns

Start with URLs already visible in Google Search or Google Search Console.

You can also use Google to look for obvious patterns:

site:example.com
site:example.com casino
site:example.com "日本"
site:example.com inurl:product

Use site: searches as clues rather than a complete list of everything Google has indexed.

Also check:

• Search Console page indexing reports
• spam or unauthorized sitemaps found during the incident
• server logs where available
• URL patterns discovered during the cleanup

For example, an infection might have created:

https://example.com/spam/ab123.html
https://example.com/spam/cd456.html
https://example.com/spam/ef789.html

If /spam/ was created entirely by the attacker and contains no legitimate pages, the shared prefix can be useful when requesting removal.

5. Use Search Console Removals When You Need Results Hidden Quickly

If hacked URLs are still visible in Google Search, open Search Console → Removals → Temporary Removals and create a new request.

Temporarily Remove a URL

Use this when a hacked URL needs to disappear from Google Search quickly.

The removal lasts about six months. If the URL still returns spam or HTTP 200, it can appear again after the temporary removal expires.

Exact URL or Prefix?

For one hacked URL, remove that specific URL.

Use a prefix only when you have confirmed that every URL beginning with that prefix is unwanted.

For example:

https://example.com/spam/ab123.html
https://example.com/spam/cd456.html
https://example.com/spam/ef789.html

If the entire /spam/ path belongs to the infection, you could use:

https://example.com/spam/

Do not use broad prefixes such as /blog/, /product/, or /category/ unless you genuinely want every matching URL hidden.

Clear an Old Hacked Snippet

If a legitimate page is clean again but Google still shows an old hacked description, use Clear snippet in search.

This removes the current description snippet until Google indexes the page again and generates a new one from the current content.

For an important restored page, also use URL Inspection to confirm the live page is correct and request indexing.

6. Make the Removal Permanent

When Google recrawls a hacked URL, it should find either the restored legitimate page or a real 404/410 response.

For fake spam URLs:

• 404 Not Found is appropriate when the page does not exist.
• 410 Gone is appropriate when you intentionally want to state that the resource is permanently gone.

Both tell Google that the content is no longer available. There is no need to force 410 just because you expect faster removal.

Do not redirect large numbers of hacked URLs to the homepage.

Also avoid broad server rules that return 410 for every request containing a query string. WordPress and its plugins can use legitimate query-string requests.

If thousands of hacked URLs share a pattern, make sure that pattern cannot match legitimate requests before adding any server-level rule.

7. Restore Legitimate Pages Instead of Removing Them

If a real page was hacked, do not return 404 or 410 after restoring it.

Check that the page:

• returns HTTP 200
• contains the correct title and content
• uses the correct canonical URL
• is not accidentally marked noindex
• is included in your sitemap if it belongs there

Then inspect the URL in Search Console, run a live test, and request indexing.

Prioritize important pages that previously showed hacked titles, descriptions, or content rather than requesting indexing for every URL on the site.

8. Submit a Clean Sitemap and Monitor Recovery

Remove spam sitemap submissions and make sure your current sitemap contains only legitimate URLs you want Google to crawl.

Then monitor what happens over the next crawls.

Check whether:

• spam URLs begin disappearing from Search
• fake URLs continue returning 404 or 410
• restored pages regain the correct titles and snippets
• new hacked URL patterns appear
• Google reports soft 404s or other unexpected indexing behavior

If new spam URLs keep appearing after the site was supposedly cleaned, stop treating it as an indexing problem. The infection, a backdoor, or another source of reinfection may still be active.

If that happens, return to the Japanese keyword hack cleanup guide. If you cannot identify the source of repeated reinfection, Securewp also provides a WordPress malware removal service.