301 vs 302: which should I use?

301: remember this and go straight to the new address next time. Browsers may cache it for a long period, and clearing it requires clearing the user's cache — which you cannot do remotely.

302: use the new address this time and ask again next time. Nothing durable is stored.

That asymmetry is the whole decision. A wrong 302 costs a redundant request; a wrong 301 can persist for individual visitors long after the server stops sending it.

307 is the strict version of 302 and 308 the strict version of 301: both preserve the request method, where the older pair historically converted POST to GET.

A `Cache-Control` header on the redirect response overrides the default caching behaviour, which is the one way to make a 301 less sticky — and it has to be set before anyone receives the redirect, not after.

301: index the target instead of the source. Google documents that permanent redirects pass ranking signals to the new URL.

302: keep indexing the source, because the move is stated to be temporary.

Google has said it treats a 302 left in place indefinitely as if it were permanent, because the site's behaviour contradicts its declaration. That is a correction, not a reason to be careless.

The signal is strongest when the rest of the site agrees: internal links, the sitemap and the canonical tag all pointing at the same destination.

Neither code consolidates anything on its own if the old URL keeps being linked internally. A redirect is a statement about one URL; the links are a statement about which URL you actually use.

A URL structure change: slugs, categories, a move to HTTPS, a domain migration.

Content consolidated into another page, where the old address should stop existing.

Canonicalisation: forcing one host, one scheme, one trailing-slash convention. These are permanent by definition.

A retired product with a genuine successor, where visitors arriving at the old address should land on the replacement.

In each case the test is the same: would you be comfortable if this redirect could never be removed from a visitor's browser?

Redirect to the closest equivalent page rather than to the home page. A permanent redirect to an unrelated destination is treated as a soft 404 and helps nobody.

A/B tests and temporary campaign destinations.

Geographic or language routing where the original URL remains the real address of the content.

A page temporarily unavailable and diverted elsewhere while it is fixed.

Anything seasonal, where the original will be back.

Also: anything you are not sure about. A 302 you later promote to a 301 costs nothing; a 301 you have to undo costs a support thread per affected visitor.

Maintenance diversions, where 503 with a `Retry-After` header is usually better still because it states the condition rather than sending visitors somewhere else.

Visitors whose browsers cached it continue to be redirected after the server stops sending it, with no way for you to intervene.

The documented recovery is to serve a 200 at the old URL and wait, which works only as each browser's cached entry expires.

Search engines re-crawl and correct themselves, on their own schedule, which is measured in weeks rather than hours.

The damage scales with traffic: a 301 on a low-traffic path is a curiosity, the same mistake on a home page is an incident.

This is why a short-lived 302 is the safe default while a change is still being decided.

`curl -sIL https://example.com/old | grep -iE '^(HTTP|location)'` prints the code and target of every hop.

Check the code rather than assuming the configuration matches it. Web servers, CDNs and application frameworks each have their own default, and they differ.

Verify each hop of a chain, not just the first: a 301 into a 302 into a 200 is a mixed chain and behaves like its weakest link.

VeriFixScan reports `transport.redirect_chain` with the hops it followed and `transport.http_redirect` for the HTTP-to-HTTPS step, which is the redirect most often left as a 302 by accident.