How to Investigate Japanese SEO Spam in WordPress

You search for your own domain and find Japanese-character titles or URLs that nobody on your team remembers publishing. The homepage and a few familiar articles look normal when you check the dashboard. That mismatch often leads owners to remove URLs from search first, replace every file, or run a bulk database query without finding out whether the pages came from posts, rewrite rules, or a process that will create them again.

The short answer: treat unfamiliar Japanese-language URLs as indicators to verify, not a final diagnosis. Preserve samples and timestamps, inspect Security Issues and Manual Actions separately, gather URLs from several sources, then map the slugs to WordPress objects and server layers. Find the process or unauthorized access that created them, clean the source and persistence in a controlled way, test again, and only then address index effects. Google describes new pages, hidden content, injections, and redirects as forms of hacked content, but your technical response should follow the evidence on your own site (Google Search spam policies).

First confirm that the content is actually unauthorized

“Japanese SEO spam” is a common label for spam pages containing Japanese text, product phrases, or unrelated links. Google documents one pattern known as the Japanese keyword hack: automatically generated Japanese pages under random directory names, often with affiliate links. That is a clue to investigate, not proof that every case shares every indicator (Google guide to the Japanese keyword hack). A Japanese-language site, a store serving Japanese customers, or a legitimate multilingual article may also contain those elements for good reasons. Check each sample against the content owner, publication calendar, catalog, translation plugin, and business activity before calling it a compromise.

Stronger indicators appear in combination: random or mass-generated slugs, an unknown post author, clustered creation times, links to unrecognized domains, pages that appear only for certain requests, a new administrator, or file/configuration changes without a matching work ticket. One clue is not enough by itself. Record what you observed and separate facts from hypotheses. “This URL appears in Google” is a fact; “a particular plugin must have published it” is not proven yet.

Do not treat Japanese text as a technical category. A URL might map to a post, page, custom post type, attachment, dynamic rewrite, or response assembled by files and database values. Those cases have different cleanup paths. If you also find other compromise signals, use our hacked-website response guide as the wider incident framework; this article focuses on mapping spam URLs to their source.

Preserve evidence before cleanup

Create a list of each sample URL, visible title or snippet, timestamp and time zone, discovery source, response status, and the person who verified that the content is unauthorized. Save a screenshot or Search Console export and relevant logs. Record when the URL first appeared, whether a redirect occurred, the device and browser used, and whether the session was signed in. Do not put cookies, tokens, customer data, or private query values into a public ticket.

Before changing tables, plugins, .htaccess, or files, ask an administrator to preserve copies of the database and files. Store them outside the webroot with restricted access, and ensure they are not synced into a repository or public download folder. If visitors are being sent to phishing or malware, ask the host for a suitable temporary containment measure. Do not open an unknown redirect destination and do not ask customers to click a dangerous URL just to reproduce it.

Open the Security Issues report and Manual Actions report separately. Security Issues can contain security findings and sample URLs; Manual Actions concerns enforcement of spam policies. One report’s status does not prove the status of the other. Record the property and check date so another operator can repeat the review.

Build a URL inventory, not just one Google search

A site:example.com search may help find some pages that are already visible, but it is not always complete and does not show every URL stored by the server. Use several sources: Search Console samples, the main sitemap and any unfamiliar sitemap, visitor reports, access logs, WordPress post/page lists, internal routes, and CDN or WAF logs. Export URLs into a private worksheet and label them “verified legitimate”, “suspected spam”, “redirect”, or “not checked”. Do not assign “delete” before an owner confirms the content is unauthorized.

Group patterns, not just URL counts. Record path prefixes, suffixes, query strings, date patterns, language, and whether the URL uses a taxonomy or pagination. A /product/... pattern may come from a custom post type; a pattern without a matching post may be created by a rewrite rule or script. Compare creation times with logs, file changes, account activity, and deployment events. If Search Console supplies examples, URL Inspection can help review indexed status and run a live test, but it follows redirects before testing the page and does not replace a server-side investigation (URL Inspection tool).

Preserve the original URL value; do not store only a decoded or normalized version. Unicode characters, percent encoding, slashes, case, trailing slashes, and query strings may make similar-looking URLs map to different handlers. Do not paste a URL into a browser if its destination or parameters may be unsafe. Use approved logs and staging for reproduction.

Map URLs to WordPress objects

Run inventory commands only with authorized access, preferably on a private copy or staging site. wp post list can return IDs, types, statuses, titles, slugs, and dates; check every relevant content type, not only post. Limit output fields because titles and content can contain personal information. For example:

wp post list --post_type=any --post_status=any --fields=ID,post_type,post_status,post_title,post_name,post_date

The official documentation describes the --fields option for wp post list. Match the listed slugs to URL patterns. For each match, record the ID, post_type, status, author ID, creation/modification date, and whether a trustworthy revision exists. A custom post type may belong to a legitimate business plugin; confirm with its owner before changing or deleting it.

If no post has the slug, do not assume WordPress is clean. Check taxonomies, rewrite rules, route-registering plugins, templates, mu-plugins, drop-ins, themes, REST endpoints, unexpected PHP files, and server/CDN rules. For strings or option values, start with a copy of the database and a read-only query that accounts for the table prefix. Use the site’s actual prefix, not the assumption wp_; multisite may have per-site prefixes. Do not print the entire wp_options table into a shared terminal or ticket because it can contain configuration and secrets.

A URL matching one database row does not explain who wrote it. Compare fields and revisions with logs, user activity, component changes, and configuration. If a search finds code in a serialized value, preserve the option name and enough context; do not overwrite serialized data with a raw SQL REPLACE().

Find the mechanism that created the pages or URLs

Review WordPress users and roles, Application Passwords, admin sessions, SSH/SFTP, hosting accounts, deployment keys, DNS, CDN, vendor access, and logs. Match those logs to object creation times rather than reading them in isolation. Verify core files with the relevant official checksums, then inspect active and inactive plugins/themes, mu-plugins, drop-ins, uploads, server settings, and new files that do not fit their purpose. Core checksums do not cover every custom plugin, database value, hosting configuration, or third-party script.

Check scheduled WordPress events with WP-CLI and ask the host to review system cron or jobs that are not visible in the dashboard. Look for unfamiliar sitemaps, route rules, or integrations that publish content automatically. Do not run an auto-cleaning scanner before preserving a copy and confirming its effect. If a URL returns after deletion, stop repeating the deletion and find its persistence mechanism; purging cache, flushing permalinks, or changing the display does not close persistence.

If evidence points to an unknown account or component, record its ID, timestamps, permissions, and related logs first. Revoke access that is confirmed unauthorized, replace or update the affected component from a trusted source, rotate credentials from a clean device, and inspect the same events and URLs again. Ask the host for help if you cannot access relevant logs, server configuration, or distinguish origin requests from CDN responses.

Clean the source and verify the result

Choose an action for each verified finding: edit legitimate content that was injected, restore a post from a clean revision, remove an unauthorized spam object, fix the route or script that generated it, or restore a file from a trusted copy. Do not delete all content that contains Japanese characters. Make changes reversible: record the file or record, approver, backup used, and test result. If a database change is needed, test it on a private staging copy, compare before and after, then get approval before applying the fix in production.

After cleanup, repeat the URL inventory using the same initial list and add new samples from logs. Test the paths in an anonymous browser and relevant language/device, but do not follow a dangerous destination. Check responses, rendered content, sitemap, cache, URL Inspection, login/role, and Search Console. Confirm the source does not recreate URLs after cron runs or cache changes. Record the intended response for each removed URL; do not hide every path in robots.txt, which can prevent crawlers from seeing the cleanup response.

Once the source is genuinely clean, use Removals only when temporary visibility handling is appropriate. It does not remove a post, file, rewrite, or persistence mechanism from the server. If Security Issues reports a problem, request a review through that report after resolving all findings and explain the cause, work, and verifiable outcome. Do not promise an indexing timeline or send repeated requests before an outstanding review is decided.

Prevent the spam from returning

Limit administrator accounts, require MFA where supported, review integrations that can publish content, update supported components, and remove unused plugins/themes only after checking dependencies. Separate credentials per operator, keep off-site backups, test restores, protect logs from application changes, and define who may change DNS, sitemaps, and Search Console. Monitor new URLs and role changes as signals for human review, not as automatic delete commands.

Create a short response procedure that names the hosting contact, backup location, Search Console owners, cleanup approver, and secure log collection method. For broader WordPress hardening after recovery, see our guide to securing a small-business WordPress site. Regular audits are more useful when they preserve a baseline of routes, accounts, components, and legitimate integrations; without that baseline, routine changes are harder to distinguish from new ones.

Frequently asked questions

Do Japanese words in Google results prove that the website was hacked? Not always. A multilingual site or owner-created content may be legitimate. Compare unfamiliar URLs and snippets with WordPress content, owners, logs, and Search Console before deciding there was a compromise.

Will a site: search show every infected page? No. Treat it as a discovery clue, not a complete inventory. Compare it with Search Console, sitemaps, site routes, database records, logs, and visitor reports.

Can I bulk-delete every spam URL from the database? Not based on a single word or pattern. Export the database, verify each record and owner, test on a copy, and find the process that created it. Deleting without closing persistence can repeat the problem or damage legitimate content.

When should I ask the host or a specialist for help? Immediately if redirects endanger visitors, URLs return after cleanup, evidence points to server or account access you do not recognize, or you cannot distinguish legitimate data from payloads. Preserve evidence and ask for help without opening unsafe links.

If unfamiliar Japanese URLs have appeared across many routes or keep being recreated, request a website security audit so database, files, accounts, and rules can be mapped before bulk deletion.