Redirect Chain Checker
Trace every 301 and 302 hop with per-hop latency, spot loops and chains, and see where the URL really lands. Free, no signup.
When a URL moves, the hops between the old address and the page people actually land on decide how long they wait and how much ranking signal survives the trip. This redirect chain checker walks that path one hop at a time and shows you the status code and target of each, so you can confirm a 301 resolves cleanly or flatten a chain that has quietly grown through a few years of migrations. Paste a single URL to check whether a 301 is set up the way you expect and see exactly where it points.
Not sure whether a hop should be a permanent 301 or a temporary 302? The guide on 301 vs 302 redirects covers when each one is right. For the messier cases, read redirect chains and loops on how to find them and flatten them. Moving a whole list of old URLs at once? The Redirect Mapper traces them in bulk.
Why redirect chains hurt SEO
Three separate costs stack up on every chained URL. First, crawl budget: each hop is a full request a crawler spends on plumbing instead of content, and on a large site those wasted requests come out of the pages that actually need crawling. Second, link equity: a single 301 passes nearly all ranking signal, but every extra transfer is another place a little leaks away. Third, latency: the visitor's browser walks the same chain you see in the trace above, hop by hop, before the real page even begins to load — the summed number the checker shows is pure waiting that flattening gives back.
| Chain length | Severity | What it means |
|---|---|---|
| 1 hop | OK | A clean redirect — this is what every moved URL should look like. |
| 2–3 hops | Warn | Leaking latency and signal on every visit. Point the first URL at the final destination. |
| 4+ hops or a loop | High | Crawlers may stop following before the page; Googlebot gives up entirely at 10. |
Four chain patterns to look for
Almost every long chain we trace is one of the same few shapes. If you recognize yours below, the fix is usually one rewritten rule.
The migration stack
Every site move adds one hop and nobody deletes the old ones: old-domain → new-domain → new-structure → HTTPS. Three migrations later a request crosses four servers before content appears. Flatten by pointing every historical URL straight at today's final address.
The trailing-slash flip
The server redirects /page to /page/ (or the reverse), and another rule redirects that to somewhere else. The slash hop looks free but doubles the chain on every affected URL. Make internal links use the canonical form so the flip never fires.
The silent 302
A temporary redirect set up during a launch that nobody switched to 301. Search engines keep the old URL indexed and hold ranking signals there, waiting for a return that never comes. The trace labels every hop, so a mid-chain 302 has nowhere to hide.
The http → https → www triple
One rule upgrades the protocol, a second fixes the host, a third fixes the path — three hops to express one decision. Collapse them into a single rule that emits the final https://www (or bare-host) URL in one jump.
Does your redirect chain drop to HTTP?
A protocol downgrade is the one chain defect a browser will never show you. The address bar ends on a padlock, every page loads over HTTPS, and somewhere in the middle a hop quietly answered over plain HTTP. For that single request the URL, the headers and any cookies attached to it crossed the network in the clear — and the response that decides where the visitor goes next could have been rewritten by anyone on the path.
It survives because it is invisible. The chain almost always upgrades back to HTTPS a hop later, so nothing looks broken and nobody goes looking. The trace above names it directly: any hop where an https:// address hands back an http:// destination is flagged as a high-severity finding with its hop number, so you can see the exact rule to fix.
Security scanners care because the downgrade lands in the gap HSTS cannot cover: a browser that has not yet seen your HSTS header makes a genuine cleartext request on that hop. That is why an insecure redirect shows up in SSL Labs and third-party risk reports on sites whose pages are all served correctly over HTTPS.
Three places produce it. An Apache RewriteRule left over from a pre-HTTPS migration with http:// hardcoded in its target. An nginx return 301 line with the same literal. Or a CDN rule — a Cloudflare Page Rule pinned to HTTP, or Flexible SSL, which talks to your origin in cleartext no matter how the origin is configured. Rewrite the rule to emit https:// directly, turn on Always Use HTTPS at the edge, then trace both the www and non-www forms again — a downgrade often lives on only one of them.
How to flatten a redirect chain
- 01
Trace the URL above and copy the final destination — the last address in the chain that answers 200.
- 02
Find where the first redirect lives: your CMS redirect list, .htaccess, nginx config, CDN rules, or a Netlify/Vercel redirects file.
- 03
Rewrite that first rule to point directly at the final destination, skipping every intermediate hop.
- 04
Repeat for any other rules that point at intermediate URLs in the chain — internal links too, so crawlers stop entering the chain at all.
- 05
Re-run the trace to confirm the chain is now a single 301 hop, then watch the URL so the next migration can't quietly rebuild it.
Checking many URLs at once? The bulk redirect mapper traces every chain in your list in one pass — the fastest way to find which of your old URLs still stack hops.
How it works
- 01
Enter a URL
Paste the starting URL: an old page, a shortened link, or any address you want to trace.
- 02
Follow the chain
Sitewell requests the URL and follows each 301 or 302 in order, recording the status code and target of every hop.
- 03
Inspect the path
See the whole redirect chain, confirm the final destination, and get a warning if the hops loop back on themselves.
Frequently asked questions
- What is a redirect chain?
- A redirect chain is what you get when an old URL points at a second URL, that one points at a third, and so on before a request finally lands on a real page. One hop from the old address to the new one is not a chain. Two or more is, and that is usually the point at which it is worth running a redirect chain checker over the URL to see what the path actually looks like.
- How do I check a 301 redirect?
- Paste the URL into the checker and it follows the redirect for you, showing each hop's status code and target. You can confirm the redirect is a 301 rather than a 302, see the exact URL it points to, and check that it reaches the final page in a single hop instead of bouncing through several.
- What is the difference between a 301 and a 302 redirect?
- A 301 is a permanent redirect. It tells search engines the page has moved for good and passes ranking signals to the new URL. A 302 (or 307) is temporary and asks engines to keep the original URL indexed. Use 301 for moved or merged pages, and 302 only for short-lived diversions.
- How can I tell if a redirect is a 301 or a 302?
- The checker labels every hop with its exact status code, so you can see at a glance whether a redirect is a permanent 301 or a temporary 302 (or 307/308). If you are deciding which one a page should use, the guide on 301 vs 302 redirects walks through when each is right.
- Why do redirect chains hurt SEO?
- Every extra hop costs a round trip before anyone sees the page, and each one is another chance to leak link equity along the way. Long chains can also run past the number of hops a crawler is willing to follow, which leaves the real page undiscovered. Pointing the original URL straight at the final destination in a single 301 avoids all of that.
- How many redirects is too many?
- Browsers and search engine crawlers both stop following after a set number of hops, and those ceilings are lower than most people expect. They are not a target to aim for. In practice, anything past two hops is leftover wiring from an old migration, and you can flatten it by rewriting the first redirect to point at the last URL in the chain.
- What is a redirect loop?
- A loop is a cycle that never resolves — URL A redirects to B and B back to A — and browsers give up with a 'too many redirects' error. This tracer flags loops automatically; for diagnosing and fixing one, use the dedicated redirect loop checker.
- Does this follow meta refresh and JavaScript redirects?
- It traces server-side HTTP redirects (301, 302, 307, 308) hop by hop and reports the status and target of each. A meta refresh or a JavaScript redirect happens in the browser after the response arrives, so it is not part of the HTTP chain. Check those in a browser instead.
- Does Google follow redirect chains?
- Yes, but only so far: Googlebot follows up to 10 hops in a chain before it gives up and reports the URL as a redirect error. Anything close to that ceiling is fragile — one more migration and the destination silently drops out of the crawl. Keeping every redirect to a single hop stays comfortably clear of the limit.
- Do redirect chains lose PageRank?
- A single clean 301 passes almost all ranking signal. Each extra hop is another transfer where a little can be lost, and long chains also slow crawling, which delays how quickly the destination is recrawled and credited. The safe assumption: one hop is free, chains are a tax.
- How do I find redirect chains across a whole site?
- Checking one URL at a time doesn't scale past a handful of pages. Export your URL list (from a crawl, your sitemap, or old analytics), then run it through the Redirect Mapper, which traces every URL's chain in bulk and shows which ones stack more than one hop.
- What does the latency number next to each hop mean?
- It is the time that hop's server took to answer the redirect. The summed number above the chain is how much waiting the redirects add before the real page even starts loading — time you get back entirely by flattening the chain to a single hop.
- What is an insecure redirect?
- An insecure redirect is a hop that sends a request from HTTPS down to plain HTTP. For that hop the URL, headers and cookies travel unencrypted, and anyone on the path can read or rewrite the response — including the redirect target itself. The chain usually recovers a hop later by upgrading back to HTTPS, which is why the downgrade is invisible in a browser and shows up only when you trace the chain hop by hop.
- How do I check whether my redirect chain contains HTTP?
- Trace the URL above and read the protocol of every hop. Any step where an https:// address returns a Location header pointing at http:// is a downgrade, and the checker flags it as a high-severity finding with the hop number. Test both the www and non-www forms of your domain — a downgrade often exists on only one of them.
- Why do security scanners flag an HTTPS to HTTP redirect?
- Because the downgrade defeats the protections around it. The plain-HTTP hop happens before HSTS can apply, so a browser that has never seen your HSTS header will make a real cleartext request that can be intercepted. Scanners such as SSL Labs and third-party risk-rating tools report it as a mixed-transport or insecure-redirect issue, and it can hold up a security review even when every page ultimately loads over HTTPS.
- How do I fix a redirect that downgrades to HTTP?
- Find the rule that emits the http:// Location and rewrite it to emit https:// directly. In Apache, an old RewriteRule usually hardcodes http:// in its target. In nginx, a return 301 line does the same. On Cloudflare, an HTTP-only Page Rule or a Flexible SSL mode can inject the downgrade even when your origin is configured correctly. Fix the rule, enable Always Use HTTPS at the edge, then re-trace to confirm every hop stays on https://.