301 vs 302 Redirects: The Real Ranking Impact

We replatformed an e-commerce site in January and lost 38% of organic traffic in two weeks. The culprit was not the content, the new architecture, or the Core Update that month: it was a 302 redirect rule the infra team pushed through Cloudflare Workers, thinking they could revert it later if needed. Googlebot read that as temporary, kept the old URLs in the index, and the authority signal kept ping-ponging between two versions of the same page. That case sums up the problem: a redirect is not a technical detail, it is a semantic signal, and using the wrong code costs ranking.

The formal difference is simple. A 301 tells the crawler that the URL moved permanently, transfers the accumulated PageRank (with minimal loss, per Gary Illyes in 2023), and requests an index update. A 302 says the change is temporary, keeps the old URL as the de facto canonical, and consolidates nothing. In real life, most CMSs and frameworks default to 302 when you forget to specify, which is enough to bleed equity during migrations, slug changes, and duplicate consolidation. Run a periodic How to audit on-page SEO without falling into guesswork that includes status codes and you will find 302s in places nobody remembered touching.

There are legitimate cases for 302, and you should recognize them before swapping everything. Server-side A/B tests with a fixed duration, geo-routing while you still lack proper hreflang, checkout flows that bounce back to the cart, planned 24-48h maintenance windows. The criterion is binary: will the old URL serve the original content again? If yes, 302. If no, 301. When product asks for a long-running test, push the conversation toward a 301 with a documented rollback, or you will discover in Search Console that both versions compete for the same query (see Search Console: 7 underused reports and what to extract from them to pull that data).

Ranking impact goes beyond equity loss. Redirect chains, 301-302 mixing, and loops are the real plague. In a recent SaaS audit we found 14k URLs sitting on 3+ hop chains, with the last hop being a 302. According to the log file analysis we ran (the Log file analysis: what Googlebot is actually doing piece walks through the technique), Googlebot abandoned half those chains before reaching the destination. Result: strategic pages indexed with the wrong content and crawl budget burned on redirects. Each hop adds latency, hurts LCP, and stacks conflicting canonicalization signals that fight whatever you set up in Canonical tags: common mistakes bleeding your organic traffic.

The audit methodology I use fits in four steps. First, Screaming Frog or Sitebulb in list mode, fed by the top 5000 URLs from GSC and GA4. Second, cross response code with index status via the Search Console API. Third, isolate three buckets: 302s that should be 301s (the majority), 301s in chains (collapse to one hop), and 4xx served behind redirects (worst case). Fourth, prioritize by traffic and backlinks pointing to the source URL, using Ahrefs or Majestic. In e-commerce the curve is brutal: 5% of URLs hold 80% of the equity, and that is where a correct 301 recovers traffic in 4-8 weeks, as we saw in the migration discussed in E-commerce on-page: PLP vs PDP without cannibalization.

One detail few teams consider: 307 and 308, the modern HTTP/1.1 equivalents of 302 and 301, preserve the request method (relevant for API POSTs, irrelevant for SEO on pages served via GET). Google treats 308 like 301 and 307 like 302 for indexing purposes, per the official documentation updated in 2025. Use whichever your stack serves correctly, but never mix them in the same chain. And if you work with multilingual sites, remember that IP or Accept-Language redirects without proper hreflang give you the worst case: US Googlebot never reaches the localized content, as detailed in hreflang without pain: implementation for multilingual sites.

Practical takeaway: today, run a crawl from the homepage three levels deep, filter response codes 302 and 307, and ask of each one whether the old URL will truly come back. If the answer is no or maybe, switch to 301. In parallel, map chains longer than one hop and collapse them to the final destination. Document the rules in a versioned file in the infra repo, not in the CDN dashboard, so the next platform swap does not erase the work. Link equity is not recovered by polite request, it is recovered by the right status code in the right place.