301 vs 302: when picking the wrong redirect actually costs you

What each status code tells a browser and a crawler

There are more than two redirects, and most teams only use two of them. The distinction that matters at the protocol level isn't permanent-versus-temporary — it's whether the request method survives the hop.

A 302 historically allowed clients to convert a POST into a GET. That's why 307 and 308 exist: they say the same thing about permanence, and they promise not to change the method.

Why Google says the SEO difference is small

Google's own line on this has been consistent for years: both 301 and 302 pass signals, and Google uses the code as an input to canonicalisation rather than as a binding instruction. A permanent redirect is a strong signal that the target should be the canonical URL. A temporary redirect is a weaker one.

Google also watches what you actually do. Leave a 302 in place for six months and it gets treated as permanent, because it plainly is. Ship a 301 and reverse it two weeks later and Google treats the original as still live, because it plainly is.

So the fear that a 302 'loses link juice' is largely pre-2016 folklore. If your only concern is Google, the two codes are close to interchangeable, and the canonical tag on the destination is doing more work than either — canonical vs noindex covers where that fits. That's the reassuring half of the answer. Here's the half that costs money.

The real damage path: a 301 you cannot take back

A 301 is a permanent redirect, and browsers take that literally. In the absence of explicit caching headers, a browser is entitled to cache a permanent redirect and stop asking the origin server about that URL. Historically, browsers cached them for as long as they felt like — effectively forever from a user's point of view.

Think about what that means operationally. You ship a bad rule at 4pm on Friday: /products/* now 301s to /shop/. You catch it at 6pm and revert the server. The server is fine. Every visitor who touched a product page in those two hours still has a permanent redirect sitting in their browser cache, and their browser will not ask you again. You cannot purge it. You have no access to it. They see the wrong page until they clear their cache, which they will not do.

It gets worse if the fix is naive. The instinct is to redirect the wrong destination back to the original — /shop/ 301s to /products/. For every affected browser that's now an infinite loop, and they see an error page instead of your store. The same problem exists one layer up at the CDN, except edge caches can be purged. That's why edge mistakes are recoverable and browser mistakes are not.

Which code for maintenance, tests and campaigns

Most wrong redirects come from treating 301 as the default for everything because someone read that it's better for SEO. Here's the decision, case by case.

Redirect chains, hops, and the migration that goes sideways

The most common technical failure in a replatform isn't the wrong code. It's the accumulation of hops. Old URL 301s to the 2021 structure, which 301s to the HTTPS version, which 301s to the trailing-slash version, which 301s to the new CMS path. Four hops, four chances to break, and a slow first byte for everyone clicking an old link.

Google documents following roughly ten redirect hops per crawl attempt before it reports an error. Browsers typically stop near twenty. Neither number is a budget — ship one hop. The discipline that gets you there is unglamorous, and it's most of what site migration work actually is.

1. Crawl the old site before you touch anything. Every indexed URL, every URL with a backlink, every URL with organic clicks in the last twelve months. That list is your redirect map, and there is no way to reconstruct it afterwards.
2. Map to the closest equivalent page, one to one. Bulk-redirecting a category to the homepage is the fastest way to lose the traffic you're trying to protect.
3. Flatten the chains. Every old URL should point directly at the final destination, not at an intermediate that redirects again. Re-crawl and fix until every source resolves in one hop.
4. Update internal links to the new URLs. Links pointing at redirects work, and they also broadcast that your own site doesn't know where its pages are.
5. Keep the redirects for at least a year, longer if the old URLs have real backlinks. There's no cost to leaving them in place and a real cost to removing them.
6. Watch Search Console's page indexing report weekly for two months for redirect errors and 'Page with redirect' appearing where it shouldn't.

Your framework already picked for you

Most redirect bugs aren't decisions. They're defaults nobody read. Worth knowing what your stack does when you don't specify a code.

• Apache mod_alias — Redirect /old /new issues a 302 unless you say otherwise. Use Redirect 301 or RedirectPermanent.
• nginx — rewrite ... redirect is a 302; rewrite ... permanent is a 301. return 301 is explicit and clearer.
• Express — res.redirect(url) defaults to 302. Pass the status: res.redirect(301, url).
• Next.js — in next.config.js, permanent: true emits a 308 and permanent: false emits a 307. Both preserve the method, both are correct, and 308 is the permanent one.
• WordPress redirect plugins — usually default to 301, which is why so many WordPress sites carry permanent redirects somebody meant to be temporary.