301 vs 302 Redirect: Which One Google Canonicalizes

The difference between a 301 and a 302 is not a matter of degree, and it is not about how much authority passes. It is a difference in which URL Google decides to index. Google’s redirect documentation states the outcome for each in one line apiece. A permanent redirect will “show the new redirect target in search results”. A temporary redirect will “show the source page in search results”.

That is the whole decision. If you want the destination URL to be the one people find in Google, you need a permanent redirect. If you serve a temporary one, Google has been told to keep the old URL as the indexed page, and it will do exactly that.

What the documentation says about canonicalization

The mechanism behind those two outcomes is stated explicitly, and the two sentences are worth reading back to back because they differ by one clause.

Permanent: “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.”
Temporary: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.”

Googlebot follows both. The crawler behaves identically. What changes is whether the indexing pipeline treats the move as a statement about canonicalisation. A 302 is understood as “go here for now, but the real page is still the one you asked for”, and that is a coherent thing to say. It is simply not what anyone means when they retire a URL.

Worth naming what the documentation does not say, because both claims circulate widely. It does not say a 301 passes a fixed percentage of link equity and a 302 passes none. And it does not describe a redirect as permanent because of how long it has been in place. Permanence is a property of the status code you send, not of elapsed time.

Every redirect type, and what each one signals

There are more than two. Google groups the server-side codes into permanent and temporary classes, and the classes are what matter, not the individual numbers.

Response	Class	Shown in search results	Canonicalization signal	Use it when
301 Moved Permanently	Permanent	The redirect target	Yes, target should be canonical	A URL has been retired for good. The default for any migration
308 Moved Permanently	Permanent	The redirect target	Yes, target should be canonical	Same intent as a 301, where the request method must be preserved
302 Found	Temporary	The source page	No	The original URL is genuinely coming back
303 See Other	Temporary	The source page	No	Redirecting after a form submission, not a content move
307 Temporary Redirect	Temporary	The source page	No	A true temporary move preserving the request method
Meta refresh or JavaScript redirect	Client side	Depends on rendering	Weaker and slower to be picked up	Only where you cannot configure the server

A 307 is the one that produces the most surprised clients, because it looks modern and specific and gets chosen for that reason. It is a temporary redirect and Google treats it as one. It is also what a browser will do on its own for a site on an HSTS preload list, which means a developer can end up looking at a 307 in their network tab and conclude the server is misconfigured when it is not.

When a 302 is actually the right answer

Google’s guidance on choosing is conditional: use permanent redirects “when you’re sure that the redirect won’t be reverted”. Read the other way round, a temporary redirect is correct whenever you expect to revert it. Four real cases:

A product that is out of stock and returning. Sending shoppers to the category page while the product URL is live but empty is reasonable. You want the product URL back in the index when it returns, so a 302 says the right thing.
A page down for maintenance. Though a 503 with a Retry-After is usually better than a redirect at all.
Geolocation or device routing. Where the URL a user lands on depends on where they are, and no single destination is the canonical answer for everyone.
A seasonal or campaign page. A Black Friday hub pointing at the current year’s landing page, where next year the target changes and the hub stays.

Outside cases like those, if you are asking the question at all, the answer is a permanent redirect. The failure mode of a wrongly permanent redirect is that you have to clean up a canonicalisation you did not want. The failure mode of a wrongly temporary one is that a migration silently does not transfer, which is far more expensive.

Chains, hops and how long to keep them

Two numbers from Google’s site move documentation are worth committing to memory. Googlebot can “follow up to 10 hops in a ‘chain’ of multiple redirects”, and the advice is to redirect straight to the final destination, keeping chains ideally to no more than three and fewer than five, to limit latency and stay compatible across browsers.

The practical consequence is that chains do not usually break Google. They break users, on slow connections, and they compound: a chain assembled from four separate historical migrations is how a single click ends up costing a second and a half before the destination starts loading. They also hide mistakes, because one temporary redirect anywhere in an otherwise permanent chain contaminates the whole path.

On duration, the guidance is unusually specific: “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs.” One year is a floor, not a target. If the old URLs still have external links pointing at them, and they usually do, the redirect is carrying real referral traffic and real link signals for as long as those links exist.

A worked example: the 302 migration

This is the shape of the problem when it arrives, and it arrives regularly. A site replatforms. The URL structure changes. The redirect map is complete and correct, every old URL points at the right new one, and nothing in the mapping is wrong. The load balancer or the framework issues the whole set as 302s, because that is the default in a great many stacks.

What you observe over the following weeks:

Old URLs stay in the index and keep ranking. This is the first thing that reassures everybody and it is the actual symptom.
New URLs are crawled, and get reported in Search Console as a duplicate whose Google-selected canonical is the old URL.
Rankings hold, then drift, as the old URLs accumulate no new signals and the new ones are not credited with any.
Any page whose old URL was not linked from anywhere quietly disappears from the index entirely.

The diagnosis takes one command against the redirect map, checking the status code rather than the destination. The fix is to change the status code and wait, and the waiting is the part clients find hardest. Google is clear that a move takes time: “Expect temporary fluctuation in site ranking during the move”, and for a medium-sized site it takes “a few weeks or more for Google to gradually start showing the new URLs instead of the old ones”, with larger sites taking longer. That clock restarts when you correct the codes. Nothing accelerates it, and a second change of URL structure while the first is still being processed makes it materially worse.

One more detail from the same documentation, because it changes how you plan a move. For small and medium sites, Google recommends moving all URLs at once, both for the user experience and because its algorithms detect the move faster. Staging a move section by section is advice specifically for large sites, where it simplifies monitoring. Splitting a 400-page migration across three months because it feels safer is not the cautious option. It just extends the window in which two versions of the site compete.

The check worth running today

Pull every redirect the site serves, and record the status code as well as the destination.
Flag every 302, 303 and 307 that points from a retired URL to its replacement. Those are the bugs.
Count the hops on each path. Collapse anything over three straight to its final destination.
Check that no redirect ends at a 404, a soft 404 or another redirect you missed.
Confirm the redirect target is not itself canonicalised somewhere else, which turns your redirect into the first hop of a chain you did not write.
Check the dates on your oldest redirects before anyone removes them for tidiness. The floor is a year, and external links outlive that.

301 vs 302 Redirect: Which One Google Canonicalizes, and What the Wrong Choice Costs