Recognizing the Japanese keyword hack
This attack pattern, sometimes called the Japanese keyword hack, injects auto-generated Japanese text into your site. The result is a set of new pages hosted in randomly generated directories, for example http://example.com/ltjmnjp/341.html. These pages are typically monetized with affiliate links to stores selling counterfeit brand merchandise, and they are designed to be indexed by Google Search.
Attackers often go a step further and add themselves as a property owner in Google Search Console. If you get a notification about an unknown user verifying your site, treat it as a strong indicator that your site has been compromised. Start by checking the Security Issues tool in Search Console for any detected hacked pages. You can also search for site:_your site url_ in Google Search and flip through several pages of results for unusual URLs. If Google shows nothing suspicious, repeat the same search on another engine.
Clicking a link to a hacked page usually leads to a redirect or a page full of gibberish. Sometimes you might see a 404 error instead—do not assume the problem is gone. Attackers frequently use cloaking to hide the malicious content. Use the URL Inspection tool to view the underlying content that is actually served to Googlebot.
Cleaning up the hack
Before removing anything, make an offline copy of every file you touch. Ideally, back up your entire site beforehand, including the database if you are using a CMS. You will need these copies if you have to restore files later.
1. Revoke unauthorized Search Console access
Go to the Search Console verification page and click "Verification Details" to see all verified users. Remove any owner you do not recognize, following the instructions in the Managing users, owners, and permissions Help Center.
The attacker's verification token is usually either an HTML file at the site root or a dynamically generated .htaccess file that mimics an HTML file. If you cannot find the HTML token, inspect your .htaccess for a rewrite rule similar to the following:
RewriteEngine On
RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L]
2. Replace or delete suspicious .htaccess files
Beyond faking verification tokens, .htaccess rules are commonly used to redirect users or to generate spam pages. Unless you have custom rules you need to preserve, the safest option is to replace the file entirely.
First, locate your .htaccess file. In a CMS such as WordPress, Joomla, or Drupal, search for ".htaccess file location" along with the name of your CMS—you may find multiple instances. List all of their locations. Then replace every one with a clean or default version, typically available by searching for "default .htaccess file" plus your CMS name. If no default exists and you have never configured .htaccess yourself, the file is probably malicious: save an offline copy and delete it from your server.
3. Remove malicious files and scripts
This step is time-consuming, so work methodically. If you have not backed up your site yet, do so now.
If you use a CMS, reinstall all core files from the default distribution, along with any themes, modules, or plugins you have added. This guarantees those files are clean. Search for "reinstall" and your CMS name for instructions.
Next, check your sitemap. Attackers often modify existing sitemaps or add new ones to get their URLs indexed faster. Review each sitemap file for links you do not recognize, and delete the whole file if it contains only spammy URLs.
You still need to hunt for other compromised files. Do not try to read every PHP file on your server. Instead, narrow the field:
- If you have reinstalled your CMS files, focus only on files that are not part of the default installation. This removes most PHP files from consideration.
- Sort files by last-modified date, looking for anything changed in the months around when you discovered the hack.
- Sort by size and flag any unusually large files.
Once you have a short list, open each file and scan for blocks of obfuscated code—jumbled strings usually preceded by functions like base64_decode, rot13, eval, strrev, or gzinflate. The malicious payload is often packed into one very long line. If you are not comfortable reading PHP, review the PHP documentation or enlist an experienced developer. Users of CMSs who never edit PHP directly can compare server files against the default file list for the CMS and its plugins, looking for extras and anything larger than its stock version.
$O_O0O_O0_0=urldecode("%6E1%7A%62%2F%6D%615%5C%76%740%6928%2D%70
%78%75%71%79%2A6%6C%72%6B%64%679%5F%65%68%63%73%77%6F4%2B%6637%6A");
$OO0_0OO0__=$O_O0O_O0_0{26}.$O_O0O_O0_0{6}.$O_O0O_O0_0{10}.$O_O0O_O0_0{30}
4. Verify the cleanup
After removing the hacked files, go back to the gibberish pages you identified earlier and re-check them with Fetch as Google. If they return "Not Found," your cleanup is probably complete and you can move on to closing the vulnerabilities that allowed the attack.
Preventing a repeat attack
Fixing the infection is only half the job. Around 20% of hacked sites are compromised again within a day, so you need to address the root cause. If you are unsure how the attacker got in, review the top ways websites get hacked by spammers. Otherwise, work through this checklist:
- Scan your computer regularly with up-to-date antivirus software.
- Change your passwords frequently, using a strong, unique password for every account related to your hosting, FTP, and CMS.
- Enable 2-Step Authentication (2FA) on any service that supports it. Even a stolen password is not enough to get in.
- Update your CMS, plugins, extensions, and modules regularly. Outdated software is one of the most common entry points. Some CMSs can auto-update.
- Subscribe to a security monitoring service that can watch your site for a small recurring fee.
Additional resources
If you are still stuck, these third-party scanners may flag problematic content. Note that, other than VirusTotal, Google does not run or support these tools, and no scanner can guarantee complete detection:
Google offers additional help through the Search Central Help Community and Google SafeBrowsing.
