A WordPress Japanese keyword hack can leave you with a confusing mismatch: Google shows unfamiliar shop pages or Japanese titles under your domain, while your homepage looks normal. Do not start by changing Yoast titles or deleting every unfamiliar URL. First establish whether the spam still exists on the site, survives in a cache, or remains only in Google’s older view.
Japanese text alone does not prove a hack. Legitimate translations and user content can also appear in search. The warning is content you never authorized: unrelated products, unexpected paths, or search visitors reaching a different destination. The language does not identify who caused it.
This guide gives you a safe evidence path, a cleanup handoff, and a way to separate website recovery from search-result recovery. It is not a claim that a specific plugin, host, or recent update caused your problem.
Why a WordPress Japanese keyword hack can hide from you
Google describes this attack pattern as unauthorized pages with Japanese text appearing in search, sometimes alongside unwanted Search Console owners. Its overview of common hacked-content patterns also explains cloaking: different visitors can receive different content.
That makes a normal-looking homepage weak evidence. You may be checking the wrong URL, a logged-in response, or a cached version. Equally, a spam title in Google can outlast the cleanup. Neither observation settles the whole case.
Start with three exact examples from search. Record each full URL, the unwanted title, the date you saw it, and whether it belongs to a real business page. Do not follow suspicious shopping links, download files, or enter credentials on the destination. Keep the examples in a private incident record.
Separate live spam, cached spam, and old search results
Use the same example URL throughout the comparison. A clean homepage and a suspicious product path are not a before-and-after test. Ask your developer or host to compare the public response with the underlying site and cache records when those disagree.
Evidence-to-action decision table
| What you can verify | What it means | Next safe action |
|---|---|---|
| An unauthorized URL still serves spam or sends visitors elsewhere | The unwanted public behavior remains active | Preserve evidence and arrange containment and cleanup |
| The underlying page is clean, but a public cached response contains spam | Cache state is part of the remaining problem | Verify the cleanup first, then refresh each responsible cache layer |
| A fake URL now returns a genuine 404 or 410, but Google still lists it | Google may still hold an older indexed result | Keep the correct response and monitor recrawling; investigate new examples separately |
| A real business page is clean, but its Google title is still wrong | The page needs a current inspection, not automatic deletion | Check rendered content and metadata, then request recrawl when appropriate |
| Only an unfamiliar language appears, with no unauthorized content confirmed | The evidence is incomplete | Check translation settings and content ownership before calling it a compromise |
These are working branches, not a malware verdict from one request. If the output changes by browser, visit, or route, preserve that difference. Avoid declaring recovery from a single clean screenshot.
What to inspect in Search Console
Open your verified property directly. Start with Security issues, then check Manual actions. They serve different purposes. Google’s Security issues guidance explains how reported problems, example URLs, and a review fit together. No listed issue is not a certificate that every page is clean.
- Inspect an exact affected URL. Compare Google’s indexed information with a live test where available. Save the fetch and indexing details.
- Review submitted sitemaps. Investigate entries you do not recognize. Do not delete a legitimate sitemap because it contains an unfamiliar filename.
- Review users and permissions. Confirm every owner and user with the business before removing access. Have a specialist check the underlying verification method if ownership is unauthorized.
- Look for related affected pages. Group examples by path and behavior, not just by the language of their titles.
A malicious URL need not appear as a normal WordPress post. Sucuri documented a case where a hidden sitemap sustained Japanese spam after an apparent cleanup. That is evidence from its investigation, not proof your site has the same mechanism. It does show why checking only Posts and Pages can miss part of the problem.
What to preserve before cleanup
Ask for a private snapshot of the current files and database, relevant access and error logs, and the affected URL list before changes. Keep a known-good backup separately. A fresh backup preserves evidence; it does not make an infected site safe to restore.
Also record the last known clean date, recent administrator or hosting changes, installed component versions, and the earliest available suspicious activity. Do not post logs publicly: they can contain personal data and authentication material.
The cleanup owner should investigate the entry point, unwanted files or database content, persistence, and affected access. Updating a vulnerable component may close one route while leaving injected content behind. Conversely, deleting visible spam without addressing its source can allow it to return.
Stop DIY deletion if you cannot distinguish injected material from order data, customer records, custom code, or legitimate translations. Restoring an old database can lose newer orders and enquiries. Use a tested recovery plan instead of assuming the newest backup is clean.
Do not confuse removal, security review, and re-indexing
These Google actions are not interchangeable. Choose the action after deciding whether the URL should still exist.
Which Google action fits?
| Situation | Appropriate path | What it does not do |
|---|---|---|
| A hacker-created page should never exist | Remove the unwanted content and return a real 404 or 410 | It does not clean other files or guarantee immediate disappearance from search |
| Confirmed fake URLs need urgent hiding from search | Consider a narrowly scoped temporary removal alongside permanent cleanup | It does not remove the infection or permanently erase a URL by itself |
| A legitimate page is repaired and should appear in search | Verify the live page, then request indexing once | It does not guarantee indexing, ranking, or restored traffic |
| Search Console reports a security issue or manual action | Fix the stated problem and use the review process in that report | A normal indexing request is not a substitute for that review |
Google’s Removals documentation says temporary hiding lasts about six months. It also warns against using robots.txt as the permanent removal method. Do not block your entire domain or a broad legitimate directory to hide a few fake pages.
For a repaired business page, keep useful content at its original URL when appropriate. Check its canonical, title, description, and indexing directives. Google’s recrawl guidance explains that requests do not guarantee inclusion and repeated submissions do not make crawling faster.
How to decide whether recovery is complete
Agree on two separate checkpoints with whoever does the work.
- Website checkpoint: the investigated unwanted behavior is gone; affected access and the identified cause are addressed; caches serve the intended version; important business paths still work.
- Search checkpoint: repaired pages remain eligible, fake URLs return the intended response, any required review has a recorded status, and later Google observations show progress.
Recheck the original examples and a fresh sample after cleanup. Test contact forms, login, and relevant commerce paths through an approved test process. A website that no longer shows spam but cannot accept an enquiry is not a complete business recovery.
If new spam URLs appear or clean pages change again, reopen the investigation. Do not treat repeated cache purges or removal requests as the cure. If only old search snippets remain, record Google’s last crawl before assuming a reinfection.
When professional WordPress recovery makes sense
You can collect the initial examples yourself. Professional help becomes useful when ownership is unclear, unwanted responses persist, search and live pages disagree, or cleanup must preserve orders and custom functionality.
Webless offers hacked WordPress site recovery. Review the current scope there, then share the symptoms through the contact path. Ask for a clear record of what was found, what changed, what was tested, and what still depends on Google’s processing. No responsible recovery plan can promise a particular ranking or instant removal from every search result.
If your main symptom is a redirect rather than unwanted indexed pages, the separate WordPress spam-redirect guide covers that starting point. Both symptoms can coexist, but they should not be assumed to have the same cause.