How to find and fix a redirect chain
A redirect chain sends a request through more than one redirect before it reaches a terminal response. Write down the exact statuses and Location values; the final browser address hides the path that got you there.
General educationRead a chain one response at a time
Consider an old HTTP link whose host was normalized and whose article later moved. The first response upgrades the scheme, the second chooses www, and the third changes the page path. The browser may make four requests to reach one document. Each network round trip can add latency, especially on a slow connection; there is no universal fixed penalty per hop.
http://example.com/guide → 301
https://example.com/guide → 301
https://www.example.com/guide → 302
https://www.example.com/new-guide → 200Diagnose the path, not just the destination
Use a client that displays redirect headers or an actual checker. Begin with the precise link that users see, including its scheme, host, path, and query string. At each step record the status, Location, resolved absolute URL, and whether the query survives. Stop after a sensible hop limit. A loop repeats a URL or alternates between rules; it never arrives at a terminal destination.
Compare variants deliberately. HTTP to HTTPS, apex to www, and path migrations are often owned by different layers. A campaign service may add one more hop to the landing page. Check the final response too: 200 can be right for a page, but a download or intentional terminal status may differ. A 404 or 500 is not repaired merely because intermediate redirects succeeded.
| Observed symptom | Likely place to inspect |
|---|---|
| http → https → www | Scheme and canonical-host rules |
| /old → /older → /new | Legacy route map; update first rule to final target |
| A → B → A | Conflicting host or path rules |
| Final 404 | Target publication and path |
| Query parameters vanish | Redirect rule's URL construction |
Remove avoidable hops without abandoning old URLs
If /old points to /older and /older points to /new, change the /old rule to point directly to /new. Keep /older working for external links that still use it. Update internal navigation, ads you control, email templates, and QR source URLs for future printing; existing printed addresses still need their redirect.
Combine scheme and host normalization when the infrastructure supports it, but test certificates for every HTTPS hostname before assuming an HTTP redirect can rescue an HTTPS request. The TLS handshake happens before an HTTPS redirect response. A bad certificate cannot be fixed by a later Location header.
Before: /old → /older → /new
After: /old → /new and /older → /newVerify the repair from the original entry point
Repeat the trace for the exact old URL, not only the new destination. Check the final page, hostname, status, and any campaign tags. Keep a short set of representative variants for migrations. Some destinations reject automated clients, so confirm an apparent failure with a normal browser and server logs before classifying it as a broken link.
When the chain is outside your control
If a partner's link or ad platform inserts a hop, document what you can observe and shorten only the parts you control. Replacing the public URL may break printed or syndicated links. Ask the partner to revise its destination if the external step is avoidable, then compare traces before and after. A measured improvement is more useful than assuming every redirect has the same latency.