The Japanese keyword hack: removing it from WordPress, properly.

None of this requires being a developer, but it does require working through the list in order — skipping the backdoor step is the single most common reason this hack comes back a few weeks after people think they have removed it. If you landed here without knowing yet whether you are actually compromised, start with our complete guide to what to do when your website is hacked for the full incident-response checklist — this page picks up from there with the Japanese-spam variant specifically.

It is a WordPress compromise that turns your site into a spam-hosting platform without changing what your regular visitors see. An attacker exploits a vulnerability — usually an outdated plugin or theme, a weak admin password, or an exposed upload feature — to plant malicious PHP code on your server. That code dynamically generates hundreds or thousands of fake pages, typically written in Japanese, linking to counterfeit-brand shops, gambling sites, or affiliate scams.

The pages are usually cloaked: the malicious code checks whether the visitor is a search-engine crawler and serves the spam content only to Googlebot, while showing your normal site (or redirecting) to human visitors. That is why the hack can run for months undetected — your traffic and your own visits to the site look completely normal.

To get the spam pages indexed quickly, the attacker typically also does one or both of the following:

• Submits a rogue XML sitemap listing every spam URL, either by dropping a file like sitemap-jp.xml or wp-sitemap-2.xml on your server and pointing your robots.txt at it, or by submitting it directly through Search Console if they gained access to your account or added themselves as a verified owner.
• Adds a rogue admin account in WordPress so they can keep re-deploying the malware even after you delete individual files, and sometimes so they can access Search Console itself if it is linked through a plugin on the site.

Two quick checks confirm it in under five minutes, before you touch anything on the server.

1. Search Google for your own domain

In a new browser tab, search site:yourdomain.com (replace with your real domain, no spaces after the colon). Scroll through the results. Titles or descriptions containing Japanese characters, or URLs with random strings you do not recognize, confirm the hack. Try a few pages of results — spam pages are often not on page one.

2. Check the Security Issues report in Search Console

If your site is already verified in Google Search Console, open Security & Manual Actions → Security Issues. A confirmed compromise usually shows explicitly as something like “hacked content” or references cloaked pages, along with a handful of sample hacked URLs. Those sample URLs are useful evidence — note them down, you will use them to find the injected files in a later step.

If you are not yet verified in Search Console, verify ownership now (a free Google property, no cost, no login for your visitors) — you will need it both to see the damage and to request review once you are clean.

Before touching files, remove the attacker’s ability to walk straight back in. This step alone stops active, ongoing damage while you clean the rest.

• Search Console → Settings → Users and permissions. Remove any owner or user you do not recognize. Attackers who gain admin access to WordPress can sometimes verify themselves as a Search Console owner too.
• Search Console → Settings → Ownership verification. Check every verification method listed (HTML file, meta tag, DNS record, Google Analytics, Google Tag Manager). Remove any method you did not set up yourself — a stray verification file is a common way attackers keep quiet access to your property.
• Change your hosting/cPanel and FTP/SFTP password now, even before you start cleaning files. If the password was weak, reused, or old, assume it is compromised.
• Put the site behind maintenance mode if your host or a plugin supports it, rather than taking it fully offline — you still want to inspect the live file system and database as you clean.

Connect to your server with SFTP or your host’s file manager. Before deleting anything, download a full copy of wp-content, wp-includes, wp-config.php, and your root directory to a folder on your own computer — that is your evidence and your fallback if something goes wrong.

Sort by modified date

Most SFTP clients and file managers let you sort a directory listing by last-modified date. Files changed recently that you did not personally touch are the strongest lead. Pay particular attention to:

• wp-content/uploads/ containing any .php file. The uploads folder should only ever hold images, documents, and media — a PHP file there is almost always malicious.
• Your active theme’s functions.php or header.php. Attackers commonly append obfuscated code to the bottom of these files rather than creating a whole new file, since it survives casual inspection.
• Files inside wp-includes/ with names close to real WordPress files but not part of core — attackers disguise backdoors here because the folder looks legitimate and is rarely checked by hand.
• The root .htaccess file. Look for added rewrite rules that redirect only certain user agents or referrers — this is often the mechanism behind the cloaking itself.

Search file contents for obfuscation patterns

If your host’s file manager supports searching file contents (or you can use an SFTP client with that feature), search across the whole WordPress install for these function names, which are near-universal wrappers for hidden malicious code: base64_decode, gzinflate, str_rot13, eval(, assert(, system(, and shell_exec(. Legitimate plugins occasionally use one or two of these, so verify each hit before deleting — but a long unreadable string wrapped in eval(base64_decode(…)) inside a theme file is essentially never legitimate.

In your WordPress dashboard, go to Users and sort by registration date. Look for any administrator account you and your team did not create — attackers frequently name these to blend in (a common first name, or a near-copy of a real staff username). If your dashboard access is itself compromised, check the same information directly in the database via phpMyAdmin: the wp_users table for accounts, and wp_usermeta for the wp_capabilities field to see who actually holds the administrator role.

Delete any account you do not recognize (reassign its content to a real user first if needed), then reset the password for every remaining legitimate admin account — do not assume the accounts you kept were never touched.

Also check Tools → Scheduled Actions or a cron-inspection plugin for scheduled tasks you did not create. Some backdoors use WordPress’s own cron system to silently re-create themselves on a timer, which is why files can reappear even after you delete them once.

Hand-editing every infected file is slow and risks missing something obfuscated. The more reliable approach:

• Replace WordPress core (wp-admin and wp-includes) with a fresh download of your exact version from WordPress.org, or update straight to the latest version if you were already behind.
• Replace every plugin and theme with a fresh copy from the official plugin directory, theme marketplace, or original developer — not by editing the infected copy. Delete any plugin or theme you do not actively use entirely; unused, unpatched software is extra attack surface for no benefit.
• Delete anything in wp-content/uploads/ that is not media — no legitimate plugin needs a PHP file there.
• Check the database for injected content. Some variants of this hack store the spam pages directly in the wp_options table (in an autoloaded option) or inside post content, rendered dynamically by a hooked function, rather than as separate files. Search the database for unfamiliar large text blobs or Japanese characters if your search tool supports it.

Once the malware itself is gone, update everything — core, every remaining plugin, every theme — immediately. The vulnerability that let the attacker in the first time is almost always still there until you patch it, and leaving it open is the most common reason this exact hack returns.

Finally, rotate every credential: WordPress admin passwords, hosting and database passwords, any API or SMTP keys stored in wp-config.php, and regenerate the WordPress security keys and salts in that same file. Regenerating the salts invalidates every existing login session immediately — including the attacker’s, if they were still logged in.

Rogue sitemaps are how the spam pages got indexed so fast, and they will keep feeding Google new spam URLs until you remove them. In Search Console, open the Sitemaps report and look for any submission you did not make — often named something like sitemap-jp.xml, an extra numbered sitemap you don’t recognize, or one pointing at a path that no longer matches your site structure.

• Delete the rogue sitemap file itself from your server (it was placed there as part of the injected files in Step 2).
• Remove the rogue sitemap entry from the Sitemaps report in Search Console.
• Check robots.txt in your site root for a Sitemap: line pointing at anything other than your real sitemap, and remove it.
• Confirm your legitimate sitemap (usually generated by an SEO plugin like Yoast or Rank Math, or WordPress’s built-in /wp-sitemap.xml) only lists your real pages, then resubmit it in Search Console so Google has a clean map to re-crawl from.

Only do this once every step above is genuinely complete — files replaced, rogue accounts and backdoor removed, credentials rotated, sitemap cleaned. Requesting review on a site that is still infected typically results in a rejection and a longer wait before Google will look again.

• Open Security & Manual Actions → Security Issues in Search Console, and click Request Review.
• Briefly describe what happened and exactly what you fixed — the vulnerability you found, the files you removed, and that credentials have been rotated. Specific beats vague here.
• Submit and wait. A review typically takes anywhere from a few days to a couple of weeks; you will get an email from Google once it clears (or if it is rejected, with a reason).
• For faster relief on specific spam URLs while the full review is pending, use the separate Removals tool in Search Console to temporarily hide those exact URLs from search results — this is quick (often within a day) but temporary, and does not replace the Security Issues review.

If you are comfortable following the steps above and have some technical confidence, DIY cleanup genuinely works — this hack is well understood and the steps in this guide cover it. Where people get stuck is confirming the entry point and verifying there is no remaining backdoor, which is exactly what a manual audit checks. Bug Circuit’s $49 one-time audit is built for small WordPress sites and will identify the exact vulnerability that let the attacker in; the $299 Signal plan (currently discounted for launch) goes further and has our engineer fix the high and critical issues with you, then keep watch for 3 months so a repeat attempt gets caught early. See the full breakdown on the pricing page.

The malware is only half the problem — if the vulnerability that let the attacker in stays open, the hack typically returns within weeks. Once you are clean, lock these down:

• Update WordPress core, every theme, and every plugin the moment updates are available, and remove anything you do not actively use — an inactive plugin is still exploitable.
• Enforce strong, unique passwords and two-factor authentication on every account with publish or admin access, not just the main admin.
• Block PHP execution inside wp-content/uploads/ at the server level — legitimate uploads are never PHP files, so this closes an entire class of injection without affecting normal use.
• Limit login attempts and consider restricting /wp-admin and wp-login.php by IP if your team works from stable locations.
• Keep offline, versioned backups so you have a known-clean restore point — a backup taken after the site was already compromised is not a clean copy.
• Check Search Console monthly, or run our free passive security check periodically. It looks at what your site exposes publicly — headers, TLS, visible software versions, exposed panels — at no cost and with no login, so a repeat compromise gets caught in days, not months.

This hack is one specific symptom of a broader problem: WordPress sites get compromised through the same handful of entry points over and over. If yours has been hit before, or keeps coming back after cleanup, our guide on why a WordPress site keeps getting hacked walks through the recurring causes in more depth.