Found
ActiveHTTP 302 Found indicates the target resource resides temporarily under a different URI. Defined in RFC 9110 §15.4.3. The client should continue using the original URI for future requests. Unlike 301, this does not transfer SEO equity.
Description
The 302 Found status code indicates that the target resource resides temporarily under a different URI. The client should continue to use the original URI for future requests – this is a temporary diversion, not a permanent change.
The server SHOULD include a Location header. Unlike 301, a 302 response is not cached by default.
Many HTTP/1.0 clients incorrectly changed POST to GET on 302. This historical behavior is why 307 Temporary Redirect was created – 307 guarantees method preservation. In practice, most modern frameworks use 302 for login redirects (where a GET is expected after POST anyway) and 307 when the POST method must be preserved through the redirect.
Examples
GET /promo HTTP/1.1
Host: shop.example.comHTTP/1.1 302 Found
Location: https://shop.example.com/seasonal-sale
Cache-Control: no-cacheEdge Cases
- •Login redirect: 302 is the standard redirect to a login page when an unauthenticated request hits a protected resource. Always include the original URL as a returnUrl parameter so users land where they intended after login.
- •A/B testing: 302 is correct for routing users to test variants. Using 301 for A/B testing caches the variant assignment in browsers and breaks the test for returning users.
- •Accidental 302 vs 301: many frameworks default to 302 for all redirects. If the redirect is permanent (URL restructuring, domain migration), use 301. Leaving permanent changes as 302 keeps search engines indexing the old URL indefinitely.
- •Never 302 to a 404. Verify the redirect target is live before deploying – a redirect to a non-existent page is an immediate UX and SEO failure.
- •Google treats 302 redirects lasting more than roughly one year as 301 for indexing – the original URL may eventually be replaced in the index. But this is not guaranteed or fast.
- •POST to GET: 302 does not preserve the HTTP method. If a POST must remain a POST after redirect, use 307. If a POST should become a GET (standard form submission redirect pattern), 302 or 303 are both appropriate.
When You'll See This
- →Redirecting to login page when unauthenticated
- →A/B testing variants
- →Temporary maintenance redirects
- →Geo-based content routing
Implementation References
| Language | Constant |
|---|---|
| Go | http.StatusFound |
| Rust | http::StatusCode::FOUND |
| Python | http.HTTPStatus.FOUND |
| Node.js | http.STATUS_CODES[302] |
| .NET | HttpStatusCode.Found |
| Java | HttpURLConnection.HTTP_MOVED_TEMP |
History
Originally defined in HTTP/1.0 (RFC 1945, 1996) as 'Moved Temporarily'. Renamed to 'Found' in HTTP/1.1. The method-changing behavior led to the creation of 307.
Related Status Codes
Related Headers
FAQ
What is the difference between 301 and 302?
301 is permanent (change bookmarks, update SEO). 302 is temporary (keep using the original URL, no SEO transfer).
When should I use 302 vs 307?
Use 307 if you need the HTTP method preserved (POST stays POST). Use 302 for general temporary redirects where method changing is acceptable.