Open Google, search for your own website, and instead of your real pages you see page titles in Japanese, advertising products you have never sold. Visit your site yourself and everything looks normal. That confusing combination is the usual sign of the Japanese keyword hack, a search spam attack that fills a site with fake Japanese pages under the site owner’s own domain name.
This guide explains the attack in plain language, shows you how to confirm it before you change anything, then walks through removal and the Google cleanup in order. It is written for site owners who may not be technical. Where a step needs server access, the guide says so plainly, so you know when to ask your host or a professional for help instead of guessing.
If your site has just been hacked in a general way and you need first response steps right now, start with our WordPress hacked emergency recovery guide. That guide covers containment for any hack. This article goes deep on one specific spam attack and, just as importantly, on cleaning up Google after the site itself is clean.
What the Japanese keyword hack is
The Japanese keyword hack is a form of search spam. Attackers break into a website, usually through an outdated plugin or theme or a weak administrator password, and place code on the site. That code creates fake pages, almost always in Japanese and almost always advertising counterfeit branded goods, and serves them to search engines under the hacked domain.
The attackers are borrowing your domain’s reputation. A new, unknown domain would struggle to rank for those product terms. Your established domain, with its history in Google, gives the fake pages a head start. When people click a fake result, they are sent toward the attacker’s shop, not yours.
Three features make this attack different from ordinary vandalism, and all three explain why it is often found late.
Cloaked: visitors see one thing, Google sees another
The injected code checks who is asking for a page. An ordinary visitor, and usually the site owner, sees the normal site. A search engine crawler sees the fake Japanese pages. This is called cloaking. It is the reason owners often learn about the attack from a customer, or from a Search Console message, rather than from browsing their own site.
Generated on demand: the pages may not exist as posts
In many cases the fake pages are not stored as WordPress posts you can find and delete in your dashboard. The code generates a page whenever a matching address is requested. That is why deleting a few visible pages, or looking for them in your post list, does not fix the problem. The generator itself must be removed.
Self-promoting: it invites Google in
The attack often adds its own sitemap, a list of the fake addresses, and sometimes even adds the attacker as a verified owner in Search Console so the sitemap can be submitted. Google is therefore actively invited to crawl the spam, which is how so many fake addresses can appear in search results in a short time.
How to confirm it before you change anything
Do these checks before deleting files or changing settings. Several other problems can look similar from the outside, and the fixes are different. Confirmation also gives you a record of what was wrong, which helps later when you ask Google to review the site.
Check 1: Search Google for your own domain
In Google, search for site:yourdomain.com, using your real domain in place of yourdomain.com. Browse through several pages of results. Look for titles in Japanese, product names you do not sell, and addresses in folders you do not have. A handful of odd results can be a clue. A large block of results sharing one strange address pattern is a strong sign.
You can narrow the search with a Japanese word commonly used in these spam pages, or with a brand name you do not sell. Do not click through to buy anything from a fake result, and do not enter any payment details. You only need to see that the results exist.
Check 2: Open Search Console and look at the Pages report
If your site is connected to Google Search Console, open the Pages report under Indexing. An infection often shows as a sudden jump in indexed or discovered addresses, with many addresses sharing a pattern you do not recognise. Also check Security issues and Manual actions. Google may already have flagged the site, and any message there tells you what Google has seen.
Also open Settings, then Users and permissions. If you see an owner or user you do not recognise, note it down. Do not remove it yet if you are still gathering evidence, but keep it on your list for the cleanup stage, because an unknown owner can resubmit a spam sitemap even after you clean the site.
Check 3: See the page the way Google sees it
Take one fake address from the search results and paste it into Search Console’s URL Inspection tool. Run the live test and view the tested page. This shows you what Google actually receives for that address. If the tested page shows Japanese spam while your own browser shows your normal page or a not-found page, cloaking is confirmed.
An external scanner such as Sucuri SiteCheck can give a useful first opinion from outside the site. Treat it as a first opinion only. A scanner sees the public side of the site, not your server files or database, where the deeper parts of an infection live. A clean scan result is reassuring but not proof that the site is clean.
First, protect the site and keep a copy
Before cleanup, take a full backup of the site files and the database, and label it clearly as the infected copy. Keep it somewhere safe and offline if you can. You will not restore this copy live, but it preserves evidence of how the attacker got in, and it gives you a way back if a cleanup step goes wrong.
If you can, put the site in maintenance mode or restrict access while you work, so visitors stop meeting the hacked version and you are not cleaning a moving target. Tell your hosting provider what has happened. Hosts deal with hacked sites regularly and may be able to supply a clean backup from before the infection, or run a scan of their own.
Ask your host whether they hold a backup from before the infection date. Restoring a known clean backup, followed immediately by updating everything, is often the safest route for a site owner without server experience. Restoring a backup made after the infection simply restores the infection, so the date matters. Even after a clean restore, you must still close the entry point, or the attack can succeed again.
Remove the infection: files, database, and accounts
Cleanup has three places to cover, and skipping any one of them is the most common reason the spam returns. Work through them in order, and keep notes of everything you remove or change.
Replace core files, plugins, and themes with fresh copies
Do not try to repair infected core files line by line. Replace WordPress core with a fresh copy from the official source, and reinstall every plugin and theme from its trusted source. Delete anything you do not actively use. An inactive plugin is still code on the server that an attacker can reach, so unused plugins and themes should go, not just sit deactivated.
Look in particular at the uploads folder. That folder should hold media files, not executable code files. Any code file sitting in uploads deserves a close look, and your host or a security plugin scan can help you judge it. Also check the main configuration files and the site’s rewrite rules file for lines you did not write. If you are unsure about a line, ask your host before deleting it, because removing a genuine line can break the site.
Clean the database and remove hidden accounts
Search the database for injected content: posts or pages you did not create, options holding code-like text, and scheduled tasks you cannot account for. A scheduled task that restores files is a classic persistence trick, and it is easy to miss if you only clean files. If you do not have database access or you are not comfortable working in it, this is the point to ask your host or a professional for help rather than guessing.
Open the Users screen in WordPress and check every administrator account. Delete any administrator you do not recognise, and demote any account that should not hold that role. Attackers often create a second administrator account so that closing the original entry point does not lock them out.
Rotate every credential, and do it after the backdoor is gone
Change passwords for WordPress administrators, the hosting control panel, file transfer accounts, and the database, and rotate the security keys in the configuration file, which logs everyone out. Do this after the main cleanup, not before it, because a remaining backdoor can simply collect the new passwords. Switch on two-factor authentication for administrator accounts where it is offered, and use long, unique passwords stored in a password manager.
After cleanup, repeat the confirmation test from earlier: fetch a former spam address the way Google sees it, using URL Inspection. If what Google receives now matches what an ordinary visitor sees, the cloaking is gone. If it does not, something is still generating pages, and a file or database entry has been missed.
Close the entry point so it does not come straight back
Removal without closing the entry point is only half the job. Work out, as best you can, how the attacker got in, and close that route.
- Update WordPress core, every plugin, and every theme, and keep them updated. This attack usually enters through a known weakness in outdated code, not through a novel trick.
- Delete abandoned plugins and themes, and never install nulled or pirated premium plugins. Those copies are a common source of injected code.
- Use unique administrator passwords with two-factor authentication, and give each person only the role they need.
- Ask your host about blocking code execution in the uploads folder and about a firewall or security plugin suited to your hosting plan.
If the same spam returns after a careful clean, stop guessing and get help. A returning infection means something is still present: a missed backdoor, an unrotated credential, or a vulnerability that was repaired rather than replaced. Continuing to clean the same way will keep producing the same result.
For background on what a maintenance routine should cover once the site is clean, see our WordPress maintenance checklist, and for the security services that support this kind of cleanup, see our WordPress security services and WordPress maintenance plans.
Clean up Google: owners, sitemaps, and spam addresses
Removing the infection does not remove the fake addresses from Google’s index. Until Google revisits each address and sees that it is gone, your domain can still show Japanese spam in search results. This stage is where many cleanups stall, so work through it in order.
Remove unknown owners and rogue sitemaps
In Search Console, open Settings, then Users and permissions, and remove any owner or user you do not recognise. Then remove their verification method: a verification file in the site root, a domain record, or a rewrite rule that creates the file on demand. If you remove the owner but leave the verification method, the access can be reclaimed.
Next, open Indexing, then Sitemaps, and delete any sitemap you did not submit. Check the site’s robots file for a sitemap line pointing at a file you do not recognise, and remove that line. Then submit your real sitemap, the one that lists only your genuine pages, so Google recrawls real content.
Make spam addresses return not found or gone
Once the generator is removed, former spam addresses should return a not found response or a gone response, so Google drops them as it recrawls. A gone response is a stronger signal that the address was removed on purpose, and it can help Google drop the address sooner. If the fake addresses share one address pattern, your host can often return the gone response for the whole pattern, which is far more practical than handling addresses one by one.
Do not redirect spam addresses to your homepage. A redirect looks like an attempt to keep the value of those addresses, it confuses the signal, and it slows removal. Do not block the spam addresses in the robots file either. If Google cannot crawl an address, it cannot see that the address is gone, and the address may stay indexed longer. Let Google crawl them and see the not found or gone response.
Use the Removals tool for the worst addresses, then request a review
For the most damaging addresses, or a whole spam folder prefix, use the Removals tool under Indexing in Search Console. This hides addresses from search results while recrawling catches up. Treat it as a temporary hiding step, not a permanent fix. The permanent fix is the removal itself plus the not found or gone response.
If Search Console listed a security issue or a manual action, fix everything first, then request a review, describing what was cleaned and how the entry point was closed. Requesting a review while the site is still infected only resets the clock. After the review, keep watching the Pages report. Spam addresses falling away and impressions for those addresses dropping to nothing is the signal that the index is settling.
How long recovery takes, and what to watch afterwards
Cleaning the site itself can take hours to days depending on how far the infection spread and whether a clean backup exists. Cleaning up Google takes longer, because Google has to revisit each fake address. For a large infection, expect weeks rather than days before search results look clean, and expect rankings to recover gradually once the spam is gone and any manual action is lifted. That slow, gradual pattern is normal, and it is not a sign that the cleanup failed.
Set a simple weekly routine for the period after cleanup:
- Check Search Console for new indexed addresses you do not recognise, and for any new security message.
- Check that core, plugins, and themes are up to date, and that no unknown administrator account has appeared.
- Confirm that backups are running and that you can restore one. A backup you have never tested is only a hope, not a safety net.
- Run a security scan on a regular schedule, and keep the scan reports so you can spot a change early.
A sudden jump in indexed addresses is the earliest warning sign for this attack, because the attack is designed not to be noticed by browsing the site. Watching that one number each week costs little and catches a return early, while it is still small.
Mistakes that keep the hack alive
- Deleting visible spam files but leaving a backdoor, a rogue administrator, or a rogue scheduled task, so the spam regenerates.
- Blocking spam addresses in the robots file instead of letting them return not found or gone.
- Relying only on the Removals tool without fixing the site, so the addresses return once the temporary hiding ends.
- Restoring a backup made after the infection, which restores the infection with it.
- Changing passwords before the backdoor is removed, so the new passwords are collected too.
- Requesting a Google review before cleanup is genuinely complete.
When to ask a professional for help
You can handle the confirmation checks and the Search Console cleanup yourself with this guide. Consider professional help if any of these apply: you cannot tell whether the site is fully clean, the spam returns after a careful clean, the database needs work you are not comfortable doing, or Google has applied a manual action and you want the review request handled carefully. A professional cleanup should cover files, database, accounts, and credentials together, not just the visible spam, and it should explain how the attacker got in.
For context on what a cleanup involves and what to ask before choosing help, see our guide to what affects a malware removal quote. If you would rather hand the whole cleanup over, chat with Raozan IT on WhatsApp, use the contact page, or write to [email protected]. Tell us what you found in the confirmation checks, and we can advise on the next step from there.
Frequently asked questions
What is the Japanese keyword hack?
It is a search spam attack in which injected code creates fake Japanese pages, usually advertising counterfeit goods, under a hacked domain, and serves them mainly to search engines. Visitors usually see the normal site, which is why the attack is often found late.
Why can I not see the spam when I visit my site?
Because of cloaking. The injected code checks who is asking and serves spam to search engine crawlers while showing the normal site to ordinary visitors. Use Search Console’s URL Inspection live test to see what Google receives.
Will deleting the fake pages fix it?
Usually not on its own. The pages are often generated on demand by injected code, so they regenerate until the generator, any backdoor, rogue accounts, and rogue scheduled tasks are removed and the entry point is closed.
Should I block the spam addresses in robots.txt?
No. Let them return a not found or gone response so Google can crawl them and see they are gone. Blocking them prevents Google from seeing that, and the addresses may stay indexed longer.
Is the Search Console Removals tool a permanent fix?
No. It hides addresses temporarily while recrawling catches up. The lasting fix is removing the infection, returning not found or gone for the spam addresses, and resubmitting a clean sitemap.
How long until Google stops showing the spam?
It depends on how many fake addresses were indexed and how quickly they are recrawled. For a large infection, expect weeks rather than days, with the worst addresses hidden sooner if you use the Removals tool for them.
Will the hack come back?
It can, if a backdoor remains, a credential was not rotated, or the original weakness is still present. Updating everything, removing unused code, rotating credentials, and watching Search Console weekly are the habits that keep it from returning.
The Japanese keyword hack is unsettling because it hides from its owner and borrows a trusted domain for someone else’s spam. Worked through in order, though, it is fixable: confirm it, protect the site, remove the generator and its hiding places, close the way in, and then clean up Google patiently. The site cleanup is the urgent half. The Google cleanup is the patient half. Both matter, and skipping either one leaves the job unfinished.
Raozan IT is a WordPress and digital marketing team based in Noapara, Raozan, Chattogram, founded in 2017, with 800+ projects completed. If this attack has hit your site and you would like help with the cleanup, chat with us on WhatsApp, use the contact page, or write to [email protected], and we will help you work out the next step.
