301 vs 302: redirects, SEO, and the mistakes that stick

What actually happens on a redirect

When a browser requests a URL and the server answers with a 3xx status and a Location header, the browser silently issues a second request to that new address. The visitor sees only the destination; the cost — one extra round trip — and the semantics ride on the status code.

301 says the resource moved permanently: clients should go to the new URL now and remember to skip the old one next time. 302 says it is temporarily elsewhere: go there now, but ask the original again in future. Everything that matters about redirects — SEO, caching, undo-ability — follows from which of those two promises you made.

What search engines do with each

For a 301, search engines treat the move as editorial fact: the old URL's accumulated signals — links, history, ranking — are transferred to the new one, and over the following weeks the new URL replaces the old in results. This is why site migrations, HTTPS switches and slug renames are done with 301s: the reputation follows the content.

For a 302, engines do the literal thing: they keep the old URL indexed, because you told them the content is coming back. A 302 left in place for a permanent move is one of the classic silent SEO mistakes — everything works for visitors, but the new URL builds no history while the old one slowly stales. If you discover one, simply changing it to a 301 starts the transfer; engines handle the correction gracefully.

The mirror mistake exists too: a 301 used for something genuinely temporary (a campaign page, an A/B test) tells engines to deindex the original — which is exactly what you did not want.

The part people learn the hard way: 301s stick

Browsers are allowed to cache a 301 with no expiry — and several do exactly that. The first time a visitor's browser sees the redirect it may remember it indefinitely, never asking the old URL again. Fix the server tomorrow and that visitor still lands on the wrong page, because the redirect now lives in their browser, beyond your reach. There is no purge button for other people's browsers.

Two practical consequences. First, test a move with a 302, and only promote it to 301 when you are sure — the temporary code is the reversible one. Second, put an explicit Cache-Control on redirects, because a bounded lifetime turns "stuck forever" into "stuck for a day at worst". We follow that rule on this site: our canonical redirects carry Cache-Control: public, max-age=86400, so even a redirect we later change corrects itself within a day for every visitor and cache in between.

A redirect with a bounded, cacheable lifetime

$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public

Redirect chains: the tax you pay on every click

Redirects accumulate. The http→https rule adds one hop, the www rule another, the renamed slug a third — and now every visitor pays three round trips before any content moves, while search engines dilute a little signal at every intermediate step and stop following very long chains altogether.

The fix is not avoiding redirects; it is making each old URL point directly at the final destination. When you rename a page that already had a redirect pointing at it, update the OLD rule too, so both generations of URL go straight to the new address in one hop. An occasional audit is one command per URL, and the shape you want to see is a single 301 followed by a 200.

Follow the whole chain and count the hops

# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page

# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'

# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200

Redirects on a CDN: where they should live, and caching them

A redirect served by your application works, but it costs a full trip to the origin to produce one unchanging header. Moving well-known redirects to the edge — or letting the edge cache the ones your app emits — answers them near the visitor instead.

Both halves are available here. Delivery rules can redirect at the edge directly (the mobile-site redirect is a one-field setting in the panel), and since a recent improvement the edge also caches 301s and 302s from your origin with bounded lifetimes, so repeated crawls of a moved URL stop reaching your application at all. The practical guidance: give your redirects an explicit Cache-Control like any other response, short for 302s, up to a day for 301s — long enough to absorb the traffic, short enough to survive your own mistakes.

Choosing in five seconds

Renamed a page, moved domains, switched to HTTPS, consolidated duplicates: 301, and update old chains to point directly at the final URL. Campaign page, maintenance detour, A/B test, geo-split, anything you intend to undo: 302. Not sure yet: 302 first — it is the reversible one — and promote to 301 once the move is settled.

And the meta-rule that catches the rest: a redirect is a promise about the future of a URL. Pick the code that matches the promise you can actually keep.