How to Actually Debug Redirect Chains (Not Fake Checkers)

Why Frontend Redirect Checkers Cannot Actually Check Redirects

Search "redirect checker" and you will find dozens of web pages that claim to trace any URL's redirect chain. Paste a link, click a button, and a pretty result appears. The catch: most of those tools cannot actually fetch the URL you typed. The browser will not let them, and so they fake the result.

This is not a conspiracy — it is the same-origin policy at work. Web browsers, by default, block JavaScript on example-checker.com from making an HTTP request to your-domain.com. The mechanism that allows cross-origin requests is CORS (Cross-Origin Resource Sharing), which requires the destination server to send an Access-Control-Allow-Origin header explicitly permitting the request. Random websites on the open internet do not send that header, so any frontend trying to call fetch('https://nytimes.com') from a third-party page receives a network error before a single byte is read.

To make matters worse, redirects compound the problem. Even if a CORS header allowed the initial request, the browser's fetch() API hides the redirect chain entirely. With redirect: 'follow' (the default), the response object only exposes the final URL. With redirect: 'manual', the response is opaque — status code zero, no headers visible — explicitly to prevent leaking information about the redirect target. There is no JavaScript API in the browser that returns the full chain of intermediate URLs and status codes for an arbitrary cross-origin URL. None.

So what do these "checker" web pages actually do? Three things, in roughly this order of frequency. First, the most common pattern: they show a hardcoded mock result that ignores your input entirely. Type any URL, get the same fake "URL → 301 → final destination, 1 hop" answer. Second, slightly less dishonest: they use a backend proxy that does the curl-style work server-side, but the proxy is rate-limited, often broken, and the demo on the homepage was hardcoded long ago. Third, the truly clever ones spin up a hidden iframe, navigate it, and try to read the resulting URL — which works for same-origin scenarios and fails silently otherwise, returning a result that looks plausible but reflects nothing about the chain.

The takeaway: if a redirect-checking tool runs entirely in your browser with no backend call, it is structurally incapable of telling you the truth about an arbitrary URL. The real tools live elsewhere.

Curl One-Liners That Actually Do Work

Curl is the universal HTTP client. It ships preinstalled on macOS and Linux and on every modern Windows install. Curl runs from your machine, makes the actual request, follows the actual redirects, and prints exactly what the server returned. There is no frontend lying in the middle.

The single most useful redirect-tracing command:

curl -ILs https://example.com

Decoded: -I sends a HEAD request (no body downloaded, just headers); -L follows redirects; -s suppresses progress noise. The output is one block of headers per hop in the chain, in order. You will see something like:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

HTTP/2 200
content-type: text/html; charset=utf-8
...

That is a two-hop chain: a 301 from the bare domain to the www subdomain, then a 200 from the final destination. Each blank-line-separated block is one HTTP response, and the Location: header tells you where the next hop pointed.

For richer detail with timings and the final URL printed clearly:

curl -ILso /dev/null -w "%{http_code} %{url_effective} %{time_total}s\n" https://example.com

The -w flag prints custom output after the request completes. %{http_code} is the final status, %{url_effective} is the URL that was actually fetched (after all redirects), and %{time_total} is wall-clock latency in seconds. Useful for seeing whether your three-hop redirect chain is costing you 80ms or 800ms.

To cap how many redirects curl will follow (useful for detecting loops):

curl -ILs --max-redirs 5 https://example.com

If the chain exceeds five hops, curl gives up with curl: (47) Maximum (5) redirects followed. That is a strong signal that something on your server is generating a loop or near-loop. Browsers cap this at around 20, and search engine crawlers tend to stop following at 5–10. If your chain hits the curl cap with the default of 50, real users have already abandoned.

To inspect a single hop without following — useful when you want to know exactly what one URL responds with, no chain expansion:

curl -I https://example.com

And on Windows, the same commands work in PowerShell, in Command Prompt with curl 7.55+ (default since Windows 10 1803), and in WSL with the standard Linux curl.

One trap to avoid: PowerShell aliases curl to Invoke-WebRequest, which has different flags entirely. Use curl.exe explicitly or remove the alias if you want to follow examples written for the real curl.

Browser DevTools Network Tab Inspection

When the URL you want to debug is one your browser is already loading — say a page on your own site — the Network tab in DevTools is the most accurate source of truth available. It captures every request the browser actually made, in order, with full status codes, headers, and timing.

To trace a redirect chain in Chrome, Edge, or Firefox: open DevTools (F12), switch to the Network tab, check the "Preserve log" box (critical — without it, redirects can clear the log), and load the URL. Each redirect appears as a separate row with its own status code (301, 302, 307) and the request that followed it appears below. Click any row to see the full request and response headers, including the Location header that pointed to the next hop.

The "Initiator" column tells you what triggered each request. For the first request in a chain, the initiator is "Other" (you typed a URL or clicked a link). Subsequent redirect-followups show the initiator as the previous request. This lets you visually walk up the chain and confirm exactly which URL pointed where.

For a deeper view, right-click any request and choose "Copy → Copy as cURL". This generates a curl command that reproduces the exact request the browser made — same headers, same cookies, same body. Paste it into a terminal and you can replay the request outside the browser context, which is invaluable for sharing reproducible bug reports.

The limitation of DevTools is that it only sees what your specific browser session experienced. If a CDN is serving you a cached redirect that is different from what an uncached request would receive, DevTools shows you the cache. Pair DevTools with a fresh curl to confirm that the redirect behavior is consistent.

Server-Side: Where Redirects Actually Live

Once you have identified an unwanted chain, you have to fix it at the source. That means editing the configuration of whatever layer is generating the redirect. The same chain pattern often appears across stacks; the fix differs by tool.

Apache mod_rewrite (.htaccess). The classic three-hop chain — bare domain → www → HTTPS — usually comes from rules that were added incrementally and not consolidated. The bad version looks like two separate rules:

RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

The first rule fires, redirects to http://www.example.com, then the second rule fires on the next request and redirects to https://www.example.com. Two hops where one would do. The fix consolidates them:

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

One rule, one hop, regardless of which permutation of www and HTTPS the visitor started with.

nginx rewrite. The equivalent fix in nginx uses a single server block as a catch-all that rewrites to the canonical form:

server {
  listen 80;
  listen 443 ssl;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

Everything that arrives at the bare domain on either port goes directly to https://www.example.com in one hop. The canonical server block listens on 443 with the www name and serves content normally.

Cloudflare Page Rules. When traffic flows through a CDN, you may have redirects defined at multiple layers — the origin server, Cloudflare Page Rules, Cloudflare Workers, and an edge configuration like Bulk Redirects. Each layer can transform the URL. A common chain emerges when Cloudflare upgrades HTTP to HTTPS (one hop) and the origin then redirects from non-www to www (second hop). The fix is to use a single Cloudflare Bulk Redirect or Worker that goes straight to the canonical destination, then disable the origin redirect entirely.

The audit method that catches this kind of cruft: pick five canonical entry points to your site (homepage, top blog post, top product page, a 404, an old marketing URL) and run curl -ILs on each. If any chain is longer than one hop, find the rule that introduced the extra step and consolidate.

Crawl Budget, Link Equity, and Why Chains Cost You Real Money

Redirects are not free. Every hop costs latency for users, costs crawl budget for search engines, and dilutes link equity along the way. Most of this is well documented but easy to underestimate.

Latency compounds. A 100ms redirect doubled or tripled is the difference between a fast site and a slow one in field measurements. Largest Contentful Paint cannot start until the redirect chain resolves. If your bare domain redirects to www, then HTTP to HTTPS, then your CMS strips a trailing slash, you have spent nearly half a second before the browser even requests the HTML.

Crawl budget is finite. Search engines allocate a quota of requests per site per day. A long redirect chain consumes that quota — Googlebot has to issue a request for each hop. On a small site this is invisible; on a 500,000-URL ecommerce catalog with permission-based price pages and category redirects, redirect chains can be the single largest consumer of crawl budget, starving fresh content of indexing capacity.

Link equity transfer is mostly preserved but never improved by chains. Google has stated since 2016 that 301 chains pass full PageRank, but the number of intermediate hops is bounded; after about 10 hops, the crawler stops following and the destination is treated as unreachable. Mixed chains (a 301 followed by a 302 followed by another 301) confuse the consolidation signal — the search engine may treat the URL after the 302 as the canonical, not the final destination.

Loops are deindexing risk. A loop where A redirects to B and B redirects to A makes the page unreachable. Browsers display an error after 20 redirects; crawlers stop earlier. Loops introduced during a botched migration can drop pages from the index within days, and recovery requires a fix plus crawl re-discovery, which can take weeks.

Recommended Real Services for Redirect Auditing

For one-off URL checks where you trust the result, three categories of tools genuinely work.

Server-backed online checkers. httpstatus.io is the most reliable browser-accessible tool. It runs the request server-side, follows the chain honestly, and displays each hop with status, headers, and timing. redirectchecker.com offers similar functionality. Both are useful for a quick sanity check from a different network than your own. Confirm the result with curl from your own machine if anything looks unexpected.

Crawl-aware SEO platforms. Ahrefs Site Audit, Screaming Frog SEO Spider (the free version handles up to 500 URLs), and Sitebulb crawl your entire site and report every redirect chain in one report. This is how you catch the second-order issues — the URL with one hop today that is going to become a three-hop chain after the next CMS update because two unrelated rules are about to interact.

Synthetic monitoring with real HTTP clients. If your team runs uptime monitoring (Pingdom, StatusCake, Uptrends), most platforms include redirect-chain checks as part of their HTTP monitor configuration. You set the expected final URL and the maximum acceptable hop count; the monitor alerts when reality drifts. This is the only way to catch redirect regressions before users do.

Try our Redirect Checker for a quick one-off trace, or read our complete guide to URL redirects for a deeper look at the redirect types themselves. For server-config debugging, our htaccess guide covers the common Apache patterns in detail.