A Japanese or pharma SEO spam hack is a type of malware attack that injects thousands of spammy pages — often selling counterfeit drugs or written in Japanese characters — into your website without your knowledge. These hidden pages are served only to search engines, making the infection extremely difficult to spot through normal browsing. Acting quickly is critical: the longer the hack persists, the more damage it does to your search rankings, your visitors' trust, and your standing with Google.

What Is a Japanese/Pharma SEO Spam Hack?

SEO spam hacks, sometimes called "SEO poisoning," are among the most common website attacks tracked by security researchers at OWASP and reported through Google Search Central. Rather than defacing your site visibly, attackers exploit it silently — using your domain's authority to rank spam pages in search results.

There are two main variants:

Japanese SEO spam: Your site begins ranking in Google for Japanese-language keywords. Search results show your domain with titles and descriptions full of Japanese characters, often linking to counterfeit goods stores.
Pharma SEO spam (the "pharma hack"): Your site ranks for terms like "buy cheap Viagra," "online pharmacy," or similar. Clicking the result from Google may redirect users to an online drug store, even though your own site looks normal when you visit it directly.

Both attacks share the same mechanics: the malicious content is cloaked, meaning it is shown to search engine bots but hidden from logged-in administrators and regular visitors. This is exactly why so many site owners discover the problem only after a reader, client, or Google Search Console alert flags it.

How Do Attackers Get In?

Understanding the entry point is essential to prevent reinfection. Common vectors include:

Outdated CMS, plugins, or themes — WordPress, Joomla, and Drupal sites running unpatched components are the primary targets.
Nulled or pirated themes and plugins — These almost always contain backdoors pre-installed by the distributor.
Compromised admin credentials — Weak passwords or credentials stolen via phishing give attackers direct access.
Vulnerable file permissions — World-writable directories (e.g., chmod 777) allow malicious scripts to be uploaded without authentication.
Supply-chain compromise — A plugin or theme updated by a compromised vendor can push malware to thousands of sites simultaneously.

CISA regularly publishes advisories noting that unpatched CMS vulnerabilities are among the top initial access vectors for web-based attacks.

How to Detect a Japanese/Pharma SEO Spam Hack

Check Google Search Console First

If you have not already verified your site in Google Search Console, do so immediately at search.google.com/search-console. Once inside:

Go to Security & Manual Actions → Security Issues. Google will often flag a hacked-with-spam issue directly here.
Go to Security & Manual Actions → Manual Actions. A "Spammy structured markup" or "Cloaked pages" penalty will appear here if Google's reviewers have already found the infection.
Go to Index → Pages and look at your total indexed page count. If you have a 10-page brochure site showing 4,000 indexed URLs, that is a near-certain indicator of spam page injection.

Search Google for Your Site

Open an incognito/private browser window (important — this prevents personalisation from hiding results) and search:

site:yourdomain.com

Look carefully at the titles and descriptions Google shows. If any entries contain Japanese characters, drug-related keywords, or URLs with random strings you don't recognise (e.g., yourdomain.com/cialis-online/xyz123/), your site is infected.

You can also test cloaking directly. Search for:

site:yourdomain.com viagra site:yourdomain.com viagra "buy cheap"

Use Google's URL Inspection Tool

In Google Search Console, paste a suspicious URL into the URL Inspection tool and click Test Live URL → View Tested Page. Switch to the Screenshot tab. This shows you exactly what Googlebot sees — if it differs from what you see in your browser, cloaking is confirmed.

Use the Fetch-As Tool or a Crawler User-Agent

You can simulate a Googlebot request from the command line using curl:

bash curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://yourdomain.com/suspicious-url/

Compare the output to a normal browser request. Significant differences confirm cloaking.

Check Bing Webmaster Tools

Register your site at bing.com/webmasters and check the Security section. Bing often flags the same infections and can surface spam URLs that Google hasn't yet indexed.

Scan Your Site With Security Tools

Run your site through at least two of these reputable scanners:

Google Safe Browsing — transparencyreport.google.com/safe-browsing/search
Sucuri SiteCheck — sitecheck.sucuri.net
VirusTotal URL scanner — virustotal.com
Quttera — useful for server-side file scanning

Note that remote scanners can only see what the server returns to them; they cannot inspect your actual server files. A clean result from a remote scanner does not mean your site is clean.

How to Clean a Japanese/Pharma SEO Spam Hack

Work through the following stages in order. Skipping steps — especially the backdoor search — is the single most common reason sites become reinfected within days.

Stage 1: Take a Snapshot Before Cleaning

Before touching anything:

Back up your current (infected) state. You may need it for forensic analysis later.
Note the date you first detected the infection. Compare file modification times against this date to help identify which files were changed.

Stage 2: Take Your Site Offline (Temporarily)

Put your site into maintenance mode or use your host's control panel to block public access temporarily. This stops attackers from receiving live feedback as you clean, and it protects your visitors from potential redirects.

Stage 3: Change Every Credential — Immediately

Do this before cleaning files; otherwise attackers can re-upload malware while you work:

CMS admin password (WordPress, Joomla, Drupal, etc.)
Database password — update wp-config.php (WordPress), configuration.php (Joomla), or settings.php (Drupal) to match
FTP/SFTP credentials
Hosting control panel (cPanel/Plesk) password
SSH keys — revoke old ones and generate new pairs
Email addresses associated with the admin account

Enable two-factor authentication (2FA) on every account that supports it.

Stage 4: Audit Admin Users

In WordPress, go to Users → All Users and look for accounts you did not create. Attackers routinely create hidden administrator accounts. Delete any you do not recognise.

In MySQL directly:

sql SELECT user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;

Also check your wp_usermeta table for users with wp_capabilities set to administrator that shouldn't be there.

For Joomla, check System → Global Configuration → Users and audit the Super Users group.

Stage 5: Find and Remove Malicious Files

This is the most technically demanding stage. You need server-level (FTP/SFTP or SSH) access to your files.

Look for Recently Modified Files

Via SSH:

bash find /path/to/your/site -type f -name "*.php" -newer /path/to/your/site/wp-config.php -ls

Replace /path/to/your/site with your actual document root (commonly /public_html, /www, or /var/www/html). This lists PHP files modified more recently than wp-config.php. Review each one.

Common Locations for Injected Files

Attackers typically place files in:

/wp-content/uploads/ — this directory is often world-writable and should never contain executable PHP; any .php file here is malicious
/wp-content/themes/your-theme/ — especially in functions.php
/wp-content/plugins/ — inside plugin folders or disguised as plugin files
The site root — look for files with random names like x7hd92.php or names mimicking system files like wp-feed.php, wp-tmp.php

Scan Files for Malicious Code Patterns

Via SSH, search for common obfuscation techniques:

bash grep -rl "eval(base64_decode" /path/to/your/site --include=".php" grep -rl "gzinflate" /path/to/your/site --include=".php" grep -rl "str_rot13" /path/to/your/site --include=".php" grep -rl "preg_replace./e" /path/to/your/site --include="*.php"

Each of these patterns is commonly used to hide malicious payloads. Review every file returned — some legitimate plugins do use base64 encoding, so read the context carefully before deleting.

Check .htaccess Files

The .htaccess file is a prime target for pharma and Japanese spam hacks. It is often used to conditionally redirect Googlebot or users arriving from search results.

Open every .htaccess file on your server (there may be one in the root and one in /wp-admin/):

bash find /path/to/your/site -name ".htaccess" -exec cat {} ;

Look for RewriteCond blocks that reference HTTP_USER_AGENT (targeting bots) or HTTP_REFERER (targeting visitors arriving from Google). A clean WordPress .htaccess looks like this:

apache

BEGIN WordPress

RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress

Anything else should be treated with suspicion and investigated.

Check wp-config.php and index.php

Both files are frequently modified to include malicious require() or include() calls that load external malware files. Compare your versions against the official WordPress core files on wordpress.org/download/.

Stage 6: Clean the Database

Japanese spam hacks in particular often inject content directly into your database — into post content, post meta, or options tables.

In phpMyAdmin or via MySQL CLI, search for suspicious content:

sql SELECT * FROM wp_posts WHERE post_content LIKE '%viagra%'; SELECT * FROM wp_posts WHERE post_content LIKE '%cialis%'; SELECT * FROM wp_posts WHERE post_content LIKE '%casino%'; SELECT * FROM wp_options WHERE option_value LIKE '%base64_decode%';

For Japanese-character injection, search for the Unicode range or simply export your wp_posts table to a text file and open it in a text editor set to UTF-8 — blocks of Japanese characters will be immediately obvious.

Also check wp_options for malicious scheduled events (the cron option) and injected values in siteurl or home that redirect your domain.

Stage 7: Reinstall Core Files From Scratch

Do not attempt to manually diff every core file. Instead:

For WordPress:

Download a fresh copy of WordPress from wordpress.org matching your current version.
Delete and replace all files in /wp-admin/ and /wp-includes/ entirely — these directories should contain no custom code.
Replace root-level files: index.php, wp-login.php, wp-cron.php, wp-settings.php, etc. — but do not overwrite wp-config.php (your database credentials are in there).
Do not replace /wp-content/ as a whole — this contains your legitimate themes, plugins, and uploads. Clean it file by file.

For Joomla: Download clean files from joomla.org and replace core directories (/administrator/, /libraries/, /includes/, etc.).

For Drupal: Download from drupal.org and replace core accordingly.

Stage 8: Update Everything

Once you have clean core files:

Update your CMS to the latest stable version.
Update every plugin and theme — delete any you are not actively using.
Delete any nulled, cracked, or unverified themes and plugins entirely. Do not just deactivate them; remove the files from the server.
Replace your active theme with a freshly downloaded copy from its official source.

Stage 9: Harden the Server

Apply these hardening measures to reduce re-infection risk, as recommended by OWASP's Web Security Testing Guide:

Remove PHP execution from uploads: Add a .htaccess file to /wp-content/uploads/ containing:
```
<Files *.php>
deny from all
</Files>
```
Set correct file permissions:
- Files: chmod 644
- Directories: chmod 755
- wp-config.php: chmod 600
Disable file editing in WordPress by adding to wp-config.php:
```
define('DISALLOW_FILE_EDIT', true);
```
Implement a Web Application Firewall (WAF) — either at the server level (ModSecurity with the OWASP Core Rule Set) or via a cloud service. A WAF can block the automated scanners attackers use to probe your site.
Restrict xmlrpc.php if you do not use it for remote publishing or the Jetpack plugin.

Stage 10: Verify the Clean State

Before going back online and before requesting Google's review:

Use curl with a Googlebot user-agent (as shown in the detection section) on multiple pages and compare against normal browser output — they should now be identical.
Run your site through Sucuri SiteCheck again.
Check Google Search Console's URL Inspection tool on previously flagged URLs — they should return 404 or your normal content.
Search site:yourdomain.com in an incognito window and verify no spam titles/descriptions remain. (Note: Google's index may take days or weeks to fully update.)

How to Request Removal of Spam Pages From Google's Index

Once your site is clean, you need to:

Request a Google review via Search Console:
- Go to Security & Manual Actions → Security Issues, confirm you have fixed the issue, and click Request Review.
- If there is also a Manual Action, go to Security & Manual Actions → Manual Actions and submit a reconsideration request with a clear explanation of what you found and how you fixed it.
Use URL Removal Tool for urgent pages: In Search Console, go to Removals → Temporary Removals and submit specific spam URLs that are actively harming your brand. This is a temporary 6-month suppression but buys time while Google recrawls.
Submit your sitemap again at Indexing → Sitemaps to encourage faster recrawling of your legitimate pages.

Google Search Central's documentation on hacked sites (developers.google.com/search/docs/monitor-debug/security/hacked) is the authoritative reference for the review process timeline and expectations.

Preventing Reinfection

A full recovery means nothing if the same attack recurs in three weeks. Implement these ongoing practices:

Automatic updates: Enable automatic minor-version updates for your CMS, and update plugins and themes within 48 hours of a security release.
**Least-

Japanese/Pharma SEO Spam Hack: How to Detect and Clean It