Google Explains 301 vs 302 Redirects: What Really Happens to Canonical URLs and Ranking Signals

Google has revisited one of technical SEO's oldest questions: what is the real difference between a 301 and a 302 redirect? In a discussion reported by Search Engine Journal on November 5, 2026, Gary Illyes and Cherry Prommawin explained how redirects interact with URL clustering, canonicalization and ranking signals. This is an explanation of established Search behavior, not an announced algorithm update.

The practical distinction is straightforward: a 301 signals a permanent move, encouraging Google to treat the destination as canonical, while a 302 signals a temporary move, generally preserving the source URL as the preferred representative. Both can take a visitor to the destination. Their meaning for Google's indexing pipeline is different.

What Google actually clarified

Google groups duplicate and near-duplicate URLs into clusters, then selects a representative canonical URL for Search. Redirects can help Google recognize that two URLs are related, but not all redirects provide the same canonicalization signal. Illyes and Prommawin emphasized that a permanent redirect tells Google the move should persist, whereas a temporary redirect indicates an intention to return to the original address.

This matches Google's official redirects documentation: permanent server-side redirects such as 301 and 308 are signals that the target should be canonical. Temporary redirects such as 302 and 307 are followed by Googlebot, but the redirect itself is not used as a signal that the destination should become canonical. The target might still be indexed when other signals support it.

That last qualification matters. The statement that Google will never index a destination reached by a 302 is too absolute. Google's own documentation explicitly allows for other canonicalization signals to influence the outcome.

301 vs 302: the operational difference

Question	301	302
What does it communicate?	Permanent move	Temporary move
What happens to users?	They are sent to the target	They are sent to the target
What canonicalization signal does Google receive?	Destination should be canonical	Does not itself signal destination should be canonical
Typical Search URL preference	New destination	Original source
Typical use	URL migration, permanent consolidation	Temporary campaign or maintenance move

These are tendencies and signals, not a guarantee that Google will always display a particular URL. Canonical selection also takes account of content, internal links, canonical annotations, sitemap signals and other evidence.

Do 301 redirects transfer ranking signals?

In the November discussion, Illyes explained that a permanent redirect allows ranking signals associated with the old URL to be consolidated toward the new canonical destination. The same discussion contrasted this with a temporary redirect, where the old URL remains the intended long-term address.

It is important not to translate this into a claim that every 302 permanently destroys link equity or that a 301 guarantees identical rankings after migration. Google's documented canonicalization process considers multiple signals, and rankings can change because content, site architecture, relevance and technical accessibility change during a move.

Google's canonicalization guidance describes redirects and rel=canonical annotations as strong signals, with sitemap inclusion as a weaker one. These signals can reinforce one another, but Google still selects the canonical URL.

When to use a 301 redirect

Use a 301 when the old URL is not coming back and the destination is the appropriate replacement. Common cases include moving an article to a new permanent path, consolidating duplicate product pages, changing the preferred hostname, migrating from HTTP to HTTPS, or moving a site to a new domain.

For example, if https://example.com/old-guide has permanently become https://example.com/new-guide, a 301 from the old address to the relevant new guide tells users and crawlers where the content lives. The destination should normally return HTTP 200, be indexable and represent a sensible equivalent rather than an unrelated homepage.

For a full migration, Google recommends maintaining redirects for as long as possible, generally at least one year, to allow recrawling and signal reassignment. It is often useful to keep them longer for users following old bookmarks and external links. See Google's site migration documentation.

When to use a 302 redirect

Use a 302 when the move really is temporary. Examples include directing visitors to a temporary service notice while the original page is unavailable, routing a short-lived promotional URL to a campaign experience, or temporarily relocating a resource that will return to its original address.

The key is intent. If a move is actually permanent, continuing to use a 302 sends a weaker and potentially conflicting message about the preferred URL. If a move is genuinely temporary, using a 301 may tell Google's systems to prefer a destination you do not want to keep in Search.

Do not assume that the mere presence of a 302 makes a destination invisible. Google may select it for indexing if other signals justify that decision. Always inspect the actual canonical selected by Google rather than relying solely on the status code.

What about 307 and 308 redirects?

Google's documentation groups 308 with permanent redirects and 307 with temporary redirects. For SEO canonicalization, their broad intent corresponds to 301 and 302 respectively. The technical HTTP distinction also matters for request methods: 307 and 308 preserve the original method and request body, which is relevant to POST requests and application workflows.

For example, redirecting a checkout POST request with the wrong HTTP behavior may cause the browser to change the request method or mishandle submitted data. This is an application correctness issue as well as a technical SEO consideration. Developers should select redirect codes based on both the desired canonicalization signal and the actual HTTP semantics required by the endpoint.

Why server-side redirects are usually preferable

Google recommends server-side HTTP redirects whenever possible. They communicate the move directly through the response status and Location header. JavaScript redirects and meta refreshes require additional page processing and can be more fragile when scripts fail or crawlers do not execute the page as expected.

Google can interpret some other redirect mechanisms, including immediate meta refresh, but that does not make them the first choice for a straightforward migration. A clean server-side redirect is usually simpler to audit, faster to follow and less likely to introduce unnecessary dependencies.

How to verify redirects with curl

Start by inspecting the headers returned for an old URL:

curl -I https://example.com/old-guide

A permanent redirect should show a status such as HTTP/2 301 and a Location: header pointing to the intended destination. A temporary redirect should show 302 or another appropriate temporary status.

To follow the redirect chain and see the final destination, run:

curl -IL https://example.com/old-guide

Check that the chain ends at the correct, accessible page and does not bounce through multiple unnecessary intermediate URLs. To test real GET behavior and print the final effective URL and status, you can use:

curl -L -s -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com/old-guide

Remember that curl -I uses HEAD requests; some servers treat HEAD differently from GET. If the response is unexpected, test GET and inspect the server configuration. These commands show HTTP behavior, not Google's eventual canonical choice.

How to verify the canonical URL in Google Search Console

After deployment, inspect both the old and new URLs using Search Console's URL Inspection tool. Compare the declared canonical, Google's selected canonical where available, indexing status and crawl information. A redirected source URL may appropriately be excluded from indexing while its destination becomes the indexed representative.

For a site move, submit an updated XML sitemap containing the new canonical URLs, update internal links to the final destinations and monitor indexing and performance over time. Avoid treating temporary fluctuations as proof that the redirect code alone caused a ranking loss.

When auditing a migration, maintain a mapping of old URL, expected destination, actual status, final URL, indexability and selected canonical. This makes it easier to distinguish incorrect redirects from other problems such as noindex tags, robots restrictions, missing content and server errors.

Five common redirect mistakes

Using 302 for a permanent migration. This conflicts with the long-term intent and can complicate canonicalization.
Redirecting everything to the homepage. An unrelated destination is not a reliable substitute for a removed page; use relevant replacements where they exist.
Creating long redirect chains. Multiple hops increase complexity and can slow users and crawlers. Link directly to the final URL when possible.
Leaving contradictory signals. A permanent redirect to one URL while internal links, sitemaps or canonical tags point elsewhere makes the intended representative harder to establish.
Assuming a redirect guarantees ranking preservation. Content changes, architecture, crawlability and competition still affect search performance.

What this means for AI Search and GEO

The November explanation is about Google Search's crawling, deduplication and canonicalization systems. It does not announce a new Google AI Mode ranking factor, AI citation rule or generative search redirect policy.

There is nevertheless an indirect infrastructure lesson. Publishers and brands benefit from stable, accessible canonical URLs because these reduce ambiguity for search engines, analytics systems and tools that retrieve web content. A poorly managed migration can make sources harder to discover or attribute consistently. That is a reasonable operational concern, not evidence that 301 redirects directly increase AI citations.

Teams measuring AI visibility should also normalize redirects when analyzing cited URLs and referral landing pages. Otherwise, the same page may be counted under an obsolete URL, an intermediate redirect or the final destination. That is a measurement-quality issue rather than a new optimization trick.

Frequently asked questions

Is a 301 better for SEO than a 302?

Neither is universally better. A 301 is appropriate for a permanent move; a 302 is appropriate for a temporary one. Choosing the code that accurately describes the move helps Google interpret the intended canonical URL.

Does Google follow 302 redirects?

Yes. Googlebot follows temporary redirects, but Google does not treat the redirect itself as a signal that the destination should become canonical.

Can Google index the destination of a 302?

Yes. Google's documentation says the destination may still be indexed when other canonicalization signals support it.

Does a 301 guarantee all rankings will transfer?

No. Permanent redirects support canonicalization and consolidation of signals, but final rankings depend on other factors, including relevance, content and technical accessibility.

Are 308 redirects acceptable for permanent moves?

Yes. Google treats HTTP 308 as a permanent redirect for canonicalization purposes.

Should redirects stay in place for a year?

For site moves, Google recommends keeping them for as long as possible, generally at least one year. Longer retention may help users and external links.

Do 301 redirects improve AI Overview citations?

No direct citation benefit was established in this explanation. Correct canonicalization is sound technical SEO, but AI citation outcomes require separate evidence.

The bottom line

Google's latest explanation reinforces an established rule rather than introducing a new algorithm: permanent redirects express a permanent canonical preference; temporary redirects do not. The most useful takeaway is not to chase a redirect “ranking boost,” but to align the status code with the real business decision, avoid conflicting URL signals and verify the outcome through HTTP testing and Search Console.