The migration was declared successful. Every old URL had a 301 to its new home. Search Console showed "Page with redirect" — expected. Three months later, organic traffic on the blog was still 25% below pre-migration baseline. An audit found that /blog/old-post now went: 301 → /blog/old-post/ → 301 → /articles/old-post → 302 → /articles/old-post/ → 200. Five hops, one temporary redirect, two trailing-slash normalisations layered on top of the original migration rule. Google had stopped passing full link equity after hop three. Users on mobile networks were timing out.
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
SEO: link equity dilution
Google's guidance has evolved, but the operational reality remains: each redirect hop adds latency to crawl, risks equity loss, and increases the chance Googlebot stops following (historically cited around 5 hops; in practice shorter chains rank and index faster).
A single clean 301 from old URL → new URL preserves most equity. A chain of three 301s does not behave like one 301 — crawlers may not attribute signals to the final URL as reliably.
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) do not consolidate link equity the way permanent redirects (301, 308) do. A migration that accidentally uses 302 leaves old URLs in the index indefinitely.
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 each redirect to the other depending on which URL you start from — a loop or a chain depending on rule order.
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 | ≤ 2 for canonical entry URLs; ≤ 3 for migration old URLs |
| 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 slow crawl rate for your site
- 302s may leave duplicate URLs indexed (old and new)
- 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 > 3 on any monitored URL
- 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 monitors the effective redirect path users and bots see:
- HTTP monitoring with redirect following — Request old URLs; follow up to N redirects; alert if final status != 200 or hop count exceeds threshold
- Status code per hop — Configure checks that fail on 302 when you expect 301, or on any 4xx/5xx in the chain
- Response time — Total time through redirect chain; alert when p95 exceeds budget
- Content validation on final URL — Assert the terminal page contains expected content (not soft-404 homepage)
- Multi-region checks — Same URL from EU, US, APAC — catch geo-specific CDN redirect rules
- Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
- 1-minute intervals — Detect a bad CDN rule within 60 seconds of propagation
Example configuration for a migration URL:
- URL:
https://example.com/blog/old-post(start URL) - Follow redirects: yes, max 5
- Expected final URL contains:
/articles/old-post - Max redirects: 2
- Fail if any hop status: 302 (when permanent move expected)
- Fail if final status: not 200
Run this check against every row in your migration CSV via Webalert's bulk URL import or API.
See features and pricing for details.
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.