The Japanese Keyword Hack: Find It, Clean It, Get Reindexed

If Google is showing Japanese product listings under your domain name, your site has been hit with URL injection — the hack creates thousands of spam pages on your server, links them from a fake sitemap, and serves them only to Googlebot. The fix has three phases, and most cleanup guides only cover the first two.

Phase one: confirm it, because a site: search that looks infected and a server that is actually infected are not always the same thing. Phase two: remove the files, the backdoor that planted them, and the fake Search Console account the attacker almost certainly added. Phase three — the one that gets skipped — is getting the spam URLs out of Google’s index, which is a separate job with its own tooling and its own timeline. Cleaning the server does not clear the index. Those pages will keep showing up in search results for weeks after your site is clean unless you explicitly deal with them.

Expect a day of hands-on work and two to six weeks before search results look normal again.

What the Japanese keyword hack actually does to your site

The attacker gets write access to your filesystem — almost always through a vulnerable plugin — and then does four things:

• Drops PHP files that generate spam pages on request, usually thousands of them, under paths that look plausible for your site
• Writes or modifies a sitemap file listing those URLs, so Google discovers them fast
• Adds rewrite rules in .htaccess so the spam URLs resolve
• Verifies themselves as an owner in Google Search Console, so they can submit the sitemap and watch the indexing themselves

The pages sell counterfeit goods in Japanese. Your real pages are usually untouched — which is why owners find out from a customer or a traffic collapse rather than from anything visibly broken. The hack is monetising your domain’s accumulated trust, so it has no reason to break your homepage.

The scale is worth naming. Patchstack’s State of WordPress Security in 2026 counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025, up 42% year over year: 91% in plugins, 9% in themes, six in core. 46% had no patch available at the point of public disclosure, and for heavily targeted flaws the weighted median time from disclosure to mass exploitation was five hours. This is not a hack that requires anyone to target you specifically.

How to confirm you have the Japanese keyword hack

Three checks. Do all three — each one catches something the others miss.

Search your own domain in Google

Run site:yourdomain.com and page through the results. Narrow it with site:yourdomain.com 通販 or site:yourdomain.com 激安 (“mail order” and “bargain”) to get a count fast. One thing to skip: older guides suggest Google’s cache: operator to see what Googlebot was served. It was retired in 2024 and no longer works.

Check the Security Issues report in Search Console

Google classifies this as Hacked: URL Injection — new pages created on your site, as opposed to content injection, which modifies pages you already had. The report lists sample URLs, the fastest way to learn the path pattern the attacker used.

While you are in Search Console, open Settings → Ownership verification and look at the full list of verified owners. An account you do not recognise is the single clearest confirmation you have been compromised, and it needs to come out before anything else, because an attacker with verified ownership can resubmit the spam sitemap after you clean up.

Test for cloaking with URL Inspection

Most of these infections serve clean content to browsers and spam to Googlebot, so a spam URL you open in Chrome may 404 while Google sees a full spam page. Put the URL into the URL Inspection tool and run a live test — it fetches as Googlebot and shows the HTML Google actually receives. If the live test shows spam and your browser shows a 404, you have cloaking, and your browser is not a valid cleanup check.

Where the infection actually lives on the server

Start by sorting every file by modification time — find . -type f -mmin -20160 -ls | sort -k 8 lists everything touched in the last 14 days — then check these places.

For file content, the markers are obfuscation functions: eval, base64_decode, gzinflate, str_rot13, preg_replace with the /e modifier, and assert.

grep -rEl --include="*.php" "eval\s*\(|base64_decode|gzinflate|str_rot13|assert\s*\(" .

That returns false positives — some legitimate plugins use base64 for data encoding — so read what you find rather than deleting on sight.

Cleaning it without leaving the backdoor behind

The order matters here. Deleting spam files first and hunting the backdoor later means you get reinfected while you are still working.

1. Take a full backup first, infected as it is — you will want it if you delete something you needed.
2. Verify core and plugin files against official checksums. WP-CLI does this directly:

   wp core verify-checksums --include-root
   wp plugin verify-checksums --all

   The core command compares your files against WordPress.org’s md5 list, and with --include-root it also warns about non-WordPress items sitting in the root directory. The plugin command only covers plugins hosted on WordPress.org — premium plugins cannot be checked this way and have to be reinstalled from the vendor to be sure.

3. Replace, do not patch. Delete wp-admin and wp-includes entirely and reinstall core. Reinstall every plugin and theme from source. Hand-editing an infected file leaves whatever you did not notice.
4. Replace every .htaccess with a clean default rather than editing out the bad lines.
5. Remove the attacker’s verification token — the stray HTML file in your root, or a rule in .htaccess that serves one dynamically — and then remove their account in Search Console.
6. Delete the fake sitemaps and resubmit your real one.
7. Rotate everything: all admin passwords, the database password in wp-config.php, hosting and FTP/SSH credentials, and the salts in wp-config.php (generate fresh ones from the WordPress.org secret-key service). New salts invalidate every existing login session, including the attacker’s.
8. Block PHP execution in uploads. If your host runs Apache, add this as wp-content/uploads/.htaccess:

   <Files *.php>
       Require all denied
   </Files>

   On nginx the equivalent goes in the server block: location ~* /wp-content/uploads/.*\.php$ { deny all; }. This one rule neutralises the most common reinfection path.

If this is happening right now and the clock matters, our first-60-minutes guide for a hacked WordPress site covers the triage that comes before any of this. If you would rather not do it yourself, send us the domain and hosting access and we will do the cleanup and the reindexing as one job — the second half is where most DIY cleanups stall.

Getting the spam pages out of Google’s index

This is the half that guides skip, and it is the half your traffic depends on. A clean server with 8,000 spam URLs still indexed is still a site that ranks for counterfeit handbags.

You have four tools, and they do different jobs.

The Removals tool is a curtain, not a delete. Google’s documentation is explicit that it only blocks the URL from appearing in results for about six months, and that Google may keep crawling it. If you rely on it alone, the spam reappears in roughly half a year. Pair it with a 410 every time. Note also that robots.txt alone will not get a URL removed — blocking the crawl stops Google from seeing that the page is dead, which keeps it in the index longer.

Request the review last. Google states that requesting a review while the site is still compromised “can cause longer turnaround time for the next request, or even get you marked as a repeat offender.” Verify with a live URL Inspection test on several known spam URLs first — if the live fetch still returns spam, you are not clean, whatever your browser shows.

Reviews take days to weeks. Google’s own stated range for hacked-content reviews is “a few days to a few weeks.” There is no way to accelerate it, and resubmitting does not help.

How long recovery actually takes

Ranking recovery is the uncertain one. Sites caught within days usually return to roughly where they were; sites that sat infected for months sometimes do not fully recover. Nobody can promise you a number here, and anyone who does is guessing.

One side effect worth checking while you wait: thousands of generated spam pages put real load on the server, and sites often come out of an infection measurably slower than they went in. If yours still feels sluggish after cleanup, the usual causes of a slow WordPress site are worth ruling out before you assume lingering malware.

Why cleaned sites get reinfected

Reinfection within a week or two is common, and it is almost always one of these five:

• The entry point was never found. You removed the spam but not the vulnerable plugin version that let it in. If you cannot name the vulnerability, assume it is still there.
• A second backdoor survived. Attackers plant several, in different places, deliberately. This is why reinstalling beats patching.
• A rogue admin account remained. Check wp_users directly in the database, not just the WordPress admin screen — some infections hide the user from the UI.
• Credentials were not rotated. If the attacker had FTP or database access, cleaning files changes nothing.
• Restoring from an infected backup. If the infection predates your oldest backup, restoring reinstalls the hack.

Preventing the next one

Given that nearly half of disclosed vulnerabilities have no patch when they go public, and heavily targeted ones reach mass exploitation in hours, a monthly update habit is not a defence. What actually reduces exposure:

• Delete plugins and themes you are not using — deactivated is not uninstalled, and the files are still reachable
• Deny PHP execution in wp-content/uploads permanently
• Enforce two-factor authentication on every administrator account
• Run file-integrity monitoring so unexpected file changes alert you in hours instead of being found by a customer
• Read the Security Issues email alerts from Search Console — often the earliest warning — and audit the verified-owners list quarterly
• Keep backups long enough to have a restore point predating a slow-burn infection

Our WordPress maintenance checklist covers the ongoing version of this — the update cadence, the integrity checks, and the monitoring that catches an injection in hours.

The short version

Confirm with a site: search, the Security Issues report, and a live URL Inspection test — cloaking makes your browser unreliable. Clean by replacing rather than editing, and treat the backdoor and the attacker’s Search Console ownership as the real targets. Then run the index cleanup as its own project: prefix removal for speed, 410s for permanence, a temporary sitemap to force recrawling, review request last. Budget two to six weeks.

If your site is currently serving Japanese spam to Google and you want it handled end to end — cleanup, hardening, and the reindexing work that follows — get in touch with the domain and we will tell you what we find. We will give you the entry point in writing, not just a clean scan.