Loading tutorials…
Loading tutorials…
Redirect chains kill crawl budget and bleed link equity. Screaming Frog finds them in seconds; fixing them takes coordination. This walks the exact workflow from chain detection to clean 301s.
Who this is forTechnical SEOs auditing a site post-migration, post-redesign, or post-CMS-change. If you've shipped 200+ redirects in the last year and never validated them for chains, you almost certainly have some.
What you'll need
Step 1
After crawl completion: Reports → Redirects → Redirect Chains. Also: Reports → Redirects → All Redirects.
Complete a normal crawl first. Screaming Frog tracks every redirect by default — no special configuration needed.
Top menu → Reports → Redirects → Redirect Chains. This is the master report you want.
The CSV includes: source URL, every hop in the chain, the final destination, total chain length, and status codes at each hop.
Also useful: Reports → Redirects → Redirect & Canonical Chains. This catches cases where a redirect lands on a page with a canonical pointing somewhere else — Google still has to follow both.
Step 2
Open the export. Sort by "Chain Length" descending. Any chain over 2 hops is a fix.
Open the Redirect Chains CSV. Sort by 'Chain Length' (or 'Number of Redirects') descending.
Chain of 1: source → destination. Clean. No action.
Chain of 2: source → intermediate → destination. Acceptable in some cases (e.g., http → https → www) but worth flattening.
Chain of 3+: real authority loss. Each hop drops ~10% of link equity per Google's published statements. A 5-hop chain leaks 40%+ of equity.
Loops: if the final destination redirects back to a URL earlier in the chain, you have an infinite loop. Browsers cap at ~20 hops, then show ERR_TOO_MANY_REDIRECTS. Crawlers give up and treat the URL as broken. Fix immediately — these are emergencies.
Step 3
For each chain, identify whether the redirect is server-level, CMS-level, or CDN-level.
Add a 'Source' column to your CSV. For each redirect chain, identify where the redirect rule lives.
Server-level: Apache .htaccess, nginx conf, IIS web.config. Usually the http → https and www → apex redirects.
CMS-level: WordPress plugin (Redirection, Yoast Premium), Webflow's built-in redirects, custom database tables in headless CMS setups.
CDN-level: Cloudflare Page Rules / Bulk Redirects, Vercel rewrites in next.config.js, Netlify _redirects file.
Framework-level: Next.js redirects in next.config.js, Nuxt server middleware. These execute before the request hits your server.
Without this map, you'll fix one redirect in WordPress while the duplicate rule in Cloudflare still creates the chain. Always identify the source FIRST.
Step 4
For each chain, replace the source rule with a direct redirect to the final destination. Remove or update the intermediate rules.
For a chain like /a → /b → /c → /d: change the rule for /a to redirect directly to /d. Then update or remove the rules for /b and /c as needed (they might still need to redirect for other inbound paths).
If multiple sources hit the same chain (e.g., /a, /a-old, /a-final → /b → /c → /d), update all source rules at once. Don't fix /a alone and leave the others.
Where possible, consolidate the rules into the single highest-priority layer. If your CDN can handle all redirects, move them out of CMS plugins and into the CDN — fewer hops, cleaner audit trail.
For programmatic redirects (e.g., a rule that handles 5,000 old product slugs), write the new rule to point directly at the final URL pattern, not at an intermediate.
Step 5
Use Mode → List in Screaming Frog. Paste 20 representative chain sources. Verify the new redirects resolve in 1 hop.
Before deploying all fixes, validate the rule changes on a few critical chains using SF's List mode.
File → Mode → List. Paste 10-20 source URLs from your highest-priority chains.
Run the crawl in List mode. Open the Response Codes tab.
For each source URL, the report should show exactly one redirect (301) to the final destination — no chain, no loop.
If a URL still shows a chain, the rule update didn't propagate (often CDN caching). Purge the cache and re-test before declaring victory.
Step 6
Run a full re-crawl. Re-export Redirect Chains. The total chain count should drop by 80%+ after the first sprint.
After the rules deploy and CDN caches clear (24-48 hours), run a full Screaming Frog re-crawl.
Reports → Redirects → Redirect Chains. Compare against the original CSV.
Total chain count should drop dramatically. If it dropped by less than 50%, your fixes didn't propagate — most likely cache or a duplicate rule in another layer.
Note any new chains that appeared. These are usually consequences of the fixes (e.g., a redirect rule that worked before is now creating a chain because of a new rule above it). Re-flatten.
Set a quarterly re-audit cadence. Redirect chains accumulate naturally over time — every CMS update, every dev change, every new redirect rule can introduce one.
Common mistakes
Fixing chains in one layer while leaving duplicates in another
What goes wrong: You clean up 200 chains in WordPress. The Cloudflare Page Rules still create the same chains. A re-crawl shows no improvement. You spend the next two weeks debugging 'why didn't the fix work.' Cost: 15-25 hours of wasted debugging.
How to avoid: Always map the source layer for every redirect BEFORE fixing. Use the 'Source' column workflow in Step 3.
Not purging CDN cache after rule changes
What goes wrong: You update rules, run a re-crawl 10 minutes later, and chains still appear. You assume the rule didn't deploy when actually it did — Cloudflare or your CDN is serving cached 301 responses. Hours wasted re-deploying rules that are already live.
How to avoid: After every redirect rule change, purge the CDN cache (Cloudflare → Caching → Configuration → Purge Everything). Wait 5-10 minutes before re-testing.
Treating redirect loops as 'just another chain'
What goes wrong: An infinite redirect loop shows as ERR_TOO_MANY_REDIRECTS in browsers. Googlebot stops crawling the URL. You lose any indexed status it had. On a money page, this can be $5K-50K in immediate lost revenue.
How to avoid: Filter the Redirect Chains export for 'Loop' status. These are P0 emergencies — fix today, not next sprint.
Using 302 (temporary) redirects for permanent moves
What goes wrong: 302 redirects don't pass link equity. Migrating /old-blog/ → /blog/ with 302s instead of 301s means every backlink to /old-blog/ stops counting. On a 5K-backlink site, this can cost 20-40% of organic traffic over 90 days.
How to avoid: Use 301 (permanent) for every permanent move. 302 only for genuinely temporary scenarios (A/B tests, maintenance pages).
Not collapsing http/https and www/non-www into one rule
What goes wrong: Your server does http → https. Your CDN does www → apex. A request for http://www.example.com/page hits both layers, becoming a 3-hop chain. Multiply across the site and you've leaked 10-15% of authority.
How to avoid: Consolidate canonicalization into one rule at the highest layer (usually the CDN). One redirect, one hop, regardless of incoming protocol/subdomain combination.
Skipping the post-fix re-crawl
What goes wrong: You ship redirect fixes and never validate. Three months later, a new audit shows the same chain count — turns out the fixes deployed to staging, not production. Cost: a quarter of unfixed equity loss.
How to avoid: Always re-crawl after rule deployment. Compare chain counts. Don't claim completion without measurement.
Recap
Done — what's next
How to set up Screaming Frog and run your first crawl
Read the next tutorial
Hand it off
Redirect chain cleanup is a coordination problem more than a technical one — server admins, CMS admins, CDN admins, framework devs all touch redirects. A vetted technical SEO specialist on EverestX will own the cross-layer audit and coordinate the fixes with your team — typically a 2-4 week sprint at $14-16/hr.
See specialist rates
Google's John Mueller has confirmed that each 301 'may' leak some PageRank, though they've also said it's minimal in modern systems. Conservative SEO planning assumes ~5-15% loss per hop. A chain of 4 hops in the worst case can leak 30%+ of the original equity. Treat 2+ hop chains as fixable, 3+ as urgent.
A chain is A → B → C → D (eventually reaches a 200). A loop is A → B → C → A (never reaches 200). Loops are P0 — Googlebot abandons them and browsers show errors. Chains are P1 — they work but leak equity.
Both are permanent redirects. 308 preserves the HTTP method (POST stays POST), 301 may downgrade it to GET. For SEO purposes, 301 is the standard and universally understood. Use 308 only if you have programmatic POST endpoints that must preserve method.
Sometimes. Canonical is a hint; 301 is a directive. Use canonical when both URLs must remain accessible to users; use 301 when one URL should be deprecated. Many duplicate-content cases use canonical; most migration cases need 301.
Continuously. Every CMS upgrade, every plugin install, every dev change, every CDN rule update can introduce a new chain. Quarterly re-audits are the minimum cadence for active sites; monthly is better.
Screaming Frog SEO Spider
Screaming Frog only earns its keep when the crawl matches how Googlebot actually sees your site. This walks through the install, license activation, memory tuning, and configuration choices that 90% of first-time users get wrong.
Screaming Frog SEO Spider
Broken internal links bleed crawl budget and tank user experience. Broken external links signal stale content. This walks through the exact filter + export workflow that turns a 4xx report into a prioritized fix list in 90 minutes.
Screaming Frog SEO Spider
70% of site migrations lose traffic. Almost all of those are preventable with one disciplined pre-launch Screaming Frog crawl. This is the exact checklist that separates a clean migration from a six-month recovery.
Google Search Console
GSC's Indexing report shows you what's broken — in language that often hides what to actually do about it. This is the field-tested decoder: every error type, what causes it, and the specific fix that works.
Screaming Frog SEO Spider
You've crawled the site. You have 6,000 issues. You're not sure which 30 actually matter. This is the honest decision framework for when self-managed technical SEO becomes false economy.