Redirect checker
Follow a URL hop by hop and see every status code it returns on the way, where it finally lands, and whether it loops.
Starting a trace sends this URL to our server and requests each HTTP redirect destination. Loading a URL here does not fetch it. Results do not prove a site is safe.
Chain
no trace yetReading the chain
Paste an old page URL and trace it. Compare the final address with the intended replacement, check the response code, and look for intermediate hops or loops. For example, /old-contact → /temporary-contact → /contact is a chain worth shortening to /old-contact → /contact.
Read the URL with the QR decoder first, then send it here with Check redirects. Start the trace to request the URL from our server. Check the final domain before choosing whether to open it. This traces HTTP redirects only: it does not execute page JavaScript, detect malware, or guarantee safety.
A healthy permanent move is one hop: a single 301 from the old address straight to the final one, then a 200. Anything longer is worth a look, and anything that repeats an address is a bug.
Two patterns account for most of what shows up here. The first is a chain built from reasonable decisions made years apart — an HTTP-to-HTTPS rule, then a restructure, then a rename — where each rule points at the next rule instead of at the end. The second is a 302 sitting inside what was meant to be a permanent migration, which tells Google to keep the old URL indexed and leaves the new one unable to rank.
Redirects pass full link equity, so hop count is not costing you ranking directly. What it costs is a round trip per hop on a slow connection, crawl budget, and a longer path in which any single broken link kills the whole route from the original backlink.
That is a loop, and the browser reports it as ERR_TOO_MANY_REDIRECTS after roughly twenty hops. It means two rules are each certain they are right and are undoing each other. The trace stops as soon as it detects the repeat rather than following it forever.
The usual pair is a protocol rule against a host rule: HTTP goes to HTTPS, and HTTPS goes back to the non-www host, which is served over HTTP. Or a CMS is configured for one canonical host while the server rewrites to the other.
Cloudflare SSL/TLS set to Flexible. Cloudflare fetches the origin over plain HTTP, the origin redirects to HTTPS, and Cloudflare hands that redirect back to the browser. Set the mode to Full or Full (Strict) and the loop disappears. This is the single most common cause of a loop that only appears once a site is proxied.
WordPress home and siteurl disagreeing with the server. If the options table says the site lives at the non-www host while the server rewrites everything to www, the two fight on every request. The fix is to make both agree, editing the options table directly if the admin screen is unreachable because of the loop itself.
A reverse proxy that does not forward the Host header. The backend receives an IP address, decides that is not its canonical hostname, and redirects to the name it expects — which arrives back through the proxy unchanged. Setting the Host header on the proxied request stops it.
SSL terminated twice. If the proxy already terminates TLS and the origin still has its own HTTPS-forcing server block, the origin keeps trying to upgrade a connection the proxy has already handled. Remove the redundant block on the origin.
Both hostnames serving the same pages, with no redirect between them and no canonical tag tying them together, is the version of this problem that produces no error at all. Nothing breaks; the site is simply available at two addresses and search engines have to pick one.
A 2026 study of 2,165 small business sites posted to r/TechSEO found around one in twenty doing exactly this, with a third of those concentrated on a single host. It is common precisely because nothing visibly fails.
Trace both forms. One should redirect to the other in a single hop, and the survivor should return 200 with a canonical pointing at itself.
Redirects, explained
9 entriesA redirection chain occurs when a URL points to another URL, which then points to another, and potentially more. These are often the result of multiple migrations, site restructures, or security implementations (like HTTP to HTTPS).
A 301 redirect is 'Permanent' and tells search engines to transfer the SEO value to the new URL. A 302 redirect is 'Temporary' and suggests search engines should keep the original URL indexed. Our tool detects both along with other status codes.
Long chains (more than 2-3 jumps) slow down page load times for users and can 'leak' SEO value. They also consume more 'crawl budget' from search engines like Google, which might result in some pages not being indexed.
Yes, our tool is designed to identify circular redirects where URL A points to B and B points back to A. When a loop is detected, the trace will stop and notify you of the potential infinite loop.
It's a response from a server to a browser's request. 200 means success, while 300-range codes indicate redirects. 404 means the page wasn't found, and 500-range codes indicate server-side errors.
The browser followed about twenty hops without reaching a 200 and gave up. Almost always two rules are undoing each other: something sends HTTP to HTTPS while something else sends HTTPS back to HTTP, or www to non-www against non-www to www. Trace the URL here and look for the same address appearing twice in the chain; the pair of rules that produced those two hops is your bug.
Check the SSL/TLS encryption mode. On Flexible, Cloudflare requests your origin over plain HTTP; if the origin then redirects HTTP to HTTPS, Cloudflare serves that redirect back to the browser, which asks again, and the loop never ends. Setting the mode to Full or Full (Strict) fixes it, because Cloudflare then speaks HTTPS to the origin and the redirect never fires.
The browser follows every hop before it paints anything, so you only ever see the final URL. Checking by hand means calling the URL, reading the Location header, calling that, and repeating until it stops. This tool does that loop for you and prints each step.
No. It follows HTTP-level redirects, the 3xx responses with a Location header. A meta refresh tag or a window.location assignment happens after the page has already returned 200, so the chain here ends at that 200. If the trace stops somewhere the browser clearly does not, a client-side redirect is the likely reason.
Return to your tools
When enabled, this browser remembers only the names of tools you complete. No URLs, text, QR contents or results are saved. Shortcuts open a fresh tool.