How to Fix Redirect Chains and Loops

A page that redirects several times before loading can feel slow or unreliable, and it can make a site’s URL behavior harder to maintain. Each redirect sends the browser to another URL; a sequence of redirects before the final page is a redirect chain. Conflicting rules can instead send the browser around a loop until it gives up.

This guide explains how to trace redirects, identify their source, and simplify them without breaking canonical URLs or important page migrations. You’ll also learn how to check for redirect loops and verify a fix.

Key takeaways

A redirect chain is a series of HTTP redirects leading to a final URL; a redirect loop never reaches a final page.
Inspect the status code and Location header at every hop, not just the final page.
Fix the rule that creates each unnecessary hop, then point old URLs directly to the intended destination.
Check redirects at every layer: application, web server, CDN, and hosting platform.
Re-test representative URLs and update internal links, canonical tags, and sitemaps where appropriate.

What is a redirect chain?

A server uses a 3xx HTTP response to tell a client that a resource is available at another location. A Location header usually identifies the next URL. The client follows that instruction, receives another response, and may repeat the process.

For example:

http://example.com/page
  → https://example.com/page
  → https://www.example.com/page
  → https://www.example.com/page/
  → final page

This is a chain of three redirects. Any one of those URL changes might be intentional, but multiple steps can indicate that separate rules are handling protocol, hostname, and trailing-slash preferences independently.

A redirect loop occurs when the responses send the client back to a URL it has already visited, such as URL A redirecting to URL B while URL B redirects to URL A. Browsers and command-line clients stop after detecting a loop or reaching a redirect limit; the exact behavior can vary. The result is that the page does not load normally.

HTTP defines redirect response behavior, including status codes such as 301, 302, 307, and 308. For a permanent URL change, 301 and 308 are permanent redirect statuses; 302 and 307 are temporary. The method-handling behavior differs: 307 and 308 preserve the request method, while clients may change the method for 301 and 302 in some circumstances. Choose a status that matches the intended behavior, especially for requests other than ordinary page loads.

Advertisement 5349509459

Why redirects happen more than once

A chain often forms when multiple systems each add a redirect rule without accounting for the others. Common sources include:

Protocol rules: HTTP redirects to HTTPS.
Hostname rules: a bare domain redirects to a www hostname, or the reverse.
Path formatting: a URL without a trailing slash redirects to one with a slash, or vice versa.
Old URL migrations: a former page redirects to an intermediate URL that later moved again.
Application or CMS rules: plugins, routing code, or platform settings add their own redirects.
CDN or proxy settings: edge rules may conflict with the origin server’s rules.
Locale or device routing: a request is sent through one or more location or preference-based URLs.

A loop can have similar causes. For example, a proxy may receive an HTTPS request from a visitor but connect to the origin over HTTP. If the application does not recognize the original request as HTTPS, it may keep redirecting to HTTPS. A loop can also result from a rule that adds a slash while another removes it, or from two layers that prefer different hostnames.

How to fix redirect chains

1. Record every hop

Test the exact starting URL that users or search engines are requesting. A redirect checker can help you inspect a URL’s redirect path. You can also use curl from a terminal:

curl -sS -D - -o /dev/null -L --max-redirs 10 \
  -w '\nFinal URL: %{url_effective}\nRedirects: %{num_redirects}\nHTTP status: %{http_code}\n' \
  https://www.example.com/old-page

The response headers show the status and Location for each hop. The summary reports the final URL, number of redirects, and final status. Replace the example URL with a page you own or are authorized to test. This command makes a GET request while discarding response bodies; it does not test every browser condition, such as cookies, JavaScript navigation, or user-specific routing.

For a browser-based check, open the developer tools Network panel, enable the option to preserve the log if available, and reload the page. Review each document request and its response headers. Compare results in a private window or another browser when cookies or cached redirects may affect what you see.

2. Identify which layer creates each redirect

For each hop, note the requested URL, status code, Location value, and any relevant request conditions. Then check the systems that can modify the response:

CDN or edge redirect rules.
Load balancer or reverse proxy configuration.
Web server rules, such as Apache or Nginx configuration.
Application routes, CMS settings, or redirect plugins.
Browser-side navigation, if no HTTP redirect explains the change.

Configuration access and logging differ by hosting environment. If the response appears to come from an edge service, changing only the application may not remove the redirect.

3. Point old URLs directly to the final destination

If a page has moved more than once, update the existing redirect so the original URL goes directly to the current destination. For example, replace:

/old-page → /renamed-page → /current-page

with:

/old-page → /current-page
/renamed-page → /current-page

Keep each mapping specific enough to avoid sending unrelated pages to the wrong destination. A blanket redirect of every missing URL to the homepage can confuse visitors and conceal broken links.

4. Consolidate site-wide URL preferences

Choose one canonical format for protocol, hostname, and path style, then make the rules consistent. For example, decide whether the site uses HTTPS, www or a bare hostname, and trailing slashes. Where practical, enforce the full preferred URL in one coherent redirect rule rather than making visitors pass through a separate redirect for each preference.

Do not remove a redirect merely to reduce the hop count if it serves an active migration or required URL preference. Instead, make the necessary redirect lead directly to the correct final URL.

Advertisement 8972488872

5. Fix loops by finding the conflicting condition

Start with the two URLs that repeat in the chain and determine which system returns each response. Check for:

Contradictory slash or hostname rules.
Redirects that point to a URL covered by the reverse rule.
HTTPS detection that does not account for the proxy or load balancer setup.
Application rules that act on a URL already rewritten by the web server.
Cached redirect responses that persist after a configuration change.

When an application relies on forwarded protocol headers from a proxy, configure trust carefully. Accept such headers only from known, trusted proxies; do not treat arbitrary client-supplied forwarding headers as authoritative. A URL parser or a successful test of one URL does not establish that a proxy configuration is correct.

6. Verify the whole URL set

After changing rules, test the original URLs and their destinations. Check that:

Each changed URL reaches the intended final page without a loop.
Permanent and temporary status codes match the intended change.
The final page returns the expected status, usually 200 for a working page.
Query strings and required path segments are preserved where the application depends on them.
Internal links point directly to the preferred URL instead of relying on redirects.
Canonical tags and XML sitemaps use the preferred URL where applicable.

For a site migration, test a representative set of old and new paths, including pages with query parameters and unusual characters. Keep a record of the mappings so you can review or update them later.

Common mistakes

Checking only the final page: A working destination does not show how many redirects came before it. Inspect every response.
Using HEAD as the only test: Some servers handle HEAD differently from GET. If a result seems inconsistent, test with a GET request as well.
Changing only one configuration layer: A CDN, server, and application may all issue redirects. Trace the actual response path before editing rules.
Assuming every redirect is permanent: Select a status based on the intended duration and method behavior, not just convenience.
Redirecting removed pages to the homepage: Redirect to a relevant replacement when one exists; otherwise, return an appropriate not-found response rather than implying an unrelated page is equivalent.
Forgetting cached behavior: Browser or intermediary caches can make a fixed redirect appear to persist. Re-test with a clean session and allow for applicable cache lifetimes.
Testing only the homepage: Deep links, locale paths, trailing slashes, and query strings can follow different rules.

Conclusion

To fix redirect chains, capture the complete sequence, identify which layer issues each response, and update old URLs to reach their intended destination directly. For loops, locate the conflicting rules or request conditions and correct them at the layer responsible. Then test the affected URL patterns and update internal references so visitors and crawlers can use the preferred URLs without unnecessary detours.

How to Fix Redirect Chains: Causes, Checks, and Solutions