Redirect chains and loops

Separate extra hops, loops and canonical disagreement

A chain might move from HTTP to HTTPS, then to the preferred host, then to a renamed path. Each redirect can be individually reasonable while their combination is avoidable. A loop returns to a previously requested address, perhaps through host or slash normalisation. The browser eventually gives up rather than showing the intended page.

Canonical disagreement is different. A page can load successfully but identify another URL as its canonical. That can complicate URL consolidation without creating a network loop. Likewise, a script that repeatedly navigates after a successful response may look like a redirect problem without appearing in a simple HTTP trace.

Classify the observed behaviour before proposing a fix. The practical objective is a stable, relevant destination reached with as few necessary redirects as possible. Counting hops without checking destination correctness can make an unrelated landing page look like an improvement. Start with the approved redirect map if the correct arrival page is uncertain.

Capture the complete request trace

Request the exact failing address, including scheme, hostname, case, path and query. Record each response status and Location value until a terminal page, error or repeated address appears. Resolve relative Location values against the address that returned them. Save the timestamp and test environment so the trace can be reproduced after configuration changes.

Use GET for representative checks, especially if a HEAD test disagrees with browser behaviour. Command-line requests reveal server responses; browser network tools reveal script navigation, service-worker effects and browser-side upgrades. Compare both when the symptoms differ. Avoid relying on a final-URL column that discards intermediate responses.

• Capture source and expected final destination.
• Record every hop with status, Location and response headers.
• Note cookies, authentication, browser history and cache state.
• Identify which delivery layer issued each response where possible.
• Preserve a failing trace and a successful comparison case.

Keep personal tokens and session identifiers out of shared diagnostic exports. A useful trace shows routing behaviour without exposing a customer's account state.

Find the layer that owns each decision

Redirects can originate in a CDN rule, load balancer, reverse proxy, web server, CMS plugin or application route. Browser HSTS behaviour can also upgrade HTTP before the server sees it. Map these layers in request order and ask which one owns protocol, preferred host, legacy paths and application-specific flows.

A common fault is duplicated ownership: the edge chooses a bare hostname while the application chooses www, or the proxy terminates TLS while the application believes the original request was HTTP. Changing a destination in the CMS cannot repair a loop created before the request reaches that CMS.

Compare edge and origin behaviour using an approved diagnostic method with the infrastructure owner. Do not remove security controls merely to make a crawler happy. Check forwarded scheme and host handling against trusted proxy configuration. For protocol-specific faults, use the HTTPS migration workflow to include certificates and mixed content in the investigation.

Test competing explanations before editing rules

If only returning browsers loop, compare a clean session and inspect cached responses or cookies. If only one hostname fails, inspect host normalisation and certificate coverage. If only query-bearing URLs fail, test whether parameters are repeatedly appended or translated. If a route loops only after login, treat it as an authentication flow until evidence shows otherwise.

Build a small matrix that changes one input at a time: scheme, host, slash, case and query. Keep the path constant while testing host rules, then keep the host constant while testing path rules. This isolates interactions that a large unstructured crawl may report as hundreds of separate failures.

For an apparent loop with no repeated HTTP address, look for script navigation or values that change on each hop. Repeated parameter addition can exceed browser limits without producing an identical URL. Preserve the exact values so the mechanism is visible. A generic “too many redirects” message does not identify the responsible rule.

Flatten historical routes without changing meaning

Once the desired destination is established, update old sources to point there directly where the architecture allows. If A redirects to B and B now redirects to C, change A to C while retaining B to C for existing references. Do not delete B simply because internal navigation no longer uses it.

Then update links you control so ordinary visitors reach C directly. This includes menus, article links, sitemap entries and campaign templates. A shorter redirect map alone does not remove chains from journeys when pages still link to obsolete variants. Prioritise widely used references and systemic template faults over isolated low-use historical paths.

Preserve meaningful queries and language selection. A blanket rule that discards them can shorten the trace while showing the wrong content. Keep login, payment and upload routes outside broad normalisation changes until their owners validate the method and state requirements. Redirect optimisation should not silently alter application semantics.

Illustrative example: a proxy and application disagree

Illustrative example: a request for an old HTTP product URL reaches a proxy that upgrades it to HTTPS. The application receives an internal HTTP connection and issues another redirect to the same public HTTPS address. Every subsequent request follows the same pattern, so no product page loads.

One hypothesis is a bad legacy product mapping; another is incorrect original-scheme handling behind TLS termination. Test a current product URL on the public HTTPS host. If it also repeats, the legacy map becomes a weaker explanation. Inspect the proxy headers and the application's trusted-proxy settings with engineering.

The repair makes the application recognise the original secure request through the trusted infrastructure path. Legacy mapping can then send the old URL to the final product page. Acceptance includes current pages, old paths and direct public HTTPS requests. This is an illustrative fault model, not a report of an incident or a measured speed improvement.

Specify repair acceptance at the boundary

Require every known failing source to reach its approved terminal page without revisiting an address. Require host and protocol variants to converge consistently, and require current internal links to use that final form. For legacy permanent moves, check the agreed permanent response; temporary application flows need their own expectations.

Include representative GET requests, meaningful queries, encoded paths and a genuine not-found route. The not-found route should remain an error rather than being pulled into a catch-all redirect. Confirm that the destination's canonical and substantive content match the intended outcome. Add a browser case if scripts or authentication were involved in the original failure.

Automate the failing cases as regression fixtures using the redirect validation approach. Record the layer and rule responsible for each expected behaviour. A future CDN or CMS replacement then has a concrete contract to preserve, rather than an unexplained list of historical exceptions.

Recognise false positives and reversible repair risks

A browser may show an internal HSTS upgrade that is not a server-issued redirect. A crawler may stop because of its configured hop limit rather than a genuine cycle. Geo-routing and consent flows can vary by state. Validate the relevant public journey before assigning all extra navigation to the same technical defect.

Extra hops add requests and failure opportunities, but hop count alone cannot quantify a ranking effect. Measure actual latency and affected journeys if performance is the concern. Do not claim a fixed amount of search value is lost per redirect. A direct wrong destination is still a worse user outcome than a correct route with an avoidable intermediate stop.

Version rules before changes and make rollback specific. Removing a catch-all can expose previously hidden missing routes; reversing protocol enforcement can conflict with browser security policy. Cached permanent redirects may outlive the deployment change. Retest from a clean client and the public edge before declaring the rollback complete. The HTTP status guide helps interpret terminal responses after the routing fault is removed.