Why does a redirect loop keep coming back after it was fixed?

Where redirect rules actually live

On a typical modern site, redirects can be issued from at least five places: rules at the CDN or edge, rules on a load balancer or reverse proxy, the web server configuration (an htaccess file or a server block), the application framework itself (trailing slash normalization, locale routing, https enforcement), and CMS plugins that manage redirects through an admin screen. On top of those, individual pages can carry a meta refresh or a JavaScript redirect. Each layer decides independently, and each one usually has a different owner. Related: Auditing a Large Site Without Missing Pages

A loop happens when two of those layers disagree about the canonical form of a URL. One layer adds a trailing slash while another strips it. One forces the www host while another forces the bare domain. The most common one is an application behind a proxy that does not read the forwarded protocol header: the proxy terminates TLS and passes plain http to the app, the app sees http and redirects to https, the proxy delivers that as https, and the cycle repeats. Every hop looks correct to the layer that issued it.

Keep reading: When to Run a Full Link Audit, How a Site Crawl Actually Works, Reading a Redirect Chain Map. See how DeadLinkr helps you on demand link and redirect audits for seo.

Why the fix does not hold

The usual fix is local. A developer edits the server config or disables a plugin rule, tests in a browser, sees the page load, and closes the ticket. Then something restores the other side. A deployment copies a config file from the repository over the hotfix that was made directly on the server. A CMS plugin update re-registers its default rules on activation. A CDN configuration is synced from a template that still contains the old rule. A load balancer change drops the forwarded protocol header that the app was relying on. None of these look like redirect changes to the people making them.

Loops are also conditional, which is why they slip past testing. The cycle may only trigger on http rather than https, on the bare host rather than www, on paths with a trailing slash, on a specific country or device, or only when a certain cookie is absent. The developer who tests from a logged-in desktop browser with a warm cache may never hit the condition that a first-time visitor on a phone hits every time. Browsers also cache permanent redirects aggressively, so a fix can appear to work for the person who just cleared their cache while everyone else keeps looping. Related: Why does a link audit report errors that a normal browser never shows?

Diagnosing a loop properly

Start with a fetcher that shows every hop individually: the status code, the Location header, and the full response headers of each hop, not just the final result. Response headers usually reveal which layer produced each redirect, because CDNs, proxies, web servers, and application frameworks each leave distinct headers behind. Test the variants deliberately: http and https, www and bare host, with and without a trailing slash, with a mobile and a desktop user agent, and with no cookies at all. In a chain map, a loop shows as a hop whose destination is a URL that already appeared earlier in the chain. Related: When should a website use a 302 redirect instead of a 301?

Write down the exact request that reproduces the loop, including scheme, host, path, and headers, and hand that to whoever fixes it. Ask them to reproduce with a command line request rather than a browser, since browsers follow redirects silently and reuse cached ones. Note whether the cycle is two URLs bouncing between each other or a longer circuit through several rules; long circuits usually mean a redirect map was imported without checking for cycles, where an old path was later reused as a live destination.

Fixing the cause so it stays fixed

Pick one canonical form for the site (scheme, host, trailing slash policy) and enforce it at exactly one layer, ideally the edge or the web server, then remove the same enforcement everywhere else. Make sure the application trusts the proxy's forwarded headers so it never second-guesses the scheme. Put every redirect rule in version control, including the ones that live in CDN settings if the provider supports configuration as code, so a deployment cannot silently revert a fix. If marketing maintains a redirect spreadsheet, run a cycle check on it before each import.

After the change, purge the CDN cache and remember that visitors may still carry cached permanent redirects for a while; during a transition it is acceptable to use a temporary redirect until the new rules are confirmed. Then make a recrawl part of every deployment that touches routing, redirect rules, proxies, or plugins, and compare the chain map with the previous run. That turns the vague complaint that it came back into a diff you can see the same day it happens, with the responsible layer named in the headers. Related: Reading a Redirect Chain Map