302 redirect: temporary moves and what search shows

A 302 redirect is the HTTP status 302 Found: the server says the page is temporarily at another address and the original address remains the right one. Google follows it but keeps showing the original address in results. Of the redirect codes, it is the one that says "not yet" rather than "moved".

What the code means

The meaning comes from the HTTP specification, RFC 9110: "The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the target URI for future requests."

The second sentence is the practical one. A visitor's browser goes to the new address this time, but anything that stores addresses, such as a bookmark, a link in another document or a list in a crawler, is asked to keep the old one. The move is real, and it is expected to end.

Its permanent counterpart, the 301 redirect, says the opposite: the resource "has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs."

What Google does with a 302

Google follows the redirect and keeps the source address as the one to show. Its documentation on redirects, last updated on 2026-04-14 and checked on 2026-10-09, puts the difference in two lines:

For temporary redirects the same page adds that "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present."

So a 302 does not hide the target. It simply declines to vote for it. If the target earns canonical status, it does so through other signals, not through the redirect.

When a 302 is the right answer

A 302 is right when you want the old address to keep its place in results while visitors go somewhere else for now. Google's own example is a service that is temporarily unavailable: send people to a page explaining what is happening "without compromising the original URL in search results."

Other honest uses on example.com:

• A seasonal page. /sale/ points to this year's offer while the offer runs, and nothing should replace /sale/ in search.
• Maintenance. One section moves to a holding page for an afternoon.
• A test. Some visitors go to an alternative version of a page while the original remains the one you intend to keep.

In each case you know the redirect will be removed, and you want search to act as if it never happened.

When a 302 is a mistake

A 302 is a mistake when the move is permanent, and the most common cause is not a decision but a default. Apache's Redirect directive returns a 302 unless told otherwise; its documentation says of the temporary status: "This is the default." WordPress's wp_redirect() function also defaults to 302 (see WordPress redirects). A site that moved pages with either, without naming the status, has told search that every move is temporary. How to name the status in Apache is covered under .htaccess redirects.

The result is the opposite of what was intended: Google keeps showing the old addresses and does not take the redirects as a signal that the new ones are canonical. The fix is to send a permanent code, not to wait.

302 next to 307 and 303

The 302 shares its meaning with two other temporary codes and differs in how the request travels.

• 302 and 307

  RFC 9110 notes that, "for historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request." A form submitted to a 302 can arrive at its destination as a plain page load with the data gone. 307 was specified to rule that out; the pair is covered under 307 and 308 redirects.

• 302 and 303

  A 303 See Other deliberately sends the client to a different resource with a GET, typically after a form is submitted. Google lists 303 with the temporary redirects.

For ordinary page moves the choice between them rarely matters; for anything that receives forms or API calls, it does.

Ending a temporary redirect

A temporary redirect ends in one of two ways, and each needs a deliberate step. If the original address comes back, remove the redirect, so the address answers with its own page again; leaving a 302 pointing at a finished offer sends visitors somewhere stale. If the temporary state turns out to be permanent, replace the 302 with a permanent code rather than leaving it in place and hoping it will be read as one.

Either way, write down when the redirect was added and why. Temporary redirects outlive the reason for them more often than permanent ones, because nobody owns the moment they were meant to end.

Checking which code you send

The code is decided by whatever issues the redirect, so the check reads the live response, not the setting. Request the old address and look at the status line and the Location header it returns. How a trace reads each hop and its status, including the ones a browser hides by following them straight away, is covered under redirect tracing.

If a permanent move shows 302, look for the layer that issued it: a server rule without a status, a CMS function using its default, or a service in front of the server. The overview of redirects explains why more than one of these is often active at once.

FAQ