Updated: 2026-10-27
You search your own brand name and the third result is your domain, followed by a string of Japanese characters and a price in yen. You click it. Your homepage loads, looking perfectly normal. You click again from Google and land on a shop selling knock-off sneakers.
That is the Japanese keyword hack. Your site is fine for you and broken for Google, and that split is exactly what makes it hard to kill.
What the Japanese keyword hack actually is
Google’s own write-up describes it plainly: the hack creates new pages with auto-generated Japanese text in randomly named directories, and those pages carry affiliate links to stores selling fake brand merchandise. The pages are built to rank in Google Search, not to be seen by you (web.dev, “Fix the Japanese keyword hack”).
The trick is cloaking. The hacked site shows one thing to Googlebot and another thing to a human. Open one of the spam URLs in your browser and you may get a redirect, a page of gibberish, or a “not found” message that looks reassuring and is not. Google’s page lists all three as possible faces of the same hack.
There is a second, quieter symptom: an unknown person may show up as a verified owner of your property in Search Console. Once they are an owner, they can change settings such as sitemaps or geotargeting. Google calls a notice that a stranger verified your site “a strong sign” of compromise.
So the shape of the problem is:
hole in a plugin or a stolen password → injected PHP → thousands of spam URLs → a hijacked sitemap and a fake Search Console owner → Google indexes the spam under your name
Cleaning the files fixes the first half. The index is the second half, and most DIY cleanups stop before they get there.
How to tell if you have it
Three checks, in this order. None of them needs anything installed.
- Search Console → Security Issues. If Google has flagged hacked content, it shows up here. Google’s help page names the categories it uses for hacked sites: malware, code injection, content injection and URL injection (Search Console Help, Security Issues report). The Japanese keyword hack usually lands under content or URL injection; the report itself shows which category applies in your case.
- A
site:search. Typesite:yourdomain.cominto Google and scroll. Look for URLs in folders you never created and titles in a language you do not publish in. Google suggests repeating the search on a second search engine as well. - URL Inspection. Paste one of the suspicious URLs into the URL Inspection tool in Search Console. Because the hack serves Googlebot a different page, this is how you see what Google sees instead of what your browser sees. Older versions of Google’s guide call this step “Fetch as Google”; in today’s Search Console it is URL Inspection.
While you are in Search Console, open Settings → Users and permissions. Any owner you do not recognise is part of the hack (Search Console Help, managing users).
How to fix the Japanese keyword hack, step by step
This follows Google’s own sequence, with the WordPress-specific detail filled in. If you are dealing with a general compromise rather than this specific spam pattern, the broader guide for a WordPress website hacked some other way covers incident response from the first minute.
1. Take a backup of the infected site
Before you delete anything, copy the files and export the database. It feels backwards to save the malware. It is not: if the cleanup breaks the site, you need something to go back to, and the infected copy is also your evidence of how they got in.
2. Remove the fake Search Console owner
In Settings → Users and permissions, open the menu next to the unknown user and choose to remove access. If Search Console warns the user may regain access, they were a verified owner, and you also have to remove their verification token from the site. Until the token is gone, they can simply verify again.
3. Delete the verification tokens
Google notes the tokens can be a plain HTML file in your root folder, or generated on the fly by a rewrite rule in .htaccess. Delete the files, fix the rule, then request a made-up token URL in your browser and confirm it returns a 404.
4. Replace .htaccess
Swap it for a clean default. The hack commonly hides its routing here, which is how the random Japanese directories resolve to real pages. If you never configured an .htaccess yourself and one exists, Google’s advice is to save a copy and delete it.
5. Reinstall WordPress core, plugins and themes
Upload fresh copies of the same versions you run. WordPress.org’s hacked-site FAQ adds a useful detail: do it by SFTP, not with the dashboard’s reinstall button, because the built-in installer overwrites existing files while hacks often add new ones. /wp-admin and /wp-includes can be replaced wholesale; go through wp-content more carefully because your theme and uploads live there (WordPress.org, FAQ My site was hacked).
6. Hunt the leftover PHP
Look for files modified recently, files that are unusually large, and PHP files that are not part of a default install. Google’s guide calls out obfuscated code using functions such as base64_decode and eval, and names index.php and 404.php as common targets. WordPress.org adds the theme’s header.php, footer.php and functions file to the watch list, because a change there runs on every page.
7. Clean the sitemap
Check every sitemap submitted in Search Console. Remove spam URLs from yours, and delete any sitemap you did not create. A sitemap that lists only Japanese spam URLs is the hacker’s, not yours.
8. Make the spam URLs return 404 or 410
The cleaned site should answer every spam URL with “not found”. Google says hacker-created pages that return 404 will fall out of its index with time (web.dev, “Clean and maintain your site”). If you want them out of results faster, the Search Console Removals tool hides a URL for about six months, but only temporarily: the removal sticks only if the page also returns 404 or 410, sits behind a password, or carries noindex (Search Console Help, Removals tool).
9. Check again as Google
Run a few of the old spam URLs back through URL Inspection. A fake “not found” page served to you while Googlebot still gets spam is the oldest move this hack has. You want Google to see the 404, not you.
10. Request a review, once
If the Security Issues report listed a problem, fix every affected page, not just the sample URLs Google shows, then use Request Review in that report. Say what happened, what you did, and what the result was. Google’s guidance is that spam-hack reviews can take up to several weeks, and that you should not resubmit while a request is pending (web.dev, “Request a review”).
A worked example
No client case studies exist on this site yet, so here is a hypothetical walk-through instead of a story.
Say a small WordPress shop finds pages of spam URLs under /a8kq2/-style folders in its site: results. The files look clean on the surface. My agent works it like this:
snapshot → Search Console owners → tokens → .htaccess → core and plugin reinstall → PHP diff → sitemap → 404/410 on the spam pattern → URL Inspection spot-check → review request
The interesting part is usually step six. A plugin that has not been updated in a long time is the likely door, and a single extra file in the uploads folder is the likely engine. Both get flagged in the report, and a human reviews the result before anything is handed back.
Common mistakes
- Cleaning the files and calling it done. The server is clean, the index is not. Until the spam URLs return 404 and Google recrawls them, your brand search still shows yen prices.
- Trusting your own browser. The hack is built to look fine to you. Always check with URL Inspection.
- Forgetting Search Console. A stranger left as owner can resubmit a spam sitemap after you clean up.
- Using the Removals tool as the fix. It is a six-month curtain, not a delete button.
- Not closing the door. If the outdated plugin or the reused password stays, the hack comes back. After cleanup, run through the wordpress hardening steps: updates, unique passwords on every access point, two-step login, file editing disabled in the dashboard.
- Panicking about links. Spam pages can pick up spammy inbound links. Once those URLs return 404, the links point at nothing. Google says most sites never need the disavow tool, because it can decide which links to trust on its own (Search Console Help, disavow links). Read our note on toxic backlinks before you upload a disavow file you did not need.
Do it yourself, or hand it over
My stance: if Google shows only a handful of spam URLs, you have SFTP access, and you are comfortable in Search Console, do it yourself with the steps above. It is tedious, not mysterious.
If the spam runs into the thousands, keeps coming back, or you cannot find where the redirect lives, hand it over. That is what our repair service covers: cleanup, de-indexing and hardening, done by an AI agent pipeline and reviewed by a human before delivery. Your credentials are used for the job and removed afterwards. No ranking promises; Google decides how fast the index heals. Hack cleanup is $79; see pricing.
The hack wants Google to believe your site sells counterfeit sneakers. The fix is just showing Google the 404 your visitors were promised all along.
Wayback Press (waybackpress.com) is an independent restoration and hacked-site cleanup service. Not affiliated with the Internet Archive or the Wayback Machine, nor with the Shift8 open-source “WaybackPress” command-line tool of the same name.