Half of All Redirects on the Web Are Broken

Researchers at Old Dominion University and the Internet Archive crawled 11 million redirecting URLs, followed each one up to ten hops, and found that only half of them actually reach a live, working page. The other half dead-end somewhere along the way.

That's not a small-sample fluke or an edge case from one broken CMS. It's a measurement of the open web at scale, published at the 2025 ACM Web Science Conference, and it reframes a redirect audit from a nice-to-have step before a migration into something closer to load-bearing infrastructure. Brass-SEO's practical migration checklist already covers the how; this post covers the why, using the primary research and official specifications behind it.

What 11 Million Redirects Actually Showed
301 vs 302 Is Not a Style Choice
The Method-Preservation Rule Almost Nobody Knows
How Long Google Says to Keep a Redirect Live
How Common Redirects Are on an Ordinary Home Page
What to Check Before You Trust a Redirect Map
Frequently Asked Questions

What 11 Million Redirects Actually Showed

The study, by Garg, Alam, Ayala, Weigle, and Nelson, set out to measure redirect behavior across the web rather than on any single site. Their method was direct: start from a large corpus of known redirecting URIs, follow each chain up to ten hops, and record where it ends. Across 11 million unique redirecting URLs, only 50% terminated in a page that actually loaded successfully. The rest ended in an error somewhere along the chain, and only 0.06% of chains ran long enough to hit the researchers' ten-hop cap.

Brass-SEO reads that 50% figure as the strongest available argument against skipping a redirect audit during a migration. A redirect written correctly two years ago doesn't stay correct forever — the target it points to can move again, get deleted, or start returning an error, and nothing about the original redirect changes to flag that. Half the redirects on the open web have already reached that state. There's no reason to assume a given site's redirect map is the exception without checking.

301 vs 302 Is Not a Style Choice

Google's own documentation on redirects and Search states the distinction plainly: for permanent redirects (301 and 308), "the indexing pipeline... uses [the redirect] as a signal that the redirect target should be canonical." For temporary redirects — 302 and 307 — "the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."

That's the entire mechanism behind the standard advice to use a 301 for anything permanent. A 302 tells Google the move might be temporary, so Google keeps indexing the old URL as canonical and doesn't fully transfer the signals a 301 would consolidate onto the new one. A site that migrates every URL with 302s, intending it as a quick technical shortcut, ends up asking Google to keep treating the old, soon-to-be-deleted URLs as the real pages.

The Method-Preservation Rule Almost Nobody Knows

RFC 9110, the current IETF standard covering HTTP semantics, defines a distinction that has nothing to do with permanence and everything to do with what happens to the original request. For a 301 or 302, the spec states a user agent "may change the request method from POST to GET" — a legacy allowance dating back to how early browsers actually behaved. For a 307 or 308, the spec states the method "must not" change.

That single clause explains a specific, recurring migration bug: a form-submission endpoint redirected with a 301 can silently turn a POST request into a GET, breaking whatever the form was supposed to do, while the exact same redirect written as a 308 would have preserved it. Most SEO guidance treats 301 and 308 as interchangeable "permanent redirect" options. The HTTP spec doesn't, and neither should a migration plan that includes any form, API endpoint, or non-GET request in its redirect map.

How Long Google Says to Keep a Redirect Live

Google's own site-move documentation gives a specific number most migration plans skip: keep redirects active "for as long as possible, generally at least 1 year." The same documentation states that migration processing happens on a per-URL basis, with no fixed crawl frequency guaranteed, and that "visibility of your content in Search may fluctuate temporarily during the move. This is normal."

That second point matters as much as the first. A site that sees a ranking dip in the two weeks after a migration hasn't necessarily done something wrong — Google states outright that this is expected behavior, not a symptom to panic over. The redirect timeline is the part worth acting on: removing redirects at three or six months, before Google has finished re-crawling and re-indexing every migrated URL, cuts off the signal transfer before it's finished.

How Common Redirects Are on an Ordinary Home Page

The most recent HTTP Archive Web Almanac to measure redirect prevalence at the status-code level was the 2019 edition. It found 302 was the second most common non-200 status code returned by crawled home pages: 6.71% on desktop, rising to 10.45% on mobile — a gap the researchers attributed largely to older, non-responsive sites redirecting mobile visitors to a separate URL. Later Web Almanac editions dropped this specific breakdown, which makes the 2019 figures the best available independent baseline, even seven years on.

The mobile-desktop gap is worth flagging on its own. A site built during the era of separate mobile URLs (m.example.com-style setups) may still be carrying that redirect layer years after it stopped serving any purpose, adding an extra hop to every mobile request without anyone noticing.

What to Check Before You Trust a Redirect Map

A redirect map that was correct on launch day needs the same three checks the research above points to, repeated on a schedule rather than assumed permanent.

Every redirect target should actually resolve to a live page, not just a URL that looked right when the map was built — the 50% broken-chain figure from Garg et al. is the reason to verify rather than trust. Every permanent move should use 301 or 308, never 302, unless the move is genuinely temporary, per Google's own canonical-signal documentation. Any redirect touching a form, API call, or anything besides a simple page load should use 308 specifically, not 301, to preserve the request method per RFC 9110. For the full pre-migration, migration-day, and post-migration checklist built around these rules, see Site Migration SEO Checklist and 301 vs 302 Redirects: The Complete Guide.

Frequently Asked Questions

How many redirects on the web are actually broken?

About half. Garg et al. (2025) crawled 11 million unique redirecting URLs, following each up to ten hops, and found only 50% terminated in a page that loaded successfully — the rest ended in an error somewhere in the chain.

Does a 302 redirect pass the same ranking signals as a 301?

No. Google's documentation states permanent redirects (301/308) are used by its indexing pipeline as a canonical signal, while temporary redirects (302/307) are not. Using 302 for a permanent move leaves Google treating the old URL, not the new one, as canonical.

What's the actual difference between a 301 and a 308 redirect?

Method preservation. RFC 9110 states a 301 or 302 "may" change a POST request into a GET when followed, while a 307 or 308 "must not" change the method. A redirect on a form or API endpoint should use 308, not 301, to avoid silently breaking the original request.

How long should redirects stay active after a migration?

At least a year, according to Google's own site-move documentation, which recommends keeping redirects live "for as long as possible, generally at least 1 year," and states that temporary visibility changes during that window are expected, not a sign the migration failed.

Every source cited in this post — the full RFC text, Google's documentation, and the Garg et al. study — is fact-checked and linked in the Redirects & Site Migration entry of the Brass-SEO Research Index.