301 vs 302 Redirects: Which to Use and When

By ToolSura DevTools Team, Senior Engineers · View profile

What 301 and 302 actually mean

The 301 vs 302 redirect decision starts with two status codes defined in the [HTTP specification (RFC 9110)](https://httpwg.org/specs/rfc9110.html#status.301). A 301 Moved Permanently tells every client that the resource now lives somewhere else, indefinitely ([MDN documents the full status registry](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)). A 302 Found tells clients the content currently sits at a different address but will return. Same user experience in a browser, either code lands the visitor on the right page. The difference lives entirely in what each code promises about the future.

That promise is what search engines act on. As [Google's documentation on redirects](https://developers.google.com/search/docs/crawling-indexing/301-redirects) explains, crawlers treat the codes as instructions about which URL should be indexed going forward.

The SEO consequences of each choice

Use a 301 and search engines consolidate: the new URL inherits the old one's accumulated ranking signals, and over time the old URL drops from the index. Use a 302 and engines do the opposite: they keep the original URL indexed, expecting it to return, and route little to the temporary address. Pick the wrong one and outcomes follow predictably. A permanent migration implemented as 302s leaves the new URLs struggling to rank while the dead originals cling to the index. A genuinely temporary change implemented as 301s forces you to untangle cached redirects when the original comes back.

One nuance matters in practice: [Google has documented](https://developers.google.com/search/docs/crawling-indexing/301-redirects) that long-lived temporary redirects are eventually treated as permanent, because reality outranks intention. A 302 left in place for a year stops being a promise and becomes a fact.

When to use each redirect

Redirect choice by scenario

Scenario	Correct code	Why
Domain migration	301	Signals should transfer permanently
URL structure redesign	301	Old URLs are gone for good
Merging duplicate content	301	One canonical target forever
Seasonal campaign page	302	Original returns after the campaign
A/B test variant serving	302	Test is temporary by design
Geo or language negotiation	302	Users may need the original

The table's pattern is simple: if you can name the date the original returns, use 302; if you cannot, use 301.

The 307 and 308 successors

Two newer codes refine the pair for technical cases, as [MDN's redirect guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections) details. A 307 is the temporary redirect that guarantees the [HTTP method](https://httpwg.org/specs/rfc9110.html#rfc.section.15.4.3) survives: a POST stays a POST after the hop. A 308 is its permanent sibling. The older 301 and 302 historically allowed clients to switch POST requests to GET, which broke form submissions in edge cases. For everyday page moves, 301 and 302 remain the norm; for API endpoints where method preservation matters, 307 and 308 are the precise instruments.

Redirect chains quietly cost you

A chain looks like /old-page to /newer-page to /final-page, with each hop adding latency and diluting the signal path. [Google's guidance](https://developers.google.com/search/docs/crawling-indexing/301-redirects) recommends pointing redirects directly at the final destination and keeping chains under a handful of hops. Chains accumulate naturally over years of redesigns: each migration adds a layer on top of the last instead of replacing it. The fix is periodic auditing, tracing every redirect you own to its final target and rewriting the first hop to point there directly.

The URL redirect checker traces each hop of any URL, which makes chain audits a paste-and-read job rather than an archaeology project. Redirect behavior also doubles as infrastructure evidence in the website technology detection workflow, since hop patterns expose CDN and routing layers.

Common redirect mistakes

Mistakes that turn redirects into problems

Mistake	Consequence	Fix
302s for permanent moves	New URLs fail to inherit rankings	301 for anything permanent
301s for temporary changes	Browsers cache the hop past its useful life	302 when the original returns
Redirecting everything to the homepage	Soft-404 signals, poor relevance	Map old URLs to closest new pages
Letting chains accumulate	Latency plus diluted signals	Point first hops at final targets

The homepage-dump mistake deserves its reputation: redirecting every retired URL to the homepage looks tidy in the server config but tells search engines the old content has no relevant successor, which engines treat closer to deletion than migration.

How to verify your redirects

Verification is a two-check habit. First, trace the path: run your important URLs through the redirect checker and confirm each lands on the intended final page with the intended code and no surprise hops. Second, confirm the code matches the intent: permanent migrations should read 301 (or 308), temporary serving should read 302 (or 307). After any migration, spot-check the ten highest-traffic old URLs before declaring the work done; those ten carry most of the SEO consequence.

Choosing between 301 and 302 from here

Every future 301 vs 302 decision reduces to one question: is this move forever? Forever means 301 and its ranking-signal transfer; temporary means 302 and a preserved original. Mind the method-preserving 307 and 308 for API work, keep chains short, and verify with a hop trace before calling any migration finished. Bookmark this 301 vs 302 redirect guide for the next redesign, and run your existing URLs through a checker this week, because chains never announce themselves.