Start here
Before You Fix It: What This Check Means
Redirect chains add unnecessary hops before the page people and crawlers actually need can load. In plain terms, this checks whether users and crawlers have to bounce through too many URL hops before the real page loads. Scavo compares the URL it requested with the final URL that actually loaded, then counts how many redirect hops happened in between.
Why this matters in practice: operational drift here often causes hard-to-debug regressions across environments.
How to use this result: treat this as directional evidence, not final truth. This reflects the scanned entry URL only; other campaign, locale, or legacy URLs may still have different redirect paths. First, confirm the issue in live output: trace the requested URL to the final landing URL and count how many hops happen on the way Then ship one controlled change: Trace the full path from the requested URL to the final destination using `curl -I -L` or browser/network tooling. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: This check asks how many URL jumps a visitor or crawler has to make before reaching the real page. One redirect is often normal. Two is a sign of drift. Three or more usually means old routing rules, host rules, or campaign paths are stacking on top of each other.
Redirects are sometimes necessary: HTTP to HTTPS, old URLs to new ones, non-www to www, or old campaign paths to their replacement. The problem is not “redirects exist.” The problem is when they form a chain. Every extra hop adds another request before the final page can even begin loading, and it makes crawling, debugging, and migration hygiene worse.
What Scavo checks (plain English)
Scavo compares the URL it requested with the final URL that actually loaded, then counts how many redirect hops happened in between.
This check is intentionally simple and practical:
- it looks at the scanned entry URL
- it records the final landing URL after redirects
- it counts the redirect hops needed to get there
How Scavo scores this check:
- Pass: no redirect was needed, or only one redirect hop was needed
- Warning: two redirect hops were needed before the final page loaded
- Fail: three or more redirect hops were needed
- Info: Scavo could not reliably determine the requested and final URL pair
Scavo is not judging whether the final destination is the right canonical URL for your whole site. It is judging whether the path to get there is cleaner than it needs to be.
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for redirect_chain_hygiene, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
redirect_chain_hygiene - Category:
TECHNICAL
Why fixing this matters
Every extra redirect hop delays the moment the browser can fetch the real document. That makes the page feel slower, especially on mobile or weak connections, and it also adds noise to debugging because the “real” route is no longer obvious.
For search and maintenance, redirect chains also create operational drag. They often appear after migrations, CMS rewrites, CDN changes, domain consolidations, or layered marketing redirects. Nobody intends to create a chain; it just happens when each system adds “one more” redirect and no one flattens the result.
Common reasons this check warns or fails
- HTTP redirects to HTTPS, then HTTPS redirects from non-www to www, then a trailing-slash rule redirects again.
- Old CMS URL rules still exist underneath newer CDN or edge redirects.
- Campaign or tracking URLs route through a legacy redirector before landing on the final page.
- Old product or blog URL migrations were never flattened after launch.
- Multiple teams own different redirect layers and each added a valid rule in isolation.
If you are not technical
- Ask your developer for the full redirect path, not just the final URL.
- Ask which system owns each hop: app, CDN, server config, CMS, or marketing redirect tool.
- Ask for the smallest safe change that removes intermediate hops without breaking old links.
- Re-run Scavo on the same entry URL and confirm the hop count drops.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Redirect Chain Hygiene (redirect_chain_hygiene). Please map the full redirect path from the scanned URL to the final destination, remove intermediate hops where possible, and share before/after proof of the final redirect count.If you are technical
- Trace the full path from the requested URL to the final destination using
curl -I -Lor browser/network tooling. - Decide the one canonical final URL for that entry path.
- Collapse stacked protocol, host, path, locale, and slash rules so the entry URL lands on the final destination in one hop where possible.
- Remove legacy redirect layers that are now redundant.
- Re-test old backlinks, campaign links, and migration paths so flattening the chain does not break coverage.
- Keep redirect ownership documented so future migrations do not recreate the chain.
How to verify
- Run
curl -I -L https://your-entry-urland note each hop. - Confirm the first requested URL reaches the intended final URL directly or in one deliberate hop.
- Test representative variants:
http,https,www, non-www, trailing slash, and known legacy URLs. - Re-run Scavo and confirm
redirect_chain_hygieneimproves on the same entry URL.
What this scan cannot confirm
- It only reflects the specific URL Scavo requested. Other campaigns, locales, or legacy routes may still have worse chains.
- It does not decide your canonical URL strategy; it measures the efficiency of getting to the chosen destination.
- It does not replace a full redirect-map review during large migrations.
Owner checklist
- [ ] Assign one owner for redirect policy across CDN, app, and CMS.
- [ ] Keep a documented canonical URL policy for protocol, host, slash, and locale handling.
- [ ] Review redirect chains after migrations, domain changes, or marketing tooling changes.
- [ ] Add smoke tests for top landing pages and legacy URL groups.
FAQ
Is one redirect always okay?
Usually yes. A single HTTP-to-HTTPS or host-normalization redirect is common and often acceptable.
Why is two redirects only a warning?
Because it is often survivable, but it is also usually fixable. It suggests layered routing that should be cleaned up before it grows.
Are redirect chains only a performance problem?
No. They also make crawl paths noisier, complicate migrations, and make routing bugs harder to diagnose.
Should we flatten old migration redirects too?
Yes, if the old URL still matters. Old paths should ideally jump straight to the final destination, not through several historical versions.
Sources
Need help flattening protocol, host, and legacy path rules into one redirect policy? Send support one example entry URL and the full hop chain you observed.
