How I check what a Japanese keyword hack did to a site's Google results

What does a Japanese keyword hack look like in Google?

It looks like your site, speaking Japanese. The hack creates new pages of auto-generated Japanese text in randomly named folders, and Google finds and indexes them like any other page on the domain. Google's guide to the hack starts with the Security Issues report in Search Console, then a site: search on the domain, looking for unusual URLs.

The fix has two halves, and they belong to different people. Someone has to remove the malware and close the hole it came in through. Then somebody has to clear up what the hack did to your search results, which is what my Google penalty recovery services cover, and that's the half I do.

The spam pages can also be cloaked, so a visitor sees the normal site while Googlebot gets the Japanese text. Google's guide points to the URL Inspection tool for that, because it shows what Google received.

Who cleans the site, and what do I need before I start?

A security specialist or your host cleans the site. I don't remove malware or harden servers, because pulling spam URLs out of Google while the hole's still open just means new ones keep appearing.

What I need is short: full user access to the Search Console property, ideally a Domain property; the specialist's written confirmation that the site is clean and the entry point closed; and the date the hack was first noticed, so I can line the Performance report up against it. If there's no Search Console property at all, that's the first job, because the Security issues report and the review button both live there.

Remove owners you don't recognise. Google's guide says that if a new owner you don't recognise has been added in Search Console, you should revoke their access as soon as possible, and remove the verification token they used, often an HTML file in the site root or an .htaccess rule faking one. I check Settings, Users and permissions before anything else, because an unknown owner sees every report I'm about to work from.

What should the spam URLs return once they're gone?

A 404 or a 410. Google's documentation says it doesn't index URLs that return a 4xx code, and indexed URLs that start returning one get removed. It treats every 4xx except 429 the same way, so I use a 410 where the server can match a whole spam folder easily, and a 404 everywhere else.

The robots.txt block is the one people reach for, and it backfires. Google says robots.txt isn't a way to keep a page out of Google, and a blocked URL can still appear in results. The crawler has to reach the spam URL to learn it's gone.

Then I test every URL on the list with a browser user agent and with Googlebot's. A spam URL that 404s for one but returns 200 for the other means the cleanup isn't finished, and it goes back to the specialist.

How does the Security issues review work?

It's a button, but what you write behind it matters. Once every issue is fixed across the whole site and the fix is tested, you select Request Review in the Security issues report. Google's help says the request should explain the exact issue, describe the steps taken and document the outcome.

So I write it from the evidence: the URL patterns, the date the entry point was closed, how many spam URLs now return a 404 or 410, and what changed in the sitemaps and robots.txt. It's short and it doesn't argue. Once Google has checked the site is fixed, it removes the 'This site may be hacked' message.

How long does Google take to drop the spam pages?

There's no fixed number, and I won't invent one. Google's documentation gives three separate clocks. Each 4xx URL is dropped once Google recrawls it and sees the error, so every spam URL goes on its own schedule. The Security issues review takes several days or weeks, Google says, and it asks owners not to resubmit while one is pending. The Removals tool hides a URL for about six months, which is why I only use it for the worst few while the 404s do the real work.

So I track it rather than promise it: spam URLs moving into Not found (404) in the Pages report week by week, and the Japanese queries fading in Performance. If real pages start slipping into discovered or crawled but not indexed, that status has its own diagnosis, and it isn't always the hack. I can't promise when traffic comes back, and nobody truthfully can.

How do I stop the Japanese keyword hack coming back?

Closing the hole is the specialist's side, but I don't finish a job without asking about it. Google's guide to the Japanese keyword hack cites a study finding that 20% of hacked sites are hacked again within one day, and its checklist is plain: work out how the site was hacked, change the passwords for hosting, FTP and the CMS, turn on two-step authentication, and keep the CMS, plugins and themes updated.

My own last check is Search Console again, a few weeks on: no unknown owners back in Users and permissions, and no new Japanese queries in Performance.