If the Japanese keyword hack has hit your site, cleaning the files is only half the job. The spam URLs stay in Google’s index after the malware is gone, and they keep appearing under your domain until Google refetches each one and learns it is dead.
This post is about that second half: which removal signal to send, how to use the Removals tool without tripping its two traps, and how to verify the cleanup now that the tool Google’s own guide points you at no longer exists.
Key Takeaways
- The Japanese keyword hack plants autogenerated Japanese spam pages in randomly named directories on your site, monetizes them with affiliate links to counterfeit goods, and cloaks them so crawlers see them and you do not.
- Cleaning the files does not remove the pages from Google. Each spam URL has to return a 404 or a 410 and then be recrawled before it drops out of the index.
- 410 fits a hacker-created URL that never legitimately existed; 404 is fine where a 410 is impractical. Google lists both as making the removal permanent.
- Do not block the spam paths in robots.txt. Googlebot then cannot fetch them, never sees the 404 or the noindex, and the URLs can sit in the index indefinitely.
- The Removals tool is a temporary curtain of about six months. Google’s own documentation tells hacked site owners to point it at the hacker’s URLs and not at the whole site.
- Google’s hack guide still tells you to verify your cleanup with Fetch as Google, which Search Console no longer has. The URL Inspection tool’s live test is the instrument that replaced it.
What is the Japanese keyword hack?
The Japanese keyword hack is a site compromise that creates thousands of autogenerated Japanese-language pages on your domain, usually inside a randomly named directory such as /ltjmnjp/341.html. Those pages are monetized with affiliate links to stores selling counterfeit brand merchandise, and they get shown in Google Search under your name.
Google’s own guide describes it in almost those words, and its description is accurate, so there is no argument to have here:
The Japanese keyword hack typically creates new pages with autogenerated Japanese text on your site in randomly generated directory names (for example, http://example.com/ltjmnjp/341.html). These pages are monetized using affiliate links to stores selling fake brand merchandise and then shown in Google Search.
Google, Fix the Japanese keyword hack
site: search on a compromised domain, with the injected Japanese pages sitting in the organic results next to the site’s real pages. Image credit: Google, “Fix the Japanese keyword hack”, used under the Creative Commons Attribution 4.0 License.Security vendors usually call the same thing Japanese SEO spam, so if you are searching for help you will see both names. A few other traits are consistent enough that most write-ups agree on them, and they are worth knowing because each one is a place you have to look.
- It cloaks by user agent. The code checks who is asking, so a crawler gets Japanese sales text while you get your normal page. That is why your own browser is not evidence on a hacked site.
- It rewrites
.htaccess. A rewrite rule routes those invented filenames to a script, which is how thousands of URLs exist without thousands of files. - It adds its own sitemap. The hack wants the spam pages discovered quickly, so it feeds Google a map of them.
- It hides in obfuscated PHP. Google names
base64_decode,rot13,eval,strrevandgzinflateas the usual giveaways, commonly injected intoindex.php,wp-load.php,404.phpandview.php. - The attacker often verifies themselves in Search Console. Google’s guide says the hacker will “typically add themselves as a property owner in Search Console, to increase profits by manipulating your site’s settings like geotargeting or sitemaps.”
On 30 July 2026, the SEO practitioner Joe Youngblood posted that this hack was moving through WordPress sites quickly and that standard security plugins were missing it. I looked for independent confirmation of the plugin-bypass part and did not find any, so treat that as one practitioner’s report rather than an established fact. The wave itself is real enough that it is worth reading this before it is your problem.
How do I know if my website is hacked?
Run a site:yourdomain.com search and read a few pages deep, then put one of the odd URLs through the URL Inspection tool’s live test. Those two checks take about a minute and they see what your browser cannot, because the hack decides what to serve based on who is asking.
There is a third tell that costs nothing. If Search Console emails you that someone you do not know has verified ownership of your property, treat that as a compromise until proven otherwise.
Clean the files first, because removing URLs from a live infection just refills
Everything below assumes the infection is gone. If it is not, removal requests are pointless, because the hack regenerates URLs faster than you can file them.
I am going to be straight about scope here: we are an SEO consultancy, not a security vendor, and we have never cleaned a hacked site of our own. So this is not a malware removal tutorial, and a half-good one would be worse than none. For that half, work through Google’s own cleanup steps or bring in a security firm. The short version of what that half involves, so you know whether you are ready for this one:
- Take the site offline or lock it down while you work, so the attacker cannot watch you clean and re-infect behind you.
- Change every password and key, including hosting, FTP, database and admin users, because a leftover credential undoes the whole job.
- Remove unknown owners and users from Search Console, since an attacker with owner access can keep steering your geotargeting and sitemaps after you have fixed the files.
- Replace
.htaccesswith a clean copy, because that rewrite rule is what makes the invented URLs resolve at all. - Reinstall core, plugins and themes from official sources rather than trying to spot every edited line by eye.
- Search the files and database for the obfuscated PHP named above, and delete the injected spam posts the hack may have written into your content tables.
Once that is genuinely done, you have a clean site with a dirty index. That is the problem almost nobody writes about, and it is the one an SEO is actually the right person to solve.
Why do the spam pages stay in Google after the files are gone?
Because Google’s index is a stored record, not a live mirror of your server. Deleting the files changes what your site returns; it does not change what Google already holds. Each spam URL keeps its index entry until Googlebot fetches that specific URL again and gets a signal telling it the page is gone.
That is the whole mechanic, and it explains the timeline that frustrates people. You cleaned the site in an afternoon, and Google has thousands of URLs to recrawl, most of them junk it has no reason to prioritize.
So the job splits into two things you control. Send the right signal on every spam URL, and make sure Googlebot can reach that signal.
Should the hacked URLs return 404 or 410?
Use 410 where you can, because a hacker’s directory is exactly the case 410 describes: a URL that was never legitimately yours and is not coming back. Use 404 where a 410 is impractical, which on most CMS setups it will be.
Google’s removals documentation lists both as ways to make a removal permanent, and it does not claim one is processed faster, so neither will I.
Here is the full set of instruments and where each one actually belongs. I have covered the mechanics of the last three in more depth in how to deindex a page from Google; this table is about which one fits a hacked site.
| Signal | Use it when | What Google says about it |
|---|---|---|
| 410 Gone | The URL never legitimately existed on your site, which is true of every hacker-created path. | Listed alongside 404 as a way to remove the page permanently. |
| 404 Not Found | A 410 is impractical, or your platform will not emit one without extra work. | Listed alongside 410, same permanence effect. |
| noindex | The URL genuinely has to keep responding with a real page. Rare during a hack cleanup. | Rated as “less secure than the other methods.” |
| Removals tool | You need the spam gone from search results today, while the 404 or 410 propagates. | “A successful request lasts only about six months.” |
| robots.txt | Never, for this job. | “Do not use robots.txt as a blocking mechanism.” |
That last row is the one that quietly costs people months. Blocking the spam directory in robots.txt feels like the fastest fix, and it is the one move that guarantees the URLs stay indexed.
The reason is simple once you see it. A robots.txt disallow stops Googlebot fetching the URL at all, so it never sees your 404, your 410 or your noindex, and the entry it already holds has nothing to update it. Google states this plainly on the removals page itself, and it is the same trap that keeps ordinary pages indexed after a botched deindexing attempt.
What does the Removals tool actually do on a hacked site?
It hides the URLs from search results for about six months while your real fix propagates. It does not delete anything, and it is step one of a permanent removal rather than the removal itself. Google is unusually direct about using it on a hacked site, and it is worth quoting because almost nobody does:
If your site was hacked and you want to get rid of bad URLs that got indexed, use the URL blocking tool to block any new URLs that the hacker created […]. But we don’t recommend blocking your entire site, or blocking URLs that you’ll eventually want indexed. Instead, clean up the hacking and let us recrawl your site.
Google, Removals and SafeSearch reports tool (the omitted clause is Google’s own example URL)
So the panic move, which is blocking the whole property to make the embarrassment stop, is the one thing Google explicitly warns against. Point the tool at the hacker’s paths only. The step-by-step mechanics of the Removals tool are the same as for any other removal, so I will not repeat them here.
What is worth repeating is the pair of traps sitting in Google’s own warning box on that page, because they change the order you do things in.
- Block first, then delete. Google says that if the URL is unreachable when you file the request, “it will assume that the page is gone, and your block request will expire.” The instinctive order, delete the spam files and then file removals to hurry things along, is backwards.
- If you already blocked before cleaning, unblock and reblock. Google’s permanence checklist includes that step explicitly, and it exists to clear an entry that got recrawled while the block was in place. It is the sort of detail that never appears in hacked-site guides and quietly explains a stubborn URL.
One small thing to notice while you are on that page: Google writes “about six months” in the prose and “180 days” in its own comparison table. Same thing, two numbers, so do not treat the difference as meaningful.
How do you verify the cleanup now that Fetch as Google is gone?
Use the URL Inspection tool and click Test Live URL on the spam paths. A live test fetches the URL right now as Googlebot, which is exactly what you need, because a cached report would still be showing you the infection.
The reason this needs saying is that the highest-ranking guide on this topic tells you to do something else. Google’s own page closes with a verification step built on Fetch as Google, a tool Search Console retired years ago, and the page carries a last-updated date of 1 January 2015.
I am not pointing that out to score a point. Verification is exactly where a scared site owner gives up, and the most authoritative page on the subject sends them to a screen that is not there. The same guide names URL Inspection correctly, much earlier, for the cloaking check, and then forgets about it by the time it matters.
The page’s age shows in other places too. It cites “a recent study” on reinfection rates without naming a study, which on an eleven-year-old page is not a number anyone should be repeating, and it still links the retired google.com/webmasters/tools/ URLs.
Here is the check I would run instead, in this order.
- Collect five to ten of the spam URLs from your
site:search, spread across different injected directories rather than all from one, so a single missed folder cannot pass the test for you. - Run each one through URL Inspection and click Test Live URL. The live test is the whole point; the default view can be weeks old.
- Confirm the live test reports the URL as not found rather than returning a page. If any of them still render, you have missed a file or a rewrite rule and the index work is premature.
- Check the rendered HTML on one that does still resolve, because cloaking means the live test may show you Japanese text on a URL your browser renders normally. That is the fastest confirmation that the infection is still active.
- Submit a clean sitemap and delete any sitemap the hack added. If Search Console throws a fetch error on the new file, the usual sitemap couldn’t fetch causes apply and it is rarely as dramatic as it looks.
- Re-run the
site:search weekly, a few pages deep, and count. That count going down is the only progress signal that means anything.
Why does the indexed page count keep rising after you are clean?
Usually because you are reading the Page Indexing report as if it updated daily, and it does not. We measured this on our own property: the report has been delivering wide multi-day snapshots rather than fresh daily data, so a chart you refresh every morning can show a number that is several days behind whatever your site is actually doing.
A hacked site recovery is the worst possible situation to misread that chart in. You clean everything, you watch the indexed count climb for three more days, and you conclude the cleanup failed. Often it is just the report catching up on crawls that happened before you fixed anything.
The practical rule is to judge recovery on the site: count and on live URL Inspection tests, and to treat the Page Indexing chart as a slow confirmation rather than a live dashboard. If you want the detail on how far behind it runs, I wrote that up in Search Console indexed pages decreased: recount vs real deindexing.
The other thing worth expecting: your legitimate pages may sit in crawled, currently not indexed for a while after a compromise. That is uncomfortable but not unusual while Google reassesses a domain it has just seen serving thousands of spam pages.
Why does WordPress get hacked so much?
Mostly because it is everywhere, and scale attracts automation. Attackers do not target your site specifically; they scan for a known vulnerable plugin version across millions of installs and take whatever answers. That is also why the prevention list is boring and works.
- Update core, plugins and themes promptly, because the scans are looking for versions with published vulnerabilities, and an unpatched plugin is the single most common way in.
- Use unique passwords and two-factor authentication on hosting, FTP, the database and every admin account, so one leaked credential does not hand over everything.
- Remove plugins and themes you do not use, since an inactive plugin still has files on disk and is still scannable.
- Keep offsite backups you have actually restored once, because a backup you have never tested is a guess, and this is not the week to find that out.
- Watch Search Console ownership, and treat any unexpected verification email as an incident rather than a curiosity.
So how long until the Japanese keyword hack spam is out of Google?
Honestly, longer than the cleanup and shorter than it feels, and how long depends almost entirely on whether you sent Googlebot a signal it could actually reach. Sites that 410 the hacker’s paths, leave them crawlable and file removals in the right order tend to watch the site: count fall steadily. Sites that block the directory in robots.txt because it felt decisive can still be sitting on those URLs months later.
The part I would push back on is the idea that this is a security job you hand off and then wait out. The malware removal is a security job, and you should get a professional for it. Everything after it is search work, and if nobody does that work deliberately, the spam pages keep representing your brand in Google long after your server is spotless.
Common questions about the Japanese keyword hack
Is the Japanese keyword hack the same as Japanese SEO spam?
In practice, yes. Google’s documentation calls it the Japanese keyword hack and most security vendors call it Japanese SEO spam, and both names describe the same injected Japanese affiliate pages. If you are searching for help, try both terms.
Can I remove my whole site from Google and start fresh after a hack?
You can, but Google advises against it: its removals documentation says not to block your entire site or URLs you will eventually want indexed. You would be throwing away the index history of every legitimate page to hide a set of URLs you can remove individually.
Do I need a manual action to be lifted after a Japanese keyword hack?
Only if Search Console actually shows one. Many of these compromises are caught before Google issues anything, in which case there is nothing to appeal and the recovery is purely a recrawl. Check the Security Issues and Manual Actions reports before assuming either way.
Work with WpConsults
Still seeing the spam URLs in Google?
If the files are clean and the index will not follow, send me the domain and I will tell you which signal is missing and in what order to fix it.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
