Why does the live check only show one redirect, not the full chain?

Browser fetch() defaults to redirect: "follow" mode, which silently follows every hop and only exposes the final response to JavaScript - for a cross-origin request, intermediate 30x responses and their headers are completely invisible to the page, by design, for security reasons. This is true in every browser, not a limitation specific to this tool.

How do I see every hop in a redirect chain, like 301 then 302 then 200?

Run `curl -IL https://example.com` in a terminal - the -I flag fetches headers only and -L tells curl to follow redirects, printing a full status-line-plus-headers block for every hop it follows. Paste that output into the "paste a multi-hop trace" box and this tool will parse it into an ordered chain.

Is a 301 or 302 redirect better for SEO?

Use 301 (permanent) when a URL has moved for good, e.g. after a domain migration or URL restructure - search engines transfer ranking signals to the new URL and update their index to point there. Use 302 (temporary, or 307 for a stricter method-preserving version) only when the move is genuinely short-lived, like a maintenance redirect, since engines keep the original URL indexed and don't transfer signals as fully.

Why did fetching my URL fail entirely instead of showing a redirect?

Most likely CORS: the target site (or an intermediate hop) doesn't send permissive cross-origin headers, so the browser blocks the request before any response reaches this page - a network-level fetch failure, not a 4xx/5xx response. Paste a curl -IL trace instead, which runs from your terminal and isn't subject to browser CORS rules at all.

Redirect Checker - Trace 301/302 Chains & Final Destination

Overview

Introduction

Redirects are easy to set up wrong in ways that only show up much later: a redirect chain that hops through three URLs before landing, a 302 left in place long after a page moved for good, or a redirect loop that never resolves. Most of these are invisible from a normal browser tab, which just shows you the final page with no indication of what happened to get there.

This tool checks a URL two ways: a live fetch that reports whether a redirect happened and where it ended up, and a paste-in mode that parses a full `curl -IL` trace into every individual hop, status code, and Location header along the way.

What Is Redirect Checker?

A redirect chain inspector built around the reality that browsers hide intermediate redirect hops from JavaScript for cross-origin requests - so it offers both what a live browser fetch actually can see (the final destination and status) and a way to get the full picture from a terminal-based trace.

The live-fetch path answers "did this URL redirect, and where did it end up?" quickly. The paste path answers "show me every single hop, in order, with its status code and Location header" for a proper technical-SEO audit.

How Redirect Checker Works

For a live check, it calls the Fetch API against the URL and reads `response.redirected` and `response.url` after the browser has followed any redirects - this is the only redirect information a browser exposes to page JavaScript for a cross-origin target.

For a pasted trace, it scans the text for lines matching an HTTP status line pattern (e.g. "HTTP/1.1 301 Moved Permanently"), splits the text into one block per hop, and extracts each block's status code and Location header, producing an ordered list of every redirect the trace recorded.

When To Use Redirect Checker

After setting up a redirect (URL migration, domain change, trailing-slash normalization) to confirm it actually points where you intended and returns the status code you expect.

While auditing a site for redirect chains, since a URL that hops through two or three redirects before landing adds latency and can dilute the SEO signal transfer at each extra hop.

Often used alongside HTTP Header Checker and Meta Tag Checker.

Features

Advantages

Parses a real `curl -IL` trace into a structured, per-hop chain, something a browser's Network tab summarizes but doesn't hand you as clean structured data.
Is upfront about what a live browser check can and can't see, instead of silently reporting only the final hop as if that were the whole story.
Works on any URL via the trace-paste path, regardless of CORS restrictions that block the live-fetch path.

Limitations

The live-fetch path can only ever report the final destination for a cross-origin redirect; it cannot show intermediate hops no matter how the request is configured, because that data is not exposed to page JavaScript by the browser.
Trace parsing depends on the pasted text containing recognizable "HTTP/version status" lines; a trimmed-down or reformatted paste (e.g. only headers, no status lines) won't parse into a chain.

Examples

A pasted three-hop chain

Input

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

HTTP/1.1 302 Found
Location: https://example.com/new/

HTTP/1.1 200 OK
Content-Type: text/html

Output

3 hops found - 2 redirects before the final response.
1: 301 Moved Permanently -> https://example.com/new
2: 302 Found -> https://example.com/new/
3: 200 OK

The trace shows the URL bounces through a permanent redirect and then a temporary one before finally resolving - a candidate for collapsing into a single 301.

Best Practices & Notes

Best Practices

Collapse multi-hop redirect chains into a single direct redirect wherever possible - each extra hop adds a round trip of latency and, historically, a small amount of diluted ranking signal.
Use 301 for permanent moves and reserve 302/307 for genuinely temporary redirects, since search engines treat them differently for indexing and ranking-signal transfer.

Developer Notes

The trace parser splits on any line matching /^HTTP\/\d(?:\.\d)?\s+(\d{3})/i and treats every subsequent non-blank line up to the next status line as that hop's headers; it only reads the Location header from each block today, though the same block data would support surfacing Cache-Control or other per-hop headers later.

Redirect Checker Use Cases

Confirming a newly configured redirect points to the correct final URL with the correct status code
Tracing a suspected redirect chain to see exactly how many hops it takes and where each one points
Verifying a domain migration's redirects resolve to https:// on the new domain rather than looping back through http://

Common Mistakes

Leaving a 302 (or 307) in place for a redirect that's actually permanent, so search engines keep the old URL indexed instead of transferring signal to the new one.
Chaining redirects across a migration (old URL -> intermediate URL -> final URL) instead of updating the redirect to point straight at the final destination.

Tips

If a live check reports "no redirect" but you expected one, double-check the URL scheme (http:// vs https://) - some setups only redirect on the http:// entry point.

Redirect Checker