302 Found

302 Found is a temporary redirect: the resource currently lives at the URL in the Location header, but the client should keep using the original URL for future requests. Browsers don't cache it long-term and search engines keep the original URL indexed.

302 vs 301 vs 307

The "method preserved" column is the subtle one: historically browsers turned a POST that hit a 302 into a GET at the new location. If you redirect form submissions or API calls and need the method and body to survive, use 307.

Typical legitimate uses

• Post-login redirects and OAuth flows
• A/B tests and geo-based routing to a variant page
• Maintenance pages that will revert (though 503 is more correct for crawlers)
• "Random" or "latest" URLs that resolve to a changing target

Common problems

• 302 where 301 was intended — after a permanent migration, a lingering 302 means search engines keep the old URL indexed and don't transfer ranking. Audit migrations with a redirect-chain check.
• Login-wall redirects breaking monitors — a health check that follows a 302 to /login and reports 200 is testing your login page, not your app. Assert on the final URL or expect the 302 explicitly.
• Redirect loops — session logic that bounces between /login and /dashboard when a cookie is missing.

Debugging

Trace the chain with the free HTTP header checker — every hop, status and Location header. In an HTTP monitor you can pin the expectation: either "this URL returns 302 to exactly this target" or "following redirects ends at 200 on this final URL".