302 Found

The resource is temporarily at a different URL given by the Location header. The original URL remains canonical — clients and search engines should not update their references.

What It Means

A 302 Found response tells the client that the requested resource has been temporarily moved. The server provides the temporary location in the Location response header. Clients should follow the redirect, but must continue to use the original URL for future requests.

Unlike 301, a 302 response is not cached by default. Caches require an explicit Cache-Control or Expires header before they will store a 302. This makes 302 reversible — you can change or remove the redirect without worrying about stale cache entries in browsers.

When It Occurs

• Temporary promotions or campaigns. Redirecting a stable URL to a landing page for a limited time.
• Login redirects. Sending unauthenticated users to a login page with ?next= appended, then redirecting back after authentication.
• A/B testing. Temporarily routing some traffic to a variant URL without making the redirect permanent.
• Maintenance pages. Routing traffic to a status page while the origin is down.

Common Issues

• Using 302 when you mean 301. If the move is permanent, use 301. Using 302 for permanent moves means search engines continue crawling both the old and new URL, potentially splitting link equity.
• Method change (POST to GET). Historically, many clients changed the method from POST to GET when following a 302. RFC 9110 acknowledges this historical behavior — clients MAY change POST to GET on a 302 — so use 307 (Temporary Redirect) when you need the method preserved.
• Redirect loops. A 302 can create a loop just like a 301 — for example, a login redirect that sends already-authenticated users back to the login page.

How to Diagnose

Use the Probe tool to trace the full redirect chain. Verify the Location header at each hop and confirm the final destination returns a 200. For the difference between 301 and 302, see the 301 vs 302 comparison.