What is 302 Redirect?
Definition
A 302 redirect is a server response with the status code 302 Found, saying the requested resource temporarily lives at another address. The user is sent to the URL in the Location header, but clients are expected to keep using the original URL in future. Google follows a 302 without treating it as a canonical signal, so the source URL usually stays in search results. 307 Temporary Redirect is its method-preserving equivalent.
Also known as: Found, temporary redirect, HTTP 302, 302 Found
What a 302 promises
RFC 9110 keeps it short: the target resource resides temporarily under a different URI, and since the redirect might change, the client ought to keep using the original URL for future requests. In plain words, a 302 says "go over there for now, but my address hasn't changed".
HTTP/1.1 302 Found
Location: https://example.com/maintenance-notice/
Cache-Control: no-storeGoogle reads it the same way. Googlebot follows the redirect, but the indexing pipeline doesn't use it as a signal that the target should be canonical; in Google's words, temporary redirects show the source page in search results. The permanent-versus-temporary comparison lives on the redirect overview, and the permanent side is covered in detail under 301 redirect.
Where a temporary redirect belongs
- Experiments: for A/B tests that send users from the original URL to a variant URL, Google explicitly recommends 302 rather than 301, so the original stays indexed while the test runs.
- A service that is briefly unavailable: sending visitors to a page that explains the outage keeps the original URL's place in search intact.
- Pages that need a session: bouncing a signed-out user to
/login?next=/account/is temporary by nature. - Short campaigns: pointing a category URL at a promotion for a couple of weeks, then removing the rule.
The common thread: once the redirect is removed, you want the original URL to carry on as before. If the address has genuinely changed, 302 is the wrong tool.
307 Temporary Redirect and 303 See Other
Like 301, a 302 lets the browser turn a POST into a GET when following it. 307 keeps the "temporary" meaning but forbids the client from changing the HTTP method, so a form post or API call arrives at the new URL intact. 303 See Other deliberately does the opposite: after a POST, it sends the user to a result page with GET, the classic Post/Redirect/Get pattern. Google treats 307 as equivalent to 302.
Not every 307 in DevTools came from your server. On a site using HSTS, the browser upgrades http:// requests to HTTPS internally and labels this a "307 Internal Redirect"; no such response was ever sent.
Accidental 302s from framework defaults
Many 302s on real sites are defaults rather than decisions. In PHP, sending only header('Location: ...') produces a 302; in Express, res.redirect() without a status code does the same. Next.js uses 307 for redirect() and for rules with permanent: false. Run a permanent move through those defaults and the site quietly tells Google the old address is still the real one. State the code explicitly every time: 301 or 308 for permanent moves, 302 or 307 for temporary ones.
What happens to a 302 left in place for months?
Google's documentation does not describe any rule that silently promotes a temporary redirect to a permanent one. What it does say is subtler: with a temporary redirect, the target page might still be indexed if other canonicalization signals point at it. So a 302 that stays for a year while internal links, the sitemap and the canonical tag all name the target may well end with the target chosen as canonical; with mixed signals the outcome is hard to predict. If the move is permanent, switching to 301 or 308 is the only reliable way to state that intent, rather than waiting for Google to work it out.
curl -sI shows which code a URL returns. After any migration, bulk-check the old URL list and pull every 302 into its own review list; Google's rules are documented on Google Search Central.