Before configuring any redirect, one question settles the choice: will the original URL ever serve content directly again? If the honest answer is no, you want a 301, and most redirects that get built as 302s fail that test. A 302 is not a gentler or safer version of a 301. It is a different signal that tells search engines the move is temporary, and using it when you meant a permanent move quietly costs you.
A 302 tells the browser the requested URL has temporarily moved. The user is sent to the new location, but the server signals that the original URL is still authoritative and may resume serving content later. Most 302s in production are accidents: the framework defaults to 302, someone copies an .htaccess rule without checking the code, or the redirect gets set up in a hurry with nobody deciding which type applies. The result is a permanent move wearing a temporary label, which produces the wrong outcome in search. This piece covers where 302 is genuinely correct and how to find the ones that should have been 301. The permanent-move mechanics and the full status-code map are separate topics; here the focus is only the 302-versus-301 decision.
What a 302 actually does to crawlers and link signals #
When a search engine receives a 302, it reads the response as “this URL is the real one, but content is being served elsewhere for now.” Per Google’s redirect documentation, a temporary redirect keeps the source URL in search results, while a permanent one moves the destination into results. That plays out three ways. The original URL stays indexed and keeps appearing in results even though clicks land on the target, where a 301 would replace it. Link signals stay with the original rather than transferring to the destination, which strands them if the move is actually permanent. And Googlebot tends to re-crawl the original more often, since it is flagged as temporary, which can waste crawl budget on a large site.
There is a safety net, worth understanding precisely so you do not lean on it. Google has stated repeatedly, through representatives including John Mueller, that a 302 left in place for a long time gets treated more like a 301, with signals transferring after enough time. There is no fixed cutoff; a 302 live for many months, with links pointing at the destination, may eventually behave like a 301. That corrects the common myth that a 302 passes no signal at all. It does pass them, eventually, but the timeline is variable and slower than doing it right, so the mechanism is a backstop, not a substitute for the correct code.
The legitimate uses of 302 #
The real cases are narrower than common practice suggests. A handful of patterns genuinely fit, and each shares the same three conditions: the move is truly temporary, the original URL is truly authoritative, and the destination is a stand-in that should not replace the original in results.
A/B testing with a separate variant URL. The test is temporary, the variant is not meant to replace the original, and measurement depends on the canonical URL staying in results. A 302 to the variant keeps the original indexed while routing test traffic.
Geographic or language redirects, with caveats. A visitor in France hits the global product page and gets sent to the French version. This is the most contested item on the list. Google favors hreflang annotations and a language selector over automatic IP-based redirects, because Googlebot crawls primarily from US-based IPs; an IP redirect can leave the crawler seeing only one regional version while others go uncrawled. (Hreflang annotations are HTML or sitemap declarations telling search engines which URL serves which language and region.) When such a redirect is truly unavoidable, 302 with hreflang for every variant is the pattern, but the cleaner default is hreflang plus a banner suggesting the regional version rather than forcing a redirect.
Maintenance during temporary downtime. A site under maintenance sends its URLs to a maintenance page. A 302 signals the temporary nature, though a 503 Service Unavailable response with a Retry-After header is more correct, since it flags the outage without implying a redirect at all.
Authentication redirects to a login screen. A user clicks a protected page, gets routed to login, then returns after signing in. The login URL is a temporary intermediate stop. A 302 works, though many implementations use 303 (See Other), which is more semantically correct for the sign-in-then-return flow.
Out-of-stock products with planned restocking. A product is temporarily unavailable but will return, so its page redirects to the category during the gap. The original should stay indexed because it will serve content again. A 302 fits, removed once the product is back.
The cases that look temporary but are not #
Plenty of moves feel temporary when built and turn out permanent. A discontinued product is gone; the redirect to the category page should be a 301. A consolidated blog post, where two articles merge, is a permanent move from the absorbed URL. A renamed page will not use the old URL again. A migrated domain, where every old URL maps to a new one, is the canonical permanent move; 301 with no exceptions, and 302 here is one of the most damaging redirect mistakes in common practice. An HTTP-to-HTTPS change and a staging-to-production switch are both permanent. In each, the move is irreversible, so the redirect should be permanent because the move is. The mental test is one question: is there a realistic scenario where the original URL starts serving content directly again? If yes, 302 might fit. If no, 301 is the answer, and most candidates fail it.
The status codes that look similar but are not #
The 3xx family holds several redirect types with overlapping but distinct purposes.
| Status code | Meaning | When to use |
|---|---|---|
| 301 | Moved Permanently | Permanent redirects, the standard case for URL changes |
| 302 | Found (temporarily moved) | Genuinely temporary redirects, a narrow set of cases |
| 303 | See Other | Redirect after a POST request, often for form submissions |
| 307 | Temporary Redirect | Like 302 but explicitly preserves the request method |
| 308 | Permanent Redirect | Like 301 but explicitly preserves the request method |
The 303 code handles a POST-then-GET pattern: after a form submission, the user is redirected to a result page fetched with a fresh GET, so refreshing it does not re-submit the form, which is the standard flow behind thank-you pages. The 307 and 308 codes were added in HTTP/1.1 to remove an ambiguity where older browsers handled non-GET requests inconsistently. For search, 308 behaves like 301 and 307 like 302; the newer codes matter most for API endpoints and form-handling URLs.
One 307 case causes recurring confusion: the internal 307 tied to HSTS. When a site sends an HSTS header, the browser rewrites HTTP to HTTPS itself on later visits, showing a 307 in developer tools. That 307 is a browser-internal action, not a redirect the server sent. Google has clarified that Googlebot does not carry an HSTS list the way a browser does; it fetches the HTTP URL directly and follows whatever real redirect the server returns, which for a proper HTTPS setup is a 301. So the HSTS 307 in DevTools is neither something you configure nor something Googlebot acts on, and it is no substitute for the server-side 301 a protocol migration needs.
How to find the 302s that should be 301s #
Most content sites carry 302s that should be 301s, so detection comes first. Server log analysis surfaces every 302 the server returned with its from and to URLs. A crawler such as Screaming Frog follows redirects and reports the status code for each chain. Manual inspection covers what the crawler cannot reach: open the .htaccess file, the Nginx config, the WordPress redirects plugin, and any CDN-level rules, and apply the temporary-or-permanent test to each 302. Google Search Console flags redirected URLs in its Page indexing report, so cross-referencing that against the configured rules reveals where the code you set is not the one Google saw.
The fix is the same each time: change the code to 301. Signals transfer over time, the index updates to show the new URL, and crawl activity on the original settles. A few defaults make the wrong code easy to miss. Some frameworks return 302 when a generic redirect function runs without a status code, so Express, Django, and Rails each expose an explicit way to set it. Older Apache versions default the bare Redirect directive to 302, so Redirect 301 has to be stated. Checking the actual response with curl -I, browser DevTools, or a redirect checker catches these. Worth doing across the whole site once, then revisiting, since new redirects can default back to 302.
FAQ #
Does a 302 pass any ranking signal, and how long until Google treats it like a 301?
Not immediately, which is the point of the code: signals stay with the original URL on the assumption it will resume serving content. The claim that a 302 passes nothing at all is outdated, though. Google treats a long-running 302 more like a 301 over time and does transfer signals, but there is no published cutoff and the timing is unpredictable, so this is a backstop rather than a plan.
Should I use 301 or 302 for an HTTP-to-HTTPS migration?
- The move is permanent, so a 302 sends the wrong signal in one of the most damaging contexts for the mistake. The HSTS-related 307 in DevTools is a browser action, not a server redirect, and does not replace the server-side 301 the migration needs.
The harder question is never “when should I use a 302?” It is “am I sure this is actually temporary?” A maintenance window planned for a week becomes a six-month outage; an A/B test set to run a quarter never gets concluded; a product due back in stock never returns. If there is any doubt, 301 is the safer reach, since a permanent redirect can be removed later if things reverse, while a temporary one that should have been permanent strands signals until Google’s slow auto-correction catches up. Use 302 only when you can name the specific event that will return the original URL to service. If you cannot name the event, the move is not temporary, and 301 is what you actually want.