301 vs 302 Redirects: Which to Use and What SEO Sees

What a redirect actually is

A redirect is not a page. It is a response with no useful body: a status code in the 3xx range and a Location header naming where to go instead. The client reads the header and makes a second request to the new URL.

That shape matters because it means every redirect costs a full extra round trip, and because the status code is the only thing that tells anyone whether the move is permanent. The Location header says where; the status code says what this means. Get the second part wrong and the URL still works for visitors while quietly doing the wrong thing to your search rankings and to every browser that has seen it.

There are five redirect codes in practice, but the whole decision comes down to one question: is this move permanent or not?

301 and 302: the actual difference

A 301 Moved Permanently says: this URL is gone for good, use the new one from now on, and update anything you have stored. A 302 Found says: serve this other URL for the moment, but keep asking for the original one, because it is coming back.

Three consequences follow, and they are the entire practical difference:

• Search engines consolidate on a 301. The old URL drops out of the index, the new URL takes its place, and the ranking signals the old URL had accumulated pass to the new one. On a 302, the engine keeps the original URL in the index, because you told it the original is the real one.
• Browsers cache a 301, often aggressively. A browser that has seen a 301 may not even ask your server next time; it goes straight to the target. A 302 is not cached by default, so the browser asks again every time.
• A 301 is hard to take back. Because of that caching, a 301 you regret keeps redirecting returning visitors long after you have removed it from your configuration. This is the single most expensive mistake in this whole topic.

So the rule is not “301 is better for SEO”, though you will read that everywhere. The rule is: a 301 is better when the move is genuinely permanent, and genuinely bad when it is not.

What SEO actually sees

Modern search engines are more forgiving than the folklore suggests, which has produced some persistent myths worth clearing up.

• “A 301 loses 15% of your link equity.” This came from a decay factor that applied years ago. Google has stated it no longer applies PageRank dilution to redirects. A correctly implemented 301 passes signals.
• “A 302 passes nothing.” Not quite. Google will eventually treat a 302 that has been in place for a long time as if it were permanent, because the behaviour contradicts the declaration. But “eventually” is doing a lot of work: you spend weeks or months with the wrong URL indexed, and you do not control the timing.
• “Redirects always hurt rankings.” A single clean redirect to a closely related page is routine and usually costs nothing measurable. What hurts is redirecting to something irrelevant — pointing a hundred retired product pages at your homepage reads as a soft 404, and those pages' signals go nowhere.

The real risks are duller than the myths: chains, loops, mixed signals and redirected URLs still sitting in your sitemap. Those are covered below.

Which one to use, by situation

Almost every case falls into one of these.

Use a 301

Changed a URL slug or restructured your paths. Moved to a new domain. Picked a canonical hostname and need the other one to follow it — www to apex or the reverse. Forcing HTTPS. Merged two pages into one. Retired a product page in favour of the category that replaced it. In all of these the old URL is never coming back, which is exactly what a 301 declares.

Use a 302

Maintenance or a holding page while the real page is down. A/B testing two versions of a page. Geographic or language routing where the original URL must stay canonical. A temporary promotional page standing in for the usual one. A sign-in redirect that bounces the user back afterwards. Here you want the original URL to stay indexed, and a 301 would remove it.

When 307 and 308 matter

307 Temporary Redirect and 308 Permanent Redirect are the strict versions of 302 and 301. The difference is about the HTTP method: with 301 and 302, clients historically changed a POST into a GET when following the redirect, and that behaviour is now baked in. 307 and 308 are required to preserve the method and the body.

For ordinary page moves, 301 and 302 are what search engines expect and what you should use. For APIs and form submissions, use 307 or 308 — a redirected POST that silently becomes a GET loses the request body, and the resulting bug is maddening to trace.

303 and the one thing it is for

303 See Other deliberately turns the follow-up request into a GET. Its proper use is the post-and-redirect pattern: accept a form POST, then 303 to a results page so that refreshing the browser does not resubmit the form. It is not a general-purpose redirect and has no place in page moves.

Meta refresh and JavaScript redirects

Two non-HTTP ways to move a visitor exist, and both are worse than they look.

A meta refresh (<meta http-equiv="refresh">) is handled by the browser after it has downloaded the page. Search engines do follow it and will usually treat a zero-delay refresh as a permanent redirect, but it is slow, it is invisible to anything that does not render HTML, it breaks the back button, and a delayed one is a genuine accessibility problem. Use it only when you have no access to the server configuration at all.

A JavaScript redirect is worse still. It requires the page to load and the script to execute first, nothing that does not run JavaScript will follow it, and it wastes the entire first request. Both of these are workarounds, not tools. If you can set a status code, set a status code.

Chains and loops: where traffic actually leaks

This is the part that costs real money, and it is almost always accidental.

A chain is a redirect to a redirect. It builds up over years, one rule at a time: http://example.com → https://example.com → https://www.example.com → https://www.example.com/new-page. Every hop is a full round trip, so a four-hop chain on a mobile connection is noticeably slow, and crawlers give up on long chains — Google follows a limited number of hops before it simply stops. Collapse chains by pointing the first URL directly at the final destination.

A loop sends the client back to where it started and the page never loads at all. The classic cause is two rules disagreeing: one forcing www, another forcing the apex, each undoing the other. Browsers show ERR_TOO_MANY_REDIRECTS after about twenty hops. If you see that, you have two rules fighting, not one broken rule.

Two more leaks worth checking:

• Redirected URLs left in your sitemap. A sitemap should list final destinations only. Listing a URL that redirects tells the crawler to spend its budget on a hop.
• A canonical tag that disagrees with the redirect. If the page you land on declares a canonical URL pointing back at the old one, you have given two contradictory instructions and the engine picks for you.

How to check what a URL actually returns

You cannot tell a 301 from a 302 by looking at the browser's address bar — both end up at the same place. You have to read the response.

Check these three things:

• The status code of the first response, not the final one. A browser's network panel shows the whole sequence; the first line is the one that declares permanence.
• The full hop sequence. Count the redirects between the URL you entered and the page that renders. Anything above one deserves a look; anything above two is a chain to collapse.
• Whether the chain mixes codes. A 301 followed by a 302 is a common and confusing pattern that says “permanently moved to somewhere temporary”.

An HTTP status code checker shows the status of each hop and the Location header at every step, which is exactly the view you need. For the HTTPS and hostname rules specifically, confirm the certificate covers the hostname you are redirecting to with the SSL certificate checker — a redirect to a hostname the certificate does not cover produces a warning page rather than a working site.

Common mistakes

• Using a 301 for anything temporary. Browsers cache it, so returning visitors keep getting redirected after you remove the rule. Clearing that is not in your control.
• Using a 302 for a permanent move and wondering why the old URL is still the one ranking. You told the engine the old one is canonical.
• Redirecting everything retired to the homepage. Google treats an irrelevant destination as a soft 404. Redirect to the closest equivalent page, or return a clean 410 if there is no equivalent.
• Letting chains accumulate. Each new rule stacks on the last instead of replacing it.
• Two hostname rules fighting, producing a loop. Decide on one canonical hostname and write exactly one rule for it.
• Redirecting a POST with a 301 or 302. The method becomes a GET and the body is lost. Use 307 or 308 for anything that is not a plain page view.
• Leaving redirected URLs in the sitemap, or keeping internal links pointed at the old URL. Update your own links; a redirect is for other people's links.

The short version

A 301 means permanent: search engines move the ranking signals to the new URL and browsers cache it hard, so use it for slug changes, domain moves, HTTPS and hostname canonicalisation — and never for anything you might reverse. A 302 means temporary: the original URL stays indexed, which is exactly right for maintenance pages, A/B tests and sign-in bounces. Use 307 or 308 when a POST must survive the redirect, keep chains to a single hop, and make sure no rule points back at its own starting point. Check what a URL really returns, hop by hop, with the free HTTP status code checker, and if you are redirecting to a new hostname, confirm its certificate first with the SSL certificate checker. For a wider tour of what every response class means, the complete guide to HTTP status codes covers the rest.

Related tools and guides:

• HTTP Status Code Lookup - A quick reference for every HTTP status code and what it means.
• Security Headers Checker - Check for HSTS, CSP, X-Frame-Options, and other key security headers.
• 404 vs 410: What Each One Tells Google About a Dead Page - What a 404 and a 410 each tell a crawler

Frequently Asked Questions