Redirect chain monitoring records every hop and verifies the final URL, final status, loop safety, protocol, status intent, and total latency. Short direct redirects are easier for users and crawlers, but Google does not document a rule that link equity stops after hop three or that every temporary redirect prevents signal consolidation.
Nothing was "down." Every hop returned a valid redirect. The site was up. The redirects were just wrong — and they'd been wrong since a CDN rule update six weeks after launch.
Redirect chains are the silent SEO and performance tax. They don't trigger uptime alerts. They don't show in application error rates. They accumulate invisibly as teams add HTTPS rules, www canonicalisation, trailing-slash policies, locale prefixes, and marketing UTM strippers — each innocent alone, catastrophic in sequence.
This guide covers why chains matter, how they break, how to monitor them externally, and what to alert on. By the end you'll have a redirect-monitoring spec that catches a five-hop chain the day it's introduced, not the quarter your traffic never recovers.
Why Redirect Chains Hurt
Search: slower, less reliable consolidation
Google treats redirects as a canonicalization signal and recommends redirecting directly to the final destination. Additional hops consume fetches, increase failure opportunities, and slow users. Avoid assigning a fixed percentage of "equity loss" or a universal hop cutoff that Google does not publish.
See Google's redirect and canonicalization guidance for current treatment of permanent and temporary redirects.
Performance: TTFB multiplication
Each hop is a full round trip. A chain of four redirects on a 150ms RTT adds 600ms before the browser receives the first byte of the final page — before HTML download, before TLS, before render. Mobile users on high-latency networks feel this as "the site is slow" even when the origin is fast.
See TTFB Monitoring: Server Response Time for the broader latency story.
Reliability: loops and broken terminals
An infinite redirect loop (A → B → A) causes browsers and bots to error after ~20 hops. A chain that ends in 404 or 500 is worse than no redirect — you lose both the old URL's equity and the user's session.
Operations: migration debt
Post-migration, redirect maps are "done" and never re-audited. New infrastructure layers redirects on top. Six months later nobody remembers the original map, and flattening the chain requires archaeology.
Types of Redirect Breakage
Long chains (> 3 hops)
http://example.com/page
→ 301 https://example.com/page
→ 301 https://www.example.com/page
→ 301 https://www.example.com/page/
→ 200 https://www.example.com/page/
Four hops where one rule would suffice: http://example.com/page → https://www.example.com/page/ (single 301).
Infinite loops
/page → /page/ → /page → /page/ ...
Often caused by conflicting trailing-slash and non-trailing-slash rules, or http/https and www/apex rules fighting each other.
302 where 301 was intended
Temporary redirects (302, 307) communicate that the source may return, while permanent redirects (301, 308) are the right intent for a permanent move. Search engines can still follow and pass signals through temporary redirects, but the wrong status makes migration intent ambiguous.
Monitor: final hop should be 301 or 308 for permanent moves; flag 302 on URLs in your migration manifest.
HTTPS downgrade chains
https://example.com/old → 301 http://example.com/new → 301 https://example.com/new
The middle http hop triggers mixed-content warnings, HSTS confusion, and SEO distrust. See SSL Certificate Expiration Monitoring for the TLS side.
www vs apex inconsistency
example.com and www.example.com can redirect to each other depending on rule order, producing a loop or avoidable chain.
Pick one canonical host. Assert every entry URL resolves to it in ≤ 1 redirect hop.
Query-string stripping
Marketing adds a redirect rule that strips ?utm_* by redirecting to the bare path — but the bare path redirects again for another reason. Two hops per email link.
Post-migration layer cake
Original migration: /old → /new. Six months later: CDN adds /new → /new/. Nine months later: locale prefix /new/ → /en/new/. The migration "301" still works — it's just three hops deep now.
How to Test Redirect Chains
Manual: curl with verbose
curl -sI -L --max-redirs 10 -o /dev/null -w '%{url_effective}\n%{num_redirects}\n' \
'https://example.com/old-path'
-L follows redirects. --max-redirs caps loops. Log each Location header in verbose mode (-v) to see the chain.
Scripted: record every hop
For monitoring, don't only check the final URL. Record:
| Hop | URL requested | Status | Location header | Time ms |
|---|---|---|---|---|
| 0 | http://example.com/old |
301 | https://example.com/old |
45 |
| 1 | https://example.com/old |
301 | https://www.example.com/old/ |
52 |
| 2 | https://www.example.com/old/ |
200 | — | 180 |
Store this chain. Alert when hop count > 2, when any hop is 302 on a permanent-migration URL, when final status != 200, or when any Location uses http://.
HEAD vs GET
Most redirects are visible with HEAD (faster, less bandwidth). Some servers behave differently on HEAD vs GET — spot-check critical URLs with GET quarterly.
Entry URL matrix
Don't test one URL. Test a matrix:
- Top 100 URLs by organic traffic (from Search Console export)
- Every URL in your migration manifest (old → expected new)
- Homepage variants:
http://,https://,www., apex, trailing slash - API docs, login, checkout — paths that often get special redirect rules
Multi-region
CDN edge rules differ by region. Run redirect tests from multiple probe locations. See Multi-Region Monitoring: Why Location Matters.
What to Assert in Production Monitoring
External monitoring should run on a schedule (daily for long-tail, hourly for top URLs) and on every deploy (full migration manifest).
| Check | Pass criteria |
|---|---|
| Hop count | Direct to final where possible; alert when a chain grows from its approved baseline |
| Final status | 200 (or 410 if intentionally removed) |
| No loops | Same URL not seen twice in chain |
| Permanent migration | 301 or 308 on migration URLs, not 302 |
| HTTPS throughout | No http:// in any Location after first hop |
| Canonical host | Final URL uses your chosen www or apex |
| Expected terminal | Old URL /blog/x final URL matches manifest /articles/x |
| Response time | Total redirect time < 500ms (p95) |
For migration manifests, store a CSV: old_url,expected_final_url,max_hops. The monitor follows redirects from old_url and compares url_effective to expected_final_url.
CDN and Edge Redirect Layers
Modern stacks have redirects at multiple layers:
- DNS / registrar — sometimes redirects apex
- CDN edge — Cloudflare, Fastly, CloudFront page rules
- Load balancer — ALB/NGINX rules
- Application — framework redirect helpers
- CMS — WordPress redirect plugins
A change at layer 2 doesn't show in application logs. External monitoring is the only way to see the effective chain users and bots experience.
After any CDN rule change, re-run the full redirect matrix. See CDN Monitoring: Edge Cache & Origin Uptime for the broader edge story.
SEO and Googlebot Behaviour
Googlebot follows redirects but has practical limits:
- Long chains add fetch latency and more failure points
- Temporary redirects communicate weaker permanence than 301/308
- Redirect loops waste crawl budget and produce "Redirect error" in Search Console
- Soft 404s via redirect-to-homepage are penalised — old product URL → homepage is not a valid migration
Pair redirect monitoring with JavaScript SEO Monitoring and Sitemap & robots.txt Monitoring for full crawl-path coverage.
Alerting Thresholds That Work
Critical (page)
- Infinite loop detected (same URL twice in chain, or max redirects exceeded)
- Migration URL final destination != expected (manifest mismatch)
- Final status 404 or 5xx on any top-100 organic URL
- HTTPS downgrade (
http://in Location) on production
High (notification)
- Hop count exceeds the approved per-route baseline
- 302 on URL documented as 301 migration
- Total redirect latency > 1s on top-20 URLs
- New hop appeared in chain since yesterday (chain grew)
Informational
- Hop count == 2 where 1 is possible (optimisation opportunity)
- Redirect chain changed but still passes (document intentional CDN change)
See HTTP Status Codes Explained for Monitoring and 5xx Server Error Rate Monitoring for status-code context.
See Alert Fatigue: Notifications That Get Acted On for low-noise alerting.
Post-Deploy and Migration Workflow
- Before migration — Export top URLs + build redirect manifest with expected finals
- Deploy redirects — Apply edge + app rules
- Immediately after — Run full matrix from external monitor; fail deploy if any manifest row fails
- Weekly for 8 weeks — Re-run matrix (chains grow as teams add rules)
- Quarterly forever — Audit top 500 URLs + homepage variants
See Website Migration Monitoring: Zero-Downtime Checklist for the full migration playbook.
Redirect Chain Monitoring Checklist
- Migration manifest: old_url → expected_final_url
- External monitor follows redirects with hop logging
- Top 100 organic URLs in monitor set
- Homepage variants (http/https/www/apex/slash) tested
- Max hop alert (≤ 2 canonical, ≤ 3 migration)
- 302-on-301-manifest alert
- Loop detection (duplicate URL in chain)
- HTTPS-only Location headers
- Post-deploy gate on full manifest
- Multi-region probes for CDN geo rules
- Quarterly chain flattening audit
- Paired with sitemap/robots and security-header checks (sibling posts)
How Webalert Helps With Redirect Chain Monitoring
Webalert's published feature and pricing pages do not list per-hop redirect assertions, expected final-URL rules, hop limits, redirect-map imports, or p95 calculations. Use a redirect-capable synthetic tool or deployment test for those controls.
Webalert can provide adjacent coverage:
- Separate HTTP checks — Monitor important old URLs and their intended destination URLs as independent checks.
- Content validation — Assert the destination contains a stable expected token rather than a soft-404 template.
- Response-time thresholds — Detect a check that exceeds its configured millisecond budget; keep redirect-chain percentiles in the redirect-capable tool.
- US, EU, and APAC checks — Catch regional user-visible failures in the published footprint.
- Alert channels — Email and Slack on all plans; SMS, webhooks, Discord, and Microsoft Teams on paid plans.
Keep the migration CSV and per-hop assertions in CI or the specialist monitor, then link both layers to the same incident runbook.
Summary
- Redirect chains multiply latency, dilute SEO equity, and accumulate invisibly after migrations and CDN changes.
- Common breakage: long chains, loops, 302 vs 301, HTTPS downgrades, www/apex fights, trailing-slash layer cake.
- Monitor externally: log every hop, assert hop count, final URL, final status, and HTTPS throughout.
- Test a matrix — top organic URLs, migration manifest, homepage variants — not a single URL.
- Alert on loops, manifest mismatches, hop count growth, and 302 on permanent URLs.
- Re-audit weekly post-migration, quarterly ongoing. CDN rule changes require immediate re-run.
- Pair with sitemap/robots monitoring and migration checklists for full deploy safety.
Redirects are infrastructure. Treat them like code: test on deploy, monitor in production, alert on drift.