Permanent or temporary: picking between 301 and 302 redirects

By ToolSura DevTools Team, Senior Engineers · View profile

In the 301 vs 302 redirects debate, both codes behave identically at the protocol level: the server answers with a status and a Location header pointing at the replacement URL, and the browser or crawler follows it.

What 301 and 302 actually mean

The 301 vs 302 redirect decision starts with two status codes defined in the HTTP specification (RFC 9110). A 301 Moved Permanently tells every client that the resource now lives somewhere else, indefinitely (MDN documents the full status registry). 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 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 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
HTTP to HTTPS migration	301	Every http:// URL is permanently replaced
www to non-www canonicalization	301	One host becomes the canonical home
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 two most common 301s in practice are migrations nobody announces: moving a site from http:// to https:// and settling on a single www form. Both permanently replace every URL on the site, which is exactly the claim a 301 encodes, and both belong in server-level rules rather than per-page patches.

The 307 and 308 successors

Two newer codes refine the pair for technical cases, as MDN's redirect guide details. A 307 is the temporary redirect that guarantees the HTTP method 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 recommends pointing redirects directly at the final destination and keeping chains at three or fewer. Chains accumulate naturally over years of redesigns: each migration adds a layer on top of the last instead of replacing it.

The gap between tidy configs and live traffic shows up in traces. When we traced ten well-known domains from their bare http:// origins during this guide's research, eight required at least one hop before serving a final page. Seven needed two or more; nike.com and ibm.com each burned three round trips before content appeared.

The fix is periodic auditing: trace every redirect you own to its final target and rewrite the first hop to point there directly. Our dedicated redirect chain guide walks the full audit process, and Moz's redirection reference documents the same best practice from the SEO side.

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. The Google redirects documentation and Moz both recommend mapping old URLs to their closest true successors instead.

Implementing redirects on common stacks

The theory above lands differently depending on where redirects live. Three quick reference patterns for permanent moves; swap 301 for 302 when a move is temporary.

nginx

rewrite ^/old-page$ /new-page permanent; inside the server block, or return 301 https://example.com/new-page; for full control over the destination.

Apache

Redirect 301 /old-page https://example.com/new-page in .htaccess or vhost config, enabled by mod_alias; RedirectMatch 301 ^/blog/(.*)$ https://example.com/posts/$1 handles pattern migrations.

Next.js

A redirects() entry in next.config.js returning { source: '/old-page', destination: '/new-page', permanent: true }, where the permanent flag chooses between 308 and 307 semantics.

Whichever stack you run, one config file accumulating years of uncommented rules is how chains are born. Comment each rule with its migration date and delete rules whose origins no longer receive traffic.

How to verify your redirects

Verification is a two-check habit.

1. 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.
2. 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, and our indexing timeline guide explains what to expect while engines reprocess the changes.

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.