How to Find and Fix Redirect Chains and Redirect Loops

A redirect is supposed to move a request from one URL to another. Problems begin when the destination redirects again, and again, or eventually points back to a URL already visited. The first pattern is a redirect chain. The second is a redirect loop.

Both are easy to miss because a browser may complete a short chain so quickly that the visitor only notices the final page. A loop is more obvious because the browser eventually stops and reports that the page redirected too many times. For crawlers, scripts, APIs, and performance monitoring, even a chain that technically works can create unnecessary work and latency.

What is a redirect chain?

A redirect chain contains multiple consecutive redirects before the request reaches a final non redirect response.

Example:

http://example.com/page → 301

https://www.example.com/page → 301

https://example.com/new-page → 200

The request requires two redirect hops before reaching the content. A better configuration would usually send the first URL directly to the final canonical URL.

Chains often grow gradually. A URL was redirected during one migration, then the destination was moved during another redesign, and nobody updated the original rule.

What is a redirect loop?

A loop occurs when redirect rules send the request back to an earlier URL in the sequence.

For example:

https://example.com/page → 301 → https://www.example.com/page

https://www.example.com/page → 301 → https://example.com/page

There is no final content response. The two hostname rules contradict each other, so the request can continue indefinitely until the client gives up.

Loops can involve more than two URLs, which makes them harder to spot manually.

Why redirect chains matter

A single necessary redirect is normal. Problems arise when additional hops provide no value.

Each hop requires another HTTP request and response before the final page can load. That adds latency. Chains also complicate crawling, analytics, debugging, caching, and migration monitoring.

Google advises avoiding redirect chains during site moves and recommends pointing to the final destination directly. Its general crawler can follow multiple hops, but relying on crawler limits is not a strategy. Other bots, APIs, social crawlers, monitoring systems, and client libraries may behave differently.

Common causes of redirect chains

HTTP and hostname normalization

A site might first redirect HTTP to HTTPS, then redirect www to non www, then apply a trailing slash rule. If these rules are configured independently, one request can pass through several hops.

A cleaner setup combines normalization so each unwanted variant goes directly to the preferred URL.

Repeated site migrations

Imagine /old-product was redirected to /products/item, and a later redesign moved that page to /shop/item. If the first rule is not updated, visitors from the oldest URL travel through both redirects.

CMS and server rules overlapping

A hosting platform, CDN, web server, CMS plugin, and application framework can all create redirects. Two layers may perform similar normalization without knowing about each other.

Internal links pointing to old URLs

Even when the redirect itself is valid, navigation may still point to the old address. Every click then creates a needless redirect before reaching the current page.

Common causes of redirect loops

Loops usually come from conflicting assumptions between layers.

One layer may force HTTPS while another believes the original request was HTTP because proxy headers are not being interpreted correctly. One rule may force www while another removes it. A locale rule may redirect / to /en/ while an application rule sends /en/ back to /.

Authentication flows can also loop when a login page redirects to an account page that immediately redirects back because the session is not recognized.

Cookies and cached redirects can make browser testing confusing, so an external checker is useful for seeing the server level path clearly.

How to trace the full redirect path

Start with the exact problematic URL and run it through a redirect checker. Record every hop in order:

1. requested URL
2. status code
3. Location target
4. next status code
5. final URL and response

A healthy path might be:

http://example.com/about → 301 → https://example.com/about → 200

A chain might be:

/old → 301 → /older-target → 301 → /new → 200

A loop will eventually repeat a URL or normalization pattern.

Inspect the Location header at each hop. It tells you what target the redirect response is instructing the client to request.

How to identify which system creates the redirect

The hardest part is often not seeing the chain but finding the responsible rule.

Check the layers that can redirect traffic:

• CDN or edge configuration
• hosting dashboard rules
• Apache or nginx configuration
• application framework redirects
• CMS redirect plugins
• ecommerce platform settings
• internationalization or locale logic
• authentication middleware

Response headers can sometimes reveal which layer generated a hop. Server logs can be even more useful when you control the infrastructure.

Change one layer at a time and retest the complete path. Fixing one hop can expose another rule that was previously hidden.

How to fix a redirect chain

The principle is simple: update older sources to point directly to the current final destination.

If the existing path is:

A → B → C

change the rule so A → C, while retaining B → C if requests to B still need to be handled.

Then update internal links, canonical tags, XML sitemaps, hreflang references, feeds, and other first party references so they point directly to C. That reduces dependence on redirects for routine navigation and crawling.

Do not blindly remove intermediate rules if external links or users may still request those URLs. The goal is direct routing, not breaking historical addresses.

How to fix a redirect loop

First, write out the complete loop so you can see the contradiction. Then identify which rule should own the canonical decision.

For a www loop, choose one preferred hostname and make every alternate form redirect toward it. Do not configure another layer to reverse that choice.

For proxy related HTTPS loops, verify that the application correctly understands the original scheme provided by the proxy or load balancer. For login loops, confirm session cookies, domain scope, secure cookie settings, and authentication conditions.

After changing the rule, test in an external checker and a clean browser session because browsers can cache redirects.

Redirect chains during SEO migrations

Migration audits should test old URLs in bulk and verify that each important source reaches the intended final page through a direct permanent redirect.

Also confirm that the final URL returns 200, is indexable, uses the expected canonical, and is not blocked by robots rules. A redirect can be technically correct while the destination itself is unsuitable for indexing.

Keep redirect mappings documented. Future developers can then update old mappings instead of stacking new redirects on top of historical ones.

A practical redirect audit checklist

For each important URL, verify:

• the first status code is expected
• the Location target is correct
• the path contains as few hops as practical
• no URL repeats
• permanent moves use an appropriate permanent status
• the final page returns the intended successful response
• internal links point directly to the final URL
• canonical and sitemap URLs use the final address

This turns a vague "too many redirects" problem into a sequence that can be tested and repaired one rule at a time.