If Google shows Japanese titles and thousands of Japanese pages under your domain, your site has been hit by the Japanese keyword hack, not a translation glitch. A hidden script is generating those pages for search engines only, and they will keep coming back until you remove the code and the backdoor behind it.
The short answer
- Japanese pages in Google under your domain almost always mean the Japanese keyword hack: a server-side script generating cloaked spam for crawlers.
- Deleting the visible pages does nothing. Remove the generator, the backdoor and the stolen credentials first, or the spam returns within hours.
- Don't block spam URLs in robots.txt. Let Googlebot see 404 or 410 Gone, then use Search Console Removals as a temporary stopgap.
- File a reconsideration request only if Search Console shows a manual action, and only after the site is verifiably clean.
Key takeaways
- The Japanese keyword hack uses a hidden server-side script to generate cloaked spam pages that only search engines see.
- Confirm it with site: searches plus Search Console URL Inspection on a spam URL, because your browser shows the clean site.
- Remove the generator, the backdoor and stolen credentials before touching Google, or the spam returns.
- Serve 404 or 410 Gone for spam URLs; robots.txt blocking keeps them indexed longer.
- Deindexing takes days to weeks; ranking recovery can take weeks to months.
Why does Google show Japanese pages for my website?
Google shows Japanese pages for your site because a malicious script on your server creates them and serves them to crawlers. The culprit is the Japanese keyword hack, also known as Japanese SEO spam. The pages advertise counterfeit watches, designer bags, sneakers and pharmaceuticals, with links to affiliate shops the attacker is paid to push.
The choice of Japanese is deliberate, and it is about money. Yahoo Japan, a major search portal in Japan, has historically drawn its web results from Google’s index. Poison Google’s index and you reach Japanese shoppers on both engines without ever touching yahoo.co.jp.
Your domain is the asset being rented out. It already has age, backlinks and trust. A brand-new spam domain gets filtered quickly, while a dentist’s site from 2014 with a clean history ranks the same spam far better, at least until Google catches on.
Translation plugin or hack?
A translation plugin is the explanation only if you installed one, it outputs Japanese versions of your real pages, and the URLs follow your own structure, such as /ja/about/. WPML, Polylang, Weglot and hreflang setups translate content you wrote, with your navigation and branding intact.
The hack looks different. Titles mention products you never sold. URLs look random: numeric paths ending in .html, or query strings like ?xyz=48213. Snippets read like keyword salad about “cheap” luxury brands. If even one Japanese result fits that description, treat the whole site as compromised.
How does the Japanese keyword hack work under the hood?
The spam is usually generated on the fly by one small PHP file, not stored as thousands of real pages. The script holds a list of Japanese keywords and page templates. When a request arrives for a URL it recognizes, it assembles a page with a keyword-stuffed title, filler text and outbound links. A file of a few kilobytes can produce tens of thousands of indexable URLs.
The second half of the trick is cloaking. Before it responds, the script checks who is asking:
- User-Agent: crawlers such as Googlebot or Bingbot get the spam.
- Referer: visitors arriving from a Japanese search result may be redirected to the attacker’s shop.
- Accept-Language or IP: some variants only trigger for Japanese browsers or verified Google IP ranges.
Everyone else, including you in your own browser, gets the normal site. That is why owners so often say “but my site looks fine.” It also explains why many file-signature scanners miss it: the payload may live in the database or an .htaccess rewrite. Google treats this behavior as cloaking and as a strong hacking signal.
How do I confirm the Japanese keyword hack?
Start with a Google search for site:example.com, then add a Japanese word such as site:example.com 通販 (mail order) or site:example.com 激安 (super cheap). Japanese titles in the results confirm the problem publicly. Treat the result count as a rough estimate: site: numbers are not a real inventory of indexed URLs.
Then check what Googlebot actually receives. In Google Search Console, open URL Inspection on one of the spam URLs, run Test live URL and view the rendered HTML. This is the most reliable view, because the request comes from real Google infrastructure and defeats IP-based cloaking.
A quick check from your own terminal compares a normal request with a Googlebot-style one. Use an actual spam URL from your site: results, not the homepage. Cloakers usually trigger only on spam paths, so a homepage comparison can come back identical and falsely reassure you.
curl -s https://example.com/spam-url-from-results > normal.html
curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1)' https://example.com/spam-url-from-results > bot.html
diff normal.html bot.html | headA difference confirms User-Agent cloaking. No difference does not clear you, because cloakers that verify Google’s IPs will still serve your clean page.
Finally, in Search Console check Indexing → Pages for a sudden spike in indexed URLs, Sitemaps for sitemaps you never submitted, and Security & Manual Actions for a hacked content notice. In your access logs, look for Googlebot hitting large numbers of paths your CMS doesn’t have.
| Method | What it shows | What it misses |
|---|---|---|
| site: search | Public proof, sample spam URLs | Exact counts, freshly created pages |
| URL Inspection live test | Exactly what Googlebot is served | Where the code lives |
| curl with Googlebot UA on a spam URL | User-Agent cloaking | IP-verified cloaking |
| Server access logs | Scale, timing, the spam URL pattern | The payload itself |
Where does the Japanese spam code hide on WordPress and Joomla?
On WordPress, the generator usually sits in a modified core or theme bootstrap file, a dropped PHP file in a writable folder, or the database. Check these first:
index.php,wp-blog-header.php,wp-settings.phpandwp-config.phpfor extra include or require lines- The active theme’s and child theme’s
functions.php,header.phpandindex.php wp-content/mu-plugins/, which loads automatically and doesn’t appear in the normal plugin list- Fake plugin folders with plausible names, and PHP files inside
wp-content/uploads/orwp-content/cache/ - Files mimicking core names, such as a stray
wp-includes/wp-tmp.php .htaccessor nginx server blocks that rewrite unknown paths to a PHP file- Database tables:
wp_posts,wp_postmeta,wp_options(large unfamiliar autoloaded values), andwp_usersfor administrators you didn’t create
On Joomla, look at templates/<your-template>/index.php, unknown entries under /components/ and /modules/, the root index.php and configuration.php, .htaccess, and the #__content and #__modules tables. Drupal, Magento and OpenCart sites get the same treatment in their own bootstrap and template files.
Searching for Japanese characters is a fast locator, since your own code rarely contains them:
grep -rlP '[p{Hiragana}p{Katakana}p{Han}]' --include='*.php' /path/to/siteMany generators store keywords encoded, so also search for base64_decode, eval, gzinflate, str_rot13, assert and very long single-line strings. Never run a suspicious file to see what it does. Copy it out for analysis instead.
How do I clean the infection so it stays gone?
Clean in a fixed order, because skipping ahead lets the attacker reinfect you mid-cleanup. This sequence works for WordPress and Joomla alike:
- Take a forensic backup of all files and the database. This is evidence for finding the entry point, not something to restore later.
- Put the site in maintenance mode or restrict access to your IP.
- Change every credential: hosting panel, cPanel, FTP/SFTP, SSH, database user, CMS admins and the email tied to the hosting. On WordPress, rotate the salts in
wp-config.phpto log out every session, including the attacker’s. - Replace, don’t patch, core and extensions. Run
wp core verify-checksumswith WP-CLI to list modified core files, then reinstall core, plugins and themes from official sources. Delete anything you don’t use. - Hunt the backdoor in writable folders and in files with modification times you can’t explain.
- Clean the database: remove spam posts, rogue options, unknown admin users and suspicious cron entries.
- Check the rest of the hosting account. Addon domains, subdomains and forgotten staging copies are usually infected through the same door.
Don’t restore a “clean” backup taken after the compromise began. Cloaked spam can sit undetected for weeks, so last Tuesday’s backup may already contain the backdoor. Our hacked-site cleanup cases show how often that happens.
Why the Japanese pages keep coming back
Deleting pages removes the output, not the machine producing it. Since the spam is generated per request, there is often nothing to delete. Even after you remove the generator, attackers usually leave a second, quieter file that lets them reupload everything later.
Backdoors are small and deliberately boring. They hide in a single line appended to a legitimate file, an image-named PHP file in uploads, or a plugin that does “nothing.” Some reinfect through a scheduled task or a rogue admin account instead. Our write-up on webshells left behind after a PHP exploit shows how these survive a casual cleanup.
Credentials are the other route back. If the attacker used your FTP or panel password, possibly stolen by infostealer malware on your own computer or reused from another breach, they will simply log in again. Scan the PC you manage the site from before setting new passwords on it.
How do I remove the Japanese spam pages from Google?
Return 404 or 410 Gone, and never block the URLs in robots.txt. A robots.txt block stops Googlebot from crawling them, so it never sees they are gone, and the URLs can stay indexed indefinitely. Google’s own hacked-site guidance recommends 404 or 410.
Once the generator is gone, most spam URLs return 404 on their own. If they share a pattern, return 410 explicitly. On Apache, a rule like this one (adapt the regex to your log data) does it:
RewriteRule ^[0-9]{5,}.html$ - [G,L]The [G] flag sends 410 Gone. In practice, 410 URLs tend to drop out faster than 404s. Make sure the pattern cannot match any real page.
| Option | Effect on spam URLs | Verdict |
|---|---|---|
| robots.txt disallow | Googlebot cannot see the status code; URLs may linger | Backfires |
| 404 Not Found | Removed after recrawl | Good |
| 410 Gone | Removed after recrawl, permanent signal | Best for known patterns |
| 200 + noindex or X-Robots-Tag | Works, but keeps thousands of junk URLs alive | Only if a URL must stay live |
| Search Console Removals tool | Hides URLs from results for roughly six months | Stopgap alongside 404/410 |
Then delete any sitemap in Search Console you didn’t create, resubmit your real one, and repeat the cleanup in Bing Webmaster Tools, which has its own removal tools. The spam is often indexed there too.
How long it takes, and when to file a reconsideration request
Removals tool requests usually take effect within about a day. Permanent deindexing depends on Googlebot recrawling each URL and seeing the 404 or 410, which typically takes days to a few weeks, longer on large infections. Expect a long tail of stragglers.
File a reconsideration request only if the Manual Actions report shows a penalty, usually labeled hacked content or pure spam. A Security Issues notice is cleared with a review request. Submit only after the site is verifiably clean: rescan, retest spam URLs with URL Inspection, and confirm nothing new appears for several days. A rejected request can delay the next review.
In the request, state briefly how the attacker got in, what you removed and what you changed. Reviewers want evidence that the entry point is closed, not just that the pages are gone.
Will your rankings recover?
Usually, but not instantly and not guaranteed. Once the spam is out and any manual action is lifted, rankings for real pages typically recover over several weeks to a few months. Recovery is slower if the spam ran for months or security vendors blocklisted the domain, so check the major blocklists and request delisting where needed.
How do I stop the Japanese keyword hack from coming back?
Close the doors the attacker used and add monitoring that sees what Googlebot sees. The baseline:
- Two-factor authentication on the CMS, hosting panel and registrar; SFTP or SSH keys instead of plain FTP
- Unique long passwords in a password manager, and a malware-free admin PC
- Prompt updates for core, plugins and themes, and deletion of anything unused
define('DISALLOW_FILE_EDIT', true);inwp-config.phpso a stolen admin login cannot edit theme PHP- PHP execution disabled in
wp-content/uploads, and a database user with only the privileges the site needs - A web application firewall in front of the site to block exploit attempts against outdated plugins
- File-integrity monitoring and off-site backups you have actually tested
For monitoring, enable Search Console email alerts, run a site: spot-check weekly, and use scanning that covers the database and server-side files, not just the rendered homepage. A website antivirus and firewall protection layer flags file changes and blocks exploits before Google indexes anything.
FAQ
Why does my website show Japanese characters in Google search results?
Your site has been infected with the Japanese keyword hack. A malicious script serves Japanese spam pages to search engine crawlers, so Google indexes them under your domain while human visitors see the normal site.
Why can't I see the Japanese pages when I visit my site?
The spam is cloaked. The script checks the User-Agent, referer or IP and only shows spam to crawlers like Googlebot. Use URL Inspection's live test in Google Search Console on a spam URL to see what Google receives.
Can I just delete the Japanese spam pages?
No. The pages are usually generated on demand, and a backdoor lets the attacker reinstall the generator. Remove the malicious code and backdoor, change all credentials, then let the URLs return 404 or 410.
How long does it take to remove Japanese spam pages from Google?
The Removals tool hides URLs within about a day, for roughly six months. Permanent removal after Google recrawls the 404 or 410 URLs usually takes days to a few weeks, longer for very large infections.
Do I need to rebuild my whole website?
Usually not. Reinstalling core, themes and plugins from official sources, cleaning the database and removing the backdoor is normally enough. A rebuild makes sense only when you can't find the entry point or the site is too old to update.
Can the Japanese keyword hack spread to my other sites?
Yes, if they share a hosting account. Attackers reuse the same access across addon domains, subdomains and staging copies, so check and clean every site on the account.
If the spam keeps returning or you can’t find the backdoor, our team handles malware removal and hack recovery: we remove the generator and the backdoor, close the entry point, and help you get the junk URLs out of Google.