Skip to main content

Redirect Chain Tracer

What it does

The Redirect Chain Tracer follows every hop a URL takes — 301, 302, 307, 308, anywhere along the way — and reports the status code, response time, and Location header at each step. It flags protocol downgrades (HTTPS → HTTP), unexpectedly long chains (over two hops), and 302s where 301s would be more appropriate.

Common situations

A migration has just gone live and you want to verify the redirect map is doing what you intended — old URL hits 301, lands on new URL, returns 200. The tracer shows the full chain in one report, and any unexpected hops jump out immediately.

A page that should rank is showing as canonicalised to a different URL in Search Console. Trace the URL — sometimes a CDN, security plugin, or hosting platform has added unexpected hops (HTTP-to-HTTPS, www-to-non-www, trailing-slash normalisation) on top of your intended redirect.

A user reports a “this site keeps loading” experience that turns out to be a redirect loop. Trace the URL; if the chain hits the maximum without resolving, you have a loop. The tracer caps at ten hops to surface loops without hanging.

You are auditing why a competitor’s URL canonicalises differently than expected. Trace it; the chain reveals the hosting platform, redirect logic, and any subdomain canonicalisation they have in place.

A piece of internal documentation references an old URL and you need to know what it currently redirects to (if anything) before updating the doc. The tracer answers in seconds without you having to follow the chain manually in a browser.

What you need to know

A redirect chain is the sequence of HTTP redirects between an entered URL and its final destination. Each hop costs latency (one full request-response cycle) and SEO equity (the more hops, the less authority transfers to the destination). Google has been clear since the mid-2010s that chains over three hops are penalised, and even shorter chains leak some equity at every step.

The tracer captures four things per hop:

Status code. 301 is permanent, 302 is temporary, 307 and 308 are HTTP/1.1 successors with stricter method-preservation semantics. Most production redirects are 301; 302 is for genuinely temporary redirects (A/B tests, maintenance pages). The tracer flags 302s as a low-severity warning — they are correct in some cases but often used unintentionally where 301 would be appropriate.

Time. The TTFB-equivalent for each hop. Chains often appear to complete quickly because each hop is fast individually, but a four-hop chain at 200ms each is 800ms before the user sees content — meaningful for both UX and SEO performance signals.

URL and Location. The URL being requested at each hop, and the Location header that triggers the next hop. Following the Location chain reveals where redirects originate (server, CDN, edge worker, application).

Issues automatically detected:

  • Long chain (>2 hops): every additional hop costs SEO equity. Consolidate to direct redirects.
  • Protocol downgrade (HTTPS → HTTP): both a security and SEO regression. Always 301 to HTTPS, never the reverse.
  • 302 used: low-severity, in case the redirect is meant to be permanent.

What the tracer does NOT do: follow JavaScript redirects (window.location = ...), follow meta-refresh redirects (those are not technically HTTP redirects), or fetch fully-rendered DOM. The tracer reads HTTP status codes and Location headers — the standard mechanism. Pages that redirect via JavaScript will appear to terminate at the first 200 OK response, which is technically correct from an HTTP standpoint but may not match user experience.

The follow limit is 10 hops — beyond that, the tracer reports “too many redirects” rather than continuing. This catches loops without hanging.

Frequently asked questions

How many redirects is too many?

One is normal (HTTP-to-HTTPS), two is borderline acceptable, three or more is a problem. Google has explicitly said it penalises long chains, and every hop adds latency users feel.

What’s the difference between 301 and 302?

301 is permanent — bots transfer SEO equity, browsers cache aggressively. 302 is temporary — bots keep the old URL canonical and don’t transfer equity. Use 301 for permanent moves, 302 only for genuine temporary redirection.

Why is my redirect showing as a chain when I only set one redirect?

CDN, hosting platform, or security plugin layers add their own redirects (HTTP-to-HTTPS, www normalisation, trailing-slash handling) on top of yours. Each is a hop. The fix is to consolidate them at the highest layer (usually the CDN) or accept the chain.

What’s the difference between 301 and 308?

Both are permanent redirects, but 308 preserves the HTTP method — a POST to the original URL stays a POST after the redirect. 301 historically allowed browsers to convert the method to GET. For most web pages (GET requests), the difference is irrelevant; for APIs, 308 is more correct.

What’s a redirect loop?

URL A redirects to URL B which redirects back to URL A (or any cycle of length ≥ 2). The tracer caps at 10 hops and reports “too many redirects” if the chain doesn’t resolve. Real browsers usually cap at 20 and show an error.

Are JavaScript redirects detected?

No. JavaScript redirects (window.location = ...) and meta-refresh redirects don’t show up as HTTP-level chain entries. The tracer reports the page as resolved at the JS-redirecting page; the redirect happens client-side. Use a headless browser tool if JavaScript redirect tracing is what you need.

Does the tracer follow cross-origin redirects?

Yes. HTTP redirects work across domains, and the tracer follows them. Final URL is reported regardless of how many domain changes happen along the way.

How long do search engines take to honour 301s?

Days to weeks for individual URLs; weeks to months for site-wide migrations. Google has to recrawl the source URL, see the 301, recrawl the destination, and update its index. Submitting both URLs in Search Console accelerates this.

Common problems

Problem: A 301 was set up but the tracer shows 302.

Hosting platform, CDN, or security plugin is overriding the application-level 301. Common culprits: WordPress plugins that override redirect logic, Cloudflare Page Rules set to 302 by default, IIS rewrite rules with the wrong redirectType. Audit each layer to find where the 302 is being applied.

Problem: The chain shows two HTTPS hops where one should suffice.

Common when the SSL cert covers example.com but the canonical version is www.example.com. Hit example.com redirects to https://example.com (HTTP-to-HTTPS) which redirects to https://www.example.com (non-www-to-www). Two hops where one direct redirect (example.com → https://www.example.com) would suffice.

Problem: The destination URL is correct but Google is still indexing the source.

Google’s index lag — recrawling and processing 301s takes time. Verify in Search Console URL Inspection that Google has seen the 301; if it has but the index still shows the old URL, the next index update will reflect the change.

Problem: Protocol downgrade (HTTPS to HTTP) reported but you didn’t set one.

Usually a misconfigured .htaccess or Cloudflare Page Rule. Mixed-protocol redirects are almost always unintentional and should be fixed immediately — they’re a security regression and a small SEO penalty.

Problem: The tracer says “too many redirects” but the URL loads in a browser.

Browsers usually have a higher hop cap (20) than the tracer’s 10. If the chain genuinely exceeds 10 hops, even though it eventually resolves, it is too long. Consolidate.

Tips

  • Verify every redirect after deploy. Don’t assume the redirect rules you wrote are the redirects users actually see — CDN, plugin, and platform layers often add hops.
  • Consolidate redirects to one hop. If A goes to B which goes to C, change A to go directly to C.
  • Use 301 for permanent moves, 302 only for genuinely temporary cases. Wrong status code is a slow-motion SEO leak.
  • Check both protocols and both subdomains during audits — http://example.com, http://www.example.com, https://example.com, https://www.example.com. They should all resolve to one canonical URL.
  • Trace high-traffic URLs after major changes (deploys, plugin updates, CDN reconfiguration). Drift is the most common source of unexpected redirect issues.

Related tools in this suite

The Redirect Rules Generator is the source-side companion — once the tracer reveals an issue, the generator builds the corrected rule. The HTTP Headers Inspector is useful when investigating why a redirect is happening at all (security headers, CDN rules, etc.).

What this looks like at scale

For a single URL, the tracer is fine. For a migration involving thousands of URLs, the tracer becomes a verification tool used as part of a larger redirect-management workflow — generate the redirect map, deploy, trace representative URLs to verify, monitor for drift afterward. The WP Beacon Plugin tracks redirect chain length across an entire site over time, surfacing chains that grow unexpectedly.

Take it further

If a site has chronic redirect issues — chains that creep, plugins that override rules, drift between deploys — the underlying problem is usually that redirect logic is spread across too many layers. Talk through the architecture and we can scope what consolidation looks like.