You search for your business and find your own domain advertising products you’ve never sold. Some titles are in Japanese. Others look like an unrelated online shop.

Then you open your homepage and it looks fine.

That mismatch is worth investigating. It can be a Japanese keyword hack, a type of search spam placed on a compromised site. I wouldn’t treat it as a problem with page titles until I’d checked how those pages got there.

What Japanese keyword spam actually does

An attacker adds content or code that uses your domain to get spam into search results. The pages may be stored as WordPress posts, generated by a PHP script or served through rewrite rules. They don’t have to appear in your dashboard.

The language doesn’t identify the attacker. The useful question is whether your site is serving content you didn’t authorize.

Some attacks use cloaking: search engines and ordinary visitors receive different responses. The code may check the visitor’s device, referrer, cookies or IP address. That’s why opening the homepage once isn’t a reliable test.

There’s another possibility too: the infection has already been removed, but Google is still showing old results. I check both the current server response and what Google has indexed before deciding what needs fixing.

1. Confirm what Google is showing

Start with a search for site:example.com, replacing the example domain with yours. Record a few suspicious URLs and screenshots. This search is useful for spotting problems, but it isn’t a complete index report.

In Google Search Console:

Open Performance, then the search results report. Check Queries and Pages for products, languages or URLs unrelated to your site.
Use URL Inspection on one of the suspicious URLs. Review the indexed information, then use Test live URL and View tested page where available.
Open Security issues for reported hacked content or other threats.
Check Manual actions separately. Not every infection results in a manual action.

A live test is one fetch, not proof of everything every visitor receives. A clean Security issues report doesn’t rule out an infection either.

Don’t follow spam links to unfamiliar shops or download anything from them. You can preserve the URL and investigate your own server without interacting with the destination.

2. Check for access the attacker shouldn’t have

Review Search Console’s Settings, including Users and permissions and Ownership verification. Look for owners or verification methods you don’t recognize.

Confirm with your team before removing access. Remove unauthorized verification methods as well as unauthorized users, following Google’s ownership controls. Don’t accidentally remove the legitimate token that keeps your own access working.

Also review WordPress administrators, hosting accounts and recent changes to DNS or redirects. Search spam can involve more than the files your first scanner flagged.

3. Preserve evidence before removing files

Save a complete copy of the current files and database outside the public web directory. Ask your host to retain access logs and any scanner report with full file paths.

If the site is sending visitors to scams or serving malicious downloads, restrict public access at the host while you investigate. A maintenance plugin inside the infected site may not cover every spam URL.

If this is your first response to the incident, use my hacked WordPress checklist before making irreversible changes.

4. Look beyond the visible spam pages

Places I’d check include:

New or modified PHP files in the web root and wp-content.
Unexpected must-use plugins and plugin or theme modifications.
Rewrite rules in .htaccess or the host’s server configuration.
PHP settings such as auto_prepend_file in .user.ini.
Database posts, options, users and scheduled tasks.
XML sitemaps you didn’t create.

For an authorized administrator working over SSH, these read-only file searches can provide leads:

# XML files near the site root
find . -maxdepth 2 -type f -iname '*.xml'

# Recently modified PHP files
find . -type f -iname '*.php' -mtime -14

# Configuration that may load code before a page runs
rg -n --hidden --no-ignore 'auto_prepend_file'   -g '.user.ini' -g '.htaccess' -g 'php.ini' .

Run them from the site root. The last example needs ripgrep; otherwise inspect those files through SFTP or the host’s file manager.

Don’t delete everything they find. XML files can be legitimate, updates change PHP timestamps, and an attacker can preserve old timestamps. Generated sitemaps may not exist as files at all.

Changing a request’s user agent to Googlebot can sometimes reveal different content, but it doesn’t reproduce a verified Google crawl. A negative result wouldn’t convince me the site is clean.

5. Remove the infection, not just the search results

The cleanup needs to address malicious files, injected database content, unauthorized accounts, persistence and the original entry point. Replace affected core files and components from trusted sources, then patch vulnerable software or secure compromised accounts.

My WordPress malware removal guide explains that sequence and the limits of checksum checks.

After cleanup, test the exact spam URLs you recorded. Pages that never belonged on the site should return a real 404 Not Found or 410 Gone response. A page saying “not found” with HTTP status 200 is a soft 404, not the same thing.

Don’t redirect all spam URLs to the homepage, and don’t block them in robots.txt as a removal method. Google needs to crawl the URLs to see that they’re gone. Clear affected caches only after removing the source of the spam.

6. Clean up the Google side

Once the server is fixed:

Remove unauthorized sitemap submissions in Sitemaps, and remove the malicious sitemap from the server. Removing a submission alone doesn’t delete indexed URLs.
Submit your legitimate sitemap, containing only pages you want indexed.
Use Removals for temporary hiding if visible spam needs urgent attention. Check URL or prefix scope carefully so you don’t hide legitimate pages.
If Security issues reports a problem, request a review after fixing all affected areas and explain what changed.
If there’s a Manual action, follow its separate reconsideration process after resolving it.

Temporary removal isn’t cleanup and doesn’t permanently remove a URL by itself. Returning 404 or 410 for deleted spam allows Google to process the permanent change as it recrawls.

For legitimate pages whose content has been restored, use URL Inspection and request indexing where appropriate. Don’t request indexing for spam URLs you want gone.

What to expect after the fix

Google results can lag behind the live site. There isn’t a fixed recovery time I can promise, and a clean site won’t necessarily regain its previous rankings immediately.

Watch the suspicious URLs, Search Console reports, new files, new users and scheduled tasks. If fresh spam pages appear, go back to the server investigation. That isn’t just Google taking time to update.

I wouldn’t call this solved because the Japanese titles disappeared for a day. I’d want the unauthorized content removed, its access path addressed and the affected URLs returning the right responses.

Want me to take a look?

I offer a free diagnosis based on what I can see from outside your site. Send me the domain and what you’re seeing. Don’t send passwords over WhatsApp. Cleanup is a separate service, with the scope agreed before work starts.

Ask me for a free diagnosis on WhatsApp or see my WordPress security services.

Japanese keyword spam on WordPress: how to remove it