How to find and fix redirect chains and loops

Read the chain in order

Run the original URL through RedirectPath and inspect each Location value. A chain might change the scheme, then the hostname, then the path. A loop might alternate between www and the bare domain, or between two versions of a trailing slash rule.

RedirectPath follows up to ten HTTP redirects. Reaching that limit does not by itself establish that a loop exists: a long chain can also exhaust the budget. Look for a repeated URL and review the reported reason the scan stopped.

Chain: /old-guide → /guides/old-name → /guides/new-name
Loop:  /account → /login → /account → …

Find the layer responsible for each hop

Map every unexpected hop to a place where you configure routing: a CDN, load balancer, web server or application. Two individually reasonable rules can conflict when they disagree about the preferred host or whether the incoming request already uses HTTPS.

Check trusted proxy and forwarded-scheme handling when the application sits behind TLS termination. Review the actual infrastructure configuration before changing it. The trace shows the symptom; it cannot tell you which internal layer generated the response.

Remove detours while preserving the intended journey

Where practical, point an old content URL to its final replacement and update internal links to use that destination. Keep intentional steps, such as authentication or a deliberate HTTPS upgrade, in the review. The objective is a reliable route to the right resource.

MDN describes how conflicting redirects can form loops. Use that model to check pairs of rules together, especially host normalization, language selection and application routes. RedirectPath does not execute JavaScript or follow meta refresh, so investigate browser-only navigation separately.

Reference: MDN: Redirect loops

Retest the variants that used to fail

Capture the original URL before editing a rule. Testing only the final destination will miss the problem that brought a user there.

1. Trace HTTP and HTTPS versions of the affected public URL.
2. Check the bare and www hostnames if both are supported.
3. Test a deep path and a harmless query parameter to catch accidental data loss.
4. Verify that the final response is expected and that the same URL no longer repeats.