301 vs 302 Redirects: Which One to Use (and When It Actually Matters)

Updated July 25, 2026

🛠️ This guide pairs with our free HTTP Header Checker — Trace redirect chains hop by hop, grade security headers, and fetch as Googlebot.

Every redirect answers one question for search engines: is this move permanent? Answer it wrongly and you either keep dead URLs in the index for months or accidentally deindex pages you meant to bring back. Here’s the decision in plain terms, plus the modern 307/308 variants and the chain problem most sites don’t know they have.

The four status codes

For normal page-to-page redirects the method question is irrelevant (browsers GET pages), so the practical choice is simply 301 for permanent, 302 for temporary. The 307/308 variants matter when redirecting API endpoints or form targets, where converting a POST to a GET would break things.

When 301 is correct

• Site migrations — domain changes, http→https, restructured URLs.
• Consolidating duplicates — non-www to www, trailing-slash normalization.
• Deleted content with a successor — old article redirects to its replacement.
• Merging pages — three thin posts combined into one guide.

A 301 tells Google “transfer everything to the new URL”: indexed status, and the large majority of link equity (Google has said PageRank loss through 301s is no longer a practical concern — but chained hops still cost crawl time and latency).

When 302 is correct

Genuinely temporary situations — and they’re rarer than their usage suggests:

• A/B tests routing some visitors to a variant.
• Geo-redirects to country versions (with the canonical staying global).
• A product page redirecting to a category while out of stock, returning later.
• Maintenance windows.

The classic mistake is shipping 302s for permanent moves because a framework or hosting panel defaulted to it. Google now treats long-lived 302s as de-facto 301s, but the transition costs you weeks of split signals during exactly the period (a migration) when you can least afford it. If the old URL is never coming back, use 301.

The silent killer: redirect chains

Individual redirects are fine. Chains — A→B→C→D — are where sites bleed:

• Each hop is a full round trip before the user sees anything. Three hops on a mobile connection can add over a second of pure latency.
• Googlebot follows up to ~10 hops, then gives up; deep chains can leave URLs unprocessed.
• Chains grow organically: the 2019 http→https redirect, plus the 2022 www consolidation, plus the 2024 path restructure — each layer written without checking what was already there.

The fix is mechanical: trace the chain, then update the first rule to point directly at the final destination. Our HTTP Header Checker shows every hop with its status code and latency — paste the oldest URLs you still have links pointing at (check your backlink reports and old marketing emails) and collapse anything with 2+ hops.

Migration checklist

1. Map old→new for every URL — your XML sitemap is the source of truth for “every URL”.
2. Implement one-hop 301s from each old URL directly to its new home — not to the new homepage (mass-redirecting everything to the homepage is treated as a soft-404).
3. Keep redirects live for at least a year; permanent is better. Old backlinks never stop sending traffic.
4. Verify by fetching, not by clicking: browsers cache 301s aggressively, so a fixed redirect can look broken in your own browser. Use the header checker or curl for the truth.
5. Watch Search Console’s coverage report for spikes in “Page with redirect” and “Redirect error”.

Quick answers

• Do 301s lose PageRank? Not meaningfully, per Google — but chains still waste crawl budget and latency.
• How long until Google processes a 301? Days to months depending on crawl frequency; the old URL disappears from results gradually.
• Can I redirect with JavaScript or meta refresh? They work but are slower and weaker signals. Server-side 301s are strictly better when you control the server.
• HSTS and redirects? After the first visit, Strict-Transport-Security makes browsers skip the http→https hop internally — one more reason to send it (see HTTP headers for SEO).

Try the free HTTP Header Checker →