302 Found

A 302 response indicates the target resource temporarily resides at a different URL, given by the Location header. Because the move is temporary, the client is expected to keep using the original request URL for future requests rather than updating any stored links, which is the defining difference from 301. RFC 9110 calls this out explicitly: user agents must not automatically change the request method to GET unless it already knows the response, in practice, causes that behavior in deployed clients.

That last clause exists because 302 has a long, messy history. The original HTTP/1.0 specification did not clearly say whether the method should be preserved, and virtually every browser ever built responds to a 302 on a POST by re-requesting the Location with a GET and no body. This is now such an entrenched convention that servers must treat 302 as effectively GET-only for non-idempotent requests, exactly like 301, even though the RFC text nominally allows otherwise; 307 was introduced specifically to fix this ambiguity.

A classic real-world pattern is the post/redirect/get flow: a form submits via POST, the server processes it, and responds with a 302 to a confirmation or resource page. Following the redirect issues a GET, so refreshing the resulting page does not resubmit the form. 302 is also the workhorse of login walls, load-balancer failover, and short-lived promotional redirects, anywhere the destination might change again soon.

Unlike 301, browsers generally do not cache a 302 for long unless the response carries explicit caching headers (Cache-Control, Expires), because the semantics say the redirect is temporary. Search engines similarly keep indexing the original URL rather than transferring ranking signal to the target, which is why 302 is the wrong choice for a permanent site migration and 301 or 308 should be used instead.