Skip to content

The Japanese keyword hack on WordPress: spam pages in Google and how to get them out

Someone has added pages to your site, or made it answer Google differently than it answers people, to sell links and traffic. Clean the site until every spam address answers 404. Then clear Google's index with the Removals tool, a clean sitemap and a review. They are two separate jobs.

By
WP Ministry
Published

In short

  • Search Google for your domain with the site operator, then inspect a suspect address with Search Console's URL Inspection tool. A page that looks like a 404 to you can still be serving spam to Google.
  • In Search Console, look for an owner you do not recognize and a sitemap you did not submit. Removing the owner does not last until their verification token is off the site.
  • Checksums cover WordPress's own files and plugins from WordPress.org. They skip .htaccess, wp-config.php, themes, uploads and the database.
  • A spam address leaves Google's index after it answers 404 or 410 and Google has crawled it again. Do not block it in robots.txt.
  • The Removals tool hides an address for about six months. It removes nothing by itself.
  • If the Security issues report lists the hack, request a review once the whole site is clean. Google says a review for spam can take up to several weeks.

Search results under your own domain in Japanese, or for pills, loans or gambling, mean someone has broken into the site. They have added pages to it, or made it answer search engines differently than it answers people, to sell links and to send search traffic somewhere else. Google documents three forms of this: the Japanese keyword hack, the gibberish hack, and the cloaked keywords and links hack.

There are two separate jobs. Cleaning the site stops the spam being served. Cleaning Google's index takes the results out of search, and it only works once the first job is done. The site can look normal to you the whole time.

Which of the three hacks is it

Google publishes a cleanup guide for each one. This is how those guides describe them.

HackWhat shows in search resultsWhat the guide finds on the server
Japanese keyword hackNew pages of autogenerated Japanese text, in folders with random names, such as example.com/ltjmnjp/341.html. The pages carry affiliate links to stores selling fake brand merchandise..htaccess rules that redirect visitors or create the pages. Sitemaps that were added or altered. Injected PHP files. Typically a new owner in Search Console, verified by a file on the site or a rule that imitates one.
Gibberish hackMany pages of nonsense sentences filled with keywords, at addresses such as example.com/cheap-hair-styles-cool.html, sometimes inside a folder of random characters. A visitor who opens one is redirected to an unrelated page..htaccess rules that redirect visitors. .txt files that hold the HTML template for the spam pages. .php files that decide what goes into each page.
Cloaked keywords and links hackMany pages of nonsense text, links and images. Some carry parts of your own site's template, so they pass for your pages at a glance. The links are sold, and visitors are often redirected.A RewriteRule in .htaccess that hands matching addresses to one PHP file. That file, usually named with a few harmless-looking words.

You do not need to settle which one you have. The three overlap, and Google's steps for them are nearly the same.

All three hide from the owner. Google's guides warn that a hacked address may show you a redirect, a page of gibberish, or a message that the page does not exist, while Google is still served the spam. That is cloaking: presenting different content to people and to search engines. It is why a 404 in your own browser proves nothing yet.

Confirm it

None of these checks needs access to the server. Most need Google Search Console. If the site is not there yet, add it and verify that you own it.

  1. Step 1: Search Google for your own domain

    The site: operator limits results to one domain. Google's guides say to look through a couple of pages of results for addresses you do not recognize. On a larger site, add a word your site would never use: Google's own examples are pharmacy, viagra and casino. The operator does not necessarily return every indexed address, so ordinary results do not clear the site.

    text
    site:example.com
site:example.com pharmacy

  2. Step 2: Open the Security issues report

    In Search Console, this report shows what Google has found. For this kind of hack the entry is hacked content: URL injection (new pages), content injection (spam links or text added to pages) or code injection. Expand it for the date it was first detected and a list of example addresses. Google says the list is a sample, not every affected page. Look at the Manual actions report too.

  3. Step 3: Look at the Page indexing report

    Select "View data about indexed pages" for an example list of up to 1,000 indexed addresses, and look for ones you never created. The filter above the chart can limit the report to the addresses in one sitemap.

  4. Step 4: Inspect a suspect address as Google fetches it

    Paste the full address into the inspection bar at the top of Search Console. Select "Test live URL", then "View tested page". You get the HTML that Google's inspection crawler received just now, and a "Screenshot" tab. If your browser gets a 404 or your normal page and this shows a page of spam, the site is cloaking.

  5. Step 5: Check who owns the property

    Open Settings, then "Users and permissions". The page is visible only to owners. A user marked Owner and Verified proved ownership with a token, such as a file uploaded to the site. Google's guide to the Japanese keyword hack says the hacker typically adds themselves as an owner, to change settings such as sitemaps. Note any account you do not recognize. Removing it comes later, with its token.

  6. Step 6: Open the Sitemaps report

    The report lists the sitemaps submitted through it or through the API. Select one you did not submit and follow "See index coverage" to see what it holds. The report leaves out sitemaps Google found another way, so also open example.com/robots.txt and read any line that begins Sitemap:.

For checks beyond this hack, see how to check whether your WordPress site has been hacked. The hacked-site check looks from outside for visitors from search being sent somewhere else and for links hidden in a page.

Where it lives on a WordPress site

Before you change anything, keep a copy of the site as it is, files and database. Google's guides say the same, and the runbook for the first hour puts the first moves in order. The checks below only read.

The commands need SSH access and WP-CLI. Run them from the site's main folder. Without SSH, your host's file manager shows the same files.

  1. Step 1: Read every .htaccess file

    .htaccess is a file Apache reads, one folder at a time. All three of Google's guides start with it, and WordPress's documentation says copies can sit in several folders. List them and open each one.

    Google's guides give two examples of what the hack adds: RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L] and RewriteRule (.*cj2fa.*|^tobeornottobe$) /injected_file.php?q=$1 [L]. The words vary. Write down the PHP file each rule names. A RewriteCond line above a rule sets the condition under which it applies. It can test HTTP_USER_AGENT or HTTP_REFERER, which is how a server is told to answer a crawler one way and a person another.

    A clean file in the main folder holds the block WordPress writes, shown further down, plus rules you can account for. Google notes that not every unfamiliar rule is malicious.

    bash
    find . -name ".htaccess"

  2. Step 2: Compare WordPress and the plugins with their checksums

    The first command compares each WordPress file with the checksums WordPress.org holds for your version. A clean run prints "Success: WordPress installation verifies against checksums." and nothing else. It warns "File doesn't verify against checksum" for a changed file and "File should not exist" for an added one. Read every line: an added file alone is a warning, and the last line still says Success. --include-root also warns about anything in the main folder that is not part of WordPress, which is where a folder with a random name or a stray PHP file shows up. Some of what it lists will be yours.

    Google's guides name index.php and wp-load.php among the files attackers commonly inject. Both are WordPress's own, so a change to either shows here. A clean index.php in the main folder is short: comments, one line that defines WP_USE_THEMES and one that loads wp-blog-header.php.

    The second command does the same for plugins and ends a clean run with "Success: Verified" and a count. It skips, with a warning, a plugin that did not come from WordPress.org.

    bash
    wp core verify-checksums --include-root
wp plugin verify-checksums --all --skip-plugins --skip-themes

  3. Step 3: Open wp-config.php

    No checksum covers this file. The command prints its lines that load another file or name a function used to hide code. On the sample file that ships with WordPress it prints two lines: a comment, and require_once ABSPATH . 'wp-settings.php';. Trace any other file yours loads. Google's guides describe hidden code as a block of jumbled letters and numbers, usually preceded by PHP functions such as base64_decode, rot13, eval, strrev or gzinflate.

    bash
    grep -n -E "include|require|eval|base64_decode|gzinflate|strrev|rot13" wp-config.php

  4. Step 4: List the PHP files that changed recently

    Google's guides suggest sorting files by the date they were last modified and reading those changed within a few months of when you first saw the spam. -mtime -90 matches files whose contents changed less than 90 days ago. Updates change files too. A clean result is a list your own updates explain.

    bash
    find . -type f -name "*.php" -mtime -90

  5. Step 5: Look for the spam templates

    The gibberish hack keeps its page templates in .txt files. This lists the .txt files that contain a title tag. Google's guide shows <title>{keyword}</title> as the kind of line they hold, with a stand-in word that is swapped for each page. A clean site returns nothing, or a file you can explain.

    bash
    grep -rl --include="*.txt" "<title>" .

  6. Step 6: Find sitemap files you did not make

    Google's guide says hackers often change a sitemap, or add new ones, to get their addresses indexed more quickly. WordPress's own sitemap is at /wp-sitemap.xml and is built when it is requested, so it is not a file in the folder. A plugin can switch that off and provide its own. This lists every .xml file that holds a sitemap's list of addresses. A list of addresses you never published is the hacker's.

    bash
    grep -rl --include="*.xml" "<urlset" .

  7. Step 7: Look for a verification file or tag

    The first command lists the HTML files in the main folder. WordPress ships one, readme.html. Open any other: Google describes its verification file as one with a long alphanumeric name, holding a single line of text that includes google-site-verification. The second command looks in the themes for the tag form, <meta name="google-site-verification" content="..." />.

    Each token should be one Search Console lists for an owner you know. If you find none and a stranger is still a verified owner, Google's guide says to look in .htaccess for a rule that answers for a verification file that does not exist.

    bash
    find . -maxdepth 1 -name "*.html"
grep -rl "google-site-verification" wp-content/themes

  8. Step 8: Search the database

    Google's cleanup guide tells owners to clean the records a hacker changed in the database. The first command lists posts and pages with their dates, so that you can look for titles you never wrote. The second searches the text columns of WordPress's tables for the verification string, in case a tag is stored there. Run it again with a word from the spam results. A clean result is posts you recognize, and matches only for tokens that are yours.

    bash
    wp post list --post_type=page,post --fields=ID,post_title,post_date,post_status --skip-plugins --skip-themes
wp db search "google-site-verification" --skip-plugins --skip-themes

Checksums are the fastest of these checks and the narrowest. They do not cover:

  • .htaccess and wp-config.php, which the WordPress command leaves out;
  • the rest of wp-content, including uploads;
  • plugins that did not come from WordPress.org, and every theme, since WP-CLI has no checksum command for themes;
  • the database.

Clean the site

The full cleanup has its own guide: how to remove malware from a hacked WordPress site. It covers locking the site down, replacing WordPress, plugins and themes with clean copies or restoring a backup from before the break-in, and finding the way in. Google's three guides ask for the same reinstall. Do that work. The steps below add only what is particular to this hack.

  1. Step 1: Remove the owner you do not recognize

    In Search Console, open Settings, then "Users and permissions". Open the menu beside the user and select "Remove access". If a notice warns that the user might regain access, they were a verified owner and their token is still on the site. "Unused ownership tokens" lists what is left. Until those are gone the removed owner can verify again.

  2. Step 2: Take their verification token off the site

    Delete the HTML file, or remove the meta tag from wherever the home page gets it. Remove only the stranger's token: removing your own ends your verification. Then test for a token made on the fly, the way Google's guide does, by asking for a verification file that does not exist. 404 means a rule is probably no longer answering for it. 200 means one still is.

    bash
    curl -s -o /dev/null -w "%{http_code}\n" https://example.com/google1234.html

  3. Step 3: Replace .htaccess with WordPress's default

    Google's guides say to replace every .htaccess with a clean or default version, after saving a copy offline. This is the default from WordPress's documentation for a single site at the root of its domain. The same page has the blocks for multisite. Put back only the rules you can account for. Selecting "Save Changes" under Settings, then Permalinks, also makes WordPress write its own section, if the file is writable.

    For a copy in another folder, Google's advice is that if you never configured one, it is probably malicious: save a copy offline and delete it. If your own posts answer 404 afterward, see how to fix 404 errors on WordPress posts and pages that exist.

    .htaccess
    # BEGIN WordPress
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]
# END WordPress

  4. Step 4: Delete the files the rules pointed to

    Find the PHP file each rogue rule named. Google's guide says its name is usually a random set of innocuous words. Keep a copy off the server and delete it. Do the same with the .txt templates. If they sit together in one folder, Google says to remove the whole folder.

  5. Step 5: Remove the sitemap

    Delete the hacker's sitemap file from the server. In the Sitemaps report, select it, open the more options menu and choose "Remove sitemap". Google's help says removing it from the report does not make Google forget the sitemap or the addresses in it, so the file has to go and the addresses have to stop answering. Read your own sitemap for added lines too.

Then close the way in, or the pages come back. Google's help lists the usual routes for injected content: a directory left with open permissions, a vulnerability in out-of-date software, and third-party plugins. WordPress file permissions covers the first, and the cleanup guide covers the rest.

Get the results out of Google

Google drops an address from its index after it crawls it and gets a 4xx status code. Its crawler documentation says an indexed URL that returns 4xx is removed from the index, and that every 4xx code except 429 is treated the same. So 404 and 410 both work, and neither is documented as the faster one.

Google sets no time for this. It happens as each address is crawled again, and Google keeps trying a removed address for a while, less and less often.

Two things stop it working:

  • Blocking the spam addresses in robots.txt. Google has to fetch an address to learn that it is gone. Its Removals help says not to use robots.txt as a blocking mechanism.
  • A "not found" page that answers with status 200. Google calls that a soft 404 and recommends returning a real 404 code.

  1. Step 1: Check that each spam address answers 404

    Take addresses from the search results and the Security issues report. The first command asks as an ordinary client. The second gives Googlebot's name and a referrer from Google Search, because Google's help says hackers often target specific user agents or referrers. Both should print 404 or 410. Then run a live test on the same address in the URL Inspection tool. That request comes from Google, so trust it over curl.

    bash
    curl -s -o /dev/null -w "%{http_code}\n" https://example.com/ltjmnjp/341.html
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -e "https://www.google.com/" https://example.com/ltjmnjp/341.html

  2. Step 2: Hide the worst of it with the Removals tool

    This step is optional. In Search Console, open Removals, the "Temporary Removals" tab, then "New Request" and "Temporarily remove URL". Enter the address exactly as it appears in search results, and choose "Remove this URL only" or "Remove all URLs with this prefix". The prefix suits spam that sits in one folder. Google says a request usually takes up to a day to process and is not guaranteed to be accepted.

    The block lasts about six months and applies to Google Search only. It does not stop Google crawling the address and it deletes nothing. The removal is permanent only because the address answers 404 or 410. Use the tool only for addresses the hacker created. Google says not to block your whole site, or pages of your own that you want back in results.

  3. Step 3: Resubmit your sitemap and ask for a recrawl

    Open your sitemap and confirm it lists only your pages. In the Sitemaps report, paste its address into "Add a new sitemap" and select "Submit". On WordPress with no sitemap plugin, that is wp-sitemap.xml. Google treats a sitemap as a hint.

    For the few pages of your own that were altered and matter most, inspect the address in the URL Inspection tool and select "Request indexing". Google says crawling can take anywhere from a few days to a few weeks, and that asking more than once does not speed it up.

  4. Step 4: Request a review if anything is listed

    If the Security issues report lists the hack, fix it on every page, not only on the examples, then select "Request Review". Google asks for three things in the request: the exact issue, the steps you took, and the outcome. Send one request and wait. Google says a request made before the problem is fixed can lengthen the next review.

    Google's help gives the time as a few days to a few weeks. Its guide for hacked sites says a review for spam can take up to several weeks, because it can involve manual investigation or reprocessing the hacked pages. If Google finds the site clean, it says warnings in search results and browsers are removed within 72 hours. A manual action has the same button in its own report.

Progress shows in the Page indexing report. The spam addresses move to the "Not found (404)" reason, which lists addresses that returned 404 in the past month. Google's help counts a 404 for a page you removed as a right reason for not being indexed, so that list growing is the result you want.

What "This site may be hacked" means

Google Search Help says the message appears on a result when Google believes a hacker might have changed some of the site's pages or added new spam pages. It tells searchers they could be redirected to spam or malware, and recommends not visiting until the message is gone.

Google states that the message will not be removed until the site's owner takes action. The route it gives is the one above: verify the site in Search Console, read the example addresses in the Security issues report, fix the hole that let the attacker in, and request a review there once the whole site is clean and secure. Google removes the message after it has checked that the site is fixed.

When to get help

Google's guides recommend getting help with the PHP files if you are new to code. Get help when:

  • a spam address still answers Google after the cleanup;
  • the stranger's ownership returns after you removed it, which means they can still write to the site;
  • you find code you cannot read and have no clean original to replace it with.

Our malware removal service is a one-time clean-up with hardening, a blacklist removal request and a written report.

Common questions

The spam result gives me a 404 when I click it. Is it gone?

Not necessarily. Google's guides warn that a hacked page can show the owner a "not found" message while still serving spam to Google. Run a live test on the address in Search Console's URL Inspection tool. If that also reports the page as not found, the result will drop out when Google crawls the address again.

How long until the spam results disappear from Google?

Google gives no fixed time. An address drops out after Google crawls it again and gets a 404 or 410. A Removals request hides an address sooner: Google says it usually takes up to a day to process, and the block lasts about six months. A review of a Security issues listing can take up to several weeks.

Should I block the spam addresses in robots.txt?

No. Google can only learn that an address is gone by fetching it, and a robots.txt rule stops the fetch. Google's Removals help says not to use robots.txt as a blocking mechanism, and its review guide says pages must be open to crawling so that Google can see they are clean.

I have never used Search Console. Can the hacker be an owner of my site there?

Yes. Ownership can be proved by uploading a file to the site, and someone who can write files to the site can do that. Verify the site yourself, then open Settings and "Users and permissions" to see every owner, and "Ownership history" for when each was added.

More on this subject

Malware removal, done for you

Malware removal is $99. Full clean-up, hardening, blacklist removal request and a written report. 30-day re-clean guarantee. It starts with a free diagnosis.

Get a free diagnosis