Japanese titles, fake product pages, or strange URLs appearing in Google are common signs of the Japanese keyword hack.

Your WordPress site may still look normal when you visit it yourself. The spam can be generated dynamically or shown only to certain visitors, search engines, or requests.

Do not start by deleting anything containing Japanese text. First find what is generating the spam, remove the infection and its persistence, then verify that the original behavior is gone.

Japanese keyword hack showing spam search results

1. Confirm What Is Actually Happening

Start with one suspicious URL from Google or Google Search Console.

Check whether:

  • the URL actually exists in WordPress
  • it returns Japanese or other spam content
  • it redirects somewhere else
  • it behaves differently when you are logged out
  • Google shows a title or description you never created

You can also use Google to quickly look for unexpected pages:

site:example.com

If you already know part of the spam pattern, narrow the search:

site:example.com "日本"
site:example.com inurl:.html
site:example.com inurl:product

Treat these searches as clues rather than a complete list of affected URLs.

If possible, open the suspicious URL while logged out and from another device or network. Some infections hide from WordPress administrators or behave differently depending on how the visitor reaches the page.

2. Check Google Search Console

Search Console can reveal parts of the compromise that are not visible from the WordPress dashboard.

Check:

  • Security Issues: Look for hacked content, malware, or other security warnings.
  • Manual Actions: Check whether Google has applied a manual action.
  • Sitemaps: Remove any sitemap you did not create.
  • Users and permissions: Look for unknown users or owners.
  • URL Inspection: Inspect several affected URLs and check what Google can currently fetch.

If you find an unknown Search Console owner, do not only remove the account. Check how ownership was verified. An attacker may have left a verification file, tag, DNS record, or another verification method behind.

Google Search Console showing performance drop and indexing spike

3. Find What Is Generating the Spam

The hacked URLs do not necessarily exist as WordPress posts or pages. Use what you found in the affected URL to decide where to look next.

What you seeWhere to look
The fake page exists in WordPressPosts, pages, users, imports, post metadata, and database content
The URL does not exist in WordPress but returns spamRewrite rules, PHP files, plugins, themes, and MU plugins
A direct visit looks normal but search visitors see spam or redirectsConditional PHP, JavaScript redirects, referrer checks, and user-agent checks
Thousands of random URLs return similar content.htaccess, Nginx rules, PHP routing, and malicious sitemap generation
The spam returns after cleanupBackdoors, scheduled tasks, compromised credentials, or another infected site

Check Rewrite Rules

If the site uses Apache or LiteSpeed, inspect its .htaccess files. On Nginx, inspect the active site configuration.

Look for unfamiliar rules that:

  • send requests to an unknown PHP file
  • match random paths or filenames
  • redirect only certain visitors
  • generate URLs that do not exist in WordPress

Do not delete a rule simply because you do not recognize it. Hosting platforms, caching systems, security tools, and plugins can add legitimate rewrite rules. Compare suspicious entries with a clean backup or known configuration first.

Check WordPress Files

Pay particular attention to:

  • wp-config.php
  • files in the WordPress root
  • wp-content/mu-plugins/
  • active plugins and themes
  • wp-content/uploads/
  • recently added or modified PHP files

If WP-CLI is available, verify WordPress core files against the official checksums:

wp core verify-checksums --include-root

A modified core file deserves investigation, but a successful check does not mean the entire site is clean. Malware can live outside WordPress core.

You can also look for PHP files inside uploads:

find wp-content/uploads -type f -name '*.php' -print

PHP inside the uploads directory is worth reviewing, but do not automatically delete every result. Establish what created the file and what the code does.

The same applies to functions such as base64_decode(), eval(), or curl_exec(). Their presence alone does not prove a file is malicious. Context matters.

Check the Database and Users

Review WordPress for:

  • posts or pages you did not create
  • unknown administrator accounts
  • unexpected scripts or spam content
  • altered SEO titles or descriptions
  • settings or options added by software you do not recognize

Avoid running broad database replacements for Japanese text. Legitimate content may contain Japanese characters, and careless replacements can corrupt serialized WordPress data.

4. Check the Site Externally and Inside WordPress

An external scan can catch behavior that is hidden from your logged-in WordPress session.

The Securewp Remote Security Scanner can check the public-facing site for suspicious content and redirects.

Securewp remote scanner detected content cloaking

Inside WordPress, SiteFort or another trusted malware scanner can help identify modified files, suspicious code, backdoors, and vulnerable software.

A clean scan is useful, but it is not enough by itself. The strongest confirmation is that the same URLs and behavior that originally exposed the compromise can no longer be reproduced.

5. Clean the Infection

Take a backup of the current files and database before removing anything. This gives you a recovery point and preserves evidence if further investigation is needed.

Then remove the components you have identified as malicious.

Where possible:

  • replace compromised WordPress core files with clean copies
  • replace infected plugins or themes with trusted packages
  • remove confirmed backdoors and fake plugins
  • remove unauthorized WordPress users
  • remove malicious rewrite rules
  • remove confirmed malicious scheduled tasks

Be careful with customized themes and plugins. Preserve legitimate custom code before replacing files.

When replacing a plugin or theme, use a clean package from the original developer or another trusted source rather than copying files from an unknown backup.

6. Close the Way the Attacker Got In

Removing the spam is only part of the cleanup. If the original access still works, the infection can return.

Investigate likely entry points such as:

  • outdated or vulnerable plugins and themes
  • abandoned plugins that are no longer maintained
  • stolen WordPress administrator credentials
  • compromised hosting, SFTP, FTP, or SSH credentials
  • another infected WordPress installation under the same hosting account

Update vulnerable software and remove plugins or themes you no longer need.

After malicious access and persistence have been removed, rotate affected credentials and enable 2FA for administrator and hosting accounts where available.

If you change passwords while an attacker still has a working backdoor, the new credentials alone will not secure the site.

7. Verify That the Hack Is Really Gone

Return to the same URLs and symptoms that originally proved the site was compromised.

Check that:

  • fake spam URLs no longer return hacked content
  • legitimate pages show the correct titles and content
  • search visitors are no longer redirected
  • unknown Search Console owners and sitemaps are gone
  • removed malware or backdoors are not reappearing
  • new spam URLs are no longer being generated

URLs that should not exist should return a real 404 or 410 response. A page that visually says “Not Found” while returning HTTP 200 is not the same thing.

You can check the response headers with:

curl -I https://example.com/suspicious-url/

If the URL redirects, follow the redirect chain:

curl -IL https://example.com/suspicious-url/

Do not redirect thousands of hacked URLs to the homepage. URLs that genuinely should not exist should return an appropriate error status.

8. Clean Up the Remaining Google Results

Old hacked URLs can remain visible in Google after the website itself has been cleaned. Google needs to recrawl the affected URLs before its search results fully reflect the cleanup.

This is a separate step from removing the malware.

For handling 404 and 410 responses, temporary Search Console removals, large lists of hacked URLs, and legitimate pages that need to be restored in Google, see How to Remove Injected Spam Pages from Google Search.

How to Keep the Hack From Coming Back

Once you know how the site was compromised, fix that weakness first.

  • Keep WordPress, plugins, and themes updated.
  • Remove unused or abandoned plugins and themes.
  • Use unique passwords and 2FA for privileged accounts.
  • Monitor vulnerable plugins and unexpected file changes.
  • Keep reliable backups outside the live website.
  • Review administrator accounts and important activity regularly.
  • Use a firewall and malware scanning as additional protection, not as a replacement for patching.

If the spam returns after cleanup, assume something was missed. A backdoor, compromised account, scheduled task, vulnerable component, or another infected site may still be providing access.

If you cannot find what is generating the spam or the site keeps getting reinfected, Securewp also provides a WordPress malware removal service.