Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Japanese characters showing up in your Google results? Here is how to confirm the Japanese keyword hack, clean it properly, and get the spam pages deindexed.
The Japanese keyword hack is one of the most common ways a WordPress site gets compromised. You search your own domain in Google and find pages you never created. Japanese characters in the titles, URLs you do not recognise, links to stores selling counterfeit goods. Your customers see the same thing when they search for you.
Attackers get in through a weakness in your site, then spend your domain's reputation on their spam. You lose rankings you spent years building. You also lose trust with the people who were about to buy from you, and that part costs money immediately.
Open your site in a browser and it looks fine. That is deliberate.
Fixing this is two separate jobs. Clean the malware off your server, then get the spam pages out of Google's index. Most guides cover one and leave you holding the other.
The attack creates thousands of auto-generated Japanese pages on your domain, usually inside randomly named directories like /ltjmnjp/341.html. The pages are filled with affiliate links to storefronts selling fake branded goods. Every click those pages earn pays the attacker, and your domain does the ranking work for them.
Google calls it the Japanese keywords hack. Security companies call it Japanese SEO spam. Both names describe the same infection, so you will see them used interchangeably while you research the fix.
It belongs to a family of SEO spam infections that work the same way. The pharma hack swaps the Japanese counterfeit goods for pharmaceutical products. The gibberish hack drops the language angle and generates keyword-stuffed nonsense pages instead. The cleanup logic in this guide applies to all three.
Run these four checks in order. Each one tells you something the last one could not.
1. Search your own domain. Type site:yourdomain.com into Google and page through the results. Then narrow it with site:yourdomain.com 激安, a word that appears in almost every version of this spam. Any URL you did not create is a confirmed spam page.
2. Check Search Console. Open the Security Issues report. Google often flags this directly as hacked content. Then open the Pages report and look at your indexed URL count. A site with forty pages showing three thousand indexed URLs has a problem, even if Security Issues is empty.
3. Inspect one of the spam URLs. Paste it into the URL Inspection tool and view the crawled page. This is the check that proves it, because it shows you what Googlebot receives rather than what your browser receives.
4. Check who owns your Search Console property. Go to Settings, then Users and permissions, and look at the verified owners list. Attackers add themselves so they can submit sitemaps and speed up indexing of their spam. An owner you do not recognise confirms the compromise on its own.
One rule holds all four of these together. Your browser is not evidence. The malware checks who is asking for the page. Googlebot gets the Japanese sales copy. You get your normal page or a 404, which is why so many site owners conclude the problem is already fixed when it is not.
Your first instinct is to open the file manager and search for Japanese characters. That is the right instinct, and on most infections it works. You find the injected file in about a minute.
This one is built to defeat it. Three thousand spam URLs does not mean three thousand files sitting on your server.
The malware adds a rewrite rule to your .htaccess file. That rule catches any request matching a pattern and hands it to a single PHP script. The script builds the Japanese page on demand, often pulling the content from the attacker's own server. The URL exists as far as Google is concerned. Nothing matching it exists on your disk.
That same script is what decides who sees what. It reads the request, works out whether a crawler or a person is asking, and answers accordingly.
So file scanning on its own will not tell you whether your site is clean. You have to read the .htaccess file, follow it to the script it points at, and check the database as well.
Before you delete anything, take a copy of everything.
The only record of how the attacker got in is sitting in your file modification times, your access logs, and your database timestamps. Cleanup overwrites all three. Once that record is gone you are guessing about the entry point, and guessing is how a site gets reinfected two weeks later.
Take a full file archive and a database dump first. Label it clearly as infected and never restore from it. It is a record, not a backup.
Then download your raw access logs separately. Hosts rotate these out within days on some plans, and they are the piece people lose most often. They show what was requested in the hours before the first file changed, which is usually where the answer is. Our guide to investigating a hacked WordPress site covers how to read them.
Work in this order. Skipping steps is what brings the hack back.
Put the site behind a maintenance page first. You do not want the attacker watching you clean and reinfecting behind you.
Replace all WordPress core files with a fresh download from WordPress.org rather than patching the existing ones. Do the same with your themes and plugins. Delete them and reinstall from clean sources instead of hunting for injected lines inside them.
Then check the places a core replacement does not reach.
wp-content/uploads should hold media files only. Any .php, .js or .ico file in there is suspect.
Replace .htaccess with a clean default, and read what you removed before you discard it. That is where the rewrite rule lives.
In the database, check wp_posts for spam entries, wp_options for encoded values, wp_users for accounts you did not create, and wp_postmeta for injected redirect data.
Search your web root for sitemap files you never generated, including plain text ones with names like spamurl.txt.
Finish by resetting every password and key. Hosting, FTP, database, and every admin account. Rotate your WordPress salts as well. One credential left in place undoes the whole job.
One honest note on scope. This infection hides backdoors well, and a cleanup that misses one puts you back where you started within weeks. If you are not comfortable reading PHP, our emergency malware removal team does this daily and preserves the evidence trail while cleaning.
Most guides tell you to remove the unauthorised owner from Search Console and move on. On its own, that step does nothing.
Google verifies ownership through a token that sits on your site. Remove the owner but leave the token in place, and the attacker verifies again the next day and carries on submitting sitemaps.
You have to remove all four.
The owner, under Settings, then Users and permissions.
The google[hash].html verification file in your web root.
Any verification token added to .htaccess.
Any google-site-verification TXT record in your DNS that you did not add.
Then open the Sitemaps report and look for submitted files you never created. Delete the submission in Search Console, then delete the file from the server. A sitemap left in place keeps feeding Google spam URLs long after your server is clean. It is the most common reason a site owner believes the cleanup failed when the server side was actually done correctly.
Your server can be spotless while Google still shows Japanese pages under your brand name. This half is search work, and no security scan does it for you.
Serve 410, not 404. A 404 tells Google the page might come back, so the URL stays in the recrawl queue for months. A 410 says it is permanently gone. These URLs never legitimately existed on your site, so 410 is both the honest answer and the faster one. Add a rule to .htaccess that returns 410 for the spam directory patterns.
Do not block the spam paths in robots.txt. This is the instinct that costs people the most time. Blocking the paths stops Googlebot from fetching them, so it never sees your 410 and never learns the pages are gone. The URLs then sit in the index indefinitely. Let Google crawl them so it can process the removal.
Treat the Removals tool as temporary. It hides URLs for roughly six months. If the underlying signal was never fixed, they reappear afterwards. Point it at the attacker's URL patterns rather than your whole site, and use it to buy time while the 410s do the permanent work.
Resubmit a clean sitemap and request indexing on your important pages first. Your homepage, service pages and top articles get recrawled quickly when you nudge them, and those are the results that decide what a customer sees when they search your brand.
Handle the manual action last. If Search Console shows one, file the reconsideration request only once you can demonstrate the site is clean, and describe what you fixed. A rejected request costs you another round of waiting. A security audit before you file is worth more than a fast submission.
You do not have to chase every spam URL. Some will sit in Google's index for months and cost you nothing at all.
Two questions decide it. Does the URL appear when someone searches your brand, your services, or anything a customer would actually type? Is it picking up impressions or clicks in your Search Console performance report?
If both answers are no, leave it. It drops out on its own as Google recrawls. Your time is better spent confirming your real pages are clean and reindexed. Trying to remove every last spam URL is the most common way people lose two weeks to this.
Reinfection traces back to one of three things almost every time. A backdoor left behind. A password or key that never got rotated. Or the way in that is still sitting open.
The third one gets missed most. Removing what an attacker left behind does nothing about the weakness that let them in, and that is usually an outdated plugin or a known vulnerability nobody had got round to patching.
It is also why a clean scan is not the same as a clean site. Scanners match known patterns, and a well hidden backdoor can sit quietly for a long time. On one client site we investigated, the attacker had been inside for sixteen months before anything visible happened.
Keeping a site clean after the fact is a maintenance job rather than a one-off fix. Updates applied on time, file changes monitored, access reviewed. That is the gap our security and maintenance service is built to cover.
No. Rankings normally recover once the spam is gone and your real pages have been recrawled. Recovery takes longer if a manual action was applied or if the infection ran for months before anyone noticed.
Days for pages Google crawls often, weeks or longer for the rest. Serving 410 speeds it up. There is no way to clear them all at once.
Sometimes, on the file side. No plugin touches the search half. None of them remove the attacker's verification token, clean up a hijacked sitemap, or file your reconsideration request.
No. Google has been clear that those links are not what is hurting you. Fix the content on your own site and leave the disavow tool alone.
Run site:yourdomain.com again a month from now. When the only pages that come back are yours, the job is done. Keep checking after that, because that search is where a customer notices something is wrong before you do.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →How attackers actually break into WordPress sites, what they do with the access, and why most owners discover the problem months after it started.
How to work out how long your site has actually been compromised, and why that answer decides everything else.
A breakdown of the fake Cloudflare verification scam hitting WordPress sites — how it hides from site owners, why security scanners miss it, and how we remove it.
How to remove malware from a WordPress site: hidden backdoors, database spam, rogue admin accounts, and a fake Cloudflare verification page.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
