The Japanese keyword hack is an infection that creates Japanese-language spam pages under your domain so they can rank in Google. The pages are often cloaked, meaning Googlebot sees them while you see a normal WordPress page, so an empty-looking site does not rule it out. Remove the infection, make the fake URLs return the right error, and secure the access route that allowed it in.
What the Japanese keyword hack does
The Japanese keyword hack uses your domain's reputation to advertise unrelated products, services, or search terms. It may create thousands of URL paths that look like directories and pages your site never had, or it may generate the content only when a crawler requests it. Search results can show Japanese titles and descriptions even if the visible site is entirely in English.
The goal is not usually to change your home page. The attacker wants search traffic, which is why this is commonly a search visibility problem before it becomes an obvious visitor-facing problem. A conventional WordPress dashboard review may miss it.
Treat the result as a real compromise. The same access can leave backdoors, create WordPress administrators, alter files, or give someone control of your Search Console property. Start with a backup of the current files and database so you preserve evidence and have a rollback point. Then use a measured hacked WordPress cleanup process instead of deleting unfamiliar files one at a time.
Confirm whether Google is indexing the spam
The quickest public check is a Google site: search. Search for site:yourdomain.com, then look through several result pages for Japanese titles, unfamiliar paths, and pages that do not fit your business. Repeat the search with a Japanese word copied from a suspicious result if one appears. A normal site search does not show every indexed page, but it is a useful early signal.
Google Search Console gives you a better view of what Google has discovered. Check the Pages report for unexpected indexed URLs, sitemaps you did not submit, and spikes in discovered or excluded URLs. Open a few suspicious URLs in URL Inspection. The inspection result can show whether Google indexed the page and what canonical URL it selected.
Also check who can administer the property. In Search Console, open Settings, then Users and permissions, and inspect both users and owners. Remove an owner you did not add only after you have secured the site and your ownership verification method. If an attacker added a verification file, DNS record, tag, or another method, remove that method too when it is not yours. Otherwise they may retain access to the property after the WordPress cleanup.
Keep a short list of example spam URLs, affected queries, suspicious sitemap URLs, and dates. It makes it easier to verify that the cleanup and removals worked.
Look in the places this infection commonly hides
The malicious code must run before it can serve a different page to Google. Start by comparing the site to known-good WordPress, plugin, and theme packages. With WP-CLI available, wp core verify-checksums identifies modified or unexpected core files. Reinstall core, plugins, and themes from trusted sources rather than trusting a single changed line to be the only problem.
Check .htaccess in the WordPress root and in relevant subdirectories for unfamiliar rewrite rules, PHP handlers, encoded strings, or rules that route crawler requests somewhere else. Review index.php as well. Core index.php is small, so large additions or unfamiliar includes deserve investigation. On a server that uses Nginx or Apache virtual-host configuration, review the active site configuration too. A clean WordPress directory cannot fix a redirect or rewrite rule placed at the server level.
Search PHP files for recently changed code and for unexpected PHP outside normal WordPress locations. Pay particular attention to wp-content/uploads, where PHP should not normally be stored, plugin directories, mu-plugins, and files with names intended to blend in. Infected PHP can be injected into an existing file, so do not limit the search to newly created files.
Generated sitemaps are another frequent clue. Inspect the XML sitemap index that your domain exposes and the sitemap entries listed in Search Console. Spam infections sometimes add a standalone sitemap file, alter a generated sitemap, or use a PHP file that produces a different sitemap for crawlers. Delete only the malicious sitemap or generator after you have identified the code creating it. Otherwise it can return on the next request.
Clean the site in the right order
The reliable fix is to replace compromised components and remove persistence, not simply remove the indexed URLs. Put the site in maintenance mode if you can do so without interrupting necessary recovery work, and restrict WordPress and hosting access to trusted people.
- Save a full copy of the files, database, access logs, and the suspicious URLs before making changes. Do not restore that copy over the cleaned site later without checking it.
- Change WordPress administrator passwords, hosting panel passwords, SFTP or SSH passwords, database credentials, and API keys that may be exposed. Force password resets for all legitimate administrators.
- Review WordPress Users for unknown administrators and remove them. Check any hosting-level users, scheduled tasks, deployment keys, and Search Console users as well.
- Replace WordPress core with a fresh copy of the same current version, then reinstall every plugin and theme from its official or trusted source. Remove plugins and themes you do not use, including inactive copies.
- Remove injected code and malicious files only after you have traced what loads them. Check
.htaccess,index.php,wp-config.php, plugin and theme files,mu-plugins, uploads, and server configuration. - Review the database for unfamiliar options, injected content, unknown administrator records, and spam URL generators. Database cleanup matters because PHP cleanup alone can leave a payload that writes itself back.
- Update WordPress, every retained extension, and the active theme. Confirm the original weak password, vulnerable extension, abandoned plugin, or compromised host account is no longer usable.
If you find a suspected PHP backdoor but cannot establish what it loads or how it was reached, preserve it for analysis rather than guessing. A thorough WordPress malware removal review can identify persistence across files, the database, and configuration.
Remove Japanese spam URLs from Google
Cleaning stops new spam responses, but Google still needs to recrawl old URLs. Every fake URL should return 404 Not Found if it never existed, or preferably 410 Gone when you can confidently mark the spam URL as permanently removed. Do not redirect all of the bad URLs to the home page or a generic category page. That obscures the problem and is not a replacement for a proper not-found response.
Use the Removals tool in Search Console for urgent, temporary hiding of prominent spam URLs or prefixes. It is useful for reducing visibility while Google processes the cleanup, but it does not delete the hacked content or remove it from Google's index permanently by itself. The correct status code and a clean crawlable response do that over time.
After changes, inspect several former spam URLs in Search Console and request indexing for important legitimate pages that may have been affected. Monitor Pages, Security Issues, and sitemap reports for new suspicious patterns. Retain the list of sample URLs until the reports are stable.
Prevent the hack from returning
Prevention starts with reducing the ways code and credentials can be changed. Keep WordPress core, plugins, and themes current, and remove unused components instead of leaving them installed. Use unique passwords and multi-factor authentication for hosting and WordPress accounts where available. Limit administrator access to people who need it.
Keep regular, tested backups outside the same hosting account. Review file changes, administrator accounts, Search Console permissions, and error logs after an incident. A practical WordPress hardening checklist can help turn those checks into a repeatable maintenance routine.
File permissions should allow WordPress to operate without making everything writable. Avoid using 777 to solve an update problem, and investigate why ownership or permissions are wrong instead. If agencies or vendors have access, remove credentials and deploy keys when their work ends.
When to get help
Get help when spam returns after cleanup, the server configuration is unfamiliar, or the site handles customer information. West Oakbridge can help with WordPress malware removal and a follow-up security audit to identify the entry point and remaining exposure.