How to clean up the Japanese keyword hack in WordPress?

To clean up the Japanese keyword hack in WordPress, you need to remove the injected spam pages and the malicious code that generates them, replace compromised core, theme, and plugin files with clean copies, delete rogue users and Search Console owners, and then ask Google to drop the spam URLs from its index. The cleanup itself is usually a few hours of careful work, but the search results can take several weeks to recover.

The Japanese keyword hack (sometimes called the Japanese SEO spam hack) is one of the most common forms of SEO spam on WordPress sites. It quietly creates thousands of auto-generated pages in Japanese, usually selling counterfeit goods, and they show up in Google under your domain. This guide walks you through how to confirm the infection, where the malicious code typically hides, how to remove it step by step, and how to repair your search presence afterward.

What Is the Japanese Keyword Hack?

The Japanese keyword hack is a type of SEO spam where attackers use your site's reputation to rank their own pages. Once they gain access, they plant code that generates pages full of Japanese text, affiliate links, and links to fake online shops. These pages often live under random-looking URLs such as /abc123.html or /?xyz=45678, and many of them are not stored in your database at all. They are generated on the fly by a PHP script whenever a request comes in.

A particularly frustrating trait of this hack is cloaking. The malicious code checks who is visiting. If the visitor is Googlebot, it serves the spam content. If it is a regular human visitor, or you logged in as an admin, it shows your normal site or a 404 page. That is why many site owners only discover the problem when a customer mentions odd search results, or when Google Search Console flags it.

Common Symptoms

You may be dealing with the Japanese keyword hack if you notice:

• Google search results for site:yourdomain.com showing Japanese titles and descriptions you never wrote.
• A sudden spike in indexed pages in Google Search Console under Indexing > Pages.
• New sitemaps in Search Console that you didn't submit, or new verified owners you don't recognize.
• A "This site may be hacked" label under your listing in search results.
• Unknown admin users in Users > All Users.
• Unfamiliar files in your web root, such as random .php files or a modified .htaccess.

Why Does This Hack Happen?

The Japanese keyword hack is not a vulnerability in itself. It is the payload attackers drop after getting in some other way. The most common entry points are:

1. Outdated or vulnerable plugins and themes: A known flaw in a plugin lets attackers upload a file or run code.
2. Nulled (pirated) themes and plugins: These frequently ship with backdoors already installed.
3. Stolen or weak credentials: Reused passwords for WordPress admin, FTP, SFTP, or your hosting panel.
4. Cross-site contamination on shared hosting: One infected site in the same account can spread to others that share the same file permissions.

Understanding this matters, because if you only delete the spam pages and don't close the entry point, the hack will almost certainly return within days.

Step 1: Confirm the Infection and Take a Backup

Before changing anything, confirm what you are dealing with and preserve the current state.

• Search Google: Run site:yourdomain.com in Google and scan through several pages of results. Also try site:yourdomain.com japan or searching for common spam terms in Japanese.
• Use the URL Inspection tool: In Google Search Console, inspect one of the spam URLs and click Test Live URL, then View Tested Page. This shows you what Googlebot actually receives, which bypasses the cloaking.
• Check with curl as Googlebot: From your own terminal, request a spam URL with a Googlebot user agent to see the cloaked content.

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -s https://yourdomain.com/suspicious-page.html | head -50

• Take a full backup: Back up your files and database even though they are infected. You want a snapshot to compare against and to fall back on if the cleanup breaks something. Label it clearly as infected so no one restores it by accident.

If you have a clean backup from before the infection started, restoring it can save a lot of time. Just remember that restoring alone does not fix the entry point, so you still need to complete the hardening steps below.

Step 2: Lock Down Access

Attackers usually leave themselves several ways back in. Cut those off before you start cleaning.

1. Change every password: WordPress admin accounts, hosting control panel, SFTP/SSH, and the database user. Use a password manager to generate long, unique passwords.
2. Update the database password in wp-config.php: If you change the database user's password in your hosting panel, update DB_PASSWORD in wp-config.php to match.
3. Rotate the security keys and salts: Replace the AUTH_KEY, SECURE_AUTH_KEY, and related constants in wp-config.php with fresh values from the WordPress.org secret key generator. This logs out every user, including the attacker.
4. Review users: Go to Users > All Users and filter by Administrator. Delete any account you don't recognize and attribute its content to a legitimate user.

You can also list administrators quickly with WP-CLI:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Some infections hide admin users from the dashboard with a filter, so checking the database directly is a good idea:

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Replace wp_ with your actual table prefix if it is different.

Step 3: Find the Malicious Files

The spam generator is usually a PHP file (or several) that you did not put there. Common hiding spots include:

• The web root, next to wp-config.php, with names that look legitimate, like wp-log.php or class-wp-cache.php.
• wp-content/uploads/, which should almost never contain PHP files.
• Inside theme files such as header.php, functions.php, or index.php.
• Inside plugin folders, sometimes as a fake plugin with a plausible name.
• .htaccess files with rewrite rules that send random URLs to the spam script.

Look for Recently Modified Files

If you have SSH access, list PHP files changed in the last few weeks:

cd /path/to/wordpress
find . -type f -name "*.php" -mtime -30 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r | head -100

Attackers sometimes fake timestamps, so treat this as a starting point rather than a complete list.

Find PHP Files in Uploads

find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.php5" \)

Anything returned here deserves a close look. Legitimate plugins very rarely store PHP in uploads.

Search for Suspicious Code Patterns

Obfuscated malware commonly relies on a handful of functions. Search for them, but remember that legitimate plugins use some of these too, so review each result rather than deleting blindly:

grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(|assert\(" --include="*.php" wp-content/ | head -50
grep -rl "Googlebot" --include="*.php" . | head -50

The second search is especially useful for this hack, since cloaking code has to check for Google's user agent.

Check .htaccess

Open the .htaccess file in your web root. A standard WordPress file looks like this:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

If you see rules pointing to unfamiliar PHP files, conditions matching Google's user agent or referrer, or long blocks of rewrite rules you didn't add, remove them. Also check for extra .htaccess files in subfolders:

find . -name ".htaccess" -type f

Step 4: Replace Core, Theme, and Plugin Files

Rather than hunting for every changed line in WordPress core, replace it entirely with a clean copy.

• Verify core checksums: WP-CLI compares your core files against the official versions.

wp core verify-checksums

• Reinstall core: This replaces core files without touching wp-content or wp-config.php.

wp core download --force --skip-content

• Check plugins: WP-CLI can also verify plugins hosted on WordPress.org.

wp plugin verify-checksums --all

• Reinstall plugins from trusted sources: Delete and reinstall each plugin from WordPress.org or the vendor's official site. For premium plugins, download a fresh copy from your account on the vendor's site.
• Replace your theme: Download a fresh copy of your theme. If you use a child theme with custom code, review every file in it line by line, because child themes cannot be verified against a public checksum.
• Remove anything you don't use: Delete inactive plugins and themes. They are still exploitable even when deactivated.

Finally, look at wp-config.php and any mu-plugins folder (wp-content/mu-plugins). Must-use plugins load automatically and don't appear in the normal plugin list, which makes them a favourite hiding place.

Step 5: Clean the Database

Some variants store spam content or code in the database rather than in files.

• Look for spam posts: Check for published posts or pages you didn't create, especially with Japanese titles.

SELECT ID, post_title, post_type, post_status, post_date
FROM wp_posts
WHERE post_date > '2026-08-01'
ORDER BY post_date DESC
LIMIT 100;

• Check options for injected scripts: Look at autoloaded options for suspicious content.

SELECT option_name, LEFT(option_value, 200) AS preview
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%eval(%';

• Confirm siteurl and home: Make sure these point to your real domain.

wp option get siteurl
wp option get home

Delete only what you are sure is malicious. When in doubt, export the row first so you can restore it.

Step 6: Scan the Site

After manual cleanup, run at least one reputable scanner to catch anything you missed. Good options include:

• Wordfence Security: Compares files against repository versions and scans for known malware signatures.
• Sucuri Security: Includes a remote scanner and file integrity monitoring.
• MalCare: Offers server-side scanning that doesn't rely on your server's resources.

Your host may also offer a malware scan in its control panel. No scanner is perfect, so use these as a second opinion, not a replacement for the manual checks above.

Step 7: Fix Your Google Search Presence

Once your site is clean, you need to tell Google.

Clean Up Search Console

1. Remove rogue owners: In Search Console, go to Settings > Users and permissions. Remove any owner or user you don't recognize. Attackers often verify themselves as owners so they can submit spam sitemaps. Also remove their verification token (an HTML file or DNS record), or Google may re-verify them.
2. Delete unknown sitemaps: Under Indexing > Sitemaps, remove any sitemap you didn't submit, then resubmit your real one.
3. Check Security Issues: Under Security & Manual Actions > Security issues, review any flagged problems. Once fixed, click Request Review and briefly explain what you cleaned and how you closed the entry point.

Make the Spam URLs Return 404 or 410

Google drops URLs from its index once they consistently return a 404 or 410 status. After cleanup, the spam URLs should naturally return 404 because the generating script is gone. Confirm this with curl using the Googlebot user agent, as shown earlier.

If the spam URLs follow a recognisable pattern, you can return a 410 (Gone) to speed things up. In Apache, add this above the WordPress block in .htaccess, adjusting the pattern to match your spam URLs:

<IfModule mod_rewrite.c>
RewriteEngine On
# Example: spam pages like /12345abc.html that never existed on this site
RewriteRule ^[0-9]+[a-z]+\.html$ - [G,L]
</IfModule>

On Nginx, a similar rule goes inside your server block:

location ~ "^/[0-9]+[a-z]+\.html$" {
    return 410;
}

Be careful that your pattern doesn't match any real pages. Test a few legitimate URLs afterward.

Use the Removals Tool for Urgent Cases

The Removals tool in Search Console temporarily hides URLs (for roughly six months) while Google re-crawls. It's useful for the most visible spam pages, but it doesn't permanently delete anything, so the 404/410 responses still matter.

Expect recovery to take anywhere from a few weeks to a couple of months depending on how many spam URLs were indexed and how often Google crawls your site.

Step 8: Prevent Reinfection

Now close the door the attackers used.

• Update everything: WordPress core, themes, and plugins, plus the PHP version your host runs.
• Remove nulled software: Never use pirated premium themes or plugins.
• Disable file editing in the dashboard: Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php above the "That's all, stop editing!" line.
• Block PHP execution in uploads: Add rules so the uploads folder can't run scripts.
• Enable two-factor authentication for every admin account.
• Use a web application firewall: A plugin-level firewall or a cloud WAF can block many exploit attempts before they reach WordPress.
• Set up file integrity monitoring: So you get alerted when new PHP files appear.
• Keep regular, off-site backups: So you can restore quickly if anything happens again.

To block PHP in uploads on Apache, create wp-content/uploads/.htaccess with:

<FilesMatch "\.(php|phtml|php[0-9]|phar)$">
    Require all denied
</FilesMatch>

On Nginx, add this inside your server block:

location ~* ^/wp-content/uploads/.*\.(php|phtml|php[0-9]|phar)$ {
    deny all;
}

When to Call a Professional

If the hack keeps coming back after you've cleaned it, if you can't find the entry point, or if your site handles payments or personal data, it's worth bringing in a professional malware removal service. Persistent reinfections often point to a backdoor hiding somewhere unusual, such as a cron job on the server, a compromised database user, or another site in the same hosting account.

---

FAQ: Japanese Keyword Hack

---

Conclusion

The Japanese keyword hack is stressful because it hides from you while showing spam to the whole world through Google. The fix follows a clear sequence, though: confirm the infection, lock down access, remove malicious files and database entries, replace core and plugin files with clean copies, and then clean up Search Console so Google can re-crawl a healthy site.

The most important part is what comes after the cleanup. Find out how the attackers got in, patch it, and put monitoring, firewalls, two-factor authentication, and regular backups in place. With those habits, you are far less likely to see Japanese spam under your domain again.