Status code 302 is an HTTP response used to indicate that a web page or resource has been temporarily moved to a different URL. In 2026, it will remain an important part of web development and SEO management. When a server sends a 302 redirect, it tells browsers and search engines to visit a new location for a short period while keeping the original URL unchanged in most cases. It is commonly used for temporary page changes, testing, or maintenance.
What Is HTTP Status Code 302?
A 302 status code, officially called “302 Found,” is an HTTP response that tells browsers and crawlers the requested resource has temporarily moved to a different URL, specified in the Location response header. Unlike a 301, the original URL is considered the canonical address and should continue to be indexed.
When a server returns a 302, the browser silently follows the Location header and loads the destination page. The user never sees it happen. From a browser perspective, it’s nearly invisible.
From a search engine perspective, it’s a different story.
The response looks like this in raw HTTP:
HTTP/1.1 302 Found
Location: https://www.example.com/new-profile-url
Content-Type: text/html; charset=UTF-8
Content-Length: 0
The original URL stays live. The server is saying: “What you want is over there for now.”
How a 302 Redirect Actually Works (Step by Step)
Most explanations stop at “it redirects the user.” That’s true but incomplete. What browsers and bots do mechanically matters.
How-to block (Featured Snippet B):To understand how a 302 redirect processes:
- Browser sends a GET request to the original URL.
- Server responds with 302 and a Location header pointing to the new URL.
- Browser automatically sends a new GET request to the destination URL.
- Server responds with 200 OK and serves the page content.
- Browser displays the destination page — the original URL stays in most browser histories.
One detail worth flagging: when a 302 responds to a POST request, browsers are permitted by the HTTP spec to switch the follow-up request to a GET. This method-switching behavior is why 307 Temporary Redirect exists. If you need the method preserved (POST stays POST), use 307, not 302.
302 vs 301 vs 307 The Comparison That Actually Matters
This is where most developers get burned. The codes feel similar. They’re not.
Comparison block (Featured Snippet C)
Quick Comparison
Code | Type | SEO Link Equity Passed? | Method Preserved? | Best For |
301 | Permanent redirect | Yes | No (POST→GET allowed) | Permanently moved pages, domain migrations |
302 | Temporary redirect | No | No (POST→GET allowed) | Temporary campaigns, A/B tests, maintenance pages |
307 | Temporary redirect | No | Yes (POST stays POST) | API redirects, form submissions, login flows |
303 | See Other | No | Always changes to GET | Confirming POST submissions (e.g., “your order was placed”) |
302 is better suited for genuinely temporary situations because the original URL remains the canonical address. 301 works better when a page has moved for good the key difference is whether you intend search engines to update their index.
Some experts argue that Google is “smart enough” to eventually treat a long-standing 302 like a 301. That’s valid in theory Google has said it may eventually follow this logic. But if you’re dealing with a page that’s been 302-redirecting for 6+ months and you actually want the destination URL indexed and ranking, don’t rely on Google’s interpretation. Just use a 301.
The SEO Impact of a 302 Redirect (This Is What Most Guides Skip)
FLet’s be direct about this.
According to Google’s John Mueller (Google Search Central, 2021), 302 redirects do not pass PageRank to the destination URL. Link equity stays on the source URL. So if a page with 40 referring domains is sitting behind a 302 to a new URL, those 40 domains are not helping the destination rank.
That’s not a fringe edge case. That’s the default behavior.
Most junior SEOs either don’t know this, or they’ve read conflicting Stack Overflow threads and decided it’s probably fine. I’ve seen conflicting data here; some case studies suggest Google does eventually consolidate signals on long-running 302s in certain crawl conditions. My read is: don’t gamble on Google’s interpretation when a one-line server config change solves it permanently.
The other indexation risk: if your 302 redirect chain is longer than one hop, Google may not crawl past it at all. Screaming Frog SEO Spider will visualize your entire redirect chain, including all intermediate 302s, and flag chains over two hops.
A 302 doesn’t just fail to pass link equity it can cause the wrong URL to get indexed. If Googlebot sees the 302 consistently, it may decide the destination is a better canonical choice and index that instead of your original. Now you’ve got two competing URLs with diluted authority and no clear canonical signal.
When a 302 Is the Right Choice
Here’s a framing that helps: ask whether you want the original URL to remain the canonical address. If yes, 302 is correct. If not, use 301.
Legitimate 302 use cases include:
A/B testing
When you’re routing 50% of traffic to a variant URL temporarily, a 302 is exactly right. You don’t want search engines indexing the variant.
Login-wall redirects
A user hits /dashboard, the server checks authentication, finds they’re not logged in, and 302s them to /login. The original /dashboard URL should remain the canonical destination — the redirect is a temporary gate.
Geographic redirects
A UK visitor hits example.com and gets 302’d to example.co.uk. The .com stays canonical globally; the redirect is conditional. (Though for large-scale geo-targeting, hreflang + 302 in combination is worth discussing with your SEO team separately.)
Maintenance pages
If you take a page down for 2 hours for updates and redirect to a “we’ll be back” page, 302 is semantically correct. A 301 would tell crawlers to update their index wrong signal for a 2-hour window.
How to Detect and Fix 302 Issues in Practice
Look if you’re a developer who’s just inherited a codebase and you’re seeing unexpected 302s, here’s what actually works.
Detection
- Google Search Console: Coverage report → filter for “Excluded” URLs → look for “Redirect error” or unexpected indexed URLs that should have changed
- Screaming Frog SEO Spider: Response Codes tab → filter for 3xx → export and look for any 302 on URLs that have been “permanently” moved
- Browser DevTools: Network tab → load the URL → check the Status column in the waterfall for any 302 before the final 200
Conclusion
The 302 status code is essential for managing temporary web redirects without permanently affecting SEO structure. However, it must be used carefully because improper use can impact search engine indexing and user experience. In 2026, understanding when to use a 302 redirect versus a 301 redirect is crucial for developers and website owners to maintain proper site performance.
FAQs
What's the difference between a 301 and 302 redirect?
A 301 is permanent; it passes link equity and tells search engines to update their index. A 302 is temporary; it keeps the original URL as canonical and doesn’t transfer PageRank to the destination.
Does a 302 redirect hurt SEO?
It can. A 302 used where a 301 was needed means link equity stays on the old URL, the destination may struggle to rank, and the wrong URL could end up indexed over time.
When should I use a 302 instead of a 301?
Use a 302 when the redirect is genuinely temporary login gates, A/B tests, maintenance pages, or conditional geo-redirects where the original URL should remain canonical.
Why does my 302 redirect change POST to GET?
By the HTTP specification (RFC 9110), browsers are permitted to switch a POST request to GET when following a 302. If you need the method preserved, use a 307 Temporary Redirect instead.
How do I find 302 redirects on my site?
Use Screaming Frog SEO Spider to crawl your site and filter by 3xx response codes. Google Search Console’s Coverage report also flags redirect issues that affect indexation.
