SEO Spam: How Hackers Inject It, What Each Check Can See, and How Long Injected Pages Stay in Google
· Royking Niba
SEO spam is content a hacker places on your site so that search engines, not your visitors, see it: thousands of new pages selling counterfeit goods or pharmacy products, hidden links stitched into your existing pages, or redirects that send searchers somewhere else. Google’s spam policies file it under hacked content, “any content placed on a site without permission, due to vulnerabilities in a site’s security.” The fix is a security job first and an SEO job second: close the hole, remove what was injected, make every injected URL return a 404 or 410, and only then ask Google to look again. Below is Google’s own wording, quoted exactly and checked on 17 October 2026, a table of what each detection method can and cannot see, a cleanup sequence in the order that stops a reinfection, and the arithmetic that decides how long injected pages stay in the index.
What Google calls SEO spam
Google’s spam policies (last updated 2026-08-28) do not use the phrase “SEO spam”. They describe the same thing under hacked content and list four forms of it. Knowing which form you have tells you where to look, because each one lives in a different place on the server.
| Form | Google’s description | Where it usually lives | What you see as the owner |
|---|---|---|---|
| Page injection | “Sometimes, due to security flaws, hackers are able to add new pages to your site” | New files at the web root or in a folder, or rows added to the database | Often nothing: the pages are not in your menus or your CMS page list |
| Content injection | “Their goal is to add content to your site that search engines can see” | Theme files, plugin files or post content, often hidden with CSS | A page that looks normal in a browser but carries links in its source |
| Code injection | “they might try to inject malicious code into existing pages on your site” | Core files such as index.php or wp-load.php, or JavaScript added to templates | Sometimes nothing, sometimes pop-ups for some visitors |
| Redirects | “Hackers might inject malicious code to your website that redirects some users to harmful or spammy pages” | .htaccess rules or server-side code that checks the visitor | Your own visits work; visitors arriving from Google are sent elsewhere |
Search Console’s Security Issues report uses a slightly different split. Its help page defines hacked content as “any content placed on your site without your permission because of security vulnerabilities in your site” and names three types: code injection (“A hacker has compromised your site and is injecting malicious code in your pages”), content injection (“A hacker has added spammy links or text to your site’s pages”) and URL injection (“A hacker has created new pages on your site, often containing spammy words or links”). URL injection is what most people mean by SEO spam, and the best documented example of it is the Japanese keyword hack.
The Japanese keyword hack and the pharma hack
Google’s article on fixing the Japanese keyword hack (published on web.dev and still Google’s reference for this hack, although the page carries a 2015 date) describes a hack that “creates new pages with autogenerated Japanese text on your site”, pages that are “monetized using affiliate links to stores selling fake brand merchandise”. Two details in that article explain why owners miss it for weeks. First, attackers “add themselves as a property owner in Search Console”, which lets them submit their own sitemaps and, in some cases, change settings. Second, “Hackers often modify your sitemap or add new sitemaps to get their URLs indexed more quickly.” The pharma hack works the same way with pharmacy keywords instead of Japanese text, and it more often uses content injection into existing pages than brand new URLs.
Both depend on cloaking, which Google’s spam policies define as “presenting different content to users and search engines”. The injected code checks who is asking. Googlebot gets the spam, a visitor who types your address gets the normal page, and a visitor arriving from a search result may be redirected. Google’s own warning in the Japanese keyword article is blunt: “Hackers will try to trick you into thinking the page is gone or fixed when it’s still hacked.” My guide to cloaking covers the mechanics in more depth.
How to find it: what each check can and cannot see
Because the spam is built to hide from the owner, the checks that feel most natural are the least reliable. This table is my own summary of what each method can observe, based on how the four forms above work.
| Check | Sees injected new pages | Sees content cloaked to Googlebot | Sees redirects aimed at searchers | Notes |
|---|---|---|---|---|
| Browsing your own site | No | No | Usually no | The weakest check; the hack is designed to pass it |
| A site: search in Google | Yes, once indexed | Yes, in titles and snippets | Clicking a result may trigger it | Add words like viagra, casino or a Japanese term to narrow it |
| URL Inspection, live test | For URLs you already know | Yes: it shows the HTML Googlebot received | Shows the final destination | Google’s own recommended cloaking check |
| Performance report, filtered by page or query | Yes, if they earn impressions | Indirectly, through the queries | No | Queries in a language you do not publish in are a strong sign |
| Security Issues report | When Google has detected it | When Google has detected it | When Google has detected it | An empty report does not mean a clean site |
| Search Console users and sitemaps | Indirectly: unknown sitemaps list the spam URLs | No | No | An owner you did not add is proof of compromise |
| Server files and database | Yes | Yes, in the code doing it | Yes, in .htaccess or code | The only check that finds the cause, not just the symptom |
Google names the files to start with: “Attackers commonly inject scripts into the following files: index.php, wp-load.php, 404.php, and view.php.” On the .htaccess file its advice is to replace rather than repair: “Unless you have custom .htaccess rules, consider replacing your .htaccess with a completely new copy.”
The cleanup sequence
The order matters more than any single step. If you delete spam pages before closing the entry point, they come back, and the Japanese keyword article cites a study finding that “20% of hacked sites are hacked again within one day.” This is the sequence I follow.
- Keep evidence. Take a full copy of the files and the database before you change anything, so you can find the entry point later.
- Take back Search Console. Under Settings, then Users and permissions, remove any owner you did not add; Google’s advice is to “revoke their access as soon as possible”. Then delete any sitemap you did not submit.
- Close the entry point. Update the CMS, every plugin and theme, remove anything unused, change every password (hosting, FTP, database, CMS admins) and turn on two-factor authentication.
- Remove the injected material. Compare core files with clean copies, replace .htaccess, delete unknown files and admin users, and search the database for the spam keywords and for script tags in post content and options.
- Make every injected URL return 404 or 410. Not a redirect to the homepage. A redirect to an unrelated page tells Google nothing useful about the spam URL, while a 4xx is the documented removal signal (more below).
- Verify as Googlebot. Run URL Inspection live tests on a sample of spam URLs and on your key pages, and check the HTML Google received, not what your browser shows.
- Request a review if the report lists issues. Google’s instruction: “When all issues listed in the report are fixed in all pages, select Request Review in the Security Issues report.” Its stated timing: “A review can take from a few days to a few weeks to complete.”
- Speed up removal where you can. Use the Removals tool for any spam that sits under a shared prefix, then keep watching the Performance report for spam queries for at least three months.
A security review is not a manual action, and the two are handled in different reports. If Search Console also shows a manual action, the reconsideration process is a separate step, covered in manual action or algorithmic demotion.
Why 404 or 410, and how long the spam stays indexed
Google’s HTTP status code documentation (last updated 2026-02-04) is explicit: “URLs that are already indexed and return a 4xx status code are removed from the index.” It also settles the 404 against 410 debate for Google Search: “All 4xx errors, except 429, are treated the same.” The catch is that removal happens when Google recrawls each URL, and the same page warns that for such URLs “The crawling frequency gradually decreases.” So the index clears at the speed Googlebot revisits the spam, not at the speed you deleted it.
Here is a model with stated assumptions, not a client case. Assume 12,000 injected URLs were indexed, and that after cleanup Googlebot revisits some fixed number of them per day. Each recrawl returns a 404 and removes one URL.
| Spam URLs recrawled per day (assumed) | Days until all 12,000 have been seen once | What it means |
|---|---|---|
| 1,000 | 12 | A site Google crawls heavily: the spam is mostly gone in two weeks |
| 400 | 30 | A typical small business site: about a month |
| 150 | 80 | A low-authority site: close to three months of spam in the results |
Two simplifications are worth stating. The model holds the daily rate constant, while Google says crawl frequency for these URLs falls over time, so the real tail is longer than the table suggests. And it assumes every recrawl hits a different spam URL, which is the best case. Treat the three figures as floors.
When the Removals tool helps, and when it cannot
The Removals tool hides URLs from Google’s results while the recrawl catches up, but its help page is clear that it is temporary: “A successful request lasts only about six months”, and “Using the tool alone won’t work.” Its useful feature for SEO spam is the prefix removal, which “blocks all URLs beginning with the specified prefix”. Whether that helps depends entirely on how the hacker named the injected URLs.
| How the injected URLs are named | Shared prefix? | Removals tool | What to rely on |
|---|---|---|---|
| All inside one new folder, such as /shop-jp/… | Yes | One prefix request hides them all | Prefix removal now, 404s for the permanent fix |
| A fixed parameter, such as /?page_id=…&jp= | Only if the prefix is unique to spam | Possible, but check it does not also cover real pages | Test the prefix against your real URLs first |
| Random file names at the web root, such as /a8x2k.html | No: the only shared prefix is your whole domain | One URL per request, impractical at thousands | 404s and recrawl only |
| Hidden links inside your real pages | Not applicable | Do not use it: it would hide your real pages | Clean the pages and let Google recrawl them |
The third row is the common case for URL injection, and it is why the recrawl arithmetic above matters: when the spam has no shared prefix, there is no shortcut, and the only lever left is helping Google recrawl, mainly by keeping the server fast and the 404s consistent. The crawl errors guide explains why a burst of 404s after a cleanup is a normal outcome rather than a new problem.
Will rankings come back?
Usually, if the spam was removed completely and quickly. The damage from SEO spam comes from three places: Google’s warning labels and interstitials while the issue is open (the Security Issues help page says affected pages “can appear with a warning label in search results”), the spam pages competing with and diluting your own, and visitors who bounce off a redirect. All three stop once the site is clean and the review succeeds. What does not come back on its own is trust from visitors who saw a warning, which is one more reason to move fast. If traffic stays down after the spam has cleared from a site: search, the cause is probably something else, and the diagnosis steps in my Google penalty recovery guide apply.
SEO spam checklist
- Run a site: search with spam terms, and filter the Performance report for queries in languages you do not use.
- Check Search Console owners and sitemaps; remove anything you did not add.
- Inspect suspicious URLs and your homepage with a URL Inspection live test.
- Compare index.php, wp-load.php, 404.php and view.php with clean copies, and replace .htaccess.
- Patch, update, change every password and turn on two-factor authentication before deleting anything.
- Make every injected URL return 404 or 410, never a redirect to the homepage.
- Request a review in the Security Issues report once every listed issue is fixed.
- Use a prefix removal only when the spam shares a prefix your real pages do not.
- Watch for reinfection daily for the first week, then weekly for three months.
Related reading
- Google Penalty Recovery: how I diagnose and reverse a traffic collapse
- Cloaking in SEO: what Google counts and how it is detected
- Manual action or algorithmic demotion: how to tell which one hit you
- Negative SEO: what a real attack looks like in the data
- Crawl errors: what each one destroys and what to fix first
- Soft 404: why Google flags it and how to fix it
Leave a Reply