Japanese Keyword Hack: How to Find and Remove It

The Japanese keyword hack is an infection that creates thousands of auto-generated Japanese pages on your domain to sell counterfeit goods through affiliate links. To remove it, take back Search Console ownership, delete the attacker's verification tokens and sitemaps, clean .htaccess and the infected code, then make every spam URL return a 404 or 410 so Google drops it. The order matters, because an attacker who still owns your Search Console property can push the spam pages back into Google within hours of your cleanup.

This guide covers only this one hack. For the first-24-hours plan that applies to any compromise (containment, a forensic backup, rotating credentials), follow my hacked website incident response plan first, then come back here.

What the Japanese keyword hack is and why attackers use it

The Japanese keyword hack is a form of SEO spam that borrows your domain's trust in Google to rank pages that a brand-new domain cannot rank quickly. Google's guide to fixing the Japanese keyword hack (web.dev, Google) describes it as auto-generated Japanese text placed in randomly named directories, for example /ltjmnjp/341.html, and monetised with affiliate links to stores selling fake brand merchandise.

Attackers target established small-business sites for 3 reasons:

• Domain authority: your backlinks and age help spam pages rank far faster than on a new domain.
• Low monitoring: owners rarely run a site: search or read Search Console in Japanese.
• Scale: one injected script generates pages on demand, so a single site produces tens of thousands of URLs.

The damage goes beyond the spam itself. Google's Search Console Help on security issues (Google) explains that hacked content triggers warnings shown to searchers. On top of that, thousands of junk URLs dilute your index and soak up crawling that belongs to your real pages.

How to detect the Japanese keyword hack

Detect the hack by checking what Google sees, not what your browser shows. Google's Security Issues documentation states that "many hackers make changes that are visible only to Google machines," a technique called cloaking. Your homepage looks normal to you while Googlebot receives Japanese spam.

Search Google for Japanese pages on your domain

Run site:yourdomain.com in Google and page through at least 5 pages of results. Then narrow the search with Japanese shopping words, for example site:yourdomain.com 通販 (mail order) or site:yourdomain.com 激安 (cheap). Japanese characters in search results for your domain, with titles you never wrote, confirm the infection.

Read Search Console in the attacker's language

Search Console shows the spam from 3 angles:

1. Performance report: filter queries and pages for Japanese characters or brand names you do not sell. Add a country comparison as well: impressions from Japan on a site with no Japanese customers point straight at the spam.
2. Security Issues report: expand any "Hacked content" issue to see sample URLs. Google notes the list is "just a sample," so the real count is higher.
3. Settings, Users and permissions: look for verified owners you do not recognise. web.dev calls an unknown owner a strong sign of compromise.

Check sitemaps you did not create

Open the Sitemaps report in Search Console and list every submitted sitemap. Attackers add their own sitemap files, or edit yours, so Google discovers spam URLs faster. Any sitemap with an unfamiliar filename or thousands of unknown URLs belongs to the attacker.

Expose cloaked content

Expose cloaked pages with the URL Inspection tool, because it fetches the page from Google's own infrastructure. Paste a suspect spam URL, run a live test, and view the rendered HTML and screenshot. web.dev warns that hackers "try to trick you into thinking the page is gone or fixed when it's still hacked," for example by showing you a 404 while serving Googlebot the spam.

A quick command-line check helps too:

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yourdomain.com/ | grep -i "<title>"

Treat a clean result from curl as inconclusive. Here is the insight most guides miss: Google publishes how site owners can verify that a visitor really is Googlebot (Google Search Central) using reverse DNS or Google's IP range lists. Malware authors read the same documentation. A script that checks the IP, not only the user agent, serves you a clean page however you set your user agent, so URL Inspection is the only test you can fully trust.

How to remove the Japanese keyword hack

Remove the hack in the order Google's web.dev guide sets out, after you take a full backup of files and database. The guide lists these steps, and I add why each one matters.

Step 1: Remove unknown Search Console owners

Open Search Console, go to Settings, then Users and permissions, and remove every owner you do not recognise. Attackers verify ownership so they can submit sitemaps and request indexing of spam URLs, and a rogue owner sees your data and receives your alerts.

Step 2: Delete the attacker's verification tokens

Delete the verification method, or the rogue owner re-verifies automatically. web.dev points to 2 places tokens hide:

• HTML token files: files named like google1234abcd.html in your web root that you did not upload.
• Dynamic rewrite rules: an .htaccess rule that generates any google*.html file on request.

Test the second case by requesting a made-up token URL, for example /google0123456789abcdef.html. A real 404 means no rule is answering. A page that returns the token means the rewrite rule is still live. Also check DNS TXT records at your registrar for verification strings you did not add.

Step 3: Replace every .htaccess file

Find every .htaccess file, including hidden ones in subfolders, and replace each with a clean default copy. web.dev recommends replacing it "with a completely new copy" unless you wrote custom rules. Attackers use .htaccess for both the cloaking logic and the token generator.

Step 4: Remove rogue sitemaps

Delete sitemap files that contain only spam URLs, and remove spam entries from your legitimate sitemaps. Then remove the attacker's sitemaps from the Search Console Sitemaps report.

Step 5: Reinstall the CMS and find the malicious files

Reinstall core files, plugins and themes from official sources, then hunt for what remains. web.dev names the files attackers inject most often (index.php, wp-load.php, 404.php, view.php) and the functions that signal obfuscated code: base64_decode, eval, gzinflate, strrev and rot13. Sort files by modification date and by size to find the ones changed around the time of the attack. On WordPress, follow my WordPress malware removal guide for the database and plugin checks that a file cleanup misses.

Step 6: Verify with URL Inspection

Run URL Inspection again on 5 to 10 spam URLs from different directories. Each one must now return "Not found" to Google, not only to your browser.

How to remove thousands of indexed spam URLs from Google

Make every spam URL return a 404 or 410 status code, and let Google recrawl them. Google's HTTP status code documentation (Google Search Central) states that "all 4xx errors, except 429, are treated the same" and that already-indexed URLs returning them are removed from the index. A 410 carries no special speed advantage in Google's documentation, so pick whichever your server returns most easily.

Do not redirect spam URLs to your homepage. Google's 404 errors help page (Search Console Help) says that redirecting non-existent pages to another page, such as the homepage, is "problematic" and creates soft 404s.

Use the Removals tool for the worst URLs only

The Removals tool hides URLs fast but does not delete them. Google's Removals tool documentation (Search Console Help) states that "a successful request lasts only about six months," after which the URL can reappear unless it returns a 404 or 410, is password-protected or carries noindex. Google also says not to use robots.txt to block the pages, because Google then cannot see the 404.

Use "Remove all URLs with this prefix" when the spam sits in a few directories, for example /ltjmnjp/. This hides thousands of URLs in one request while the 404s take effect.

What about a sitemap of removed URLs

Google does not document a "removal sitemap" as a method for hacked pages. Its sitemap guide (Google Search Central) says Google uses <lastmod> only when it is "consistently and verifiably accurate." A temporary sitemap listing the dead spam URLs with accurate lastmod dates is a recrawl hint, not an instruction. Treat it as a short-term nudge and delete it once the URLs drop out, so it never conflicts with your real sitemap.

How long recovery takes

Recovery runs on 3 separate clocks:

• Security review: Google states a review "can take from a few days to a few weeks" after you request it in the Security Issues report.
• Removals tool: hidden URLs stay out of results for about 6 months, which covers the deindexing window.
• Deindexing: spam URLs drop out as Google recrawls them, and Google crawls known 404 URLs less often over time, so the long tail takes weeks to months on a site with tens of thousands of spam pages.

Reinfection resets every clock. web.dev reports that "20% of hacked sites are hacked again within one day," which is why the backdoor hunt in Step 5 matters more than the visible cleanup. Track organic clicks to your real pages during recovery, and use my guide to diagnosing a website traffic drop if rankings do not return after the spam clears. A site that has been through this usually has wider crawl and index problems, which is the work a technical SEO consultant handles.

Frequently asked questions

Why do I see Japanese characters in Google results for my site?

Japanese characters in your search results mean an attacker has injected spam pages or altered your page titles, which is the Japanese keyword hack. Confirm it with a site:yourdomain.com search and the Security Issues report in Search Console.

Why does my site look normal when Google shows Japanese spam?

The malware uses cloaking, serving spam only to visitors it identifies as Googlebot. Use Search Console's URL Inspection live test to see the page exactly as Google receives it.

Should I redirect Japanese spam pages to my homepage?

No, make spam URLs return a 404 or 410 status code instead. Google treats redirects of non-existent pages to the homepage as soft 404s, which confuses both users and Google.

Does the Removals tool permanently delete hacked pages from Google?

No, a removal lasts about six months. The URL stays out of Google permanently only when it returns a 404 or 410, requires a password or carries a noindex tag.

How long does it take to recover from the Japanese keyword hack?

A Google security review takes a few days to a few weeks after you request it. Thousands of indexed spam URLs take weeks to months to drop out fully, depending on how often Google recrawls them.