Last updated
Why My Redirects Are Losing Me Traffic
Redirects lose traffic when a hop breaks before the crawler ever reaches a final URL. Each additional jump risks status confusion, header loss, or a crawler giving up, and only the last URL in the chain can inherit whatever ranking signal survived.
What a broken handoff actually costs you
A redirect is supposed to be invisible plumbing. A crawler or an inbound link asks for the old address, gets pointed at the new one, and ranking or citation signal is expected to follow without anyone noticing the handoff happened.
Traffic loss shows up when that handoff fails partway through: too many hops, a loop with no exit, a 302 sitting where a 301 belonged, or a migration that never mapped old URLs to real replacements. This diagnostic isolates which failure is yours before you touch server rules that were never the problem. Broader machine-access failures that have nothing to do with redirects, including render and parsing issues, live on why AI cannot read your website.
Six ways redirects bleed signal instead of passing it
These failures compound easily. A single URL can carry a three-hop chain and a stray 302 at the same time, so work through each cause independently before you assume the whole redirect strategy needs a rebuild.
Multi-hop redirect chains burn crawler patience before the destination
Chains form quietly. A URL gets redirected during one migration, then that redirect target gets redirected again during the next one, and nobody removes the first rule. Each hop a crawler follows spends part of a limited fetch allowance, the same crawl-budget pressure covered in why your site is not crawlable.
Crawlers that do finish a long chain still receive a weaker version of the original signal, because status codes, headers, and context can shift at every jump. Some crawlers stop before the last hop entirely, which means the final URL never gets credited with anything the old page earned.
What this looks like: A URL history shows /old-page/ to /interim-page/ to /new-page/, three hops deep before anything returns a 200.
A redirect loop points two URLs at each other forever
Loops usually form by accident. Two teams edit redirect rules independently, a template-level rule collides with a manual one added later, or a URL gets redirected to a page that itself was redirected back during a rollback nobody finished cleaning up.
A loop has no resolvable destination, so there is no URL left to inherit signal at all. Crawlers that detect the cycle abandon it, and both URLs involved tend to drop out of consideration until someone breaks the circle.
What this looks like: /page-a/ redirects to /page-b/, which redirects back to /page-a/, and neither one ever returns a 200.
A permanent move still answers with a temporary 302
A 302 tells crawlers the move is temporary and the original URL should stay the reference point. Many CMS and hosting tools default to a 302 because it is technically reversible, and teams treat that default as safe without ever revisiting it after launch.
When the move is actually permanent, that mismatch keeps signal anchored to a page you no longer want ranked. The fix is not another redirect. It is changing the status code the server returns for that rule.
What this looks like: curl -I on the old URL still returns 302 Found six months after a permanent migration, not 301 Moved Permanently.
Bulk migration redirects funnel every old URL to one homepage
Catch-all redirects are fast to ship during a deadline-pressured migration. One rule, one destination, every old path covered in a single line of config. The tradeoff is that the destination shares nothing topical with most of the URLs pointing at it.
Signal has nowhere relevant to attach when the target page is not about what the old page was about. A homepage cannot inherit the specific relevance a retired category or product page held, so that relevance simply disappears at the handoff.
What this looks like: Hundreds of retired product or blog URLs all 301 to the homepage instead of their closest real replacement.
A second migration stacks a new hop onto the first redirect
Redirect drift accumulates across successive migrations. The first move creates a clean rule. The second move redirects the first move’s destination instead of updating the original rule to point straight at the newest URL, and the chain grows by one hop nobody planned for.
Each additional migration without cleanup adds more distance between the original URL and wherever content actually lives now. Left alone, a site can end up with three-, four-, or five-hop chains built from years of redirects layered on redirects.
What this looks like: A 2024 replatform redirect never got updated when a 2025 CMS switch shipped, so old URLs now hop twice to arrive anywhere.
Sitemaps and internal links still point at the redirected URL, not the destination
Fixing the server-side redirect rule does not update the site’s own references to it. Sitemaps, navigation menus, footers, and in-content links frequently keep pointing at the pre-migration address long after the redirect itself is correct.
Every internal reference to an already-redirected URL wastes part of a crawl on a hop that adds no value, and it dilutes the internal link equity that should be reinforcing the final destination directly. Fix the rule, then fix what still points at it.
What this looks like: The XML sitemap and main navigation still list /old-page/, forcing every crawl and every click through an extra hop.
How a redirect decides what survives the trip
Redirect signal loss is not random. It follows the same sequence every time a crawler or a link meets an old URL, and that sequence explains why some hops survive clean and others do not.
Once you can name which step of the sequence is failing, the fix stops being guesswork. A chain problem, a loop problem, and a status-code problem each call for a different change, not the same generic “add a redirect” response. Redirect health sits with the rest of the crawl stack on SearchDock technical SEO, because hop behavior and fetch status get measured on the same URLs your crawl diagnostics already cover.
From old URL to signal-transfer decision
- 01A crawler or inbound link requests the old URL
- 02The server returns a 301, 302, or meta-refresh instruction
- 03The crawler follows each hop toward a final destination
- 04Every extra hop risks a dropped status, a stripped header, or a crawler that quits
- 05Only the last URL in the chain can inherit whatever signal survived the trip
| Redirect setup | What the crawler does | Signal transfer | Common cause |
|---|---|---|---|
| Single 301, one hop | Follows once and lands on a 200 | Full signal reaches the destination | Clean one-to-one URL move |
| 301 chain, three or more hops | Follows until patience or budget runs out | Signal thins with every added hop | Old redirects stacked under new ones |
| 302 used for a permanent move | Follows the hop but treats the origin as canonical | Signal often stays on the retired URL | Migration shipped a temporary redirect by default |
| Redirect loop, A back to B back to A | Follows in a circle and abandons both URLs | No signal transfers anywhere | Two independent rules point at each other |
| Bulk redirect to the homepage | Lands on an unrelated final URL | Signal has no relevant page to attach to | Migration skipped one-to-one mapping |
| Second migration layered on the first | Restarts the chain after the original hop resolved | Signal thins again with each re-platform | Old redirect rules were never retired |
Signs your redirects are the actual leak
Each item below is testable with a live fetch or a report you already have. Check the setup, not how confident the migration plan felt at launch.
SIGNS CHECKLIST
0 / 8 checked
How to stop the leak, hop by hop
Fix in order: trace every hop first, remove loops and temporary status codes, rebuild the migration map one to one, then update what still points at the old address.
Trace the hop count before you touch a rule
You cannot fix a chain you have not measured. Start with the exact hop count and where it breaks.
Trace every hop with a live curl loop
Result: You know the exact hop count and exactly where the chain breaks or loops.
- Run the tracer against every old URL still receiving links or traffic
- Record each hop's status code and Location header in order
- Flag any chain of three or more hops for immediate cleanup
- Re-run after each fix so the record never goes stale
#!/usr/bin/env bash
URL="https://www.example.com/old-page/"
HOPS=0
SEEN=""
while true; do
RESPONSE=$(curl -sI -A "Mozilla/5.0 (compatible; RedirectAudit/1.0)" "$URL")
STATUS=$(echo "$RESPONSE" | grep -i "^HTTP" | tail -1 | awk '{print $NF}')
LOCATION=$(echo "$RESPONSE" | grep -i "^location:" | tail -1 | awk '{print $NF}' | tr -d '\r')
HOPS=$((HOPS+1))
echo "Hop $HOPS: $STATUS $URL"
if [[ "$SEEN" == *"|$URL|"* ]]; then
echo "LOOP DETECTED: $URL was already visited"
break
fi
SEEN="$SEEN|$URL|"
if [[ "$STATUS" != 30* || -z "$LOCATION" ]]; then
echo "Final status: $STATUS at $URL"
break
fi
URL="$LOCATION"
if [[ $HOPS -gt 10 ]]; then
echo "EXCESSIVE CHAIN: stopped after 10 hops"
break
fi
done
Break loops by naming one final URL
Result: Both sides of a former loop point directly at the same resolvable destination.
- List every URL pair that redirects back to a previous hop in the trace
- Pick the URL that should be canonical for that content going forward
- Point every other rule involved straight at that URL, not at each other
- Confirm the fix with the same curl trace before moving on
Tracing tells you where the damage is. The next two steps stop new damage from forming.
Swap temporary signals for permanent ones
A wrong status code is a one-line fix with an outsized effect on whether signal transfers at all.
Rewrite 302s used for permanent moves as 301s
Result: Crawlers treat the new URL as the canonical destination instead of the retired one.
- Pull every redirect rule and note which status code each one returns
- Change any rule covering a genuinely permanent move from 302 to 301
- Leave true temporary redirects, like maintenance pages, on 302
- Re-fetch each changed URL to confirm the header actually updated
Build a one-to-one migration map, not a catch-all
Result: Every retired URL points at the specific page that actually replaced it.
- Match each old URL to its closest topical replacement, not the homepage
- Reserve a homepage or category redirect only for content with no real successor
- Store the map as a simple old-path, new-path file your team can audit
- Verify every row returns a 301 to the expected target after deploy
#!/usr/bin/env bash
# migration-map.csv format: old_path,new_path
while IFS=, read -r OLD NEW; do
CODE=$(curl -s -o /dev/null -w "%{http_code}" -A "Googlebot/2.1" "https://www.example.com${OLD}")
TARGET=$(curl -s -o /dev/null -w "%{redirect_url}" "https://www.example.com${OLD}")
if [[ "$CODE" != "301" ]]; then
echo "WRONG CODE: $OLD returned $CODE (expected 301)"
elif [[ "$TARGET" != *"$NEW"* ]]; then
echo "WRONG TARGET: $OLD sent to $TARGET, expected $NEW"
else
echo "OK: $OLD -> $NEW"
fi
done < migration-map.csv
Status codes and mapping fix what the server decides. The last step fixes what your own site still points at.
Point everything else at the final URL too
Internal references are the easiest signal to fix and the easiest to forget once the server-side rule looks correct.
Update sitemaps, navigation, and internal links to the destination
Result: Internal signals reinforce the final URL instead of re-triggering old hops.
- Regenerate the XML sitemap so it never lists an already-redirected URL
- Update navigation, footer, and in-content links to the final destination
- Point canonical tags at the destination URL, not the old address
- Spot-check the destination's structured data with the schema validator
While you are in the destination URL, confirm its structured data survived the move with the schema validator, since a template swap during migration can silently drop JSON-LD along with the old address.
Re-run the hop audit after the dust settles
Result: A new hop introduced by the next migration gets caught before it compounds.
- Schedule a recurring curl trace against every URL in the migration map
- Watch Search Console's redirect report for URLs that regress
- Treat any new multi-hop chain as a defect, not routine drift
- Compare traffic on migrated URLs before and after each fix batch
What a redirect leak does to your visibility score
VISIBILITY INSIGHT
Redirect chains quietly erode entity strength and citation share
An AI visibility score weighs mention frequency, citation share, factual accuracy, entity strength, and competitive share of voice across engines. Redirect chains, loops, and misused 302s mostly damage entity strength and citation share, because engines lose track of which URL is the current authority once a hop breaks the trail. SearchDock checks whether the final URL in a redirect chain is the one engines are actually citing. It also flags when mention or citation data still references a retired pre-migration address.
Score the final URL's AI visibilityA clean redirect is invisible to a visitor and everything to a crawler deciding what to trust next.
Related redirect and crawl diagnostics
These diagnostics share the same machine-access root and the same downstream symptoms a broken redirect can trigger.
Trace it, fix the status code, then fix what still points backward
Redirect signal loss follows a simple order: trace the hops, remove loops, use a 301 instead of a 302 for anything permanent, map old URLs to their real replacement, and point every remaining internal reference at the final address. None of that work matters if the destination itself is not picked up cleanly afterward, which is the separate failure covered in why new content is not picked up by AI. Re-run the hop trace after every future migration, because the next replatform is the most common way an already-fixed redirect grows a new hop.
Find out which redirects are still leaking your trafficFrequently asked questions
Why do redirects lose SEO signal?
Redirects lose signal when a crawler has to follow multiple hops, or when the redirect type tells engines the move is temporary. Each extra hop risks a dropped status code, a stripped header, or a crawler that stops following before reaching the final URL. Only that final URL can inherit whatever signal survived the trip.
What is the difference between a 301 and a 302 redirect?
A 301 tells crawlers the move is permanent, so ranking signal is expected to transfer to the new URL over time. A 302 tells crawlers the move is temporary, so the original URL is often kept as the reference point instead. Using a 302 for a permanent migration is one of the most common reasons signal stays stuck on a retired page.
How many redirect hops is too many?
Two hops already adds unnecessary risk, and three or more is where crawlers commonly start losing patience or dropping signal along the way. Every extra hop is another chance for a broken header, an unexpected status code, or a timeout before the destination loads. The safest setup points the old URL directly at the true final destination in a single hop.
Can a redirect loop cause a sudden traffic drop?
Yes, a redirect loop can cause a sudden drop because the crawler never reaches a page it can index or rank at all. Two URLs pointing at each other, or a rule that sends a URL back to itself after a template change, both create a loop with no resolvable destination. Traffic on the looped URL falls toward zero until the loop is broken.
Why did my traffic drop after a site migration?
Traffic usually drops after a migration when redirects were built in bulk instead of mapped one to one, sending old URLs to a generic homepage or category page instead of their true replacement. Signal has nowhere relevant to attach, so the ranking the old URL held does not transfer cleanly. A one-to-one map limits how much visibility is lost during the switch.
Should old URLs redirect to the homepage after a migration?
No, redirecting old URLs to the homepage should be a last resort, not the default choice for a migration. Signal transfers best when the old URL points at the specific page that replaced it, because topic and intent still match closely. Homepage catch-alls fit only pages with no real replacement, and even then some signal loss should be expected.
How long does it take for signal to return after fixing a redirect?
Recovery timing depends on how often the URL gets crawled, but many sites see partial signal return within a few weeks of a clean single-hop 301. Full recovery can take longer if the page lost meaningful authority while the chain, loop, or 302 was live. Re-testing the chain after each fix confirms the correction actually shipped before you wait on rankings to move.