Japanese pages appearing in Google under your domain: the Japanese keyword hack explained

You typed your own domain into Google, or somebody sent you a screenshot, and there they are. Page after page of Japanese text under your business name. Product listings for things you have never sold, in a language you do not speak, all sitting on your website.

Then you opened your site to look, and everything was completely normal.

That combination is the signature of the Japanese keyword hack, and the fact that your site looks fine to you is not reassuring. It is part of how the thing is designed.

What is actually happening to your site

Somebody has got into your website and is using it to run a shop.

Not on your homepage, where you would notice. They have generated thousands of pages at addresses you would never visit, filled them with Japanese product listings, and pointed them at a store selling counterfeit goods. Your domain has years of history and a certain amount of trust with Google. They are borrowing that trust to get their spam ranked, because a brand new domain would not rank at all.

The reason you cannot see it is a technique called cloaking. The site checks who is asking for the page. If it is Googlebot, or a visitor who clicked through from a Google search, it serves the spam. If it is a logged in administrator loading the homepage directly, it serves your normal site. You are, in effect, the one visitor the malware is specifically hiding from.

The owner is usually the last person to find out, and it is not because they were not paying attention. The infection is built so the owner is the last person to find out.

How to confirm it in five minutes

Three checks, none of which require any technical skill.

1. Search your own site

In Google, search for site:yourdomain.com. This lists what Google has indexed for your domain and nothing else. Scroll. If there are Japanese pages, you will see them, and the result count at the top is often the first clue: a ten page brochure site does not have 40,000 indexed pages.

2. Check Search Console

Open Google Search Console and look at two places. Security Issues will often say “Hacked: Content injection” or similar. Pages under Indexing will usually show a sharp climb in indexed pages starting on a specific date, which is roughly when it happened.

If you do not have Search Console, set it up now. It is free, and without it you are guessing about what Google can see.

3. Look at your site the way Google does

Take one of the spam URLs from the site: search and open it in a private browsing window, having first clicked through from the Google result rather than pasting the address. Because you arrived from Google and are not logged in, you will often see the spam page that your normal browser refuses to show you.

Use Search Console’s URL Inspection tool on the same address for the definitive answer, because that shows you exactly what Googlebot receives.

How it got in

Almost always a plugin or theme that had not been updated.

Most of these infections belong to a family called Balada Injector, which has been running since 2017 and has compromised over a million WordPress sites. It works through publicly disclosed vulnerabilities in popular plugins. Once a vulnerability is announced, automated scanners begin sweeping the whole web for sites still running the old version. The gap between disclosure and mass exploitation is often measured in hours.

Nobody chose you. A scanner found a version number it recognised.

Balada is also unusually persistent. It typically creates administrator accounts, plants multiple backdoors in different places, and installs its own scheduled tasks. That is why sites get cleaned and then reinfected a week later: somebody removed the spam pages and missed the four other things holding the door open. We described that pattern in detail when we found a live infection on a client site, including a backdoor hiding in a folder that does not appear anywhere in the WordPress dashboard.

Why this is an SEO problem, not just a security one

This is the part that surprises owners, and it is the part that costs the money.

Deleting the malicious files removes the infection. It does not remove the thousands of spam URLs Google has already indexed under your domain. Those pages will start returning errors, which is correct, but they sit in the index for a while regardless. Meanwhile:

• Your crawl budget has been spent on spam rather than your real pages
• Search Console is full of errors that make genuine problems impossible to spot
• Your sitemap may have been replaced or added to
• Google may have applied a manual action, which does not lift on its own
• Your actual pages have been competing for attention with 40,000 junk ones

A security company will hand you back a clean site. That is a genuine and necessary piece of work, and it is also only half of what you needed. The other half is getting the index cleaned up and the rankings back, which is search work.

Being both is the reason our malware removal service includes the recovery rather than treating it as a separate project.

The step almost everyone misses: rogue Search Console owners

This is the first thing Google itself tells you to do, and it is the one we most often find has been skipped. It is also why some sites get cleaned properly and are compromised again a fortnight later.

When an attacker gets into your site they frequently add themselves as a verified owner in Google Search Console. They do it by dropping a Google verification file in your site root, or by adding a rewrite rule to .htaccess that generates verification files on demand. The rule looks something like RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L], and it means any token Google asks for is answered automatically.

The effect is that even after you have removed every malicious file, they still hold a verified line into your Search Console. They can read your data, submit sitemaps, and request removal of your real pages.

What to do:

1. In Search Console open Settings then Users and permissions and read the ownership list. Remove anybody you do not recognise.
2. Open Verification details and check how each owner verified. Remove the tokens belonging to anyone you have just removed.
3. Delete stray google*.html files from your site root that you did not put there.
4. Check .htaccess for the rewrite rule above and remove it.

Do this before you request a review, not after.

Cleaning it up properly

The order matters more than the individual steps.

1. Take a copy before you change anything. Including the database. You are preserving evidence, not making a backup to restore.
2. Find every affected file. Compare WordPress core against clean originals, check the theme, check mu-plugins, and check wp-content/uploads, which should never contain a single PHP file. Sort by modification date and look for anything changed on a day nobody touched the site. Obfuscated payloads usually announce themselves through a handful of functions: base64_decode, eval, gzinflate, str_rot13, strrev and preg_replace.
3. Check the database. Injected content frequently lives in the options and posts tables rather than in files. A file-only cleanup leaves it running.
4. Remove the accounts. Filter Users by Administrator and remove anything you did not create. Check for accounts with odd registration dates.
5. Remove the scheduled tasks. Balada leaves cron entries that reinstall the payload. Miss these and it comes back on a timer.
6. Close the entry point. Update everything, and work out which plugin was the way in. If you cannot identify it, assume the worst and update or remove aggressively.
7. Rotate everything. Passwords, and the security keys in wp-config.php, which invalidates any session the attacker still holds.
8. Check your sitemaps. These hacks frequently add their own sitemap file, or inject thousands of spam URLs into yours, which is how Google found the pages so quickly. Delete any sitemap you did not create and regenerate your real one.
9. Then deal with Google. Submit removals for the worst of the spam URLs, resubmit your clean sitemap, and request a review in Search Console if a security issue or manual action is listed.
10. Confirm from outside. Run the site through Google’s Safe Browsing site status page, Sucuri SiteCheck, VirusTotal and Quttera. Each catches slightly different things, and a clean result across all four is considerably more convincing than a clean result from your own security plugin.

Restoring an old backup is tempting and usually wrong. It puts the site back to a point where the vulnerable plugin is still installed and still vulnerable, and you lose whatever legitimate content you have published since.

How long recovery takes

Honest ranges, not promises.

• The cleanup itself: usually hours rather than days for a standard site.
• Search Console security warning: typically days after a successful review request, provided the site is genuinely clean when they check.
• Spam URLs leaving the index: weeks. Thousands of pages do not vanish at once, and Google recrawls them at its own pace.
• Impressions and rankings: commonly several weeks to a few months, depending on how long the spam was live and how much of it was indexed.

The single biggest factor is how long it ran before anyone noticed. A fortnight is very recoverable. Eight months of indexed spam is a longer road.

The pharma hack is the same thing wearing a different coat

If your spam pages are in English and selling pharmaceuticals rather than Japanese and selling handbags, everything above still applies. The pharma hack uses the same cloaking, the same entry points and the same persistence tricks. Occasionally it is subtler, injecting keywords into your existing page titles and meta descriptions rather than creating new pages, so what you see in Google is your own page title with a drug name bolted onto it.

Same problem, same fix, same two halves.

Frequently asked questions

Will my rankings come back?

In most cases yes, provided the cleanup is thorough and the search side is handled as well as the files. Sites that were established before the hack tend to recover reasonably well. What does not recover well is a site that gets cleaned three times because the entry point was never closed.

Do I need to disavow the links?

Usually not. The problem is spam pages on your own domain rather than bad links pointing at you. Disavowing is the wrong tool for this and can cause harm if used carelessly. Deal with your own site first.

Can I just delete the pages in Search Console?

The removals tool hides URLs from search results for about six months. It is useful for stopping the bleeding while you work, and it is not a fix. If the underlying infection is still there it will simply generate more pages. Use it as first aid, not as treatment.

Why does it keep coming back?

Because something was missed. In our experience it is nearly always one of four things: an administrator account left in place, a scheduled task that reinstalls the payload, a backdoor in mu-plugins or the uploads folder, or the original vulnerable plugin still sitting there un-updated.

My host cleaned it and it is still in Google. Is it still hacked?

Not necessarily. Index removal lags the cleanup, so seeing spam URLs in Google a week after a clean is normal. Check whether they still load. If they return an error, the cleanup worked and you are waiting on Google. If they still serve spam, the cleanup did not.

How much does this cost to fix?

For a standard WordPress site, a straightforward cleanup starts at £70. A full engagement, where we clean the site, close the entry point and handle the search recovery, is typically around £395. You get a fixed figure before anything starts.

---

Found Japanese pages under your domain?

We deal with these regularly. We will remove the infection, find and close the way in, and then do the part most cleanups skip: getting the spam out of Google and your rankings back.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n