How One Site Recovered Traffic by Collapsing 400 Redirect Chains

Most founders and operators who've dealt with a traffic drop after a site migration assume the culprit is something visible - a penalty, a content gap, a ranking shift. The actual cause is usually quieter and more mechanical: redirect chains. A single URL that hops through three or four intermediate addresses before reaching its destination. Multiply that across hundreds of pages and you're bleeding crawl budget, passing diluted link equity, and slowing load times for real users. One site we looked at had 400 redirects set up over three years of migrations. Sixty percent of them chained three hops or deeper. Collapsing them took one working day. Traffic recovered within six weeks.

This is a one-day fix, not a project. You need Screaming Frog (the free tier handles up to 500 URLs), access to your server config or redirect rules file, and Google Search Console or Analytics for traffic data. If your site has fewer than 500 redirects, you can run this entire loop without paying for anything.

Step 1: Crawl Your Site and Map Every Redirect

You're building a complete inventory of every redirect on your domain - not just the ones you remember setting up. Most sites have redirects from three or four separate migrations, platform changes, and URL restructures. Nobody has a clean list. The crawl produces one.

Open Screaming Frog and set it to crawl your domain. Under Configuration, select Spider, then check "Follow Redirects" and "Store Redirect Chains." Once the crawl finishes, go to Reports and export the Redirect Chains report. The fields you need are: Source URL, Destination URL, Status Code, Chain Length, and Redirect Type. Export to CSV.

If you prefer command line, a curl-based crawl can pull the same data for a sample of URLs:

curl -sI -L --max-redirs 10 -w "%{url_effective} | %{http_code} | %{num_redirects}\n" -o /dev/null [YOUR_DOMAIN]/[SOURCE_PATH]

Run that against a batch of URLs using a simple shell loop if you have a list to check. For a full site inventory, Screaming Frog is faster.

Here is what the raw CSV output looks like for a site in the middle of this problem:

Source URL,Destination URL,Status Code,Chain Length
https://[YOUR_DOMAIN]/old-product,https://[YOUR_DOMAIN]/new-product,301,1
https://[YOUR_DOMAIN]/new-product,https://[YOUR_DOMAIN]/category/new-product,301,2
https://[YOUR_DOMAIN]/category/new-product,https://[YOUR_DOMAIN]/shop/category/new-product,301,3
https://[YOUR_DOMAIN]/old-blog-post,https://[YOUR_DOMAIN]/blog/post,301,1
https://[YOUR_DOMAIN]/product-2,https://[YOUR_DOMAIN]/shop/product-2,301,1

The first three rows are one chain. The crawl shows them as separate rows, which is why it's easy to miss - you see three redirects, not one three-hop problem.

What you get back: a spreadsheet with every redirect on your domain, its final destination, its chain length, and its HTTP status code.

What to do with it:

• Sort by Chain Length descending. Anything with a chain length of 2 or higher is a candidate for collapse.

• Filter for Status Code 301 and 302 only. Ignore 200s and 404s for now - those are separate problems.

• Flag chains with length 4 or higher as immediate priorities. These are costing you the most crawl budget per URL.

• Cross-reference source URLs against your traffic data before doing anything. A chain nobody visits is low priority; a chain on a URL that gets 500 visits a month is not.

What this step will not tell you: which redirects exist in your CMS or app layer rather than your server config. Some platforms manage redirects internally. If your crawl shows fewer redirects than you expect, check your CMS redirect manager as a separate source.

Step 2: Identify Chains and Measure Traffic Loss

A single redirect is safe. A chain - where one redirect points to another redirect instead of a final destination - is where the damage happens. Google's crawlers follow redirect chains, but each additional hop adds latency, increases the chance of a crawl timeout, and can dilute the link equity passing through. The goal here is to separate single redirects from chains and then rank the chains by how much traffic they're actually affecting.

Your input is the CSV from Step 1 plus traffic data from Google Analytics or your server logs. Pull sessions or pageviews for each source URL over the last 90 days. If you're using Google Analytics 4 (GA4), export a pages report filtered to the source URLs in your redirect inventory. If you have server log access, grep for the source URLs directly.

To flag chains automatically, run this logic in a spreadsheet or a simple script:

import pandas as pd

df = pd.read_csv('[YOUR_CRAWL_EXPORT].csv')

# Flag any row where Destination URL also appears as a Source URL
destinations = set(df['Source URL'])
df['Is Chain'] = df['Destination URL'].apply(lambda x: x in destinations)

# Filter to chains only
chains = df[df['Is Chain'] == True]
print(chains[['Source URL', 'Destination URL', 'Chain Length']].sort_values('Chain Length', ascending=False))

That script reads your crawl export and flags every redirect whose destination is itself a source URL elsewhere in the file - meaning it points to another redirect, not a final page.

Here is what a three-hop chain looks like in practice: a user (or Googlebot) requests /old-product. The server sends a 301 to /new-product. That URL sends a 301 to /category/new-product. That URL sends a 301 to /shop/category/new-product. The browser or crawler has now made four requests to load one page. If the original URL had inbound links pointing to it, the equity passes through each hop with some degradation. If your server is under load, a chain like this under volume adds up.

What you get back: a ranked list of redirect chains sorted by traffic volume at the source URL and by chain depth.

What to do with it:

• Prioritize chains where the source URL has measurable traffic. Zero-traffic chains are still worth fixing, but they are not urgent.

• Flag any chains that cross domains. An old domain redirecting through a subdomain before hitting the current domain is a common pattern after acquisitions or rebrands.

• Note any chains that include tracking parameters or UTM strings in the middle hops. These may be intentional - mark them separately before you start collapsing.

• Check whether any chain destination URLs are themselves returning non-200 status codes. If the final destination is a 404, the chain is hiding a broken page problem, not just a redirect problem.

What this step will not tell you: whether a chain is intentional. Some redirect chains are built on purpose - URL shorteners, affiliate tracking links, A/B testing tools. The analysis can't distinguish intent. You have to check that manually before collapsing anything.

Step 3: Collapse Chains to Direct Redirects

Collapsing a chain means rewriting every intermediate redirect to point straight to the final destination. You're cutting out the middle hops. The source URL stays the same. The destination URL becomes the actual final page. Every rule in between gets either deleted or rewritten to point to the end target directly.

This is a bulk find-and-replace operation in your redirect config file (typically .htaccess for Apache, or your Nginx config). Here is what before and after looks like for a four-hop chain:

# BEFORE - four separate redirect rules creating a chain
Redirect 301 [SOURCE_URL] [INTERMEDIATE_URL_1]
Redirect 301 [INTERMEDIATE_URL_1] [INTERMEDIATE_URL_2]
Redirect 301 [INTERMEDIATE_URL_2] [INTERMEDIATE_URL_3]
Redirect 301 [INTERMEDIATE_URL_3] [FINAL_DESTINATION_URL]

# AFTER - one direct redirect, same source, same final destination
Redirect 301 [SOURCE_URL] [FINAL_DESTINATION_URL]

Delete the three intermediate rules. Keep only the rule that maps the original source directly to the final URL. If other pages link to the intermediate URLs, those links will now also need redirects - which is exactly what you set up in the cleaned config.

For a realistic scenario: a site that migrated from an old domain to a subdomain to a restructured category path to a final product URL. Four rules in the config. After collapse, one rule maps the old domain URL directly to the current product page URL. The subdomain no longer needs to exist in the chain. If the subdomain is still live, you add a direct redirect from it to the final URL as well.

For Nginx, the equivalent looks like this:

# BEFORE
location = [SOURCE_PATH] { return 301 [INTERMEDIATE_PATH_1]; }
location = [INTERMEDIATE_PATH_1] { return 301 [INTERMEDIATE_PATH_2]; }
location = [INTERMEDIATE_PATH_2] { return 301 [FINAL_DESTINATION_PATH]; }

# AFTER
location = [SOURCE_PATH] { return 301 [FINAL_DESTINATION_PATH]; }

What you get back: a cleaned redirect config file with every chain reduced to a single direct rule.

What to do with it:

• Test on staging before touching production. Deploy the new config to a staging environment and run your validation tool against it before anything goes live.

• Deploy in batches ordered by traffic volume. Start with your highest-traffic chains. If something breaks, you want to catch it fast on URLs people are actually visiting.

• Keep a copy of the old config. If you need to roll back, you want the original rules available without reconstructing them from memory.

• After deployment, update any internal links that still point to old intermediate URLs. Redirects mask the problem but don't fix the underlying link structure.

What this step will not tell you: whether your CMS is generating new redirect rules that will recreate the chains. Some platforms auto-generate redirects when you change slugs. If your CMS has a redirect manager, clear the intermediate rules there too, not just in the server config.

Step 4: Validate and Monitor for Regressions

Collapsed redirects can fail in two ways: the destination no longer exists, or the rewrite creates a loop. Both are fixable, but only if you catch them before Google does. Validation runs after every deployment, not once at the end of the project.

Your input is the new redirect config and a list of at least 50 source URLs from your highest-traffic chains. Run each one through a redirect checker. The quickest method is curl with the -L flag, which follows all redirects and reports the final destination and status code:

curl -o /dev/null -s -w "Final URL: %{url_effective}\nHTTP Status: %{http_code}\nNum Redirects: %{num_redirects}\nTotal Time: %{time_total}s\n" -L --max-redirs 10 https://[YOUR_DOMAIN]/[SOURCE_PATH]

Run that against every URL in your high-traffic chain list. What you're checking: does the final URL match the expected destination, is the HTTP status 200, and is the number of redirects 1 (not 0, not 3).

A realistic scenario after collapsing 400 redirects: you test 100. One returns a 404 because the final destination page was deleted after you built your chain map - the destination had changed between your crawl and your deployment. Another returns a loop: source redirects to destination, destination redirects back to source, curl hits the --max-redirs limit. Both of these get caught in validation, not in production.

Screaming Frog's redirect checker can run bulk validation against a list of URLs and export results as a CSV. That's the fastest way to validate 400 URLs without scripting.

What you get back: a validation report showing final destination URL, HTTP status, redirect count, and response time for each source URL.

What to do with it:

• Fix any 404 destinations immediately. Either restore the target page or update the redirect to point to the closest live equivalent.

• Fix any loops before they go anywhere near production. A