One morning, Search Console reports thousands of Japanese pages you never wrote, or your clicks collapse for no obvious reason. Your WordPress site may have been hacked to serve SEO spam, often invisible from your own browser. This article explains how these attacks exploit your search rankings, how to spot them with Google's tools, and how to get a review once the site is clean.
Why a hacker cares about your search rankings
An established site, well indexed and linked to by others, has a value the attacker cannot build alone: the trust search engines place in it. By planting their own pages on your domain, they ride on that trust to sell links, push counterfeit stores or redirect to gambling sites. Your traffic is the fuel, your domain name is the storefront. Unlike comment spam, which a WordPress anti-spam plugin can filter, this spam comes from a hack of the site itself.
Google files these practices under "hacked content" in its spam policies, which it defines as any content placed on a site without permission due to security vulnerabilities. Its policies distinguish four forms:
- Code injection: malicious scripts added to existing pages, sometimes inside iframes.
- Page injection: entire new pages filled with spam or malicious content.
- Content injection: text or links hidden in your pages, visible to search engines but not to visitors.
- Redirects: code that sends some visitors to spam pages depending on where they come from, their browser or their device.
The most common families of SEO spam
On web.dev, Google documents several variants that turn up again and again on compromised WordPress sites. Sucuri, for its part, reports that in 2022 more than 40% of the SEO spam detections by its SiteCheck scanner involved pharmaceutical spam injections.
| Variant | What the attacker creates | Typical clue | Where to look |
|---|---|---|---|
| Japanese keyword hack | Auto-generated Japanese pages in randomly named directories, with affiliate links to counterfeit goods | Japanese results in a site: search, an unknown owner in Search Console | Added PHP files, .htaccess, unknown sitemaps |
| Gibberish hack | Pages of nonsensical sentences stuffed with keywords | Visitors redirected to unrelated sites | .htaccess, unknown PHP files |
| Cloaked keywords and links | Pages that reuse your page template with spam text and links | The link seems to lead to a 404, while Google sees something else | Theme, modified core files, database |
| Pharma spam | Pages or links about drugs, served to bots | Drug titles and snippets in Google results | Core files, theme, unknown database tables |
Why you see nothing: cloaking
What these attacks share is cloaking, which Google defines as presenting different content to users and to search engines. The injected code inspects every visit: if it recognizes a search engine crawler, or a visitor arriving from Google, it serves the spam. Otherwise it shows the normal page, or even a fake 404 error. Google's guides put it bluntly: hackers try to make you believe the page is gone or fixed when it is still hacked.
A case analyzed by Sucuri in January 2026 shows the mechanism clearly: code appended to the end of a legitimate PHP file compared the user agent with a list of crawlers (Googlebot, Bingbot, Baiduspider), fetched the spam from a remote server and displayed it only to those crawlers. Ordinary visitors saw a perfectly normal site, with no pop-up and no redirect. The owner found search results overrun with spam only when searching for their own site on Google.
The impact on indexing and traffic
The consequences add up, and they are not limited to the spam pages:
- Thousands of junk URLs indexed under your domain, diluting the crawling of your real pages.
- A "This site may be hacked" label under your result in Google. Google Search Help advises users not to visit the site until the message is gone, and states that it stays in place until the owner takes action.
- Lost rankings: Google's policies state that sites violating them may rank lower or not appear in results at all.
- A browser warning if the hack also installs malware or phishing, which falls under Google Safe Browsing (see our article on the "dangerous site" warning).
- A possible manual action, separate from the security report, for example "Cloaking and/or sneaky redirects".
Detecting spam with Search Console
Search Console is the tool that sees your site the way Googlebot does. Verify your property if you have not already, then go through these reports:
- Security issues: lists the detected categories (content, URL or code injection hacks, malware, deceptive pages and more) with sample URLs.
- Manual actions: a penalty applied by a human reviewer shows up here, with its own reconsideration process.
- Users and permissions: according to Google's guide on the Japanese keyword hack, a verified owner you do not know is a strong sign of a hack. The attacker adds themselves to change sitemaps or geotargeting.
- Sitemaps: a sitemap you never submitted, full of spam URLs, must be removed.
- URL inspection: test a suspicious URL live. You see what Googlebot receives, including content hidden by cloaking.
- Performance: queries in a language or on topics unrelated to your business often give away junk pages.
Add a site:yourdomain.com search in Google, and in another search engine: scroll through a few pages of results looking for unusual URLs or titles. For the other symptoms of a compromise (unknown accounts, modified files), see our list of signs that a WordPress site has been hacked.
Cleaning up with search rankings in mind
The technical cleanup (backing up the infected site, reinstalling core, plugins and themes, checking the database, changing passwords) is detailed in our step-by-step cleanup procedure. Google's guides stress .htaccess files, often used to redirect or generate the spam pages, and recent, oversized or obfuscated PHP files (base64_decode, eval). On the search side, four decisions matter:
- Let the spam URLs return 404 or 410. Google removes already indexed URLs that return a 4xx code from its index. Do not redirect them to the home page: you would keep thousands of addresses alive for no reason.
- Do not block them in robots.txt. Google could no longer crawl them, so it would never see that they are gone. Its documentation on removals explicitly advises against robots.txt as a blocking method.
- Use the Removals tool with care. It hides a URL for about six months without removing it from the index for good: it is a bandage for the most visible results, not a fix.
- Remove unknown sitemaps and owners, along with their verification token (HTML file or the rewrite rule that generates it).
Requesting a review from Google
Once the site is clean and the vulnerability closed, you submit the request from the Security issues report, with the "Request Review" button. Google asks you to fix the problem on every affected page, not just the examples, and to describe precisely the issue, the steps you took and the outcome. Before sending, use URL inspection to check that Googlebot can crawl the home page and a few former spam URLs, with no blocking and no accidental noindex.
| Step | Time frame stated by Google | Source |
|---|---|---|
| Review of a security issue | From a few days to a few weeks | Search Console Help, Security issues report |
| Review of a site hacked with spam | Up to several weeks | web.dev, "Request a review" |
| Removal of warnings once the site is found clean | Within 72 hours | web.dev, "Request a review" |
| Reconsideration of a manual action | Several days or weeks | Search Console Help, Manual actions report |
Do not send another request until the previous one has received a decision. If it is rejected, there is still spam, a file that regenerates it or an open entry point: start the analysis again rather than rewording the request. Finally, keep your expectations realistic: lifting the flag does not immediately restore lost rankings. Legitimate pages have to be recrawled, and the return of traffic depends on Google, not on a contractual deadline.
Avoiding reinfection
Google's guide on the Japanese keyword hack points out that 20% of hacked sites are hacked again within a day. The cause is almost always the same: the entry point was not closed, or a forgotten file recreates the spam pages on every visit. In practice:
- Identify the vulnerability (vulnerable plugin, reused password, compromised FTP access) before putting the site back online.
- Update core, themes and plugins, and remove the ones that are no longer maintained.
- Enable two-factor authentication on administrator accounts.
- Regularly compare core files with the originals from WordPress.org and keep an eye on new accounts and plugins.
- Run a
site:search and open the Security issues report once a month.
The first-hand account below, in French, shows what this kind of attack looks like from a site owner's point of view.
What WP Masquerade can do
WP Masquerade is neither an antivirus nor a cleanup tool: it does not remove spam that has already been injected. It works before and after the incident. Before, by reducing the clues that point to WordPress and closing common entry points (custom login address, XML-RPC blocked). After, the Pro version helps you spot a compromise sooner: integrity checking of core files, an administrator activity log to see an added account or plugin, vulnerable plugin alerts and email alerts. None of these features guarantees you will never be hacked, but each one shortens the time spam can thrive without your knowing.
Once the site is clean, our guide to optimising WordPress SEO helps you rebuild your visibility.
Key takeaways
- SEO spam exploits the trust in your domain and often hides behind cloaking.
- Check with URL inspection and a
site:search, not just in your browser. - Make spam URLs return 404 or 410, with no redirect and no robots.txt block.
- Request a review only once, after closing the vulnerability: from a few days to several weeks.
- The return of traffic is neither guaranteed nor immediate: the priority is not to get reinfected.
Sources
- Google Search Central, Spam policies (updated August 28, 2026) (opens in a new tab)
- Search Console Help, Security issues report (opens in a new tab)
- Search Console Help, Manual actions report (opens in a new tab)
- web.dev, Fix the Japanese keyword hack (opens in a new tab)
Other sources consulted: official documentation and security research publications.
