A 302 redirect is an HTTP status code that tells the browser and search engines that a page is temporarily at a different address, and that the original URL is still the valid one. The official name of the code is Found, and it is defined in RFC 9110, section 15.4.3, the IETF specification that in June 2022 replaced RFC 7231, which many articles still cite: the target resource resides temporarily under a different URI, so the client ought to keep using the original address for future requests.
There is one practical consequence, and it is worth keeping in mind before anything else: search results keep showing the original URL, not the destination. If that is what you want, 302 is the right code. If you were expecting the new page to climb, you picked the wrong code and you need a 301 redirect.
What happens in search results
Google's documentation is explicit on this point and leaves no room for interpretation. On the page Redirects and Google Search, updated on 14 April 2026, temporary redirects show the source page in results, and permanent ones show the destination. Google adds something that is rarely mentioned: when you redirect a URL, it keeps track of both the source and the destination, and decides which of the two becomes canonical based on signals that include whether the redirect is temporary or permanent. The other becomes an alternate name for the same canonical URL.
It is worth taking apart a claim that circulates in plenty of articles: that a 302 does not pass PageRank. The question is badly framed. The point is not how much value flows from one URL to the other, it is which of the two URLs Google keeps in the index. With a correctly set 302 the signals stay where they have always been, on the original page, because that is the one that has to keep ranking. There is nothing to recover, because nothing has moved.
The 302s you didn't set up
Almost nobody ends up searching for this code because they decided to set up a temporary redirect. They get here because they ran a crawl with Screaming Frog or opened a Search Console report, found a column full of 302s and want to know whether to worry. In most cases those redirects were generated by something else: the CMS, a plugin, the hosting layer, a security rule.
| Where it comes from | Typical example | Does it need fixing? |
|---|---|---|
| Admin area and login | WordPress responds 302 Found on /wp-admin/ and sends you to wp-login.php | No, it is the expected behaviour and those URLs should not be indexed anyway |
| Multilingual plugins | Redirect from the domain root to /it/ or /en/ based on the browser language | No, as long as each language has a stable URL that can be reached directly |
| E-commerce, out-of-stock products | The theme sends the out-of-stock product page to its category | It depends: if the product is coming back it is fine, if it has been discontinued you need a 301 or a 410 |
| CDNs and web application firewalls | Forwarding rules where the code is picked from a menu and nobody checks it again | Yes, if the move is permanent |
| Staging environments | Protection that diverts visitors to an authentication page | No, but check that the same rule has not ended up in production |
| Basket and checkout | Session steps that bounce the user from one step to the next | No, provided the chain does not go beyond a couple of hops |
The WordPress case can be checked in ten seconds on any installation. A request to /wp-admin/ without an active session returns a 302 with the Location header pointing to wp-login.php. The same installation, however, uses a 301 to normalise a missing trailing slash at the end of URLs. Two different codes in the same software, chosen according to how permanent the destination is.
How to check a 302 in two minutes
The browser is no use, because it follows the redirect before you can read it. From a terminal, one short command is enough:
curl -I https://example.com/old-page/The first line of the response contains the code, the Location line contains the destination. If you want to see the whole redirect chain, curl -IL prints the hops one after another: it is the fastest way to notice that an apparently single redirect actually goes through three URLs before reaching its destination, with the response-time cost that comes with it.
On Google's side, the tool is the URL Inspection tool in Search Console: it shows the URL Google considers canonical, which is exactly the information you need when you suspect you used the wrong code. If you put a 302 on a permanent move, the canonical Google reports will stay the old address for much longer than you expect.
The detail that breaks forms
There is one 302 behaviour that has nothing to do with rankings and turns up when you least need it. RFC 9110 warns that, for historical reasons, a user agent may change the request method from POST to GET for the subsequent request after a 302. MDN Web Docs confirms that this is exactly what the Fetch Standard prescribes: when a 302 is received in response to a POST, the browser repeats the request as a GET.
On a content page nothing changes. On an endpoint that receives data from a contact form, a checkout or an integration, the request reaches its destination without the payload and the submission is lost with no visible error. For those cases the specification provides the 307, which forbids the client from changing the method. If instead you want to force the switch to GET, for example after an upload, the correct code is 303.
When a 302 is the right choice
- A page under maintenance that will come back online at the same address.
- An A/B test between two versions of the same optimised page, where the original version has to remain the indexed one.
- A seasonal promotion that diverts a category to a temporary landing page.
- A product page that is temporarily unavailable and will be back in stock, a recurring case in e-commerce SEO.
- A page taken down for a legal or editorial issue while it is being reviewed.
The common thread is reversibility. If you already know the old address will never come back, a 302 is the wrong choice even when it looks harmless in the short term.
When it needs replacing
The case to fix straight away is a 302 used for a migration, a domain change or a restructuring of slugs. There the temporary code keeps an address that no longer exists alive in the index, while the new page waits its turn. The signal Google needs to move canonical status to the destination is precisely the one a 302 does not send.
The other case is less obvious: two URLs that both stay reachable and return 200, with a 302 linking one to the other. There the redirect solves nothing and the problem becomes one of duplicate content, to be handled with the canonical tag or with a real 301. A canonical, it should be said, is a hint that Google can ignore: a redirect is a server-level instruction, and it carries much more weight.
Then there is a middle way that hardly anyone knows about, and it is useful when you have no access to the server configuration. Google interprets an instant meta refresh as a permanent redirect and a delayed meta refresh as a temporary one. It is a workaround, not a method: the same documentation puts server-side redirects at the top of the list for likelihood of being interpreted correctly.
A forgotten 302 makes no noise. It doesn't generate an error in Search Console, it doesn't break the page, it doesn't warn anyone: it simply keeps in the index an address you may have abandoned months ago. That is why it pays to treat temporary redirects like items in an inventory, with an expiry date written down somewhere, rather than as settings to put in place and forget. In an SEO project it is one of the first things we look at when a section's traffic doesn't recover after a redesign, and one of the quickest to fix.
Frequently asked questions
No. It is a normal server response, provided for by the HTTP specification, and in most cases it signals intended behaviour such as sending you to a login page. It only becomes a problem when it flags as temporary a move that is actually permanent.
A 301 declares a permanent move: the destination becomes the canonical URL and replaces the old address in search results. A 302 declares a temporary move, and the original URL stays in the results. The choice comes down to one question: will that address be valid again?
Not in itself. If the move really is temporary, the original page keeps its indexing and signals, which is exactly the intended result. Losses come when a 302 is used instead of a 301 during a migration: in that case the new page lags behind until the code is corrected.
As long as the temporary condition that made it necessary lasts, and not a day longer. Google has not stated a threshold, but a temporary redirect that stays in place for months is almost always the sign of a decision never taken. It is worth noting its expiry date alongside the rule.
For a content page the two codes are equivalent in the eyes of search engines. The difference matters on endpoints that receive data: after a 302 the browser may turn a POST request into a GET and lose the payload, while a 307 forbids changing the method. On forms, checkouts and integrations, use a 307.
