How to use this tool
Paste any URL — a marketing campaign link, a legacy URL you suspect was migrated, an affiliate redirect, an internal link target — into the input above. The tool follows every hop server-side and returns the chain in order:
- 1.Status code per hop (301, 302, 303, 307, 308, or HTML meta-refresh).
- 2.Hop URL at each step, so you can see where the redirect was configured.
- 3.Latency per hop — DNS + TLS + TTFB. Catches slow CDN edges or DNS misconfigurations.
- 4.Final destination — the URL that actually serves a 200 OK.
- 5.Loop detection — if the chain returns to a previously seen URL, the tool stops and flags it.
Use it whenever you suspect a redirect issue: a campaign link that feels slow, a migrated section that lost rankings, an affiliate redirect with a checkout drop-off. The whole trace usually takes under a second.
Why redirect chains matter
Every hop in a redirect chain costs: crawl budget, latency, and a small fraction of link equity. Google has publicly said it will follow up to 5 redirects in one pass; if the chain is longer, Googlebot defers and returns later, so a 6-hop chain can take multiple crawl rounds to index. That delays new pages from ranking and slows Google's response to content updates.
For users, every hop adds a round-trip — typically 50–200 ms per hop. A four-hop chain on a slow connection can push TTFB over 1 second on its own, independent of any server-side work. That shows up as a Core Web Vitals regression and reduces conversion rate measurably on commerce flows: Akamai's frequently-cited research puts the bounce penalty at roughly 7% per 100 ms of additional load time.
For paid campaigns, redirect chains directly inflate cost-per-click visible cost: Google Ads, Meta, and other ad platforms count clicks at the moment the user starts the redirect, not when they land. A campaign URL that redirects three times before reaching the landing page is paying for impressions that never see your content.
Redirect types at a glance
| Code | Name | Use for |
|---|---|---|
| 301 | Moved Permanently | Permanent URL change. Passes link equity. Browser and search engine cache aggressively. |
| 302 | Found (Temporary) | Temporary redirect. Google treats as not-permanent — passes signals but keeps the old URL in consideration. |
| 303 | See Other | Used after a POST to redirect to a GET. Method changes from POST to GET on the next hop. |
| 307 | Temporary (Preserve Method) | Like 302, but the HTTP method is preserved. Rarely used in web workflows. |
| 308 | Permanent (Preserve Method) | Like 301, but the HTTP method is preserved. Useful for non-GET APIs. |
| Meta refresh | HTML-level redirect | A <meta http-equiv="refresh"> tag. Slower, not cached by browsers, and treated by Google as a weaker signal than HTTP redirects. Avoid in favour of 301. |
Common mistakes
Long redirect chains
http://example.com → https://example.com → https://www.example.com → https://www.example.com/home/. Each hop is avoidable. Configure the canonical origin at the edge so the first redirect is direct to the final URL.
Redirect loops
A URL that eventually redirects back to itself. Browsers and crawlers stop following and return an error; the page is effectively unreachable. Usually caused by misconfigured rewrite rules or conflicting HTTPS/www canonicalisation.
302 used where 301 belongs
A temporary redirect applied to a permanent URL change keeps the old URL indexed indefinitely. If you meant to permanently move the URL, use 301. If you meant to redirect temporarily but preserve the original indexing, 302 is correct.
Meta refresh in place of HTTP redirect
Meta refresh requires the page to render before the redirect fires, so users see a flash of unrelated content. Search engines treat it as a weaker signal than a real HTTP redirect. Replace with a server-level 301 whenever possible.
Mixed-protocol chains
A chain that goes http → https → http mid-flight breaks HSTS, flags as insecure in browsers, and leaks referrer headers. Always finish on https.
Three real-world redirect examples
http://example.com/blog/post → 301 → https://www.example.com/blog/post
One hop, ends in https + canonical host, 301 passes link equity. Configured at the edge so every variant of the URL converges to a single canonical destination.
http://example.com → 301 → https://example.com → 301 → https://www.example.com → 301 → https://www.example.com/
Three hops where one would do. Each hop is configured separately (HTTPS upgrade, then www canonical, then trailing slash) when a single edge rule could redirect directly to the final URL. Common with platforms that compose middleware redirects.
http://example.com/old-product → 302 → https://example.com/products/legacy → 301 → https://shop.example.com/legacy → 302 → https://shop.example.com/products/123 → 301 → https://shop.example.com/p/abc → meta-refresh → https://shop.example.com/checkout
Six hops mixing 301/302 and a meta-refresh tail. Google may not follow the chain in a single pass. Mixed permanent/temporary status codes confuse the indexer about which URL is canonical. The meta-refresh hop adds visible page render time. Typical of legacy commerce migrations layered over years.
Related pages
See the full technical SEO issue library · most common technical SEO mistakes · canonical tag glossary.