Hacked Site Injection

What hacked site injection is

Hacked site injection is what happens when someone who is not you gains write access to your website and uses it to publish. Not to deface it - defacement is loud, and this is deliberately quiet. The intruder adds spam pages (URLs on your domain that you never created, usually in directories you have never opened), hidden links inside templates you did create, or code that decides what to serve based on who is asking: your ordinary page for you, a wall of pharmaceutical or gambling keywords for a search engine crawler.

The entry point - the vector, meaning the specific route by which access was obtained - is almost always ordinary. An out-of-date content management system. A plugin, a third-party code module bolted onto a CMS to add a feature, left unpatched for two years. A hosting, admin or FTP credential - File Transfer Protocol, the decades-old file transfer protocol that still ships enabled on a great many hosting accounts and still sends its passwords in the clear - reused from a service that was breached elsewhere. An upload handler that never checked what it was accepting.

Google's spam policies define hacked content as "any content placed on a site without permission, due to vulnerabilities in a site's security" and name four sub-types, in Google's own words:

• Code injection - "When hackers gain access to your website, they might try to inject malicious code into existing pages on your site."
• Page injection - "Sometimes, due to security flaws, hackers are able to add new pages to your site that contain spammy or malicious content."
• Content injection - "Hackers might also try to subtly manipulate existing pages on your site", by adding hidden links or text.
• Redirects - "Hackers might inject malicious code to your website that redirects some users to harmful or spammy pages."

(Google, spam policies for Google web search, last updated 28 August 2026.)

The oldest and best-known variant is the pharma hack - injected pharmaceutical keyword pages and links, so common in the early 2010s that it named the category. The two variants Google documents most heavily now are the Japanese keyword hack and the cloaked keywords and links hack.

Why this works when a link attack does not

Almost every other attack in this reference is an attempt at persuasion. A spam link blast asks Google to hold you responsible for pages on somebody else's server. Anchor text poisoning asks it to believe your page is about something disgraceful. Those attacks depend entirely on a ranking system agreeing to draw a conclusion, and since Penguin 4.0 in 2016 Google's stated behavior toward unearned inbound links has been to devalue them rather than act against the site they point at. The attacker is arguing, and the referee has stopped listening.

Injection argues with nobody. The spam is served from your domain, over your certificate, inside your templates, carrying whatever authority your site has spent years accumulating. Google is not being asked to attribute a stranger's content to you. It is correctly attributing your own server's output to you, which is exactly what a search engine is supposed to do. There is no misjudgment to appeal and no algorithm to convince.

That distinction is the finding this whole site keeps arriving at, and it is worth stating plainly on the page where it bites hardest: the attacks that genuinely work are the ones that compromise your own infrastructure, not the ones that try to talk a link algorithm into blaming you. Devaluation protects you from what happens on other people's servers. Nothing protects you from what happens on yours.

One honesty point the reader deserves. The usual motive here is money, not sabotage. Most injections are parasitic: the intruder is borrowing your domain's credibility to rank their own spam, and has no idea who you are. But the damage is identical whether they wanted your traffic or your ruin, and the same access supports either intention. Diagnose the access, not the motive.

The evidence, and how old it is

Google's most detailed public numbers on this are now dated, and I would rather say so than present a 2016 measurement in the present tense. In the #NoHacked: A year in review post of 20 March 2017, Google reported a 32% increase in hacked sites in 2016 over 2015, said it could not notify 61% of affected site owners because their sites were not verified in Search Console, and reported that 84% of owners who submit a reconsideration request after cleaning up succeed (as reported by Search Engine Land and Search Engine Journal on the same day). Google has published no equivalent annual figure since. Treat 32% as a 2016 datum. Anyone quoting a current "X% of websites are hacked" statistic is almost certainly quoting a security vendor's own customer base, which is not a random sample of the web.

The 61% is the number that has aged best, because it describes a structural gap rather than a rate: for most hacked sites, Google knows and the owner does not. Verification in Search Console is free, takes minutes, and is the only notification channel that exists.

The detail that gets missed most often sits in Google's own remediation guidance for the Japanese keyword hack: "The hacker will typically add themselves as a property owner in Search Console, to increase profits by manipulating your site's settings like geotargeting or sitemaps." That is not a side effect. It is direct control of your relationship with Google - the ability to change your targeting, submit sitemaps of injected URLs, and file removals - and it survives a file cleanup untouched.

Recovery is slow by design. Google's published expectation is that "Reviews for sites hacked with spam can require up to several weeks" - against "a few days" for malware and "about a day" for phishing (Google, Request a review). Spam injection is the slowest of the three to clear even after a flawless cleanup, which is why a failed review is so expensive: each cycle costs weeks, not days.

Nothing about this vector has been neutralized the way link attacks were. Penguin 4.0 and SpamBrain changed how Google treats inbound links from other people's sites; neither has any bearing on content Google fetches from your own. The 2013 answer and the 2026 answer are the same answer.

How to look at your own site the way Googlebot sees it

This is the section that matters, because the cloaking is the whole point of the attack. Injected code routinely branches on the user agent, on the referring search engine, on the visiting IP address, or on whether a session cookie is present. The owner loads the homepage, sees the site they built, and concludes the report is wrong. It is not wrong. They are simply not the audience the payload was written for.

Google prescribes the comparison directly, in its guidance on cloaking: compare the content fetched by Google to the content seen by a human user. Concretely, in current Search Console:

• URL Inspection, then "Test live URL", then view the crawled page and its HTML. This fetches the URL as Googlebot and shows you the response Google actually receives. It is the only check that settles the question, and it must be run against the suspicious URLs, not the homepage.
• Search Console, Performance report. Look at the query list, not the totals. Impressions accruing for a language you do not publish in, or a vertical you have nothing to do with, is usually the fastest confirmation available. On this attack the character of the query set changes, not just its volume.
• Search Console, Pages report. A sudden jump in indexed URL count, and unfamiliar directory names in the URL samples.
• The site: operator combined with commercial keywords you would never publish - Google's own fix steps recommend exactly this search.
• Server-side evidence. File modification times, unexpected files, a modified .htaccess carrying conditional rewrite rules, unfamiliar cron entries, sitemap files you did not generate.

Two traps. First, Google's hacked-site guides warn that "Hackers will try to trick you into thinking the page is gone or fixed when it's still hacked" - a URL can return a clean 404 to your browser and a spam page to Googlebot, so a manual spot-check proves nothing. Second, a note on the documentation itself: Google's hacked-site remediation articles now live on web.dev, several still carry a last-updated stamp from 2015, and parts of them describe a fetch tool that was retired with the old Search Console and no longer exists. The sequence those guides teach is current and correct. Where they name a tool, use URL Inspection's live test instead.

Security Issues, not Manual Actions - and why the difference matters

The most common triage error on this subject is looking in the wrong report and concluding nothing is wrong. Hacked content surfaces in the Security Issues report, whose first listed category is "Hacked content: Any content placed on your site without your permission because of security vulnerabilities" (Google, Security Issues report). A manual action - a penalty applied by a human reviewer at Google and shown in the separate Manual Actions report - is a different mechanism with a different remedy. Filing a reconsideration request when no manual action is outstanding accomplishes nothing and delays the diagnosis by weeks.

Two cautions about that report. Google warns that its sample URL list "is not necessarily complete" and that an issue can appear "with no example URLs; this does not mean that no pages are affected." Treat the samples as a starting point and never as an inventory. And in Search Console's Settings, open Users and permissions and read the list of verified owners. An owner you do not recognize is the tell for the Search Console takeover described above, and it is checked far too rarely.

In the results themselves, affected pages can carry the label "This site may be hacked", which Google says appears when it believes a hacker might have changed existing pages or added new spam pages, and that a visitor to such a site could be redirected to spam or malware. A label telling searchers your site may harm them costs clicks at every position you still hold.

How it is undone, in the order that works

The order is not a preference. Steps performed out of sequence are the reason cleanups fail and reviews get rejected.

1. Preserve evidence before you touch anything. Copy access logs, error logs, a file listing with timestamps, and a full archive of the site to storage the intruder cannot reach. Remediation destroys the only record of who did this and when. If this ever becomes a legal matter, this step is the case.
2. Quarantine if malware is being served. A holding page while you work is cheaper than the accumulating harm of a live payload.
3. Revoke access before you clean, never after. Rotate every credential - hosting, database, CMS admin, FTP and SSH keys, API tokens - and remove unrecognized verified owners from Search Console. Cleaning files while the intruder still holds a working credential just hands them a fresh copy of your site.
4. Find the vulnerability, not just the symptoms. Google sequences its own guides this way for a reason: identify the entry point, then clean. Restoring a backup without patching restores the backdoor along with the content.
5. Rebuild rather than patch where you can. Reinstall CMS core files from clean sources, replace .htaccess with a known-good file, reinstall plugins and themes from their vendors, then reapply your own customizations.
6. Return honest status codes for the injected URLs. 404 or 410 them. Do not mass-redirect thousands of spam URLs to your homepage.
7. Verify with the live URL Inspection test, not with your browser. The cloaking was aimed at Googlebot, so the verification has to be performed as Googlebot.
8. Consider the Removals tool only as a stopgap. Google is explicit that a successful request lasts only about six months and does not stop Google crawling the page, only showing it. It suppresses; it does not repair.
9. Request Review in the Security Issues report, saying specifically what you removed and how the entry point was closed. Then wait out the several weeks.

What does not help: disavowing anything, because the disavow tool addresses inbound links and this is your own content; filing a reconsideration request with no manual action outstanding; blocking the hacked directories in robots.txt, which prevents Google from ever seeing that they are clean and can leave the URLs indexed without content; and deleting logs to tidy up.

On most pages of this site there is a case for doing nothing. This is not one of them. Inaction here is unambiguously wrong, and the cost compounds daily.

Recourse, and what it is realistically worth

Unauthorized access to a website is a computer-crime matter before it is an SEO one. The federal hook in the United States is the Computer Fraud and Abuse Act, 18 U.S.C. 1030, which reaches unauthorized access to a protected computer; state computer-crime statutes generally parallel it. Your host is worth contacting for forensics and log retention, and so is the host of whatever destination the injected links or redirects point at.

Now the realistic part. For an opportunistic compromise arriving from a botnet, attribution to a person is effectively impossible, and no report you file will speed up the cleanup. The cases where recourse is real look different: a former employee, contractor or agency using a credential that was never revoked. That fact pattern is far more common than people expect, and it is the reason step one is preserving logs rather than deleting them. Logs are what turn a suspicion into a claim.

Google offers exactly one channel that lifts a security flag, and it is the review request inside the Security Issues report. There is no escalation path, no form that accelerates it, and no relationship that gets a site to the front of the queue. Anyone who tells you otherwise is selling access that does not exist.

Where I come in on a case like this is the part that is neither the developer's job nor the security vendor's: establishing what Google actually sees, distinguishing a compromise from a core update in the traffic data, sequencing the cleanup so a review is not wasted, and documenting the incident well enough to survive a legal or insurance question later. This practice sells recovery from attacks and nothing else. I have been working in search since 1996, and injected spam is the one vector where I have never seen waiting improve the outcome.

Frequently asked questions