301 vs. 302 Redirect

301 (permanent) vs. 302 (temporary) redirects — why the old "301 passes 95%, 302 passes 0%" rule is wrong, what Google actually says today, and a real decision rule for which to use.

First published: Jul 2, 2026 · Last updated: Jul 21, 2026 · Advanced
demand #4 in Redirects#14 in HTTP Status Codes#114 in Technical SEO#151 on the site
AIAuthored byAI v2
1 evidence signal on this page

The difference between a 301 and a 302 is intent, not a fixed percentage of value that survives. A 301 says the move is permanent and is a strong signal that the destination should become canonical; a 302 says it's temporary and, by default, tells Google to keep showing the original URL. The single most important thing to unlearn: the old '301 passes ~95% of link equity, 302 passes 0%' rule is wrong — redirects aren't a leaky pipe with a fixed percentage. But that doesn't mean everything is guaranteed to survive untouched either: redirect type is one canonicalization signal (among internal links, external links, sitemaps, and more) that helps decide which URL, source or destination, Google treats as canonical — your actual traffic, rankings, and links still depend on those other signals lining up, too. A 302 left in place long enough — especially to an established destination — can get treated like a 301, with no fixed cutoff (Mueller), though how fast that happens is a practitioner observation, not documented policy. Still use a 301 for permanent moves (it's unambiguous to browsers, CDNs, and search engines) and a 302 for genuinely temporary situations — Google explicitly tells you to use 302, not 301, for A/B tests. Keep permanent redirects in place at least a year.

TL;DR — 301 (permanent) vs. 302 (temporary) is a canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. signal, not a value-transfer dial with a fixed percentage. A 301 is a strong signal the destination should become canonical; a 302 tells Google to keep the source canonical by default. The “301 passes ~95%, 302 passes 0%” rule is dead — but that’s not the same as a guarantee that nothing can ever go wrong either way; the redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. type is one signal, among internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., external links, and sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., that influences which URL (source or destination) the existing signals consolidate onto, and traffic/ranking outcomes still depend on those other signals agreeing. A persistent 302, especially to an established destination, can get treated like a 301, with no fixed cutoff (Mueller) — it depends on the totality of canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. signals, not a timer, and how quickly that happens is a practitioner observation rather than documented policy. Still use a 301 for permanent moves (it’s unambiguous to browsers, CDNs, and search) and a 302 for genuinely temporary ones — Google’s own A/B-testing doc explicitly says use 302, not 301. Keep permanent redirectsA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. up at least a year; relevance still gates consolidation (an irrelevant target can be treated as a soft 404A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing. regardless of code).

The semantic difference comes first

Before any SEO effect, a 301 and a 302 say two different things under HTTP: permanent versus temporary. Evidence for this claim RFC 9110 defines 301 as a permanent move and 302 as a temporary move; both permit a user agent to change POST to GET when following the redirect. Scope: HTTP semantics for 301 and 302 responses. Confidence: high · Verified: IETF: RFC 9110 §§15.4.2–15.4.3 Google’s own docs put it cleanly: for a permanent redirect, “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. follows the redirect, and the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. pipeline uses the redirect as a signal that the redirect target should be canonical.” For a temporary one, “GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. follows the redirect, but the indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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.” Evidence for this claim Google uses permanent redirects as strong canonical signals and temporary redirects without using them as a signal that the destination should become canonical. Scope: Google Search redirect processing; other canonical signals can still affect the selected canonical. Confidence: high · Verified: Google: Redirects and Google Search

That’s the whole thing in two sentences. A 301 nudges Google toward making the destination canonical. A 302 doesn’t — by default it keeps the source as the canonical and just borrows the destination’s content for now. Mueller’s mail analogy maps onto it directly: “301 is like a permanent redirect where you’re saying, ‘Oh, I’m permanently moving to a different location’… And 302 is more like a temporary thing. You go on vacation, and you’re like, ‘My mail can actually continue to go to my old location, even though I’m not there for the time being.’”

This is the single most important thing to unlearn, so let me be blunt: it’s false. It’s the most-repeated claim in this whole topic and it survives on pages that still rank today.

Where it comes from is understandable. Back in 2013, Matt Cutts described redirects as leaking a little PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems. the way any link does: “The amount of PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems. that dissipates through a 301 is almost exactly, is currently identical to the amount of PageRank that dissipates through a link.” People took “a little dissipates” and ran it into “301 = 95%, 302 = 0%,” which was never what he said.

Then in 2016 Gary Illyes closed the door on even that: “30x redirects don’t lose PageRank anymore.” — a direct statement that redirects, by themselves, aren’t a lossy pipe the way the 2013 framing implied.

And the modern framing — the one that actually explains what’s happening — is Mueller’s. On Search Off the Record, he said the part people lose sleep over is unnecessary: “it’s not that one kind of redirect is better than the other for these [signals/PageRank], it’s just a different thing. If you’re not forwarding all of your signals, then of course, your old URL keeps the signals. And if you are forwarding them, then the new URL gets those signals. It’s not that anything is lost. It’s just a matter of ‘Well, is it on the old URL or on the new URL?’” He put a bow on it a moment later: “It’s not that you’re going to lose any page rank by doing one way or the other.”

So the correct mental model isn’t a leaky pipe with a percentage on it. It’s bucketing and canonicalization. In Mueller’s words from 2021: “With redirects, we tend to put URLs into the same bucket, and then use canonicalization to pick which one to show. The rankings will generally be the same, so whether it’s source or destination URL doesn’t really matter.” The redirect type is one input into which URL wins the bucket — not a toll booth that skims off value.

Does redirect type affect rankings, then?

The redirect code itself isn’t what tanks your rankings — what it affects is which URL Google treats as canonical and where the consolidated signals land. But get the wrong one canonicalized, or leave your other signals (internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content.) disagreeing with the redirect, and you can see real drops on the URL you actually care about. Nothing was “deleted” in that scenario — it’s just sitting on, or split across, a URL you didn’t intend. That’s a real practical risk, not merely a reporting inconvenience.

There’s no fixed timer for a 302 becoming a “301”

This is where the nuance lives. Mueller, same 2021 thread: a temporary redirect “is more about telling us the source URL might be preferred, while a permanent one suggests the destination URL would be. We use a lot more than just redirects for canonicalization though. That’s usually why a 302 ‘source-preferred’ ends up being treated more like a 301 ‘destination-preferred’ over time… if all internal & external links point to the destination, probably we should pick the destination too. There’s no fixed cut-off time for that.”

Read that last line twice. Google deliberately won’t give you a number of days/weeks. Whether a lingering 302 flips to 301-like treatment depends on the weight of all your canonicalization signals — internal links, external links, sitemaps, hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. — not on a stopwatch.

Bing is an interesting historical contrast here. Back in 2020, Fabrice Canel of Bing offered a rule of thumb via Twitter — reported secondhand by Search Engine Roundtable, not an official Bing doc — that it’s “preferable to use a 302 redirectA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. if your destination URL may change within 2 days, else 301 is recommended.” Treat that as a dated, secondary-sourced data point rather than Bing’s confirmed current policy; it hasn’t been re-verified against a primary Bing source. Directionally, though, Google’s public stance is “many signals, no cutoff,” while Bing has at least once been willing to name a number.

Real-world evidence: my own experiment

I’ve tested this directly. In one experiment I 302-redirected an established site to another established site — and Google didn’t wait around at all. When it saw the redirect, it dropped the old domain from search in favor of the “new” one, almost immediately. Ahrefs’ write-up of it framed the takeaway well: Google “seems quicker to treat 302 redirects as permanent when redirecting to an established page or site… because the new page or website has been around a while, so there’s a good chance you meant to redirect the URL permanently.”

So “a 302 eventually gets treated like a 301” isn’t always a slow drift measured in months. When the destination already has strong signals, “eventually” can mean days — in this one case. That’s a real, bounded data point that the type-based cutoff myth doesn’t survive contact with reality; it’s not proof that every established-domain 302 will reclassify on the same timeline. Treat “days, not months” as one practitioner observation, not a documented Google policy.

And it can go the other way (rarely)

Most guides present this as a one-way street: temporary redirects can become permanent, never the reverse. Not quite true. As I noted in my redirects guide, “permanent redirects can occasionally be treated as temporary redirects as well” — in rare cases Google keeps showing the old URL as canonical even behind a 301, usually when other signals contradict the redirect. It’s uncommon, but “301 always guarantees full consolidation” is not strictly correct either.

When 302 is still the technically correct choice

“Just use 301 for everything” is bad advice. There are cases where 302 is the right answer, and one of them Google spells out explicitly.

  • A/B testing. This is the textbook case, and Google has a dedicated page for it with the literal heading “Use 302 redirects, not 301 redirects.” Its words: “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary… and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page).” If you 301 an experiment, you’re telling Google to swap in your test URL permanently — exactly what you don’t want.
  • Temporary sales / promo pages. A product temporarily pointing at a seasonal landing page you’ll remove after the sale — you want the original URL to stay indexed.
  • GeoGenerative Engine Optimization — visibility inside AI answer engines./language redirects and m-dot (mobile↔desktop) redirects. Mueller’s own example: for a mobile/desktop redirect, “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” The redirect isn’t a permanent move; it depends on the visitor. But be careful with locale-adaptive routing generally: Googlebot’s default requests are US-based and don’t send an Accept-Language header, so a redirect (or any auto-detection) that decides the destination based on IP or browser language can hide your other locale variants from Google entirely. Google’s own guidance is to give each locale its own crawlable URL and connect them with hreflang annotations (including x-default where relevant) rather than relying on redirect-based detection alone — then verify Google can actually discover every variant, not just the one it happened to land on.
  • Maintenance pages / short outages — but not all “maintenance” is the same. If another page genuinely satisfies the request for now (a relevant temporary landing page), a 302 to it is reasonable and the original URL should keep its place in the index. That’s different from a short, full-site outage, where Google recommends a 503 rather than redirecting everything to one page — and different again from a longer operational pause, where keeping useful pages reachable (rather than blanket-redirecting the whole site) is usually the better move.

When 301 is the correct choice

Everything permanent. A 301 remains the right call for a permanent change because it’s the unambiguous one — it tells browsers, CDNs, proxies, and every search engine “this is permanent,” so you’re not relying on Google to eventually infer it from other signals, and you’re not leaving traffic, rankings, or link signals sitting on the old URL any longer than necessary:

  • Permanent URL changes and page moves.
  • Domain changes and site merges.
  • HTTP → HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' migrations.
  • Consolidating www / non-www or trailing-slash variants.

Google’s guidance is direct: “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible. This is the best way to ensure that Google Search and people are directed to the correct page.” Note “server-side” — an HTTP 301 is picked up fastest; an instant meta refresh (0 seconds) is treated as permanent too, a delayed one as temporary, and JavaScript window.location redirects only get picked up during renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. (use them only if you can’t do server-side or meta refresh).

For a real migration, the 301 is only half the job. Map each old URL to its actual relevant equivalent on the new site — not a bulk redirect-everything-to-the-homepage shortcut — and update internal links, canonical tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content., the sitemap, and hreflang to point at the new URLs too, so every controllable signal agrees with the redirect. Avoid chains and loops, and keep the old domain/DNS/TLS able to actually serve the redirects for as long as you’re relying on them — a redirect that starts erroring stops helping anyone.

A protocol detail worth knowing: method and caching

Two more technical differences that competing articles rarely cover, and that sit underneath the SEO discussion:

  • Method handling. For historical compatibility, a user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. may convert a POST request to GET when automatically following either a 301 or a 302 — neither status code strictly guarantees your original HTTP method survives the hop. Evidence for this claim RFC 9110 defines 301 as a permanent move and 302 as a temporary move; both permit a user agent to change POST to GET when following the redirect. Scope: HTTP semantics for 301 and 302 responses. Confidence: high · Verified: IETF: RFC 9110 §§15.4.2–15.4.3 If you need strict method preservation (a form submission that must stay a POST, for example), that’s what 307 (temporary) and 308 (permanent) exist for.
  • Caching. Under HTTP caching rules, a 301 is heuristically cacheable by default; a 302 is not — the status code alone doesn’t make a 302 cacheable, though explicit Cache-Control/Expires headers can still make either one cacheable and reused by a client. Evidence for this claim A 301 is on the RFC 9111 status-code heuristic-cacheability list by default; a 302 is not heuristically cacheable from its status code alone, though explicit cache-control directives can still make either cacheable. Scope: HTTP caching heuristics for 301 vs. 302 responses; explicit headers can override the default. Confidence: high · Verified: IETF: RFC 9111 (HTTP Caching) Don’t flatten this to “browsers cache every 301 forever and never cache a 302” — real behavior depends on the request method, the headers actually sent, cache state, and the client, not the status code in isolation.

A caveat that outranks redirect type: relevance

One thing that gates consolidation regardless of whether you used a 301 or a 302: the target has to be relevant to the source. If you redirect a page to something unrelated (a common mistake is redirecting a bunch of dead pages to the homepage), Google may treat it as a soft 404 and not consolidate signals at all — 301 or 302, doesn’t matter. Redirect to the closest real equivalent, not a catch-all.

Common mistakes

  • Leaving a 302 in place for a permanent change. It’ll often self-correct to 301-like treatment, but you’re relying on Google to guess your intent. Just use a 301.
  • Using a 301 for something genuinely temporary — especially an A/B test. You’re telling Google to permanently swap in the wrong URL.
  • Pulling a 301 too early. Google’s site-move guidance is to “keep the redirects for as long as possible, generally at least 1 year,” because that’s how long it takes to “transfer all signals to the new URLs.” I tested this: after about a year the signals had consolidated to the new URL and mostly stayed there, matching Illyes’ line that “after 1 y all signals had time to pass on from A to B.” Remove a 301 before that and you can strand the old URL with none of its former signals.
  • Redirecting to an irrelevant page — soft-404 risk, as above.

How to check how Google is actually treating your redirect

Don’t assume — verify, and treat this as two separate layers.

The HTTP layer. Run a real request against the old URL and confirm the status code, the Location header, the chain length (one hop, ideally), and how caching headers behave — a browser tab or a single HEAD request isn’t enough, since caching and client behavior can mask what the server actually sends. This is what tools like a redirect checker exist for.

The Search layer. In GSC’s URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version., inspect the old URL. The “User-declared canonical” vs. “Google-selected canonical” tells you which way Google has bucketed it. (Note that URL Inspection shows a 200 for a redirected URL, not the 301/302 — Mueller explains that’s deliberate: “we want to show you what we would use for indexing… which is the final page.”) Cross-check with the Links report to confirm the destination is picking up the source’s backlinks, and check that internal links, the sitemap, and hreflang (where relevant) agree with the redirect. Keep in mind URL Inspection shows Google’s current recorded and live state — it can’t prove what Google will do in the future, so it’s a diagnostic snapshot, not a guarantee of a particular outcome.

If a “permanent” move still shows the old URL as canonical months later, your other signals (internal links, sitemap) probably still point at the old URL — go align them, then recheck both layers rather than swapping the status code to try to force the issue.

Where this sits

301 and 302 are two of the 3xx redirect codes, and each has its own deep dive in this cluster, as do the strict-method variants (307, 308) and the temporary sibling 303 — plus the comparisons like 302-vs-307 and 301-vs-308 for the method-preservation nuances, and the operational hazards, redirect chainsA → B → C instead of A → C. Each hop loses link equity and adds latency. and redirect loopsA redirect loop is a chain of redirects that circles back on itself instead of ever reaching a live page — URL A redirects to B and B redirects back to A (or a longer cycle). No page ever returns a 200, so browsers show ERR_TOO_MANY_REDIRECTS and crawlers can't index anything.. For the whole family of server responses, see the HTTP Status Codes hubAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.; redirect type is also one of the canonicalization signals covered in canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it..

TIP Verify the status and final destination before debating semantics

The observed chain shows what the server shipped. Choosing 301 or 302 still depends on whether the move is genuinely permanent or temporary.

Run the source URL through my Redirect Checker to inspect every hop, final response, and protocol change. Redirect Checker Free

  1. Trace the source URL without relying on browser cache.
  2. Confirm the status, final destination, chain length, and relevance of the target.
  3. Use 301 for a permanent move or 302 for a temporary one, then rerun the trace.

Try it live

These are real endpoints on this site — not a simulation. Hit them from the button, open them in a new tab, or curl -i them from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗
Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.