A 302 redirect — officially "302 Found" — is an HTTP status code that tells a browser or search engine a requested URL has moved temporarily to a different location, while signaling that the original URL should remain the canonical, indexed version. It's fundamentally different from a 301 (permanent redirect) in intent: a 302 says "this content is here right now, but check back at the original URL later," while a 301 says "this content has permanently moved, update your records." Despite older SEO folklore claiming otherwise, a 302 passes full link equity to its destination — the same as a 301 does.
Key Takeaways
- A 302 redirect signals a temporary move — the original URL is expected to return to use, and search engines are meant to keep indexing the original URL rather than replacing it with the destination.
- A 302 passes full link equity to its destination, the same as a 301, 307, or 308 — the old belief that only 301s preserve SEO value is outdated and has been directly contradicted by Google's own Gary Illyes.
- Using a 302 for a genuinely permanent change is a common technical SEO mistake — it can cause Google to keep the old URL indexed far longer than intended, since the signal tells Google to expect the original URL back.
- 307 is the HTTP/1.1-era equivalent of a 302, with one technical difference: a 307 strictly preserves the original request method (like POST), while a 302 has historically been implemented inconsistently across browsers on this point.
- 302 redirects are commonly and correctly used for A/B testing, geotargeting based on visitor location, and genuinely temporary maintenance pages — situations where the original URL is meant to keep serving as the permanent, indexed destination.
Technical SEO is the broader discipline redirect strategy sits within, and correctly chosen redirect types directly protect the crawl budget efficiency a site depends on, since Google re-crawling and re-evaluating incorrectly redirected URLs wastes crawl resources that could go toward genuinely new or updated content.
When Should a 302 Actually Be Used Instead of a 301?
A 302 is the correct choice specifically when a URL's content has moved temporarily and the original URL is expected to return to active use — geotargeted redirects (sending a visitor to a region-specific page while keeping the general URL as canonical), A/B testing variants, and short-term maintenance pages are the clearest legitimate use cases. Using a 302 when the move is actually permanent is one of the more common technical SEO mistakes, since it sends Google a signal to keep the original URL indexed and treat the destination as temporary — which delays or prevents the kind of full authority consolidation a proper 301 achieves for a permanent change. The practical test worth applying before choosing: if there's a real, foreseeable scenario where the original URL will be used again, a 302 is correct; if the move is final, a 301 is the right choice regardless of how "temporary" the change might feel during implementation.
Does a 302 Redirect Actually Pass Less Link Equity Than a 301?
No — this is an outdated myth. Google's Gary Illyes has directly confirmed that all standard redirect types (301, 302, 307, and 308) pass full link equity to their destination URL, meaning the redirect type itself doesn't determine how much authority transfers. What redirect type actually controls is a permanence signal to Google's indexing systems — a 301 tells Google to treat the change as final and update its index accordingly, while a 302 tells Google to keep the original URL as the indexed, canonical version. The practical SEO consequence of choosing the wrong redirect type isn't lost link equity — it's Google potentially continuing to index and rank the wrong (original) URL for a change that was actually meant to be permanent.
The four redirect types:
- 301 (Moved Permanently) — intent signal: final, permanent change. Link equity: full equity passed. Typical use: permanent URL changes, domain migrations.
- 302 (Found) — intent signal: temporary change. Link equity: full equity passed. Typical use: A/B tests, geotargeting, temporary content.
- 307 (Temporary Redirect) — intent signal: temporary, strict method preservation. Link equity: full equity passed. Typical use: API/form-heavy temporary redirects needing exact method preservation.
- 308 (Permanent Redirect) — intent signal: permanent, strict method preservation. Link equity: full equity passed. Typical use: permanent changes requiring exact method preservation.
What's the Actual Technical Difference Between a 302 and a 307?
A 307 redirect is functionally similar to a 302 in signaling a temporary move, but strictly guarantees the original HTTP request method (like POST or GET) is preserved when following the redirect, whereas a 302's behavior around method preservation has historically been implemented inconsistently across different browsers. This distinction matters most for redirects involving form submissions or API calls, where changing a POST request into a GET request mid-redirect (a real risk with older, loosely-specified 302 handling) could cause a form submission to fail or behave unexpectedly. For most standard content redirects that don't involve form submissions, the practical difference between 302 and 307 is minimal — but for anything involving a form or API call being redirected, 307 offers a technically more reliable guarantee.
How Do You Actually Implement a 302 Redirect?
Implementation varies by server environment, but the core principle — signaling temporary status via the correct HTTP response code — stays consistent across platforms:
- On Apache servers, a 302 can be set in the .htaccess file using Redirect 302 /old-path /new-path, explicitly specifying the 302 status rather than relying on a default that might not match intent.
- On Nginx, a 302 is set within the server block configuration using return 302 /new-path; for the relevant location.
- Most CMS platforms (WordPress, Shopify, and similar) offer redirect management through plugins or built-in settings — confirm the interface is actually creating a 302 and not defaulting to a 301, since some tools default to permanent redirects regardless of stated intent.
- Test the redirect using a browser developer tools network tab or a dedicated HTTP status checker to confirm the actual status code returned matches what was configured, since misconfiguration is common and not always visually obvious.
- Monitor Google Search Console's coverage reports periodically for temporarily redirected URLs to confirm Google is treating them as expected — keeping the original URL indexed rather than shifting to the destination prematurely.
Frequently Asked Questions
Does using a 302 redirect too long (months or years) eventually cause Google to treat it like a permanent change anyway?
Google's systems can eventually adjust behavior for long-standing 302s that never revert, but this isn't a reliable substitute for using the correct 301 from the start if the change is genuinely permanent.
Can a 302 redirect cause duplicate content issues?
Not typically on its own, since Google understands a 302 signals the original URL remains canonical, though a poorly implemented redirect chain or loop involving 302s can create indexing confusion.
Is a 302 redirect visible to end users, or does it happen invisibly in the background?
A 302 redirect happens server-side and is generally invisible to users beyond the URL changing in their browser's address bar — there's no visible "redirect page" unless one is deliberately built into the flow.
Does a 302 redirect affect page load speed?
A redirect of any type (301, 302, 307, 308) adds a small additional server round-trip compared to serving content directly, though the practical speed impact is usually minor unless multiple redirects are chained together.
Can a 302 redirect be used for an entire domain migration?
It's technically possible but generally not recommended for a full domain migration, since that's inherently a permanent change better served by 301s, which correctly signal the permanence to search engines.
What HTTP status code should be used for a redirect that depends on the user's login status?
This scenario commonly uses a 302 or 307, since the redirect destination is conditional and temporary relative to that specific session or state, not a permanent URL change.
Does a 302 redirect ever get treated as an error by search engines?
A properly implemented 302 to a working destination isn't treated as an error; issues arise specifically from redirect chains, loops, or 302s pointing to broken or irrelevant destinations.
Is there a maximum number of 302 redirects that can be chained together safely?
There's no official hard limit, but chaining multiple redirects of any type adds latency and increases the risk of Google not following the full chain — keeping redirect paths as short and direct as possible is standard best practice.
Does a 302 redirect pass anchor text signals the same way a direct link would?
The redirect itself doesn't carry anchor text; anchor text signals come from the original linking page pointing to the pre-redirect URL, and that signal passes through the 302 to the destination along with the equity.
Can a 302 redirect be reversed easily if the temporary situation changes?
Yes — reversing a 302 is straightforward since the original URL was never removed from indexing consideration, unlike a 301 migration which typically requires more deliberate unwinding if reverted.
Does mobile vs. desktop redirect handling differ for 302s?
The HTTP status code behavior itself doesn't differ by device type, though device-based redirects (like redirecting mobile users to a separate mobile URL) are a common legitimate use case for 302s specifically because that redirect is conditional and not a permanent URL change.
