302 is the wrong default, but it’s the right choice for specific situations:
A 302 redirect is an HTTP response code that tells the browser the requested URL has temporarily moved to a different location. The user gets sent to the new URL, but the server signals that the original URL is still the authoritative one and may resume serving content directly at some point in the future.
The 302 status code exists because not every redirect is permanent. A site running an A/B test routes some users to a variant page without claiming the variant has replaced the original. A geographic redirect sends visitors to a region-specific page based on their location, but the regional URL doesn’t replace the canonical one. An e-commerce site temporarily redirects an out-of-stock product page to a category page while the product is being restocked. In each case, the redirect is temporary by design, and 302 signals that intent.
The trouble is that most actual uses of 302 redirects are mistakes. Sites use 302 because the framework defaults to 302, or because someone copied an .htaccess rule from a tutorial without checking the status code, or because the redirect was set up quickly and the operator didn’t think about which type to use. The result is that pages get treated as temporarily moved when they’re actually permanent moves, which produces the wrong SEO signal.
This article covers when 302 is the correct choice. The implicit theme: most situations that look like 302 candidates are actually 301 candidates, and using 302 produces the wrong outcome. The clean URLs piece covers 301 redirects as the standard tool for permanent URL changes; this piece is about the narrower set of cases where 302 is genuinely the right answer.
What 302 actually does to crawlers and link signals:
When a search engine crawls a URL and receives a 302 response, the crawler interprets the response as “this URL is the real URL, but right now the content is being served from a different location.” The redirect destination gets followed for the immediate fetch, but the original URL remains the canonical version in the index.
The practical consequences differ from 301 in three specific ways.
The original URL stays in the index. With 301, the original URL gets replaced in Google’s index by the redirect destination, and search results start showing the new URL. With 302, the original URL stays in the index, and search results continue showing the original URL even though clicks lead to the redirect destination.
Link equity stays with the original URL. With 301, the link signals from inbound links transfer to the new destination over time. With 302, the link signals remain associated with the original URL, on the assumption that the original URL will resume serving content directly. If the redirect is genuinely temporary, this is the right behavior. If the redirect is actually permanent, the link signals are stranded.
Crawl behavior differs subtly. Googlebot continues to re-crawl the original URL more frequently when it sees a 302, since the redirect is signaled as temporary and the original URL might start serving content directly again. This produces more crawl activity on the redirected URL than 301 would, which generally doesn’t matter but can waste crawl budget at scale.
The accumulated effect: 302 redirects that should have been 301 redirects produce search results that show the original URL, link signals that stay on the original URL, and ongoing crawl traffic to the original URL. Each of these is a problem if the move is actually permanent.
Google’s own documentation and statements from search representatives over the years have noted that the crawler eventually treats long-running 302 redirects as if they were 301 redirects, transferring signals after enough time has passed. The detection isn’t precisely calibrated, and the timeline is variable, but a 302 in place for many months may eventually behave like a 301 in Google’s index. The mechanism exists because so many sites use 302 when they meant 301. It’s a safety net, not a substitute for using the right status code.
The five legitimate uses of 302:
The actual cases where 302 is the correct choice are narrower than common practice suggests. Five patterns fit.
A/B testing where the variant URL exists separately. A site runs a test where some visitors see version A of a page and others see version B, with the variant served from a separate URL. The test is temporary by design, the variant URL is not meant to replace the original, and the analytics measurement depends on the canonical URL remaining in search results. 302 redirects from the canonical URL to the variant URL preserve the original in the index while serving the test traffic correctly.
Geographic redirects with caveats. A user in France visits the global URL example.com/product. The site redirects them to example.com/fr/product for the French-language version. This is the most contested item on the list. Google’s own guidance recommends hreflang annotations and language selectors rather than automatic IP-based redirects, because Googlebot crawls primarily from US-based IPs and an IP-based redirect can cause the crawler to see only one regional version, leaving other versions effectively uncrawled. When automatic geographic redirects are unavoidable, the typical pattern is a 302 with explicit exemptions for known crawler user-agents and hreflang annotations declaring every regional variant. (Hreflang annotations are HTML or sitemap declarations that tell search engines which URLs serve which language and regional audiences, so the right version surfaces in the right country’s search results.) Even with these protections, the cleaner default is hreflang plus a banner or popup suggesting the regional version without forcing the redirect. The redirect-type point is that when geographic redirects are used at all, 302 is the right status code, but the prior question of whether to use them is usually answered in favor of not.
Maintenance pages during temporary downtime. A site under maintenance temporarily redirects all URLs to a maintenance page. The redirect is genuinely temporary, the original URLs will return shortly, and the index should not be updated to show the maintenance page as the canonical version. 302 to the maintenance page (or, better, 503 Service Unavailable with a Retry-After header) signals the temporary nature.
Authentication redirects to login. A user clicks a link to a protected page and gets redirected to the login screen. After authentication, the user returns to the original URL. The login URL is not the canonical version of the protected page, it’s a temporary intermediate stop. 302 is appropriate for the login redirect, though many implementations actually use 303 (See Other), which is more semantically correct for the POST-redirect-GET pattern.
Out-of-stock product pages with planned restocking. An e-commerce product is temporarily unavailable but will return. The product page redirects to the category page or a related-product page during the gap. The original URL should remain in the index, since it will resume serving content. 302 fits, with the redirect removed when the product comes back.
In each of these cases, the redirect is genuinely temporary, the original URL is genuinely the authoritative version, and the redirect destination is genuinely a substitute that should not replace the original in search results. When any of those conditions fails, 302 is the wrong choice.
The cases that look temporary but aren’t:
Many situations feel temporary at the time the redirect gets set up but turn out to be permanent. These are the cases where 301 is the correct choice even though the operator initially reaches for 302.
A discontinued product. The product is gone. It’s not being restocked. The redirect to the category page should be permanent, since the product URL is not coming back. 301 is correct here, not 302.
A consolidated blog post. Two similar articles get merged into one. The redirect from the absorbed article to the surviving one is permanent. The original URL won’t resume serving content. 301 is correct.
A renamed page. A page’s URL changes for clarity, branding, or restructure reasons. The old URL won’t be used again. The redirect is permanent. 301.
A migrated domain. The site moves to a new domain entirely. Every URL on the old domain redirects to the corresponding URL on the new domain. This is the canonical permanent move. 301 is correct, with no exceptions, and using 302 here is one of the most damaging SEO mistakes in common practice.
A protocol change. HTTP to HTTPS migration. The old HTTP URLs will not be served again. 301 is correct. The HTTPS migration piece covers this in detail; the same redirect-type discipline applies.
A staging-to-production switch. A test URL gets promoted to the live URL. The test URL won’t come back. 301.
The pattern across all of these: the move is irreversible. The original URL won’t be used again as a content destination. The redirect should be permanent because the move is permanent.
The mental test that separates 301 cases from 302 cases is simple. Is there any realistic scenario where the original URL will start serving content directly again? If yes, 302 might be right. If no, 301 is the answer. Most of the cases that initially look like 302 candidates fail this test, and the redirect should be 301.
The status codes that look similar but aren’t:
The 3xx family of status codes contains several redirect types with overlapping but distinct purposes. Understanding what each one signals prevents the wrong choice.
| Status code | Meaning | When to use |
|---|---|---|
| 301 | Moved Permanently | Permanent redirects, the canonical case for URL changes |
| 302 | Found (temporarily moved) | Genuinely temporary redirects, narrow set of cases |
| 303 | See Other | Redirect after a POST request, often for form submissions |
| 307 | Temporary Redirect (HTTP/1.1) | Same as 302 but explicitly preserves the request method |
| 308 | Permanent Redirect (HTTP/1.1) | Same as 301 but explicitly preserves the request method |
The 303 status code handles a specific pattern: after a form submission (POST request), redirect the user to a different URL for the result page (GET request). The browser issues a fresh GET request to the redirect target rather than retrying the POST. This is the standard pattern for “thank you” pages after form submissions, and 303 is more semantically correct than 302 for this case.
The 307 and 308 status codes were introduced in HTTP/1.1 to fix an ambiguity in 301 and 302. Older redirects had inconsistent behavior with non-GET requests: some browsers would change POST to GET on redirect, others would preserve the method. 307 and 308 explicitly preserve the original method. For SEO purposes, 308 behaves like 301 and 307 behaves like 302. The newer codes matter for API endpoints and form-handling URLs more than for typical content URLs.
For most content sites, the practical choice is between 301 (permanent) and 302 (temporary). The other codes apply in specific architectural patterns but don’t affect the basic redirect-type decision.
Implementation: where to set 302 redirects correctly:
Setting up redirects depends on the server platform and the level at which the redirect should apply. Three implementation patterns cover most cases.
Server configuration. Apache’s .htaccess file uses the Redirect directive with the status code as the first argument:
Redirect 302 /old-path /new-pathNginx uses the return directive with the status code:
location /old-path {
return 302 /new-path;
}Server-level redirects are fast (no application code involved) and reliable (they happen before any framework processing).
Framework-level. Most web frameworks expose redirect functions that include a status code parameter. Express.js uses res.redirect(302, '/new-path'). Django uses HttpResponseRedirect for 302 or HttpResponsePermanentRedirect for 301. Ruby on Rails uses redirect_to '/new-path', status: 302. Framework-level redirects integrate with application logic but add overhead compared to server-level configuration.
CMS plugins. WordPress, Shopify, and similar platforms offer plugins or built-in features for managing redirects. The interface usually exposes a status code option, with 301 as the default for permanent redirects and 302 as the option for temporary ones. The plugin handles the underlying implementation.
The platform-specific defaults sometimes cause problems. Some frameworks default to 302 when calling generic redirect functions without specifying the status code. Some .htaccess patterns use Redirect (which defaults to 302 in older Apache versions) when Redirect 301 would be the correct directive. Some CMS plugins differentiate redirect features between free and paid tiers, which can quietly leave the user on a 302-only path without realizing it. Checking the actual status code returned by the redirect, using curl -I, browser DevTools, or a redirect checker, catches these defaults before they cause SEO damage.
Detection: finding the 302s that should be 301s:
Most sites with significant content have 302 redirects in place that should actually be 301 redirects. Detection is the first step in fixing them.
Server log analysis surfaces every 302 response the server has returned, along with the URLs being redirected from and to. A site crawler tool like Screaming Frog can crawl the site, follow redirects, and report the status code for each redirect chain. The crawler output shows every 302 in the crawl scope.
Manual inspection of redirect rules covers the cases that aren’t in the crawler’s reach. Open the .htaccess file, the Nginx configuration, the WordPress redirects plugin, the CDN-level redirect rules. Look for redirects using 302 status codes. For each one, apply the temporary/permanent test: will the original URL ever serve content directly again? If no, change to 301.
Google Search Console reports redirected URLs in the Page indexing report (formerly Coverage report). The report shows URLs that returned redirects during crawl, with the status code reported. Cross-referencing with the site’s redirect rules identifies cases where the configured status code doesn’t match what Google saw.
The fix in each case is straightforward: change the status code to 301. The original URL’s link signals transfer to the new URL over time. Google’s index updates to show the new URL in search results. The crawl activity on the original URL decreases as Google understands the move is permanent.
The detection work is worth doing across the whole site once, then revisiting periodically. New redirects added later may default to 302 again if the implementation pattern doesn’t enforce explicit status codes.
Seven 302 anti-patterns:
The misuses of 302 are remarkably consistent across sites. The same seven mistakes account for most of the wrongly-configured redirects in production.
- 302 for a permanently moved page. A page’s URL changed for site restructure, but the redirect uses 302 instead of 301. Fix: change to 301. The link equity transfers, the index updates, and crawl behavior aligns with the actual permanent move.
- 302 for a discontinued product. Product removed from inventory permanently, redirect to category page uses 302. Fix: 301 to the most relevant alternative (similar product, category, or related collection). The product URL won’t return.
- 302 chains. A URL redirects through multiple 302s before reaching a final destination. Each hop adds latency and dilutes the signal. Fix: consolidate to a single 302 (or 301) that lands on the final destination directly.
- 302 left in place from a temporary move that became permanent. A genuinely temporary redirect was set up correctly, but circumstances changed and the move is now permanent. The 302 was never updated. Fix: audit 302 redirects periodically. Convert to 301 once the temporary status becomes permanent.
- 302 used for HTTPS migration. The old HTTP URLs redirect to HTTPS with 302 instead of 301. The migration is permanent, but the signal says otherwise. Fix: change to 301 immediately. HTTPS migration is one of the most damaging contexts for using 302 by mistake.
- 302 from CMS default without manual override. A framework or plugin defaults to 302, and the user didn’t realize they needed to specify 301. Fix: change the default behavior in the CMS or framework settings. Document the correct status code for the team to use in future redirects.
- Mixed 301 and 302 across what should be uniform redirects. A site restructure produces hundreds of redirects, with some using 301 and others using 302 inconsistently. Fix: audit the redirect rules. Apply 301 uniformly to permanent moves, 302 only to the narrow temporary cases.
An eighth pattern worth flagging: 302 for a CDN cache miss. Some CDN configurations return 302 when the requested resource isn’t in the edge cache yet, redirecting to a fetch URL while the cache populates. This is generally a misconfiguration. Fix: the CDN should serve the resource directly, not redirect to it.
The right answer almost always begins with 301:
When the next redirect needs to be configured, the default reach should be for 301. The status code matches the most common reality: a URL changed, the change is permanent, the link signals should transfer to the new URL. The cases where 302 is actually correct are real but uncommon, and they require specific conditions to apply.
The clean URLs piece covers 301 as the standard tool for URL changes, with examples of when and how to use it. Most redirect work falls into that category. The cases this article covers (A/B test variants, geographic redirects, maintenance pages, authentication redirects, planned-restocking product pages) are narrow exceptions where the temporary nature is genuine and the original URL will continue to be the authoritative version.
The harder question isn’t “when should I use 302?” The harder question is “am I sure this is actually temporary?” Most situations that initially feel temporary turn out to be permanent in practice. A maintenance page that was supposed to last a week becomes a six-month outage. An A/B test variant that was supposed to run for a quarter never gets concluded. A product that was supposed to come back into stock never does. In each case, the redirect was set up as 302 because the operator thought the situation would resolve, and the situation never did.
If there’s any doubt about whether the redirect is genuinely temporary, 301 is the safer choice. A permanent redirect can be removed if the situation reverses, restoring the original URL. A temporary redirect that should have been permanent strands signals indefinitely, and Google’s eventual auto-correction takes longer and is less reliable than just setting up 301 in the first place.
The skeptical version of this article’s premise: most cases where you think you need a 302 redirect, you don’t. The genuinely temporary cases are a small minority. The mental cost of overusing 301 (occasionally having to update it when temporary really meant temporary) is much lower than the SEO cost of overusing 302 (link signals stranded, search results pointing at outdated URLs, ranking position uncertain about which version of the page is authoritative). Reach for 301 by default. Use 302 only when you can identify exactly why the move is temporary and what specific event will return the original URL to service. If you can’t name the event, the move isn’t temporary, and 301 is what you actually want.