Quick Summary: How I Removed 50,000+ Hacked Spam URLs From Google
This cleanup worked because I did four things in the right order:
- Confirmed the hack and mapped the URL patterns.
- Used Search Console removals for short-term triage.
- Returned hard removal signals for the hacked URL patterns.
- Cleaned the real infection and closed the reinfection points.
If your hacked site is generating thousands of spam URLs, deleting files alone usually won’t fix the search-side damage.
When a client opened Google Search Console, the numbers were brutal:
- Valid pages: 142
- Spam pages: 49,800+
This was not a small SEO cleanup. It was a large-scale hacked-site recovery.
The site had been hit with Japanese SEO spam. Google had discovered tens of thousands of junk URLs, while the real site only had a small number of legitimate pages. On the surface, the site still looked mostly normal. In search, it looked like a spam farm.
In this case study, I’ll show exactly how I handled it: how I diagnosed the patterns, how I used Search Console for triage, why I chose server-side 410 responses for this case, how I cleaned the database damage, and what I hardened afterward so the spam did not come right back.
If you’re dealing with this right now, start with my Japanese SEO spam removal service or my full WordPress malware removal service.
Why This Case Needed More Than a Normal Search Console Cleanup
I’ve handled Japanese SEO spam cases before. In one earlier recovery, I documented how we cleared 242,000 Japanese spam pages from a hacked WordPress site. In that case, Search Console removals played a bigger role.
This case was different.
At this scale, manual URL-by-URL cleanup was not the real answer. Even prefix removals only help when the spam lives under obvious folders. On a hacked site with multiple URL patterns, spam pages, and infected real pages, Search Console becomes a triage tool, not the full recovery plan.
This screenshot matters because it shows the first layer of response: reduce visibility fast, then fix the root cause properly.
Step 1: Confirm the Japanese Keyword Hack and Find the Real URL Patterns
The first job was not “remove URLs.” The first job was to understand what Google had actually indexed.
Use a simple site search first
I started with:
site:example.com
That immediately showed the pattern. Google had indexed spam pages with Japanese text, gambling phrases, and fake product-style URLs. Some lived under obvious folders. Others followed numeric or generated patterns such as:
/detail/837492837/pages/random-file.html- other junk paths generated by the malware
If you only check the homepage, you can miss this kind of infection completely. If you check search results, the problem usually becomes obvious fast.
For a broader walkthrough, see my guide on how to fix the Japanese keyword hack in WordPress.
Then I used the Search Analytics API to pull large samples
For a case this large, the Search Console interface alone is too limiting. I used the Search Analytics API to pull a large sample of affected pages and queries so I could identify patterns instead of guessing.
Important detail: I use the API here as a pattern-finding tool , not as perfect forensic truth. When you group by page and query, Search Console data can be partial. That is still fine for this job, because I was looking for the main URL shapes I needed to block and clean.
1. Open the API explorer
I used the Google Search Analytics API explorer and authenticated to the property.
2. Run a broad query
I used a request shaped like this:
{
"startDate": "2023-01-01",
"endDate": "2025-02-19",
"dimensions": ["QUERY", "PAGE"],
"rowLimit": 25000
}
3. Export, filter, and build a working list
Once I had the response, I exported the data to CSV and filtered it by the patterns I had already seen in search results: Japanese keyword terms, casino language, fake product folders, and junk HTML pages.
That gave me a practical cleanup list. Not every hacked URL on the site. Not every URL Google had ever tested. But enough to identify the patterns that mattered.
Step 2: Use Search Console Removals as Triage, Not as the Whole Fix
This is where a lot of people get stuck.
Search Console removals are useful. I still use them. But they are a temporary visibility tool , not a permanent hacked-site recovery plan.
If the infection created obvious directories like /odr/, /mbr/, or /pages/, I can use prefix removals to get immediate relief while I work on the permanent fix.
How I use prefix removals in large hacks
- Open Search Console → Removals.
- Click New Request.
- Select Remove all URLs with this prefix.
- Submit the infected directory pattern, such as
https://example.com/pages/.
This helps when the spam is concentrated in a folder. It buys time. It does not solve the hack by itself.
Important: I do not rely on removals alone. If the malware is still active, the spam URLs can come back or new ones can be generated.
Step 3: Why I Chose 410 Responses for This Case
Once I had the patterns, I needed a permanent server response for the spam URLs.
For this case, I chose 410 Gone.
Why? Because these were not real pages I planned to restore later. They were hacked URLs that should never exist again. I wanted a clean, explicit “this is intentionally gone” signal, and I wanted to deliver that signal before WordPress even loaded.
That said, I don’t treat 410 as magic. If a clean 404 setup is easier on a particular project, I’ll use that. The real win here was not the number itself. The real win was returning a clear permanent status at the pattern level and doing it server-side.
If you want the deeper SEO explanation, read my guide on 404 vs 410 for hacked and deleted URLs.
Step 4: How I Implemented the 410 Rules
There are two ways I handle this, depending on the site owner’s comfort level and hosting setup.
Method A: WordPress-level handling
If someone is not comfortable editing server rules, I can use a WordPress plugin that supports regex-based rules and 410 responses.
This is safer for non-technical site owners, but it is slower under heavy bot traffic because WordPress still has to load before the rule runs.
Method B: Server-level handling
For this client, I used Apache rules in .htaccess because I wanted the requests blocked before WordPress and PHP did unnecessary work.
Here is the simplified pattern logic:
<IfModule mod_rewrite.c>
RewriteEngine On
# Block common spam terms
RewriteRule .*casino.* - [R=410,L]
RewriteRule .*slot.* - [R=410,L]
RewriteRule .*poker.* - [R=410,L]
# Block fake product detail URLs
RewriteRule ^detail/([0-9]{10,15})$ - [R=410,L]
# Block malicious folders
RewriteRule ^odr/.* - [R=410,L]
RewriteRule ^mbr/.* - [R=410,L]
RewriteRule ^pages/.*\.html$ - [R=410,L]
</IfModule>
On very large infections, this kind of pattern-based response can do two useful things at once:
- cut down wasted crawl and bot traffic
- give search engines a consistent dead-end signal for hacked URLs
If your server is not Apache, use the equivalent logic in Nginx, at the CDN/WAF layer, or wherever you control server responses safely.
Step 5: My Temporary “Cleanup Sitemap” Tactic
This is the part most people find unusual, so let me explain it carefully.
Normally, a sitemap is for URLs you want search engines to crawl and understand as real pages. In a hacked cleanup like this, I sometimes create a temporary cleanup sitemap of the affected spam URLs that are already returning the right dead-end response.
Why? Because on large hacked sites, I sometimes want to surface those exact URLs for recrawl faster instead of waiting for Google to rediscover them naturally.
So in this case, I created a temporary file such as sitemap-spam.xml with affected URLs I wanted Google to revisit. When Googlebot requested them, it hit the permanent removal response I had already deployed.
I want to be very clear here: this is not my default sitemap strategy for normal SEO work. It is a tactical move I sometimes use during large hacked-site cleanup jobs to accelerate recrawling of dead hacked URLs. After the cleanup phase, I remove that temporary sitemap and go back to a normal sitemap setup.
If you want to understand how these spam URLs get hidden in the first place, read my hidden links malware guide.
Step 6: The Site Wasn’t Just Generating Spam URLs — Real Pages Were Also Infected
The fake URLs were only half the problem.
One of the client’s legitimate service pages was ranking with a Japanese title in Google. That meant the damage had crossed into real metadata.
I checked the database in phpMyAdmin and reviewed the SEO-related values stored in wp_postmeta. In this case, the attacker had injected Japanese title data into the page’s Rank Math-related metadata. I cleaned those rows and restored the correct English titles.
This is why I never stop after deleting files. On SEO spam jobs, the database often contains part of the real damage.
Related reading:
What Happened in the First 72 Hours
Once the hacked patterns were mapped, the temporary removals were in place, the server rules were active, and the database cleanup was done, the change was fast.
- Day 1: Server load dropped sharply because bots stopped hitting thousands of junk URLs through WordPress.
- Day 2: Search Console started reflecting the dead-end responses and the visible spam footprint began to fall.
- Day 3: The Japanese titles stopped dominating branded search results, and the legitimate titles started reappearing.
This is not a universal guarantee for every hacked site. Crawl timing always varies. But in this case, the combined approach moved much faster than “delete files and wait.”
If you want another large-scale example, read how I removed 10,500 SEO spam URLs from Google Search.
Step 7: Post-Hack Hardening So the Spam Doesn’t Come Back
A cleanup is incomplete if the attacker can still get back in.
After the search-side damage was under control, I hardened the environment:
- Rotated all access points: not just WordPress passwords, but hosting, FTP/SFTP, database, admin email, and any connected infrastructure accounts.
- Changed WordPress salts: this forced active sessions out.
- Enabled 2FA for admin accounts: I do not like leaving a cleaned site protected by password-only access.
- Disabled dashboard file editing: so WordPress could not be used as an easy PHP editor if an admin account was compromised again.
- Blocked PHP execution in uploads: because the uploads directory is a common persistence point on hacked WordPress sites.
- Reviewed logs and update gaps: because a Japanese SEO spam infection is rarely the whole story.
After cleanup, this checklist is also worth following: what to do after fixing a hacked WordPress site.
FAQ
What is the Japanese Keyword Hack?
It is a hacked-site SEO spam attack where attackers inject or generate large numbers of spam pages, often using Japanese text, gambling terms, counterfeit product terms, or fake product-style URLs. The goal is to abuse your domain’s trust in Google.
Why does my site look normal to me while Google shows spam?
Because many of these infections use cloaking. Human visitors may see the normal site, while Googlebot or search-result visitors get the spam version, the hacked URL, or the polluted metadata.
Should I use 404 or 410 for hacked spam URLs?
For permanently dead hacked URLs, either can work. In this case, I preferred 410 because the patterns were clearly hacked and intentionally retired, and I wanted a very explicit server response. The bigger issue is consistency and making sure the malware is actually gone.
Can I remove 50,000 hacked URLs using Search Console alone?
No. Search Console helps with temporary suppression and visibility management, but it does not replace cleaning the malware, fixing the server responses, and stopping reinfection.
How long does it take for spam URLs to disappear from Google?
It depends on crawl frequency, site health, and whether the infection is fully cleaned. In this case I saw meaningful movement inside 72 hours, but I never promise that exact timeline on every site.
Final Takeaway
If your hacked site has 500 spam URLs, you may be able to get away with a lighter cleanup workflow. If it has 50,000+, you need to think in patterns, not pages.
That means:
- pattern-based diagnosis
- temporary search triage
- server-side permanent responses
- database cleanup
- post-hack hardening
That is what saved this site.
Need help with a hacked site like this?
If Google is still showing Japanese spam under your domain, or your site has tens of thousands of junk URLs indexed after cleanup, I can fix both the malware and the search-side damage.
Fix My Japanese SEO Spam Problem
Or start with my full WordPress malware removal service.
Top comments (0)