302 Found (Temporary Redirect)

Redirect

The requested resource resides temporarily at a different URL. The client should continue to use the original URL for future requests because the move is not permanent. Most browsers and HTTP clients historically rewrote the request method from POST to GET when following a 302, which is technically a violation of the original HTTP/1.0 semantics but has become the de-facto behavior. That is why 303 and 307 were added in HTTP/1.1 to make the intent explicit.

When does this happen?

Use 302 when the redirect is genuinely temporary. A maintenance page that will go away, a marketing campaign URL that funnels to different landing pages, an A/B test that sends traffic to a variant, or a geo/locale router that picks a localized URL on each request. Search engines treat 302 redirects as a hint not to transfer ranking signals; the original URL stays in the index and the destination is not credited with backlinks. Browsers do not cache 302s aggressively the way they do 301s, so you can change the destination without worrying about poisoned caches. The Location header is required. If you genuinely need a permanent move, use 301 or 308. Leaving a 302 in place for years is a classic SEO mistake that costs ranking. For API endpoints where method preservation matters, prefer 307 instead. Many older HTTP libraries will silently rewrite POST to GET when following a 302.

Common causes

• Maintenance window. The application server is down for deploy and the load balancer 302s every URL to /maintenance.
• A/B testing infrastructure that routes a fraction of users to /home-variant-b on each request.
• Geo-based redirect that sends visitors from /products to /uk/products or /us/products based on IP.
• Authentication wall. Anonymous users hitting /dashboard are 302'd to /login with a return-to parameter.
• Marketing tracker that 302s through an analytics endpoint before landing the user on the final URL.
• Short-link service that 302-redirects branded short URLs to their long destinations. They choose 302 over 301 so they can change the destination later.
• Old code that uses 302 reflexively when the developer meant 301. A very common misconfiguration.

How to fix it

• If the move is permanent, switch to 301. Leaving a 302 in place prevents search engines from updating the canonical URL and consolidating link equity.
• Verify the Location header points at the right URL. Relative paths can interact badly with proxies that rewrite paths.
• Audit any code that returns 302 from an API endpoint that accepts POST. If you need method preservation, use 307 instead.
• For maintenance redirects, include a Retry-After header so well-behaved crawlers and clients know when to come back.
• Confirm the destination of a 302 returns 200, not another redirect. Chains are expensive and crawlers limit hops.
• Avoid 302-redirecting based on User-Agent. Cloaking risks an SEO penalty and breaks for bots that detect the difference.
• If your CDN or edge layer adds a 302 you did not configure, check the rules order. Most edges have a redirect rule list that is order-sensitive.

Real-world examples

Application deploy in progress. The load balancer routes every request to /maintenance until the new version is healthy.

Server returns 302 with Location: /maintenance and Retry-After: 300. Browsers follow and render the maintenance page; crawlers respect Retry-After and come back later.

Anonymous user navigates to /dashboard and the app requires login.

Server returns 302 with Location: /login?return_to=/dashboard. Browser follows, user signs in, and the login handler redirects them back.

Marketing email contains a bit.ly link that wraps the real destination for click tracking.

bit.ly returns 302 with Location pointing at the long URL. Browser follows and the user lands on the final page. The 302 keeps the short URL evergreen.

Geo-redirect at the edge sends every visitor from .com/products to /us/products or /uk/products based on IP.

Server returns 302 with the localized Location. Different users see different redirects from the same URL, which is why 301 would be wrong here.

Legacy POST endpoint /v1/login returns 302 to /v1/login/success after a successful auth.

Browser drops the POST body and follows with GET. This is the historical 302 behavior that 307 was designed to fix.

Debugging

• Run curl -I https://example.com/path and confirm the response is 302 with a Location header pointing at the expected URL.
• Run curl -IL https://example.com/path to follow the chain and see whether the 302 ultimately lands on a 200 in a reasonable number of hops.
• Inspect the Cache-Control header on the 302. Without explicit no-store, some intermediaries will cache short-term and surprise you.
• In DevTools Network tab, look for the 302 row and then the next request. Confirm the method on the second request is what you expect (GET vs original).
• If a 302 is appearing where you expected 200, check edge rules, .htaccess, and middleware order. The redirect may be added before your application code runs.

How it differs from related codes

HTTP 301

301 is permanent and aggressively cached by browsers. 302 is temporary, not cached, and leaves the original URL canonical in search engines.

HTTP 303

303 explicitly tells the client to use GET for the next request. Useful after POST to avoid form resubmission on refresh. 302 is ambiguous about method handling.

HTTP 307

307 is a strict-method temporary redirect. The client must preserve POST/PUT/DELETE and the body. 302 is the legacy form that most clients downgrade to GET.

Related status codes

200 301 303 307 308