A 302 means "temporary detour, keep using the original URL next time." Use it for genuine short-term redirects: A/B tests, login flows, geo redirects, brief maintenance. Don't use it for permanent moves — Google will eventually treat long-standing 302s as…
HTTP 302 Found is the "temporary redirect" code. Unlike 301, it tells search engines that the original URL should remain canonical — they should keep indexing it and not transfer ranking signals to the new URL. This makes 302 the correct choice when the move genuinely is temporary: A/B testing, geolocation-based redirects, login flows that send users to /auth and back, or short maintenance windows where the URL will return. Historically, some old HTTP clients changed POST requests to GET during a 302 redirect (a spec-versus-practice mismatch). When method preservation matters, use 307 (temporary) or 308 (permanent) instead.
Google does not transfer ranking signals through a 302 — the original URL stays canonical and keeps its rankings. This is correct behaviour when the move is genuinely temporary. When it is not temporary, you are leaking ranking equity until Google decides to treat the 302 as a 301 (which it does, eventually, for redirects that have been in place for a long time — but the delay can be months). Always use 301 for permanent moves.
LemWatch flags long-running 302 redirects (in place for more than 30 days) and recommends switching to 301 if the move is permanent. We also track 302 chains, which dilute ranking signals at every hop.
HTTP 302 has a confused history. The HTTP/1.0 spec (RFC 1945, 1996) defined it as "Moved Temporarily" but didn't specify whether the request method should be preserved during the redirect. In practice, most clients silently changed POST to GET — which was useful for the Post/Redirect/Get pattern but technically wrong. HTTP/1.1 (RFC 2616, 1999) renamed 302 to "Found", left the ambiguity in place, and introduced 303 (always-GET) and 307 (always-preserve-method) to clear up the confusion.
HTTP 302 Found is a temporary redirect. It tells the client to use a different URL for this request only, and to keep using the original URL for future requests. Search engines do not transfer ranking signals through a 302.
Use 302 when the move is genuinely temporary: A/B tests, login flows, geo redirects, short-term maintenance. Use 301 for any permanent move — domain change, URL restructure, HTTPS migration, content consolidation.
No — Google keeps the original URL canonical and does not transfer ranking signals to the redirect target. If the move is actually permanent, switch to 301 to preserve ranking equity. Google will eventually reclassify long-standing 302s as 301s, but the delay can be months.
Both are temporary redirects. 302 is ambiguous about whether the HTTP method (POST/PUT/DELETE) should be preserved — in practice most clients change POST to GET. 307 guarantees the method is preserved. Use 307 when redirecting POST/PUT/DELETE requests; 302 is fine for GET.
Because res.redirect(url) treats the redirect as temporary unless told otherwise. To make it permanent, use res.redirect(301, url) explicitly. The default is a frequent source of accidental temporary redirects on URLs that have permanently moved.
Only if you use it for a permanent move. Google will eventually treat long-standing 302s as 301s, but during that transition (which can take months), the original URL keeps the ranking and the new URL doesn't accumulate equity. For permanent moves, always use 301.
302 is ambiguous about method preservation; 303 always forces the next request to be a GET. 303 is the correct response after a POST when you want to redirect the user to a confirmation page that should be re-fetchable on refresh (the Post/Redirect/Get pattern).