301 vs. 302 Redirect

TL;DR — A 301 redirect means “this page moved permanently.” A 302 means “this page moved temporarily.” Both send visitors to the new URL; the difference is what you’re telling search engines about which URL should be the real one going forward. Forget the old rule that “301s pass value and 302s don’t” — that’s outdated, but it doesn’t mean everything automatically survives either way; the redirect type is one signal among several that decides which URL ends up with the credit. Use a 301 when the change is permanent, a 302 when it’s genuinely temporary.

What a 301 and a 302 actually mean

Both a 301 and a 302 are redirects: type in one URL, land on a different one. The number is the HTTP status code the server sends, and it carries a message for browsers and search engines.

• 301 — “Moved Permanently.” You’re telling everyone the old address is gone for good and the new one is the real home now.
• 302 — “Found” (temporary). You’re saying “send people over here for now, but the old address is still the one that counts — I’ll be back.”

John Mueller from Google has a nice analogy for this. A 301 is like filing a permanent change of address so your mail gets forwarded to your new home for good. A 302 is like going on vacation: your mail can keep going to your old address because you’re only away for a little while.

The one thing everybody gets wrong

You’ll still read, all over the internet, that “a 301 passes about 95% of your SEO value and a 302 passes zero.” That rule is wrong, and it’s been wrong for years.

Neither redirect type is a switch that instantly deletes your links, authority, or rankings — but that’s not the same as saying everything is guaranteed to land safely on the new URL either. The redirect type is a signal that helps Google decide which URL — the old one or the new one — it treats as the “real” version and gives credit to. Whether your actual traffic and rankings follow still depends on other signals (internal links, external links, sitemaps) pointing the same direction. A 301 points that preference at the new URL. A 302 does not provide that canonical signal, though other canonicalization signals can still select the destination. 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: 2026-07-14 Google: Redirects and Google Search

So which one do I use?

A simple rule covers almost every case:

• Is the change permanent? (You moved a page, switched to HTTPS, changed domains, merged two pages.) → Use a 301.
• Is the change genuinely temporary? (A short sale page, an A/B test, a maintenance page, sending someone to a country-specific homepage.) → Use a 302.

If you’re not sure and the change is meant to stick, use a 301 — it’s the safe default for anything permanent.

One more thing worth knowing: a 302 you leave in place for a long time will often get treated like a 301 anyway, because Google eventually decides the new URL is the one that matters. That’s fine when the move really was permanent — but it means you shouldn’t rely on a “temporary” 302 to protect an old URL forever.

Want the full picture — why the myth persists, what Google’s own docs say, the real-world experiments, and every “when 302 is correct” case? Switch to the Advanced tab.

TL;DR — 301 (permanent) vs. 302 (temporary) is a canonicalization 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 redirect type is one signal, among internal links, external links, and sitemaps, 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 canonicalization 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 redirects up at least a year; relevance still gates consolidation (an irrelevant target can be treated as a soft 404 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: 2026-07-14 IETF: RFC 9110 §§15.4.2–15.4.3 Google’s own docs put it cleanly: 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. 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: 2026-07-14 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.’”

The myth: “301 passes ~95% of link equity, 302 passes 0%”

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 PageRank the way any link does: “The amount of PageRank 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 links, sitemap, canonical tags) 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, hreflang — 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 redirect 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.
• Geo/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 → HTTPS 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 rendering (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 tags, 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 agent 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: 2026-07-14 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: 2026-07-17 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 tool, 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 chains and redirect loops. For the whole family of server responses, see the HTTP Status Codes hub; redirect type is also one of the canonicalization signals covered in canonicalization.

AI summary

A condensed take on the Advanced version:

• 301 = permanent, 302 = temporary — that’s an intent signal, not a value dial with a fixed percentage. A 301 signals the destination should become canonical; a 302 keeps the source canonical by default (Google’s docs).
• The “301 passes ~95%, 302 passes 0%” rule is false — but that’s not a guarantee nothing can go wrong either way. Redirect type is one canonicalization signal, among internal links, external links, and sitemaps, that decides which URL (source or destination) the existing signals consolidate onto — bucketing, not a leaky pipe (Mueller). Illyes (2016): “30x redirects don’t lose PageRank anymore.” Actual traffic and rankings still depend on the other signals agreeing.
• A persistent 302 can get treated like a 301 — especially to an established destination — with no fixed cutoff (Mueller, 2021). It depends on all canonicalization signals, not a timer, and how fast that happens is a practitioner observation, not documented policy. A 2020 Bing rule of thumb (“~2 days,” via secondary reporting, not re-verified as current policy) is the closest thing to a concrete number either engine has offered.
• Evidence: Patrick’s experiment — a 302 between two established sites got treated as permanent almost immediately in that one case. “Eventually” can mean days, not months, though it’s one data point, not a predictable rule.
• Protocol details: either code may let a client convert POST to GET (use 307/308 for strict method preservation); a 301 is heuristically cacheable by default, a 302 isn’t from its status alone (RFC 9111).
• Use 302 when it’s genuinely temporary: A/B tests (Google’s own doc says use 302, not 301), temporary sale pages, a genuinely relevant maintenance page (503 for a full-site outage instead), and geo/locale or mobile-desktop routing — pairing locale routing with separate URLs and hreflang so Google can discover every variant.
• Use 301 when it’s permanent: page moves, domain changes, HTTPS migration, www/non-www — it’s the unambiguous choice. For a real migration, map each old URL to its relevant new equivalent and align internal links, canonicals, sitemap, and hreflang with it.
• Relevance gates consolidation regardless of code: an irrelevant target can be treated as a soft 404.
• Keep permanent redirects at least a year (Google + Patrick’s 1-year test). Verify both layers: the HTTP response itself, and GSC URL Inspection (declared vs. Google-selected canonical) — Inspection shows current state, not a guaranteed future outcome.

Official documentation

Primary-source documentation from the search engines.

Google

• Redirects and Google Search — permanent vs. temporary redirects, how each affects canonicalization, and the meta-refresh / JavaScript redirect notes.
• How to specify a canonical URL (consolidate duplicate URLs) — where redirects sit among canonicalization signals (“a strong signal that the target of the redirect should become canonical”).
• Test different page versions (website testing) — the A/B-testing guidance with the literal heading “Use 302 redirects, not 301 redirects.”
• Redirect and Google Search — site moves with URL changes — keep redirects “at least 1 year” so all signals transfer.
• Search Off the Record, episode 51 — “Let’s talk redirects” (John Mueller + Martin Splitt) — the richest on-record discussion of 301 vs. 302 and canonicalization.
• Pausing or closing your business (Google Search Central) — when to use a 503 instead of a redirect for a short, full-site or service shutdown.
• Locale-adaptive pages (Google Search Central) — why redirect-based locale detection can hide variants from Googlebot, and the separate-URL + hreflang recommendation.

Bing / Microsoft

• Managing Redirects: 301s, 302s and Canonicals — Bing’s long-standing 301-for-permanent, 302-for-temporary framing.

IETF (protocol specs)

• RFC 9110 — HTTP Semantics — sections 15.4.2 (301) and 15.4.3 (302), including the POST→GET compatibility note both codes share.
• RFC 9111 — HTTP Caching — the heuristic-freshness rules and the status-code cacheability list (301 is on it by default, 302 isn’t).

Quotes from the source

On-the-record statements from Google and Bing. Where the source page supports it, each link is a deep link that jumps to the quoted passage.

Google docs — what each redirect signals

• “Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.” (permanent) — Google Search Central. Jump to quote
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (temporary) Jump to quote
• “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.” Jump to quote
• “If you just want to send users to a different page temporarily, use a temporary redirect.” Jump to quote

Google docs — A/B testing (use 302, not 301)

• “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.” Jump to quote

John Mueller, Google — 302 “source-preferred” becomes 301-like over time (via Search Engine Roundtable, April 8, 2021)

• “With redirects, we tend to put URLs into the same bucket, and then use canonicalization to pick which one to show.” Jump to quote
• “That’s usually why a 302 ‘source-preferred’ ends up being treated more like a 301 ‘destination-preferred’ over time… There’s no fixed cut-off time for that.” Jump to quote

John Mueller, Google (Search Off the Record, ep. 51 — official transcript PDF; cited by timestamp, no HTML anchor exists)

• “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.’” — [00:03:01]
• “It’s not that one kind of redirect is better than the other for these, it’s just a different thing… 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?’” — [00:05:07]
• “It’s not that you’re going to lose any page rank by doing one way or the other.” — [00:05:49] Transcript PDF

Gary Illyes, Google (2016) (via Search Engine Journal) — and the older Cutts line it superseded

• “30x redirects don’t lose PageRank anymore.”
• Matt Cutts, 2013 (historical, now superseded): “The amount of PageRank that dissipates through a 301 is almost exactly, is currently identical to the amount of PageRank that dissipates through a link.” Coverage

Fabrice Canel, Microsoft Bing (2020) (via Search Engine Roundtable) — a historical rule of thumb, not a re-verified current policy

• “[It’s] preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended.” Coverage

Which redirect should I use: 301 or 302?

Answer one or two questions and you’ll land on the right code. Every branch here comes straight from Google’s own guidance and the evidence above.

A note on the “not sure” path: a 302 you leave in place will often get treated like a 301 anyway (no fixed cutoff), and a 301 is the safe default for anything you expect to keep — so when in doubt about a lasting change, lean 301.

Redirect choices that fight your own intent

Leave a 302 on a permanent move

Google may eventually infer permanence, but the timing is undefined and other signals can keep the source preferred. Use 301 when the destination is meant to replace the source.

Put a 301 on a temporary experiment

A permanent code tells search engines to prefer the variation URL. Use 302 for an A/B test so the original remains the intended canonical, then remove the redirect when the test ends.

Remove a permanent redirect too early

Seeing the destination in search does not mean consolidation is complete. Keep permanent redirects for as long as possible, generally at least a year.

Redirect unrelated URLs to one convenient destination

The code cannot rescue a bad mapping. An irrelevant homepage or category target can be treated as a soft 404. Use the closest equivalent or let a genuinely gone URL return 404/410.

When Google treats the redirect differently than expected

A permanent move still shows the old URL

Symptom: You deployed a 301, but the old URL remains Google-selected canonical.

Likely cause: Google has not reprocessed the redirect yet, or internal links, sitemaps, canonicals, and external signals still favor the old URL.

Fix: Confirm the source really returns a one-hop 301, then align the controllable canonicalization signals with the destination. Recheck both URLs in URL Inspection after recrawling; do not replace the 301 with another code to force the issue.

A temporary redirect starts surfacing the destination

Symptom: A long-running 302 no longer keeps the source URL preferred.

Likely cause: The redirect persisted while internal links, sitemaps, or other signals accumulated on the destination. There is no fixed flip timer.

Fix: If the move is now permanent, change the response to 301 and align the signals. If it is still temporary, restore source-focused links/canonicals and end the redirect as soon as the temporary need is over.

URL Inspection appears to show 200 for the redirected URL

Symptom: A raw checker shows 301/302, while URL Inspection emphasizes a final 200.

Likely cause: URL Inspection is showing the final page Google would use for indexing, not replacing a raw HTTP trace.

Fix: Use a redirect checker for the status and chain; use URL Inspection for Google’s indexing and canonical view. The tools answer different questions.

The bucket-and-preference framework

Treat a redirect as two decisions, not a percentage of “link equity passed.”

1. Bucket the URLs. The source and destination are related by the redirect, so Google can treat them as alternate names for one content set.
2. Pick the preferred URL. A 301 is a strong destination-preference signal. A 302 is temporary and source-preferred by default.
3. Reconcile the other signals. Internal links, sitemaps, canonicals, external links, and the redirect’s persistence can reinforce or contradict that preference.
4. Report the winner, not a loss. Signals are not disappearing because you chose 302; they can remain associated with the source rather than consolidate onto the target.

Use this framework whenever someone asks “how much does this redirect pass?” The better question is: which URL should be canonical, and do all our signals support that choice?

301 vs. 302 at a glance

Decision rule: permanent → 301; genuinely temporary → 302. Relevance and a clean, direct target matter more than folklore about one code “passing more value.”

Tools for checking which redirect you actually shipped

Patrick’s free tools

• Redirect Checker — show the first response, every hop, and final destination for one URL or a quick batch. Use it to catch a 302 where the migration plan called for 301, or the reverse.
• Bulk HTTP Status Code Checker — audit up to 500 URLs, filter mixed temporary/permanent codes, and export the redirect set for remediation.

Check Google’s preference separately

• Google Search Console URL Inspection — inspect source and destination to compare the user-declared and Google-selected canonical. This answers the canonicalization question; it does not replace a raw redirect trace.
• Server/CDN logs — verify that search crawlers and users receive the intended code, especially where routing varies by user agent, device, or location.

Test yourself: 301 vs. 302

Five questions on the difference between permanent and temporary redirects and what Google actually does with them. Pick an answer for each, then check.

Resources worth your time

My related writing

• 11 Types Of Redirects & Their SEO Impact (Ahrefs, with Joshua Hardwick) — my full rundown of every redirect type, the preferred implementation order for temporary redirects, and the nuance that permanent redirects can occasionally be treated as temporary too.
• Is It OK to Remove 301 Redirects After a Year? We Tested It (Ahrefs) — my experiment on how long signals take to consolidate to the new URL, and what happens if you pull a 301 too early.
• The Beginner’s Guide to Technical SEO — where redirects fit in the bigger picture.

My speaking

• Patrick Stox on SlideShare and Speaker Deck — my technical-SEO talks, several of which cover redirects and canonicalization. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Google — Redirects and Google Search and the A/B testing guidance.
• Google — Site moves with URL changes (keep redirects at least a year).

From around the industry

• 301 vs. 302 Redirects for SEO: Which Should You Use? (Ahrefs, Joshua Hardwick) — cites Patrick’s 302-between-established-sites experiment, where Google treated the 302 as permanent almost immediately.
• Google Treats 302 Redirects As 301 Redirects Over Time (Search Engine Roundtable, 2021) — Mueller’s “bucket” / “no fixed cut-off” tweets.
• Bing: Use A 302 Redirect If Destination May Change Within 2 Days (Search Engine Roundtable, 2020) — Fabrice Canel’s concrete threshold.
• Google: 301 Redirects Do Not Lose PageRank (Search Engine Journal) — the Illyes 2016 and Cutts 2013 quotes side by side.
• Search Off the Record — “Let’s talk redirects” (Google Search Relations, ep. 51) — the full Mueller/Splitt discussion the quotes above are drawn from.
• A Guide To 301 Vs. 302 Redirects For SEO (Search Engine Journal, Adam Heitzman) — a solid overview to compare against.
• r/TechSEO — the community for redirect and canonicalization debugging.

Changelog