What is a 302 redirect?

The 302 code states that the requested resource is temporarily at another address and that the original one remains the valid reference. The specification puts it plainly: the client should keep using the source URL for future requests, because the diversion may disappear at any moment. That is the whole distance to the 301, which declares the move final.

There is a second temporary code that almost nobody uses and that is the right one in certain cases: the 307. The difference has nothing to do with the search engine and everything to do with the request method. For historical reasons, a browser may turn a POST request that receives a 302 into a GET, meaning it can arrive at the target having lost the data it carried. The 307 forbids that method change explicitly. On a normal page, requested with GET, both codes behave the same way and Google treats them the same way. On a form, at a payment gateway or at an API endpoint, that same difference decides whether the request arrives whole or arrives empty.

Googlebot follows the redirect and reaches the target, but the indexing pipeline does not use it as a signal that this target should become the canonical version. The visible result is the one almost everyone expects: search results keep showing the source URL for as long as the diversion is active.

What usually gets misread is the reach of that rule. The fact that a 302 does not count as a canonicalisation signal does not make it a protection. The documentation adds a sentence that changes the picture: the target page may still end up indexed if other canonicalisation signals are present. Those signals are the usual ones, and none of them depends on the status code: internal links pointing at the target, its presence in the sitemap, a canonical tag, or simply the fact that both pages carry almost the same content.

From there comes the answer to the most common case, the 302 that has been in place for months. Google does not turn it permanent through age, and there is no published deadline after which its treatment changes. What happens is simpler and less reassuring: the more time passes, the more signals the target accumulates, and at some point those signals can outweigh the absence of the signal the 302 never provided. Leaving a temporary diversion in place indefinitely freezes nothing, it only means giving up on deciding which of the two addresses should win.

curl -I https://example.com/page
HTTP/1.1 302 Found
Location: https://example.com/target

Three situations account for almost every problem.

Maintenance is the first. A page under work has not moved, it stays where it is and will be back in a few hours, so redirecting the visitor leaves the crawler with nothing to read at that address exactly when it comes by. For temporary unavailability the specification reserves a code of its own, the 503, defined for short overloads and scheduled maintenance, with a Retry-After header that indicates when a fresh request makes sense.

The second is country or language detection. Most of Google's crawls come from United States IP addresses, and the crawler sends no language preference in the Accept-Language header. A site that redirects automatically by IP ends up showing it the same version every time, and the rest go uncrawled. Google advises against that automatic redirect and proposes the opposite: hreflang annotations, every version reachable through its own URL, and a visible selector.

The third is the A/B test, and this is where the 302 fits without argument. Google recommends that code for the variants precisely because it keeps the original URL in the index while the experiment runs. The condition is to dismantle it afterwards: alternate URLs, test scripts and markup, all gone.

• Use a 302 only if the source URL is going to serve content again, and write down when. A temporary diversion with no expected date is a deferred decision, not a decision.
• Choose 307 when the request cannot change method: forms, payment gateways and API endpoints.
• Cover maintenance with 503 and a Retry-After header instead of a redirect, because the page has not moved, it is only closed for a while.
• In A/B tests, pair the 302 with a canonical tag on the variant pointing at the original URL, and remove both when the experiment closes.
• For country and language, offer a visible selector and hreflang annotations rather than redirecting by IP.
• After every migration or template change, review the redirect inventory with your own crawl and check the code actually served, without trusting what the CMS panel displays.

• Assuming a 302 protects the position of the source URL. All it guarantees is that the diversion does not count as a signal in favour of the target.
• Covering maintenance with a redirect instead of answering 503, leaving the address without content for the crawler on the very visit that mattered.
• Redirecting automatically by visitor IP, with the result that Google always sees the same language version and the others are never crawled.
• Using a 302 where the request carries data, without allowing for the fact that it can reach the target converted into a GET.
• Finishing an A/B test and leaving the test URLs, the redirect and the experiment markup in place.