How to Fix “Japanese Keyword Hack” in WordPress (The Hard Way)

If Google is showing thousands of fake Japanese pages under your domain, you are likely dealing with the Japanese Keyword Hack, also known as Japanese SEO spam.

This infection usually creates or serves hacked spam URLs designed to manipulate search rankings. Even after you remove the visible malware, the spam URLs can keep wasting crawl activity, polluting search results, and hammering your server with useless requests.

One practical way to contain that damage on Apache hosting is to block obvious spam URL patterns directly in .htaccess and return 410 Gone before WordPress does the heavy work.

If you need the broader cleanup path too, see my Japanese SEO spam removal service and my case study on removing 10,500 SEO spam URLs from Google in 12 days.

Quick answer

If your hacked WordPress site is generating large volumes of spam URLs, a targeted .htaccess firewall can help by:

• returning 410 Gone for known spam patterns,
• reducing the amount of traffic that reaches WordPress and PHP,
• making cleanup of indexed junk easier to manage.

But this only works well if the rules are site-specific and carefully tested. A bad rule can block legitimate URLs, break logins, or create more SEO problems than it solves.

What is the Japanese Keyword Hack?

The Japanese Keyword Hack is a form of SEO spam where attackers inject or generate large numbers of fake pages, often using Japanese text, spammy product terms, or junk query parameters. These pages are meant for search engines and can damage your rankings, brand trust, and crawl efficiency.

In many cases, the homepage still looks normal to the site owner. The hacked content only becomes obvious when you search Google with site:yourdomain.com or inspect strange indexed URLs in Search Console.

When this .htaccess method makes sense

This approach is useful when:

• your site runs on Apache or LiteSpeed and supports .htaccess,
• the spam URLs follow clear repeatable patterns,
• WordPress-level blocking is too slow or too heavy,
• you want to stop obvious spam requests before they hit PHP.

This is not the right approach if:

• your server uses Nginx and ignores .htaccess,
• you have not yet identified which URL patterns are actually spam,
• the rules would also catch legitimate product or page URLs,
• you are trying to solve reinfection without removing the real malware.

410 vs 404: what is the real difference?

Both 404 Not Found and 410 Gone tell search engines that the content should not be indexed. In practice, 410 can be a slightly stronger “this is permanently gone” signal, which is why many cleanup specialists prefer it for hacked spam URLs.

But it is important not to overpromise this. 410 is not an instant purge button. Google still decides when to recrawl and drop the URLs. If you need faster temporary hiding in search results, use the Search Console Removals tool alongside the correct server response.

If you want a deeper explanation of when to use each status code, read my guide on 404 vs 410 and why Google may not forget deleted pages.

Before you edit .htaccess

• Back up your current .htaccess file.
• Confirm you are on Apache or LiteSpeed.
• Make sure you can restore the file quickly from hosting file manager or SSH.
• Test the rules on a staging copy first if the site is business-critical.
• Review real spam URLs from Search Console or access logs before writing patterns.

One wrong character in .htaccess can break your entire site, so caution matters here.

Step 1: Return a lightweight 410 response

If spam bots are hammering the site, you do not want WordPress generating a heavy themed error page for every request. A small built-in 410 response can help reduce load.

# Lightweight 410 response
ErrorDocument 410 "410 Gone"

This keeps the response minimal. It is not pretty, but it is practical for hacked spam cleanup.

Step 2: Add a safe whitelist for critical access paths

Before blocking patterns, protect the paths you do not want to interfere with, especially login and admin access.

<IfModule mod_rewrite.c>
RewriteEngine On

# Allow normal admin and login access
RewriteCond %{REQUEST_URI} ^/wp-admin/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-login.php [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-json/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-cron.php [NC]
RewriteRule .* - [L]

If your site uses custom login URLs, membership endpoints, checkout flows, or headless routes, add those too before you block anything else.

Step 3: Block obvious spam keyword requests

If your indexed junk URLs clearly contain spam terms, you can block those patterns at the request level.

# Block obvious spam terms in the raw request
RewriteCond %{THE_REQUEST} "(casino|gambling|viagra|cialis|poker|baccarat|roulette|jackpot|dating)" [NC]
RewriteRule .* - [R=410,L]

This kind of rule is only safe when those terms are truly unrelated to your site. If you run a gambling, dating, or adult-related site, this would obviously be the wrong rule.

Step 4: Block suspicious query-string spam patterns

Many Japanese spam infections create junk URLs with simple one-letter parameters followed by long numbers, such as ?a=83748293. If your logs confirm this pattern, you can block it.

# Block suspicious one-letter parameter + long number patterns
RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]{8,}(&|$) [NC]
RewriteRule .* - [R=410,L]

This is one of the most useful containment rules when the infection is generating endless fake parameter URLs.

Step 5: Block fake directory patterns only if they are truly spam

If the hack is creating predictable fake paths such as /jp/ or junk product folders, you can block those too. But this is where people often overblock their own site, so be careful.

# Example fake directory blocks
RewriteRule ^jp/ - [R=410,L]
RewriteRule ^products/[0-9]+/?$ - [R=410,L]
RewriteRule ^pages/ - [R=410,L]

</IfModule>

Do not blindly block .html URLs unless you are completely sure your real site does not use them. That rule is too aggressive for many WordPress setups.

The safer full example

This example is intentionally more conservative than many copy-paste snippets. Adjust it to match your actual spam patterns.

# --- START JAPANESE SEO SPAM CONTAINMENT ---
ErrorDocument 410 "410 Gone"

<IfModule mod_rewrite.c>
RewriteEngine On

# 1) Safe-list critical endpoints
RewriteCond %{REQUEST_URI} ^/wp-admin/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-login.php [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-json/ [NC,OR]
RewriteCond %{REQUEST_URI} ^/wp-cron.php [NC]
RewriteRule .* - [L]

# 2) Block obvious spam terms when truly irrelevant to your site
RewriteCond %{THE_REQUEST} "(casino|gambling|viagra|cialis|poker|baccarat|roulette|jackpot|dating)" [NC]
RewriteRule .* - [R=410,L]

# 3) Block suspicious one-letter numeric query strings
RewriteCond %{QUERY_STRING} (^|&)[a-z]=[0-9]{8,}(&|$) [NC]
RewriteRule .* - [R=410,L]

# 4) Block known fake directories only if confirmed from logs/Search Console
RewriteRule ^jp/ - [R=410,L]
RewriteRule ^products/[0-9]+/?$ - [R=410,L]
RewriteRule ^pages/ - [R=410,L]

</IfModule>
# --- END JAPANESE SEO SPAM CONTAINMENT ---

What to do after adding the rules

1. Test your homepage, login, admin, and key business pages.
2. Use URL Inspection in Search Console on a few hacked spam URLs.
3. Submit a temporary Removals request for urgent spam cleanup if needed.
4. Keep monitoring access logs to see whether the rules are catching the intended requests.
5. Make sure the underlying malware is actually removed from files, database, users, and cron tasks.

If you stop at the .htaccess layer and ignore the real infection, the spam often comes back later through the same foothold.

This method is containment, not full cleanup

A targeted .htaccess firewall can reduce load and improve cleanup speed, but it does not replace a full hacked-site recovery. You still need to:

• remove malicious code from files and database,
• check for hidden admin users and fake plugins,
• patch the original entry point,
• rotate credentials,
• verify that Google is no longer seeing hacked content.

These related guides may help next:

• How to detect WordPress malware
• How to scan and clean your WordPress database for hidden malware
• Why WordPress malware keeps coming back

When to get expert help

You should escalate if:

• the site has tens of thousands of spam URLs indexed,
• your server is slowing down under spam requests,
• the infection keeps returning after cleanup,
• you are not sure which patterns are safe to block,
• Google is still showing hacked pages even after the malware is removed.

If that sounds like your situation, you can hire me directly or use my Google blacklist removal service if the hack has already damaged search visibility.

Final thoughts

The real value of the .htaccess method is speed and efficiency. Apache can reject obvious spam URL patterns before WordPress loads, which helps protect server resources while you finish the deeper cleanup.

Used carefully, this is one of the most practical ways to contain large-scale Japanese SEO spam on Apache-based WordPress hosting. Just do not mistake containment for full recovery.

FAQ

Is 410 better than 404 for Japanese spam URLs?

It can be slightly stronger as a permanent-removal signal, but it is not magic. Either 404 or 410 can work for removed hacked URLs if they return the correct status consistently.

Will this remove the spam from Google instantly?

No. For urgent visibility cleanup, pair the correct 404/410 response with the Search Console Removals tool, which hides results temporarily while Google processes the permanent state.

Can I use this if my server runs Nginx?

No, not in .htaccess. Nginx does not use .htaccess, so you would need equivalent server rules in the Nginx configuration.

Does this clean the malware itself?

No. It only blocks request patterns. You still need to remove the infection from files, database, users, or cron-based persistence.

Should I block every suspicious pattern I see?

No. Only block patterns you have confirmed are spam. Overly broad rules can break legitimate pages, products, or site features.

I built an open-source .htaccess firewall for this — github.com/mdpabel/japanese-keyword-hack-firewall