Trace every 3xx hop a public URL goes through and see the status code, the next address in the Location header, and the final landing page our edge actually reached.
Pro tip: Collapse multi-hop chains to a single hop and swap 302/307 for 301 when the move is permanent to preserve link equity.
Paste a single address and the checker requests it from our Cloudflare edge with redirect following set to manual, so it can record every step instead of jumping straight to the end. For each hop it captures the HTTP status (301, 302, 303, 307 or 308), the Location header that points to the next address, and any change in protocol or host along the way. It keeps walking the chain until a non-redirect response arrives or it reaches its hop limit.
Because the trace is built from the responses received at request time, it mirrors what a browser or crawler would experience on that same request rather than a cached or historical version. A redirect rule added or removed minutes ago shows up immediately, which makes the tool handy right after you ship a change to your server config, CDN rules, or CMS.
A single hop, such as HTTP upgrading to HTTPS, is normal and harmless. Problems start when one redirect points to another, which points to a third before the page finally loads. Each extra hop adds a round trip of latency, can dilute the ranking signals passed along the way, and gives crawlers more chances to give up before reaching real content. The tool flags chains of more than three hops because that is the point where the cost becomes hard to justify.
The trace also makes a protocol downgrade obvious. If a request that started on HTTPS ends up on plain HTTP somewhere in the chain, that is a security and trust problem worth fixing, and the summary calls it out explicitly rather than burying it in the hop list.
Read the chain top to bottom. The ideal shape is at most one redirect leading to a 200 on HTTPS. If you see two or more hops, look for an intermediate URL you can skip by pointing the first redirect straight at the final destination. If you see a temporary code where the move is actually permanent, switch it to a 301 or 308 so engines treat the change as durable. If the final status is 4xx or 5xx, the chain ends at a broken page and the redirect itself is the least of your worries.
Only publicly reachable hosts can be traced; localhost, .local, .internal, and private or loopback IP addresses are refused on purpose. The request is sent with a clearly identified tool user agent, so some servers detect it as automated and answer with a block page or a challenge instead of the redirect they serve to ordinary browsers, meaning the chain you see can differ from a real visitor's. JavaScript redirects and HTML meta-refresh redirects fire only after the page renders, so they are not part of an HTTP trace and will not appear here. The tool also stops after a fixed number of hops rather than chasing an endless chain, so a pathological configuration is reported as too many redirects instead of hanging.
On data handling: the URL you submit is sent to our edge so it can perform the fetch, and the trace is generated for that request and returned to you. Avoid pasting URLs that embed private tokens or session identifiers in the query string.
Input: http://example.com
Output: Hop 1: 301 example.com -> https://example.com/ • Hop 2: 301 https://example.com/ -> https://www.example.com/ • Final: 200 at https://www.example.com/ • Redirects: 2, Final protocol: HTTPS
Two clean permanent hops; pointing the first straight at the www host would save a round trip.
Input: https://example.com/old-post
Output: Hop 1: 302 /old-post -> /new-post • Final: 200 at https://example.com/new-post • Note: review temporary redirects and use a permanent code when the move is permanent.
Input: https://example.com/login
Output: Hop 1: 302 https://example.com/login -> http://example.com/auth • Final: 200 at http://example.com/auth • Warning: the chain downgrades from HTTPS to HTTP.
Sending an authenticated path back to plain HTTP exposes the request and should be corrected.
No. It follows the chain until a normal response arrives or it reaches a fixed hop limit, then reports what it found, so the trace always terminates rather than hanging on a misconfigured server.
Some origins or security layers return a challenge to non-browser clients, and our request carries an identified tool user agent. In that case the response we receive is the block, not the redirect a normal visitor gets.
Yes. The exact status number is shown for every hop, which is the detail that decides whether ranking signals are passed along permanently or treated as temporary.
No. Only redirects sent in the HTTP response are traced. A client-side redirect that runs after the page loads is invisible to an HTTP-level check.
Yes. If a chain that began on HTTPS ends on plain HTTP, the summary flags the downgrade, and if it upgrades from HTTP to HTTPS it notes that as a good sign.
Every hop adds latency and another chance for a crawler to stop early. One hop is fine; the tool flags longer chains so you can collapse them toward a single redirect.
Our editorial and data-source notes explain how each check works and where estimates come from.