301 vs 302 Redirects & Redirect Chains: The Complete Guide
An HTTP redirect is a server response that tells a browser or crawler "the content you asked for is actually somewhere else" — and which status code it uses (301, 302, or a handful of less common variants) changes how search engines treat the move, not just how the browser behaves. This guide covers exactly when to use which redirect type, how redirect chains and loops actually happen, how many hops search engines will follow before giving up, and how much ranking value genuinely transfers.
The redirect status codes, and what each one actually communicates
- 301 Moved Permanently — the resource has permanently moved to a new URL. Search engines transfer ranking signals to the new URL and update their index over time to reflect the new address as the canonical one.
- 302 Found (Temporary Redirect) — historically ambiguous about whether the method (GET/POST) should be preserved, but in practice treated by search engines as "this move is temporary." The original URL tends to stay indexed, since engines expect the content to come back at its original address.
- 307 Temporary Redirect / 308 Permanent Redirect — newer, stricter versions of 302/301 that explicitly guarantee the request method and body are preserved on the redirect (a 301/302 technically allow a client to switch a POST to a GET). Less commonly seen in general web SEO work, but correct where method preservation actually matters, like API redirects.
| Code | Meaning | Method/body preserved? | Search engine treats it as |
|---|---|---|---|
| 301 | Moved Permanently | Not guaranteed | Permanent — transfers ranking signals |
| 302 | Found (temporary) | Not guaranteed | Temporary — keeps original URL indexed |
| 307 | Temporary Redirect | Guaranteed | Temporary |
| 308 | Permanent Redirect | Guaranteed | Permanent |
The mistake that costs the most in practice is using a 302 for a move that's actually permanent. Because a 302 signals "temporary" to search engines, they're slower to fully replace the old URL in their index with the new one — the exact opposite of what you want when consolidating URLs after a migration or restructure.
Redirect chains: why every extra hop is pure cost
A redirect chain is simply more than one redirect stacked in sequence — URL A redirects to B, which redirects to C, before the browser or crawler finally reaches real content. Each hop in the chain adds a full network round-trip of latency for a human visitor, and a separate fetch a crawler has to make before it even reaches the actual page. Google's crawlers follow up to 10 redirect hops by default, and for a robots.txt file specifically, at least 5 hops before treating the file as missing. The risk starts well before either limit, though: a long enough chain makes it a real possibility the destination page never gets crawled at all.
Chains accumulate almost always the same way: a migration adds a redirect (old URL → new URL), then a later migration adds another (new URL → newer URL) without ever going back to point the original URL directly at the final destination. Each individual redirect made sense in isolation; stacked together, they form a chain nobody planned. The fix is always the same: collapse the chain so every old URL points directly at the final, current destination in one hop.
Redirect loops: the failure mode that blocks access entirely
A loop is a chain that eventually points back to a URL it already visited — A → B → A, or a longer cycle. Unlike a slow chain (which still eventually resolves), a loop never resolves. Browsers detect the repetition and stop with an error like "too many redirects" instead of ever loading anything. Loops almost always come from a leftover rule from an earlier migration that was never removed once a newer, conflicting rule was added on top of it — tracing the exact hop-by-hop sequence is the only reliable way to find which specific rule is pointing backward.
Example of the two-line rule pattern that creates one:
# Old rule from a past migration — never removed
Redirect 301 /old-page /new-page
# New rule added later, pointing the wrong direction
Redirect 301 /new-page /old-pageHow much ranking value a redirect actually passes
Google's own redirect documentation confirms a correctly implemented 301 makes the new URL canonical in its index, and treats it as passing essentially the same ranking signals a direct link would — there's no partial "redirect penalty" the way older SEO advice sometimes claimed. The real, measurable losses in practice come from two things: chain length (each extra hop costs crawl budget and adds latency, and past a certain length the destination risks not being crawled at all), and destination mismatch (redirecting a deleted page to an unrelated page, most often the homepage, rather than to a genuinely relevant replacement — a pattern search engines can identify as a poor-quality substitution regardless of the status code used).
Tracing a chain properly
Checking redirects from a browser's network tab shows individual hops, but two things make a dedicated trace more reliable: browsers auto-follow the full chain in a single visible request by default, and cross-origin restrictions can block reading intermediate status codes and headers from client-side JavaScript when the destination is on a different origin. Frost Rank's Redirect Chain Checker traces one hop at a time from the server side specifically to avoid both problems, and pairs with the HTTP Header Checker for inspecting the response headers at the final destination once the chain resolves.
Frequently asked questions
Use a 301 when a move is permanent, like a migration, a new URL structure or two pages merged into one, and a 302 only when the original URL is coming back, such as a maintenance page or an A/B test. A 302 on a permanent move keeps the old URL indexed for longer. See every redirect code compared.
Google has stated it follows up to 10 redirect hops per crawl attempt before giving up — after that, the URL is treated as unreachable for that crawl. This isn't a hard universal number across every crawler and browser (some tools cap lower), but the practical rule is the same everywhere: a chain long enough to worry about is already too long, since every hop past the first one is pure, avoidable overhead.
A loop is a chain that leads back to a URL it already visited, usually because an old migration rule conflicts with a newer one, and browsers give up with a "too many redirects" error. Fix it by tracing the chain hop by hop to find the rule that points backward. See how loops form and how to find them.
You can see each hop there, but browsers follow the whole chain automatically and cross-origin restrictions can hide the intermediate status codes. A server-side trace that requests one hop at a time avoids both problems. See how to trace a chain properly.
Effectively yes: Google treats a correct 301 as passing the same ranking signals a direct link would. Value is really lost through long chains and redirects to irrelevant pages. See where redirects really lose value.
Neither a 301 nor a 302 — use a 404 (Not Found) or, if the removal is intentional and permanent, a 410 (Gone). Redirecting a deleted page with no real replacement to an unrelated page (often the homepage) is a common mistake known as a "soft 404": it looks fine to a human visitor but signals a mismatched destination to search engines, which can hurt rather than preserve the deleted page's value.
Written from real migration cleanups where redirect chains and loops had accumulated across multiple past site changes — the exact leftover-rule pattern described above is the actual root cause found and fixed each time, not a generic textbook description.
Was this guide helpful?
Rate it and leave a comment — takes 10 seconds, and genuinely helps decide what to fix or build next.