Redirect Chain Analyzer

A redirect is a server response that tells the client to request a different URL, using a 3xx status code and a Location header. A redirect chain is what you get when that response leads to another redirect, and another, before a final page responds. The client has to make one request per hop.

http://example.com/old
 -> 301 https://example.com/old
 -> 301 https://example.com/new
 -> 200  (final response)

Here the original URL needs two redirects. The terms this analyzer uses are descriptive: 0 redirects is direct, 1 is a single redirect, 2 is a chain ("multiple redirects") and 3 or more is a long chain. These are labels for readability, not limits set by browsers or search engines, and a chain is not automatically an error.

A redirect loop is a sequence that returns to a URL it has already visited, so the client can never reach a final page. The analyzer reports the exact cycle:

https://example.com/a
 -> 301 https://example.com/b
 -> 301 https://example.com/a      (already visited: loop)

The same idea covers an HTTP and HTTPS loop (http://example.com to https://example.com and back), a www and non-www loop, and a trailing-slash loop. Browsers stop after a fixed number of redirects and show an error such as ERR_TOO_MANY_REDIRECTS. The tool only reports a loop when the same URL was actually observed again; if it reaches its limit of 20 redirect responses without a repeat, it says it stopped rather than claiming a loop.

A 301 Moved Permanently says the resource has moved for good: clients and caches may remember it and search engines generally treat the new URL as the replacement. A 302 Found is temporary: the original URL is expected to be used again, which suits campaigns, maintenance or testing.

Neither is universally better. The right status depends on what you intend. A permanent move served with a 302 may keep the old URL in circulation longer than intended, and a temporary redirect served with a 301 can be cached by browsers after you remove it, so it may keep sending people to the old destination. The analyzer flags only combinations that look unusual, such as a temporary redirect doing HTTP-to-HTTPS, and words them as "review recommended".

The difference that matters in practice is what happens to the request method and body when the client follows the redirect.

• 301 and 302: for historical reasons, clients may change a POST to a GET when following them.
• 303 See Other: the follow-up request is made with GET, which is the basis of the Post/Redirect/Get pattern for forms.
• 307 Temporary Redirect: like 302, but the method and body must be repeated unchanged.
• 308 Permanent Redirect: like 301, but the method and body must be repeated unchanged.

For ordinary page views (GET) these behave alike. Method preservation matters for APIs and form submissions, where silently turning a POST into a GET would drop the data. This tool only sends safe GET or HEAD requests, so it cannot show how POST, PUT, PATCH or DELETE behave for your URL. Some API clients also do not follow redirects automatically, so redirects on API paths (such as /api/v1/) are worth checking with the actual client. When a redirect changes the API version (for example v1 to v2), the analyzer notes a possible version migration but cannot judge compatibility.

• Additional requests: every hop is a full request and response before the real page starts.
• Latency: a hop to a different host can also need a new DNS lookup, connection and TLS handshake. The effect depends on the network and the number of hops.
• Crawling: crawlers follow only a limited number of hops, and each extra hop makes crawling and navigation less efficient.
• URL complexity: several rules each changing one part of the URL are harder to reason about than one rule that goes straight to the destination.
• Troubleshooting: long chains make it harder to see which rule is responsible, and they hide loops and dead-end destinations such as a 404.

This page makes no ranking claims: it describes what was observed and what is worth investigating.

1. Capture the whole chain, for example with curl -sIL https://example.com/old, and paste it into Manual Chain mode.
2. Decide the single canonical destination URL: its protocol, host (www or non-www), trailing-slash form and path.
3. Change the first redirect so it points directly to that destination, combining protocol, host and path changes into one hop.
4. Remove or update the intermediate rules that are no longer needed, keeping the ones that other legacy URLs still depend on.
5. Update internal links, sitemaps and canonical tags to the final URL so visitors and crawlers do not take the redirect at all.
6. Re-test with a fresh request. Browsers cache permanent redirects, so use a private window or curl to avoid seeing the old behavior.

If your redirects live in Apache configuration, the .htaccess Analyzer reviews what the rules appear to do, while this tool shows what a URL returns when it can be observed.

Start from the cycle the analyzer shows, then look for the rule that sends each URL to the next. Typical causes and fixes:

• HTTPS behind a proxy: the application sees plain HTTP because a load balancer or CDN terminates TLS, so it redirects to HTTPS forever. Make the rule check the forwarded protocol header, or set the application's "trust proxy" option.
• www and non-www rules pointing at each other: keep one direction only, in one place.
• Trailing slash added by one layer and removed by another: pick one form and make every layer agree.
• Catch-all redirect that matches its own destination: exclude the destination path from the rule.
• Cookie- or locale-dependent redirects: test again without cookies; a loop that only appears with a cookie points at the logic that sets it.

# Same URL, but the cause is a proxy hiding HTTPS from the app:
http://example.com/   -> 301 https://example.com/
https://example.com/  -> 301 http://example.com/    (app thinks it is on HTTP)

After changing the rules, test the cycle URLs again; the Apache-specific checks in the .htaccess Analyzer can help catch conflicting rules before you deploy.

Redirecting HTTP to HTTPS sends visitors and crawlers to the encrypted version of a page, normally with a 301 or 308. The usual mistake is doing it as a separate step from host canonicalization, which produces a two-hop chain (HTTP to HTTPS, then non-www to www). Combine them so the first redirect lands on the final URL.

# nginx: one redirect straight to the canonical HTTPS host
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

# Apache (.htaccess)
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Sites can also send an HSTS header so browsers go straight to HTTPS on later visits and skip the HTTP hop; see the HTTP Security Headers Analyzer and the guide to HSTS. A redirect from HTTPS back to HTTP is flagged for review rather than called a vulnerability, because context varies.

www.example.com and example.com are different hosts. Choosing one as the canonical host and redirecting the other to it avoids duplicate URLs. Neither choice is inherently better; what matters is consistency across redirects, internal links, sitemaps, canonical tags and TLS certificates.

The analyzer reports a hostname canonicalization redirect as information, and raises a Medium finding only when a chain adds www in one step and removes it in another (for example HTTP to www to non-www), because that suggests two rules disagree. A www and non-www loop is reported as a loop with its exact cycle.

/page and /page/ are technically different URLs, so many sites redirect one to the other. The analyzer never treats them as the same resource when comparing URLs, and it reports the normalization as information. It flags a trailing-slash redirect that is followed by another one, such as /docs to /docs/ to /docs/index.html, as a possible unnecessary hop. File-extension changes (/about.php to /about) are noted too, with the caveat that an internal rewrite cannot be told apart from an external redirect from the response alone.

What to inspect, without assuming a ranking effect:

• The final URL and status: ideally a 200 on the canonical HTTPS URL, not a 404 or server error.
• The number of hops before it, since additional redirects add extra requests and can make crawling and navigation less efficient.
• Whether permanent and temporary redirects are mixed in a way that does not match your intent.
• Whether old URLs redirect to a relevant destination rather than the homepage or a missing page.
• Whether protocol, host and trailing-slash normalization happen in one hop or several.
• Whether query parameters, including tracking parameters such as utm_source or gclid, are kept or dropped as you expect.

• HTTP to HTTPS: move traffic to the encrypted URL.
• www to non-www (or reverse): pick one canonical host.
• Old URL to new URL: keep links working after a page moves.
• Trailing-slash normalization: keep one form of each URL.
• Extension removal: /about.php to /about.
• Domain migration: old-domain.com to new-domain.com, often permanent.
• Status migration: moving from 302 to 301 (or 307 to 308) once a change becomes permanent.
• Temporary campaign redirect: a short-lived 302 to a landing page.
• API version redirect: /api/v1/ to /api/v2/, where client compatibility matters.
• Query to path: /product?id=10 to /products/10.

• Redirect loops, including HTTP/HTTPS, www/non-www and trailing-slash loops
• Redirect chains and too many redirects
• A temporary redirect where a permanent migration may be intended
• A permanent redirect left in place after temporary testing
• Old URLs redirected to a 404, or all to the homepage
• An unexpected cross-domain redirect
• Unnecessary canonicalization hops
• A downgrade from HTTPS to HTTP
• An inconsistent final host
• Query strings changed unexpectedly

The tool separates actual HTTP observations from static URL analysis and labels every result with its source. It runs entirely in your browser and never proxies URLs through a server, so it is bound by browser security rules:

• When the server allows cross-origin reads (CORS), it can show the final URL, final status, whether a redirect happened, accessible headers and total time. Browsers do not expose the status code or Location header of each redirect, so hop counts and per-hop timing are not available.
• When CORS blocks reading the response, it can still tell whether the first response was a redirect, and it analyzes the URL structure.
• HTTP URLs cannot be requested from an HTTPS page (mixed content), so the real HTTP-to-HTTPS hop needs curl and Manual Chain mode.
• For safety it refuses to inspect localhost, private networks, cloud metadata addresses and non-default ports; the checks follow the address ranges described in the CIDR Calculator. It never sends POST, PUT, PATCH or DELETE requests and never downloads response bodies.

Manual Chain mode analyzes output you paste (for example from curl) with full hop-by-hop detail, and is clearly labelled as manual analysis. The report can be downloaded as JSON, which you can pretty-print with the JSON Formatter. For more on why browsers restrict cross-origin responses, see CORS explained.