301 vs 302 Redirects: What Google Actually Says

A 301 tells browsers and search engines that a URL has moved for good. A 302 tells them it has moved for now. That much is settled, and a surprising amount of what gets written after it is not. This guide is for developers, technical founders, and in-house SEOs who have to pick a status code today, on a replatform, a retired feature page, a subdomain move, or an A/B test. It covers what Google's documentation actually states, where 307 and 308 fit, how to unwind a redirect chain, and which code belongs in the situations a SaaS marketing site keeps producing.

The short version

• Google's redirect documentation frames the difference as canonicalization, not link equity. It does not mention PageRank or equity transfer at all.
• A permanent redirect is a signal that the destination should be canonical. A temporary one is not, though Google notes the destination "might still be indexed if other canonicalization signals are present."
• 307 and 308 are the method-preserving versions of 302 and 301. Google sorts them into the same two buckets, so for ordinary page moves the search outcome matches the code they mirror.
• Googlebot follows up to 10 hops in a chain, and Google advises keeping chains under five. The expensive mistake is the chain nobody audited, not the code somebody picked once.
• Do not point a pile of retired URLs at the homepage. Google warns that this "might be treated as a soft 404 error."

What is the difference between a 301 and a 302 redirect?

Which URL Google keeps in its index.

Both codes send a visitor somewhere else, and Googlebot follows both. The split happens afterwards, inside the indexing pipeline. Google's documentation on redirects and Google Search sorts every redirect method into two buckets and describes the search result for each in one line. Permanent redirects "Show the new redirect target in search results." Temporary redirects "Show the source page in search results."

The mechanism behind those two lines is stated just as plainly. For a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For a temporary one, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."

Note the hedge Google attaches to the temporary case: "The target page might still be indexed if other canonicalization signals are present." A 302 is not a wall. It withholds one signal while your sitemap, internal links, and rel=canonical tags keep voting, and Google resolves the disagreement however it sees fit.

The honest one-sentence version: a 301 nominates the destination as canonical and a 302 declines to. Everything downstream of that is inference.

Does a 302 redirect lose link equity?

Google's redirect documentation does not say so. It also does not say the opposite.

This is where folklore has outrun the source material. The redirect documentation contains no mention of PageRank, link equity, or value transfer in either direction. It is a page about canonicalization, and the whole permanent-versus-temporary distinction is expressed in terms of which URL the indexing pipeline treats as canonical.

Google does discuss signals moving, but in a different document and about a different situation. Google's guidance on site moves with URL changes advises keeping redirects in place "for as long as possible, generally at least 1 year," because "This timeframe allows Google to transfer all signals to the new URLs." That is a statement about permanent moves over time. There is no matching published statement about temporary redirects, in either direction.

Two claims are therefore unsupported, and one of them is popular on each side of the argument:

• "A 302 does not pass SEO value": Google publishes nothing that says this. Most of the page-one results for this query repeat it anyway.
• "Google confirmed all 3xx redirects pass full PageRank": also not in the redirect documentation. This one circulates as a correction to the first claim, which makes it feel like the sophisticated answer, and it is still an over-claim.

Replacing one confident guess with the opposite confident guess is not an improvement. Choose the code by what you are telling Google about canonicalization, because that is the part Google documents. The equity question resolves itself when you stop treating it as the decision.

When should you use a 301 redirect?

Whenever a URL has moved and you do not expect to move it back. Google's phrasing is the practical test: "Use permanent redirects when you're sure that the redirect won't be reverted."

The common permanent cases on a marketing site:

• HTTP to HTTPS: one consistent permanent redirect, so only one version of the site is reachable.
• Consolidating duplicate hosts: pick www or the bare domain and redirect the other permanently. Leaving both live splits every signal you have.
• A domain change: map old to new one URL at a time.
• Merging two pages into one: the weaker page redirects to the survivor.
• Retiring a page that has a genuine replacement: the operative word is genuine. A loose thematic cousin is not a replacement.

One case looks like a redirect and is not. When both URLs need to stay reachable and you only want them to consolidate for search, the right instrument is a canonical tag instead of a redirect. A redirect takes the old page away from users; a canonical leaves it working and tells Google which version to index.

When not to ship one: if there is any real chance you will revert within a quarter, ship a temporary redirect and revisit it. Undoing a permanent redirect is possible, but you are asking Google to unlearn a signal you deliberately taught it.

When should you use a 302 redirect?

When you genuinely intend to send people somewhere else for a while, and you want the original URL to stay the one Google keeps.

That last clause is the whole point, and it is why the temporary code is not a lesser version of the permanent one. It does a different job. The cases where it is the correct answer rather than a hedge:

• An A/B test: traffic goes to a variant URL while the original stays canonical. This is exactly the behavior the temporary code describes.
• A geo or language interstitial: a visitor is routed to a regional page, but the original URL is still the address of record.
• A temporary maintenance or out-of-stock state: the page is coming back, so you do not want its replacement indexed in its place.
• A staged rollout: a fraction of traffic goes to the new experience while the old one remains the published URL.

The failure mode is not the code. It is the calendar. A temporary redirect that has sat in place for a year is not temporary, whatever the status code says, and the URL Google is holding onto is one nobody has looked at since the ticket closed. Nothing breaks loudly. The old URL just keeps collecting the impressions while the page people actually see sits behind it.

What I've seen in practice is that the most common version of this mistake is caution rather than carelessness. A permanent move ships with a temporary code because the person shipping it wants an escape hatch, and the escape hatch is never used. If you are reaching for the temporary code because you are nervous rather than because the change is reversible, put a date in the calendar to revisit it, or ship the permanent one.

What are 307 and 308 redirects, and do they matter for SEO?

They are the method-preserving versions of 302 and 301, and for ordinary page moves the search outcome is the same as the code they mirror.

The distinction is an HTTP one rather than an SEO one. MDN's reference on HTTP redirections records that with a 301 or a 302, "GET methods unchanged. Others may or may not be changed to GET," because "The specification did not intend to allow method changes, but there are existing user agents that do change their method." The newer codes close that gap: for 307 and 308, "Method and body not changed." To stop a user agent turning a POST into a GET, MDN's reference on the 301 status code says to "use 308 Permanent Redirect instead, as altering the method after a 308 response is prohibited."

That matters for form submissions and API calls. It rarely matters for a blog post that moved.

Code	What Google does with it	Request method	Reach for it when
301	Treats as permanent. Signals the target should be canonical, and shows the target in results.	May be changed to GET	A page or a whole site has moved for good and the traffic is ordinary GET requests.
302	Treats as temporary. Does not signal the target as canonical, and shows the source in results.	May be changed to GET	The move is genuinely reversible and the original URL should stay the indexed one.
307	Treats as temporary, same bucket as 302.	Preserved	A temporary redirect has to survive a POST, or the route serves non-GET traffic.
308	Treats as permanent, same bucket as 301.	Preserved	A permanent move where request method and body must not be altered, including API and form endpoints.

Two footnotes worth carrying. Modern hosting and framework defaults often emit 308 rather than 301 without asking, and that is not a problem to fix. This site's own retired solution URLs are an example: /solutions/organic-growth and /solutions/saas-seo both return a 308 to /solutions/seo, verified on 26 August 2026, and Google files that alongside 301. Separately, when a browser upgrades an http URL to https because of HSTS, no server redirect happens at all: MDN's documentation on the Strict-Transport-Security header describes the browser checking its HSTS host list and replacing the URL scheme with https itself, before the request leaves. Your network panel may show a hop there. Your server never sent one.

What is a redirect chain, and when is it worth unwinding?

A chain is any redirect that lands on another redirect, and Google publishes an actual number for how much of it will be tolerated.

From the site move documentation: "While Googlebot can follow up to 10 hops in a 'chain' of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5." A loop is the pathological case, where the chain never terminates. MDN notes that when a server can detect one, "it will send back a 500 Internal Server Error," which is a useful tell: an unexplained 500 on a URL you recently redirected is worth checking as a loop before anything else.

In our implementation work the expensive redirect problem is almost never the code somebody chose. It is the chain nobody audited. Chains are not authored, they accumulate: a redesign points the 2021 URLs at the 2023 URLs, a replatform points those at the 2026 URLs, and nobody repoints the first rule. Each layer is individually correct and the stack is a mess.

How to find them: crawl the site and read the redirect report, where hops appear as a column rather than a warning. Check the redirect configuration file directly, since a chain is often two rules whose source and target overlap. Spot-check by hand with a request that prints the full hop list, and include URLs that old campaigns and press coverage link to, because those point at the oldest address in the stack.

How to decide what to fix: not every chain earns a ticket, and pretending otherwise is how redirect audits get ignored. Unwind one when it sits on a URL with external links pointing at it, when a template generates it across thousands of URLs, or when it runs longer than the three hops Google names as its comfortable ceiling. Leave a single extra hop on a low-traffic URL nobody links to. The fix is always the same shape: repoint the first rule at the final destination and delete the middle.

On a migration this becomes a planning problem rather than a cleanup problem, which is why the sequencing lives with building a redirect map rather than here.

Which redirect should you use in these SaaS situations?

The generic advice breaks down fastest here, because several of these look permanent and are not, and two of the most common ones call for no redirect at all.

Situation	Ship this	Why
Retiring a feature page that has a real successor	301	The move is permanent and the successor should become the canonical URL.
Retiring a feature page with no successor	404 or 410	There is nowhere honest to send the visitor. A redirect to a loosely related page is the soft 404 risk in the next section.
Sunsetting a pricing tier	301 to the pricing page	The parent page still answers the query the old URL was getting. Use the temporary code instead if the tier is genuinely coming back.
Moving docs off a subdomain into a subdirectory	301, kept for at least a year	A permanent consolidation, and the destination needs time to inherit the signals. The subdomain versus subdirectory decision comes first; the redirect only implements it.
Marketing-site replatform where URLs change	301, mapped one to one	Permanent by definition. The risk here is chains and blanket rules, not the code.
Replatform where the URLs stay identical	No redirects	Redirect rules written "just in case" during a replatform are a common source of loops. If the URL does not change, do not touch it.
A/B test on a variant URL	302	You want the original to stay canonical for the duration. This is the temporary code doing exactly its job.
Trial, session, or preview URL churn	No redirect. Keep them out of the index	These are not ranking assets and they were never meant to be found. Redirecting them creates rules that outlive the URLs.

The pattern across the table: the code follows from whether the change is reversible, and whether the destination genuinely answers what the source was answering. Those two questions decide almost every case, and neither is about link equity.

Should you redirect a removed page to the homepage?

Usually no, and Google names the specific failure. Its site move guidance says: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error."

A soft 404 is what happens when a URL returns a success status but the content does not correspond to what was requested. Google treats it as a missing page anyway, so the blanket homepage redirect buys nothing in search terms and costs the visitor their bearings. Someone who clicked a link about your API rate limits and landed on a hero image and a signup button will bounce, and they will be right to.

The hierarchy for a removed page is short. Redirect it to the genuine replacement if one exists. If nothing replaces it, let it return 404, or 410 to state that the removal is deliberate. A clean not-found is a normal part of a healthy site. The homepage redirect is not the safer option; it is the same search outcome with worse user experience and a rule you now have to maintain.

What are the most common redirect mistakes?

Nearly all of them come from a rule that was correct when it shipped and was never revisited.

• A temporary code on a permanent move: shipped out of caution, then forgotten. The old URL stays the one Google keeps.
• Chains left to accumulate: each migration adds a layer, nobody repoints the first rule, and inbound links land at the back of the queue.
• Loops: usually two rules written by two people who did not know about each other, often surfacing as an unexplained 500.
• Blanket redirects to the homepage: covered above, and still the most common instinct when a section gets deleted.
• A JavaScript redirect as the first choice: Google's redirect documentation puts server-side redirects first and says to "Only use JavaScript redirects if you can't do server-side or meta refresh redirects." Treat that ordering as the default, not as one option among three.
• Redirected URLs left in the sitemap: a sitemap should list canonical URLs that return 200. Redirects in there send mixed signals about what you want indexed.
• Shipping the code you intended rather than the code you got: framework defaults, CDN rules, and hosting-level rewrites all rewrite redirects without telling anyone.

That last one is why redirect checks belong in a recurring sweep rather than in someone's memory. The wider status-code checks sit alongside the crawl and indexing items in a standard audit pass, and redirects are where an audit most often finds something nobody knew was there.

Where should you start this week?

The habit worth building is checking the status code you actually shipped, not the one you intended to ship. Every mistake in this article survives because the person who wrote the rule believed it and never verified it, and the gap between intent and reality is the only thing a redirect audit is really looking for. It is also the cheapest check in technical SEO, which is a strange thing to say about the one nobody runs.

This week, take the ten URLs on your site with the most inbound links or the most impressions, request each one, and print the full hop list rather than just the final destination. You are looking for three things: a temporary code on something that moved for good, a chain longer than a single hop, and anything landing on the homepage. Fix those three and you have handled most of what redirects can cost you. If the list is long enough that it needs owning properly, that is the kind of cleanup our technical SEO work starts with.