302 Hijacking

What 302 hijacking was

302 hijacking - also called the 302 page hijack or the page hijack exploit - was an attack in which a page on the attacker's domain returned an HTTP 302 response pointing at a page on your site, and the search engine responded by indexing the attacker's URL while displaying your content under it. Your own listing was then suppressed as a duplicate. A visitor clicking the result landed on your page; the address in the search result belonged to somebody else. Hijacking here means precisely that: the takeover of a page's identity in the index by a party with no access to the page itself.

Every sentence above is in the past tense on purpose, and the rest of this page explains why.

The mechanism sat in a genuine ambiguity in the HTTP specification rather than in any bug. A 301 response is a permanent redirect: the resource has moved, so index the destination. A 302 is a temporary one: this content is being served from elsewhere for now, but the original address is the real one and will return. Search engines honored that faithfully - for a 302 they kept the source URL in the index and associated the destination's content with it. That is correct behavior for a site temporarily rerouting its own traffic. Applied across domains by a stranger, it let an attacker assert that a competitor's page was a temporary outpost of the attacker's URL. A zero-second meta refresh produced the same result and was treated the same way.

What was under attack was the engine's canonicalization decision - the choice of which single URL to index when several addresses serve the same content. Nothing on the victim's site had to be compromised, there was no server to secure, and for a couple of years there was no reliable remedy. That combination is why it terrified webmaster forums at the time, and why so much of the surviving writing about it reads as though the sky is still falling.

The date it died, and who signed the certificate

The exploit was documented in reference form in March 2005 by Claus Schmidt, whose write-up noted the problem had already been around for years without being addressed. His diagnosis is worth stating because the fix took exactly the shape he proposed: engines should treat a cross-domain 302 differently from a same-domain one - honoring the specification's semantics within a domain, and treating a redirect from a stranger as an ordinary link.

Within a year, that is what happened. Matt Cutts, then the head of Google's webspam team, described the change as it shipped in a post dated 4 January 2006:

"the vast majority of the time that a search engine receives an off-domain 302 redirect, the right thing to do is to crawl/index/return the destination page."

and, on the deployment itself:

"Google is moving to a set of heuristics that return the destination page more than 99% of the time."

Cutts stated the consequence explicitly in the same post: do that consistently, and there is nothing left to worry about - no more content from one site returned under another site's address. He was candid that the figure was not a hundred percent, because Google reserved the right to prefer the source page in the rare case where that served users better. That caveat is the honest residue of the whole subject, and it is the only thing on this page that is not settled. Read the primary source at Matt Cutts on 302 redirects, 4 January 2006.

The confirmation came five years later. In a discussion reported on 10 November 2011, Cutts said: "way back in the mists of time we had things called '302 hijacks' but I haven't seen any attempts like that succeed in years" (Search Engine Roundtable, 10 November 2011). That was the head of Google's webspam team, unprompted, describing the attack as historical fifteen years ago from today.

The incentive drained away too. Gary Illyes of Google stated in July 2016 that 30x redirects no longer lose PageRank, which removed the secondary rationale people used to justify redirect games in general.

Since 2011 the attack has effectively vanished from the professional literature. Searching for a case of 302 hijacking succeeding in the last decade returns the same 2011 quote and archived forum threads from the 2000s, and nothing else. That silence is itself evidence. An attack still working against ordinary sites would generate a steady flow of help-community reports, and it does not.

The sentence in Google's current documentation that looks like a relapse

A skeptical reader will find this within about ten minutes of research, and if this page did not address it head-on the reader would be right to distrust everything else here. Google's current redirect documentation still describes temporary redirects the old way:

"Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."

That is from Google Search Central's documentation on redirects, and read in isolation it appears to describe the exact condition that made the attack possible: a temporary redirect does not hand canonical status to its destination, so the source URL can stay in the index. Several people have concluded from that sentence that the vulnerability is back.

It is not, and the reason is the other half of Google's model. Canonicalization is no longer decided by the redirect at all. Google groups duplicate pages into a cluster and selects a canonical on the strength of many signals - and it says in the same documentation set that indicating a canonical preference is a hint, not a rule. A throwaway attacker URL brings nothing to that contest: no age, no inbound links, no internal linking, no crawl history, no history of serving anyone. It loses on every axis to an established original.

The precise way to hold this is that the 302 no longer asserts anything. It merely declines to concede. In 2005 the redirect was the deciding vote; today it is one weak signal among many, and the URL casting it has nothing else to offer. Meanwhile the attacker's page - serving your content under its own banner - sits squarely inside the scraped content provisions of Google's spam policies, so the engine's interest runs against them rather than against you.

The one dissent, and why it does not survive contact

Fairness requires naming it. In September 2008 a practitioner published a claim that Google had fundamentally changed its 302 handling and that the hijack was back. The evidence was screenshots and a single asserted instance. There was no systematic analysis, no confirmation from Google, and no third-party replication; Cutts commented on the post but posted only test messages, never a substantive response. No resurgence followed in the eighteen years since.

A 2019 retrospective likewise described the hijack as rare but a persistent vulnerability. It offers no modern evidence for that characterization and no date on which it was last observed.

I record both rather than ignoring them, because a page that only cites its own side is not a reference. But they do not move the verdict. Against them stand a dated description of the fix from the person who shipped it, a dated statement five years later that it had stopped working, and twenty years in which nobody has produced a documented case. Anyone selling you monitoring or protection against 302 hijacking in the current decade is selling protection against an attack that stopped working before most of the sites being sold it existed.

The residual conditions, stated as theory rather than risk

Cutts' figure was more than 99%, not 100%, so intellectual honesty requires listing where the remainder could live. None of these is documented as having been exploited in the modern era, and I am presenting them as theoretical residue, not as a risk profile:

• A brand-new page with no links and no crawl history, where the original has not yet accumulated the signals that win a duplicate cluster. This is the same condition that makes a new page vulnerable to every other duplication attack, and the answer is the same: get indexed quickly.
• A site that is already effectively unindexed - new, blocked, or penalized - leaving no strong competitor for the cluster.
• Search engines other than Google. Every primary source on this page is Google's. Whether smaller engines ever built the cross-domain heuristics is not documented, and I have not researched Bing's handling. Do not generalize beyond Google on my say-so.

Even here I found no documented modern instance. If you believe you have one, the way to establish it is in the next section, and it takes one HTTP request plus one Search Console screen.

What you are almost certainly looking at instead

The symptom that brings people to this page - another URL is showing my content, or my listing has been replaced - has several live causes in 2026, and this is the least likely of them. Working through them in order costs less than an hour.

• Canonical hijacking. The direct modern descendant of this concern, and the profile most readers of this page actually need. A copy on another domain wins Google's canonical selection and your URL drops out. See canonical hijacking for the diagnosis and the fix.
• A copyright delisting. A page that vanishes from search while the site works perfectly, with an empty manual actions report, is the signature of a fraudulent DMCA takedown, not a redirect. Check the bottom of the results page for a removal notice.
• A 301 redirect attack. Pointing a spam domain permanently at a target is a separate, current concern with its own answer from Google; redirect hijacking covers it.
• An ordinary scraper appearing in results without displacing you at all.
• Something entirely legitimate you forgot about - a link shortener, an affiliate, an aggregator, a CDN address, or an old vanity domain of your own still pointing at the site.
• Ordinary ranking movement, including a core update, which moves competitors at the same time and is the single most common explanation for a drop that feels like sabotage.

Two checks separate all of these. First, request the suspect URL and read the raw HTTP response: a status code with a Location header pointing at your domain is a redirect, and anything else is not, no matter what a browser appears to do. Second, inspect your own URL in Search Console and read the Google-selected canonical field. If that field names your own address, nothing has been hijacked by any mechanism, and you can stop.

If you genuinely find a cross-domain temporary redirect

For a modern reader the correct answer is usually to do nothing, and that is clearer here than anywhere else on this site: diagnose the actual problem instead. If a real one turns up, this is the order.

1. Verify it is a redirect. Inspect the status code and the Location header directly. A link is not a redirect and a redirect is not a hijack.
2. Confirm there is any effect at all. Does your URL still rank, and is Google's selected canonical your own? If both hold, the redirect has done nothing and no action is warranted. Stop here; this is where most of these end.
3. Report the page under the scraped content provisions of Google's spam policies if it is serving your material.
4. File a copyright removal request against the offending URL where the copying is genuine and you hold the rights - the fastest lever available, with the caveat that a notice you know to be false creates liability of its own.
5. Send abuse reports to the host and the registrar, which is generally the only route that removes the page rather than its listing.

What does not help, and what actively hurts: disavowing links from the redirecting domain, which is the wrong mechanism entirely; filing a reconsideration request when no manual action exists; switching your own internal redirects from 302 to 301 as a "fix," which addresses nothing about a third party's server, though using 301 for genuinely permanent moves is correct practice on its own merits; adding noindex to your own page; blocking crawlers broadly in robots.txt, which prevents Google from confirming your page is the real one; and rewriting or unpublishing your content.

On recourse: I located no decided case, indictment or regulatory action arising from 302 hijacking anywhere. That is worth stating rather than papering over. The attack was neutralized technically, not legally, and the generic content-misuse theories - copyright infringement, tortious interference, and false designation of origin where the redirect misrepresents affiliation - were never tested on these facts. The classic hijack required no intrusion at all, which is exactly why it fell outside the computer-crime statutes people reach for first.

What people get wrong about 302 hijacking

Most of the errors on this subject come from reading twenty-year-old material as though it described the present.

• Treating it as a live threat and buying protection against it. This is the mistake the page exists to prevent, and it is the reason the verdict on this one is worth more than a hedge would be.
• Diagnosing a 302 hijack when the real issue is canonical selection, a scraper, or a copyright delisting. The symptom overlaps; the causes do not.
• Reading Google's temporary-redirect documentation in isolation and concluding the attack is back. That sentence is about redirect semantics, not about who wins a duplicate cluster.
• Mass-disavowing every domain that redirects to the site. Many of them are legitimate - shorteners, affiliates, aggregators, forgotten vanity domains - and the disavow tool is the wrong instrument regardless.
• Confusing it with security incidents that share the word. Session hijacking, DNS hijacking, browser hijacking and BGP hijacking are compromises of systems. This was a search-indexing artifact, and none of the defenses transfer in either direction.
• Citing 2005 to 2007 forum threads as current guidance. Much of the surviving material on this topic was written while the attack was live and reads as though it still is. Date-check everything you find on this subject, including anything that cites this page.
• Retaliating in kind. Redirecting at an attacker is conduct Google's spam policies target, and it is the party doing it who gets penalized.

Frequently asked questions