A 302 redirect is a server response that tells browsers and search engines a page is temporarily available at another address, and that the original URL is expected back. Its formal name is “302 Found”; a 307 does the same job with stricter rules about how the request is repeated.
How a 302 redirect works
Mechanically it looks just like a 301 redirect. The server answers the request for the old URL with a status code and a Location header, and the browser fetches the new address. The difference is the message. A 302 says “for now, look over there”, so Google normally keeps the original URL in its index and treats the destination as a stand-in rather than a replacement.
Browsers do not cache a 302 by default, which makes it safer to change or remove. That is also why it suits short-lived situations: a seasonal promotion page that takes over a category for a fortnight, a product page that sends visitors to a holding page during maintenance, or a split test that divides traffic between two versions of a landing page. Google’s own guidance on website testing recommends a 302 for split tests, precisely because the original page is meant to stay.
Many systems issue a 302 unless told otherwise. PHP’s Location header defaults to it, as do several redirect plugins and hosting control panels. So a large share of the 302s I find on audits were never chosen; they were simply the default.
Why it matters
Using the wrong type sends a mixed message. If a page has moved for good but the redirect says the move is temporary, Google may carry on indexing the old URL and take longer to settle on the new one. Over time Google often works out that a long-standing 302 is really permanent and starts treating it like a 301, but that guesswork adds weeks of uncertainty you do not need, usually at the moment you can least afford it, such as straight after a relaunch.
The reverse problem is less common but more stubborn. A 301 set where a 302 belonged gets cached in visitors’ browsers, so when the original page comes back, returning visitors can still be sent away from it.
None of this is a disaster in isolation, and the old idea that a 302 “leaks” all ranking value is a myth. It is a question of clarity: tell search engines what you actually mean and they act on it faster.
Common mistakes
- 302s for permanent moves. The most frequent problem, usually because a plugin or server default was never changed.
- HTTP to HTTPS or non-www to www on a 302. These site-wide rules are permanent by nature and should be 301s.
- “Temporary” redirects left for years. If the old page is not coming back, the redirect is not temporary.
- Mixed chains. A 301 followed by a 302 followed by another 301 sends contradictory signals and slows every visit.
- Client-side substitutes. A JavaScript redirect or meta refresh used where a server redirect is possible. Search engines may not process them as reliably.
How to act on it
Crawl the site and filter the results by status code. For every 302, ask one question: will the original URL ever come back? If the answer is no, change it to a 301 and point it at the final destination. Pay particular attention to the protocol and domain rules in your server configuration, because one wrong rule there affects every page on the site.
You can check any single URL with your browser’s developer tools (Network tab, then reload) or by running curl -I with the address. Where a temporary redirect is right, keep a note of why it exists and when it should end, and make sure the original page still carries a sensible canonical tag for when it returns. Redirect clean-ups are a routine part of the technical SEO work I do on established sites.