WordPress SEO spam is content a hacker plants on your site to rank their pages, not yours. It usually shows up as thousands of Japanese product pages, pharma or casino pages, or hidden links that only Googlebot can see. You often won’t spot it in wp-admin. You spot it in Google, with a site: search, or in the Security Issues report in Search Console.
The fix has three parts. Remove the spam and the backdoor that created it. Make the spam URLs return 404 or 410 so Google drops them. Then request a review if Search Console flagged the site.
This post is about spam aimed at search engines. If your visitors are being bounced to scam sites, that’s a different infection with different hiding spots, and I cover it in WordPress hacked redirect.
What Does WordPress SEO Spam Look Like?
The type of WordPress SEO spam changes where the code lives and how you clean it. When I audit a hacked site, before touching a single file, I figure out which one I’m dealing with. Four variants cover nearly everything I see on WordPress sites.
| Variant | What you notice | Where the spam usually lives |
|---|---|---|
| Japanese keyword hack | Thousands of indexed URLs in random folders, Japanese titles, fake brand goods | A PHP file that generates pages on the fly, plus .htaccess rewrite rules |
| Pharma or casino pages | English spam titles (pills, betting, loans) under your domain | Injected PHP files, fake plugins, or new rows in the database |
| Cloaked links and keywords | Your pages look normal, but Google’s cached or inspected version has spam links | Code that checks the visitor’s user agent and only prints spam to crawlers |
| Spam inside real posts | Old posts suddenly carry hidden outbound links | Injected into wp_posts content or a widget in wp_options |
Google’s own guide to the Japanese keyword hack describes it as autogenerated Japanese text in randomly named directories, monetized with affiliate links to stores selling fake brand merchandise. That matches what I see. The URLs look like /ltjmnjp/341.html, and none of them exist as posts in WordPress.
Is It a Hack or Just User-Generated Spam?
This is the first branch, and it matters because Google treats the two differently. Search Console has a Security Issues report for hacks and a separate Manual Actions report for spam policy problems.
If the spam came from outside your login system, meaning files you never uploaded, pages that aren’t in wp-admin, or links you never wrote, it’s a hack. Google’s Security Issues report files this under labels like “Hacked: URL injection” (new spam pages) and “Hacked: Content injection” (spam added to existing pages).
If the spam came through a normal feature, like comments, forum posts, open registrations or user profiles, it’s user-generated spam. The Manual Actions report lists “User-generated spam” and “Site abused with third-party spam” for exactly this. The fix there is moderation and locking down sign-ups, not malware removal.
If you’re not sure, check your users list first. A new administrator you don’t recognize means it’s a hack, full stop. Honestly, in my experience most WordPress SEO spam falls on the hack side.
Where Do I Look First?
This is the main path for confirming WordPress SEO spam. I run these checks in order, because each one is free and takes minutes.
- Search
site:yourdomain.comin Google. Add a spam word if the list is long, such assite:yourdomain.com viagraorsite:yourdomain.complus a Japanese brand term you’ve seen. Google’s hacked-site guides recommend this exact check. - Open Security Issues in Search Console. If Google found hacked content, it lists sample URLs. Those samples are your breadcrumbs.
- Check Settings, then Users and permissions. Google’s Japanese hack guide warns that hackers often verify themselves as owners of your property. Remove anyone you don’t know, and remove their verification token too.
- Open the Sitemaps report. Hackers submit their own sitemaps so Google finds the spam pages fast. An unfamiliar sitemap file is a strong sign.
- Look at the Performance report. Filter queries for spam terms. Sudden clicks on “cheap replica” queries tell you roughly when the hack started.
If you find spam URLs in the index but nothing in Security Issues, don’t relax. Google doesn’t flag every infection. I still treat the site as hacked and move to the next step.
Why Can’t I See the Spam on My Own Site?
Because it’s cloaked. Google’s spam policies describe cloaking as showing different content to search engines and people, and give the example of inserting keywords only when the requester is a search engine. The hack serves Googlebot a spam page and serves you a 404 or your normal homepage.
So your browser tells you nothing. Use the URL Inspection tool, click Test Live URL, and view the tested page. That shows the HTML Googlebot actually receives.
You can also check from a terminal. This only requests the page with a crawler-style user agent, it doesn’t touch the server:
curl -s -A "Googlebot/2.1 (+http://www.google.com/bot.html)" https://yourdomain.com/suspicious-path/ | head -50
If the curl output shows spam and your browser doesn’t, you’ve confirmed cloaking. If curl shows a clean page too, the hack may be checking Google’s IP addresses, not just the user agent. In that case URL Inspection is the only reliable view, so trust it over curl.
Branch 1: Spam Pages That Don’t Exist in wp-admin
This is the Japanese keyword hack and most pharma hacks. The spam URLs return content, but there’s no matching post or page in WordPress. That tells me a file is generating them.
Google’s cloaked keywords guide says this hack uses your .htaccess file to route requests to an injected PHP file, and names index.php, wp-load.php, 404.php and view.php as common targets. So I start there. I compare .htaccess against a clean WordPress default and look for rewrite rules that point to a PHP file I don’t recognize.
Next, I look for PHP files that changed recently or live where they shouldn’t, like PHP inside wp-content/uploads. These commands only read and list files:
wp core verify-checksums
wp plugin verify-checksums --all
find . -name "*.php" -mtime -14 -print
find wp-content/uploads -name "*.php" -print
grep -rlE "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content/
In order, those check core files against WordPress.org checksums, check WordPress.org plugins for modified files, list PHP files changed in the last 14 days, list PHP files inside uploads (there should be none), and flag common obfuscation patterns.
A match on the last grep isn’t proof. Some legit plugins use base64_decode. What I’m looking for is a file with a random name, a very long single line, or a date that lines up with the first spam queries in Search Console.
If the checksums fail on core files, don’t edit them. Replace /wp-admin and /wp-includes with fresh copies of the same WordPress version, which the WordPress.org hacked-site FAQ says you can replace safely. If a plugin fails, delete it and reinstall from WordPress.org.
Branch 2: Spam Inside Real Posts
This branch looks different. Your real URLs rank, but they now carry hidden links or blocks of pharma text. The files may be clean. The spam lives in the database.
I search post content and options for the spam terms and for hidden styling. Replace the wp_ prefix if your site uses a different one:
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%display:none%' OR post_content LIKE '%casino%'"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%casino%'"
Swap “casino” for whatever spam term you saw. If only a handful of posts are affected, clean them by hand in the editor and check revisions. If hundreds are, restore the database from a backup taken before the first spam query appeared, then re-apply any real content you published since.
Branch 2 still needs a file check. Something wrote to the database, and that something (a stolen admin login, a vulnerable plugin, a backdoor) is still there until you find it.
The Cleanup Order I Follow
Order matters more than people think. Clean the files but leave the backdoor, and the WordPress SEO spam comes back. Here’s the sequence I use.
- Take a full backup of the infected site first. Files and database, stored off the server. Google’s cloaked keywords guide says to back up before starting, and the WordPress.org FAQ adds that even an infected copy helps if cleanup breaks something.
- Change hosting, SFTP, database and wp-admin passwords. Remove unknown admin users.
- Replace core, then reinstall every plugin and theme from clean sources. Delete anything you don’t use.
- Clean
.htaccess,wp-config.phpandwp-content/uploads. Remove stray PHP files. - Clean the database (Branch 2 above).
- Find the way in. An outdated plugin, a nulled theme, a reused password. If you skip this, you’re scheduling the next hack.
- Change passwords again and rotate the WordPress salts. The WordPress.org FAQ says to change passwords after the site is clean, and new secret keys force everyone to log out.
wp config shuffle-saltsdoes the rotation. - Scan again. I use one plugin scanner and one remote scanner, because they see different things.
On scanners: Wordfence’s free plugin compares core, theme and plugin files against the WordPress.org repository, though its plugin page says free users get firewall rules and malware signatures 30 days late. Sucuri SiteCheck is a free remote scanner, and Sucuri says it only sees what’s visible at the browser level, not server-side files. Neither replaces a manual look.
How Do I Remove Spam URLs From Google?
Cleaning WordPress SEO spam off the server doesn’t clean Google’s index. The spam URLs stay listed until Google recrawls them and sees they’re gone.
Make every spam URL return 404 or 410. Once the generator file is deleted, most spam paths return 404 on their own. I prefer 410 Gone for known spam folders because it states the page is gone on purpose, and Google’s Removals help page accepts either code as a permanent removal. Check a few with curl -I.
Don’t redirect spam URLs to your homepage. Google tends to treat that as a soft 404, so the URLs linger and get recrawled. And don’t block them in robots.txt either. Google’s Removals help says not to use robots.txt for permanent removal, because Googlebot then can’t see the 404.
Use the Removals tool only for speed. Google says a successful removal request “lasts only about six months.” It hides URLs from results while the 404s do the real work. For thousands of URLs, submit a prefix removal for the spam folder instead of one by one.
Resubmit your real sitemap and delete any sitemap the hacker added, then confirm it lists only your canonical, indexable URLs, the core rule in my XML sitemap best practices. Then watch the Page indexing report as the spam count falls. It’s slow. That’s normal.
Should I Request a Review, and Where?
Only request a review when the whole site is clean, not just the sample URLs. Google’s review guidance for hacked sites says reviews for sites hacked with spam “can require up to several weeks,” and the Security Issues help page warns that resubmitting before a decision can extend the wait.
If the issue is in Security Issues, click Request Review there. Write a short, specific note: what you removed, how the hacker got in, and what you changed. Something like “Removed injected PHP files and .htaccess rules, reinstalled core and plugins, updated the vulnerable plugin, rotated passwords and salts.”
If it’s a manual action (user-generated spam or third-party spam), request reconsideration in the Manual Actions report instead. Explain the moderation changes you made.
If neither report shows anything, there’s nothing to request. Clean up, serve 404s and let recrawling take care of it.
Decision Matrix
| If you see | And | Then |
|---|---|---|
Japanese or pharma URLs in site: | No matching posts in wp-admin | Branch 1: hunt the PHP generator and .htaccess rules |
| Spam links on real posts | Files pass checksum checks | Branch 2: clean the database, then find how it was written |
| Spam only in URL Inspection | Browser shows a clean page | Cloaking confirmed, treat as a hack |
| Spam in comments or profiles | No unknown files or admins | User-generated spam: moderate, close open registration |
| Security Issues flag | Site fully clean | Request review with a specific cleanup note |
| Spam URLs still indexed | They return 404 or 410 | Wait for recrawl, use Removals for speed |
When Should You Hand It Off?
If the WordPress SEO spam returns after one cleanup, the backdoor is still there. If your host has suspended the account, or the site handles payments or customer logins, I wouldn’t keep experimenting. Get a WordPress security specialist involved, and ask your host whether other sites on the same account are infected.
That’s work we do at Skyranko under WordPress care and hacked-site repair, quoted after a free audit. If rankings dropped and haven’t come back after cleanup, SEO recovery is the next step. For the prevention side, the routine in my WordPress maintenance checklist covers the updates and backups that stop most of these hacks, and my technical SEO checklist helps you confirm the site is healthy again.
Frequently Asked Questions
Why Is My WordPress Site Showing Japanese Characters in Google?
That’s the Japanese keyword hack. A hacker placed code that generates Japanese spam pages under your domain, usually in random folders, and often cloaks them so you can’t see them in a browser. Check Security Issues in Search Console, run a site: search, and remove any unknown Search Console owners before you clean the files.
How Long Until Spam Pages Disappear From Google?
It depends on recrawling. Pages returning 404 or 410 drop out as Google revisits them, which can take weeks on a big spam footprint. The Removals tool hides URLs faster, but Google says a removal lasts only about six months, so the 404s must be in place.
Will WordPress SEO Spam Hurt My Rankings?
It can. Google may show a “This site may be hacked” label in search results, and spam pages compete with your real ones for crawling. After cleanup and a successful review, the label is removed. If traffic doesn’t return, look at what else changed during the hack.
Can a Security Plugin Remove SEO Spam on Its Own?
Sometimes, but I wouldn’t rely on it. Plugin scanners catch known signatures and modified files. They can miss database spam, cloaked output and new backdoors. Use one as a second opinion after your own checks, then fix the entry point.
Last updated: September 2026 by Mizanur Rahman
