Key Takeaways

  • The 301 vs 302 choice is a canonicalization decision, not a link equity calculation: 301 tells Google to index the destination, 302 tells Google to keep indexing the source 2.
  • Use a 301 when the move is permanent and the destination should be indexed; use a 302 only when the source URL is genuinely expected back on a defined timeline 5.
  • Permanent redirects register as strong canonical signals and outrank 302, 303, and 307 in Google's signal hierarchy, which is why server-side code selection often overrides rel=canonical and sitemap hints 6, 12.
  • Reserve 308 for permanent moves on POST endpoints and 307 for temporary method-sensitive paths like checkout during maintenance, where a 301 or 302 would strip the request body 8.
  • Aged 302s, mixed 301/302 migration mappings, and framework defaults shipping 302 on HTTPS switches are the governance failures that quietly erode client rankings and require quarterly response-header audits 3, 7.

The 301 vs 302 debate has been miscategorized for a decade. Most agency documentation still frames the choice as a question of how much ranking authority flows through the redirect, when the actual question Google's indexing pipeline asks is simpler: which URL should be treated as canonical, and how strong is that signal? Permanent redirects register as strong canonical indicators; temporary redirects register as weak ones 6, 11. That distinction, not link equity accounting, is what determines whether a client's rankings survive a migration or drift into volatility.

For agency SEO leads standardizing redirect policy across dozens of client sites, the operational consequence is direct. A 301 tells Google to show the destination URL in search results. A 302 tells Google to keep showing the source 2. When a specialist selects the wrong code during a domain move, the destination cannot inherit rankings because the source stays indexed as canonical 1. No amount of internal linking, sitemap resubmission, or Search Console prompting overrides that instruction cleanly.

The reframe changes how redirect decisions get made. Rather than debating whether a 302 passes 85 percent or 100 percent of PageRank, the question becomes: which URL is the intended index target, and for how long? That reading collapses ambiguity for junior specialists, reduces escalation to senior staff, and produces predictable migration outcomes. The sections that follow map this intent-first framework to Google's documented behavior, the scenarios agencies encounter weekly, and the governance failures that quietly erode client rankings after launch.

What Google Actually Does With a 301 vs a 302

Permanent Redirects as Strong Canonical Signals

Google's crawling and indexing documentation is unambiguous on one point: server-side permanent redirects, whether 301 or 308, are treated as strong indicators that the destination URL should become canonical 2, 11. When Googlebot follows a 301, the destination is what surfaces in search results, and the source URL is expected to fade from the index over successive crawls 2. That behavior is not a courtesy extended to well-implemented redirects; it is the default response to the code itself.

The strength of that signal matters more than most redirect debates acknowledge. Among all canonicalization inputs Google weighs, a 301 outranks 302, 303, and 307 in signaling authority 12. That hierarchy is why the code selected at the server level frequently overrides other canonical hints, including rel=canonical tags, internal linking patterns, and sitemap declarations when they conflict.

For agency SEO leads writing standards documents, the operational implication is that a correctly deployed 301 does the canonicalization work with minimal supporting infrastructure. Search Engine Journal's technical guidance frames the 301 as an instruction to user agents to use the new URL for future requests, not a request for consideration 10. The code carries the intent. Specialists who understand that hierarchy stop treating rel=canonical as a redundant safety net and start treating it as a secondary signal that reinforces, but cannot substitute for, the redirect itself.

Temporary Redirects as Weak Canonical Hints

A 302 tells Google the opposite story. The source URL is expected back, so Google continues to consider it canonical and keeps it in the index 2, 11. The destination is followed for the immediate request but is not promoted to the indexed URL. Search Engine Journal documents this behavior directly: when a 302 is deployed, ranking authority and backlinks typically do not migrate, and the original page remains the version that appears in search results 7.

That weak-signal status is a feature of the code's design, not a defect. The 302 exists precisely so operators can route traffic through a temporary destination without disturbing canonicalization. Google will follow the redirect and serve users the new content, but it treats the temporary status as a hint that the situation is transient, and will continue considering the original URL canonical unless other evidence forces a reassessment 11.

For a Head of SEO governing dozens of properties, the takeaway is that a 302 is the correct code only when the source URL being indexed is the desired outcome. If a specialist deploys a 302 during what is actually a permanent move, the signal Google receives is that the migration should not consolidate. Rankings stay tethered to a URL the client no longer maintains, and destination pages struggle to accrue the canonical status they need to compete.

PageRank Behavior: The Old Rule vs the Current Reading

The PageRank conversation around 301 vs 302 has drifted across two decades, and the drift matters for agency policy. Older technical references, some still in circulation, describe 301 as passing full PageRank while flagging that 302 may not pass any 8. The migration guide in wide circulation states the case in its sharpest form: a 301 transfers 100% of SEO ranking value to the destination URL in a domain migration 3. That figure has become shorthand in agency training decks, often stripped of the scope in which it was originally offered.

The scope is the entire point. The 100% figure describes 301 behavior in a durable, permanent domain move, where the source URL is being retired and the destination is intended as the indexed URL going forward 3. It is not a universal claim about every 301, and it is not evidence that a 302 will lose an equivalent percentage of ranking value in any scenario. Newer guidance, aligned with Google's current documentation, describes both 301 and 302 as capable of passing PageRank, with the practical difference concentrated in which URL Google keeps canonical rather than in a numeric equity gap 9.

Reconciling the two readings gives agency SEO leads a defensible position. The old rule described a specific outcome accurately: in permanent migrations, correctly implemented 301s consolidate ranking signals onto the destination. The current reading corrects the overreach by clarifying that PageRank flow is not the primary axis of difference; canonicalization is 11. Both readings converge on the same operational instruction. Use a 301 when the destination should be indexed. Use a 302 only when the source should remain the URL Google shows.

The Intent-First Rule Junior Specialists Can Execute

The rule that eliminates most redirect escalations is one sentence long: use a 301 for moves the client will never undo, and a 302 for anything they might reverse 5. That framing is deliberately intent-first. It sidesteps PageRank arithmetic entirely and forces the specialist to answer a business question the account team can confirm in a single message. Is the source URL coming back, yes or no? If no, the code is 301. If yes, and the return is on a defined timeline, the code is 302.

The reason the rule holds is that it matches the canonical signal hierarchy Google actually uses. A 301 sends a stronger canonical signal than a 302, 303, or 307 12. Permanent redirects register as strong indicators; temporary redirects register as weak ones 6. Selecting the code is not a preference; it is a declaration of which URL the indexing pipeline should treat as authoritative. When the specialist gets the intent right, the canonicalization follows without additional intervention.

Codifying the rule in a standards document changes what specialists escalate. Instead of debating equity percentages or hunting for edge-case exceptions, they confirm intent with the account lead and select the code that matches. Senior review time shifts from adjudicating every redirect decision to auditing the exceptions where intent is genuinely ambiguous, such as a discontinued product line the client may relaunch, or a URL structure being tested before wider rollout. Those cases warrant a conversation. The other ninety percent of redirect decisions do not, and treating them as if they do slows delivery without improving outcomes. The intent-first rule is what makes redirect governance delegable.

Test 301 and 302 redirect strategies in action

Validate redirect types on live pages and measure real SEO impact before full rollout.

Start Free Trial

Scenario-to-Code Decision Matrix for Client Portfolios

Redirect policy scales only when the scenarios that repeat across a client roster resolve to a single code without debate. The matrix below covers seven situations agency specialists encounter weekly, mapped to the code that matches the canonicalization intent Google's indexing pipeline expects 2. Each row assumes correct server-side implementation and no conflicting canonical signals downstream.

ScenarioCodeCanonical Outcome
Permanent domain migration301Destination URL becomes canonical and is shown in search results 2, 3
HTTP to HTTPS switch301HTTPS URL becomes canonical; HTTP source is retired from the index 2, 5
URL restructuring or slug change301New URL inherits canonical status; old path drops out of the index 1
Temporary campaign landing page302Source URL stays canonical; campaign destination is followed but not indexed 7
A/B test between two live variants302Original page remains the indexed version during the test window 7
Scheduled maintenance window302 or 307Source URL stays canonical; 307 preserves the HTTP method if POST traffic is involved 5, 8
Geo-redirect based on visitor location302Source URL stays canonical; the geo variant serves the user without replacing the indexed URL 5

Three rows carry the operational weight. The migration row is where the 100% ranking transfer figure from the migration guide applies, scoped to a permanent domain move with a correctly executed 1:1 mapping 3. The HTTPS row is where developer defaults most often ship a 302 when a 301 was intended, because framework middleware treats the switch as a runtime toggle rather than a canonical declaration. The geo-redirect row is where junior specialists most often escalate, because the instinct is to treat any code that changes based on visitor context as "dynamic," when the correct read is that the source URL should remain the indexed version regardless of which regional variant a given user sees.

The matrix is deliberately narrow. It does not cover every edge case a senior specialist will encounter in a decade of migrations, and it is not meant to. What it does is resolve the routine decisions that consume review cycles across a portfolio, so senior time flows to the genuinely ambiguous cases: discontinued product lines that may relaunch, seasonal microsites with unclear retirement dates, and consolidation projects where the intended canonical URL is still being negotiated with the client. For those, the rule stays intent-first. For everything on this matrix, the code is settled.

Infographic showing SEO ranking transfer for 301 redirectSEO ranking transfer for 301 redirect

SEO ranking transfer for 301 redirect

When 307 and 308 Belong in the Playbook

Most agency redirect policies can operate on 301 and 302 alone, but two adjacent codes earn their place in a mature standards document. The 308 is the method-preserving twin of the 301: a permanent redirect that requires the client to reissue the original HTTP method rather than silently downgrading a POST to a GET. The 307 plays the same role for temporary redirects, preserving the method where a 302 would not 8. Both codes carry canonical semantics that mirror their older counterparts, with 308 registering as a strong permanent signal and 307 as a weak temporary one 6.

The scenarios that warrant 308 over 301 are narrow but consequential. Form submissions, API endpoints, and authenticated POST traffic behind a permanent URL change need 308 so the request body survives the redirect. A 301 in those paths can convert a POST into a GET at the browser level, breaking the transaction. For content URLs indexed by Google, the SEO outcome of 301 and 308 is functionally identical, so specialists should default to 301 for standard page moves and reserve 308 for endpoints where method preservation is a technical requirement 5.

The 307 belongs in maintenance windows, geo-routing, and any temporary scenario touching POST traffic. A 302 on a checkout URL during a maintenance swap can strip the payment payload; a 307 preserves it. Canonicalization behavior tracks the 302: the source URL stays indexed, and the redirect registers as a weak signal 11. Agencies standardizing on 301 and 302 for the routine ninety percent should document 307 and 308 as the required codes for method-sensitive paths, so developers do not have to guess when a form endpoint moves.

The Long-Standing 302 Problem and Why It Is a Governance Issue

A 302 that has been in place for years is not the same object it was on deployment day. Google's canonicalization systems can reinterpret long-standing temporary redirects as effectively permanent, promoting the destination URL to canonical over time even though the code still reads 302 7. That drift sounds like a safety net. In practice, it is the reason redirect governance fails quietly across client portfolios.

The problem is not that Google eventually gets to the right answer. The problem is that the interval between deployment and reinterpretation is unpredictable, and during that window canonical signals conflict. The 302 registers as a weak indicator that the source should stay canonical 6, while the persistence of the redirect argues for treating the destination as the real URL. Specialists auditing a client site months later cannot tell from Search Console alone which reading Google has settled on for any given URL, and rankings can shift in either direction without a clear trigger.

The governance response is not to relax standards because Google will eventually compensate. It is to treat every 302 in a client's redirect table as an open ticket. Either the source URL is genuinely expected back on a defined timeline, or the code should be converted to a 301 5. Quarterly redirect audits, not one-time migration reviews, are what keep the intent-first rule enforceable at portfolio scale.

See How Enterprise Teams Manage Redirects at Scale—Without SEO Bottlenecks

Connect with experts on implementing high-volume 301 and 302 redirects efficiently, with full audit trails and measurable impact on site authority—purpose-built for agencies and digital brands managing complex migrations.

Contact Sales

Operational Failure Modes Agencies Actually Hit

Redirect Chains and Signal Degradation

Redirect chains rarely start as chains. They start as a 301 stacked on a prior 301, then a 302 inserted mid-chain by a marketing team running a seasonal promotion, then another 301 added when the URL structure shifts again. Each hop is defensible in isolation. The cumulative result is a path where canonical signals weaken with every additional step and Googlebot spends crawl budget resolving hops instead of indexing new content.

The mechanical problem is that a mixed chain undermines the strong-signal status a clean 301 would carry. A 301 outranks 302, 303, and 307 as a canonical indicator 12, but that hierarchy applies to the code Google encounters, not to an averaged reading across a chain. A single 302 embedded between two 301s converts what should be a permanent signal into an ambiguous one, because the temporary hop registers as a weak indicator that the source should stay canonical 6. The destination inherits less than it would through a direct 301, and the intermediate URLs can linger in the index longer than intended.

Agency policy should require every redirect audit to collapse chains to a single hop wherever the mapping allows, and flag any 302 sitting inside a chain as a governance defect rather than a routine entry.

Mixed 301/302 in Migration Mappings and Developer Defaults

The most common cause of post-launch ranking loss on client migrations is not a missing redirect. It is a redirect table where roughly ninety percent of rows are 301 and the remaining ten percent shipped as 302 because a developer accepted a framework default. Next.js, Express, Rails, and most CDN edge configurations default to 302 or a generic "redirect" that resolves to 302 unless the code is explicitly set. Specialists writing the mapping in a spreadsheet assume the code will match the intent. The deployed configuration does not.

The consequence is a split canonicalization signal across the migration. The rows that shipped as 301 tell Google to promote the destination URL to canonical 2. The rows that shipped as 302 tell Google to keep the source indexed and treat the destination as a temporary route 7. Rankings consolidate on part of the new site and fragment on the rest, and the pattern of which URLs recovered and which did not looks arbitrary until someone runs a status-code audit against the full mapping.

The governance response is a pre-launch verification pass that reads the actual response header for every row in the migration table, not the intended code recorded in the spreadsheet. Any 302 returned where the mapping specified 301 is a launch blocker 3.

Codifying Redirect Governance Across Client Portfolios

Redirect governance stops being a technical topic and becomes an operational one at the point where a single Head of SEO is accountable for the status codes deployed across twenty or fifty client sites. At that scale, the failure mode is not a specialist making the wrong call in isolation. It is the absence of a written standard that specifies which code applies to which scenario, who verifies the response header before launch, and how often the redirect table gets re-audited after go-live.

A portfolio-grade standard needs four artifacts.

  1. The scenario-to-code matrix, treated as the default answer for any redirect a specialist deploys without escalation.
  2. A pre-launch verification step that reads the actual server response for every row in a migration mapping, because framework defaults ship 302 when the spreadsheet says 301 more often than most senior leads acknowledge.
  3. A quarterly audit cadence that surfaces every 302 in a client's active redirect table and forces a binary decision: convert to 301 or document the timeline on which the source URL returns 5.
  4. An escalation path reserved for the genuinely ambiguous cases, so senior review time flows to discontinued product lines that may relaunch and consolidation projects with unsettled canonical targets, rather than to routine HTTPS switches.

The intent-first framing is what makes those artifacts enforceable. When the standard reads "use a 301 when the destination should be indexed and a 302 only when the source should remain the URL Google shows" 9, junior specialists can apply it without adjudicating PageRank debates, and senior leads can audit adherence by inspecting response headers rather than reconstructing intent from account notes.

Enforcing that governance at portfolio scale is where AI marketing execution platforms like Vectoron shift the operating model, running response-header verification, redirect-chain detection, and quarterly 302 audits as coordinated workflows that route exceptions to senior review rather than routine decisions.

Visualize the four governance artifacts as a process framework that supports the operating model described in the sectionVisualize the four governance artifacts as a process framework that supports the operating model described in the section

Frequently Asked Questions