See exactly where your URLs go. Trace every redirect hop visually with full HTTP headers, SEO analysis, and actionable fix recommendations. Test as Googlebot or any user-agent — catch loops, broken chains, and ranking-killing redirects before search engines do.
Written by Ishan Karunaratne · Last reviewed:
Enter any URL and watch the redirect chain unfold in real time. The checker makes an HTTP GET request from our server and follows every 3xx redirect response until it reaches a final destination (2xx) or encounters an error. Each hop is streamed to your browser as it's discovered — you see the chain build hop-by-hop, not just the final result.
For each hop, the checker captures the full URL, the HTTP status code and reason phrase, all response headers including the Location header, the resolved IP address, and response timing in milliseconds. Results are presented in multiple views: a visual redirect chain diagram with domain change indicators, a full response headers table for each hop, and a raw cURL-style HTTP transaction log with syntax highlighting.
The built-in 17-point SEO analysis engine automatically evaluates the chain for issues that damage your search rankings: excessive hops that waste crawl budget, temporary redirects losing link equity, missing HSTS headers, protocol downgrades, query string stripping, redirect-to-homepage patterns (soft 404s), mixed redirect types, DNS failures, and broken chains. Every issue comes with specific fix instructions for Nginx, Apache, and Cloudflare. Switch user-agents to test how Googlebot, Bingbot, or mobile browsers experience the chain.
The HTTP/1.1 specification ( RFC 9110 Section 15.4) defines six redirect status codes. Each has different semantics for caching, method preservation, and SEO impact.
The target resource has been assigned a new permanent URI. The response is cacheable by default. Search engines transfer link equity to the new URL and update their index. The client MAY change the request method from POST to GET for the redirected request. Use for site migrations, domain consolidation, and permanent URL restructuring.
The target resource resides temporarily under a different URI. The client SHOULD continue to use the original URI for future requests. The response is not cacheable unless indicated by Cache-Control or Expires headers. Search engines keep the original URL indexed and do not transfer link equity. Use only when the move is genuinely temporary.
The server is redirecting the client to a different resource using GET, regardless of the original request method. This is the correct code for the Post/Redirect/Get (PRG) pattern — after a form submission, redirect the user to a confirmation page with 303. Unlike 302, the method change to GET is explicitly required.
Like 302, but the client MUST NOT change the request method. If the original request was POST, the redirected request must also be POST. This was introduced to resolve the historical ambiguity of 302 where browsers would change POST to GET. Use 307 for temporary redirects where method preservation matters, such as API endpoints.
Like 301, but the client MUST NOT change the request method. The response is cacheable by default. Use 308 when you need permanent redirect semantics with method preservation — for example, a permanently moved API endpoint that accepts POST/PUT requests.
Beyond the status code, several HTTP headers carry critical information during redirect chains. This tool captures and highlights all of them.
| Header | Purpose | RFC |
|---|---|---|
| Location | The URI the client should follow for the next hop in the redirect chain. Required for all 3xx redirects. | RFC 9110 §10.2.2 |
| Strict-Transport-Security | HSTS policy. Tells browsers to always use HTTPS, eliminating HTTP → HTTPS redirect hops on subsequent visits. | RFC 6797 §6.1 |
| Cache-Control | Controls whether the redirect response is cached by browsers and proxies. 301/308 are cacheable by default; 302/307 are not. | RFC 9111 §5.2 |
| X-Robots-Tag | Can contain noindex, nofollow, or none directives. If present on the final destination, search engines won't index the page despite the redirect chain. | Google spec |
| Retry-After | When present on a 3xx response, indicates how long the client should wait before following the redirect. Often used with 503 but valid on redirects. | RFC 9110 §10.2.3 |
| Referrer-Policy | Controls how much referrer information is sent when following the redirect. Important when redirecting across domains. | W3C spec |
If http://example.com redirects to https://example.com which redirects to https://www.example.com, configure all three origins to redirect directly to the final canonical URL in a single 301. Each hop costs a full HTTP round-trip and dilutes link equity.
A common mistake is using 302 (Found) for permanent URL changes. Per RFC 9110 Section 15.4.2, 301 responses are cacheable by default and signal permanence to search engines. 302 redirects do not pass full link equity and keep the original URL as canonical.
After verifying your HTTPS redirect is correct, add the Strict-Transport-Security header with a long max-age (at least 1 year / 31536000 seconds). This eliminates the HTTP → HTTPS redirect hop entirely for returning visitors — the browser performs an internal 307 redirect without ever making an insecure request.
Some servers, CDNs, and WAFs redirect differently based on the User-Agent header. Always verify that Googlebot sees the same redirect chain as regular browsers. Cloaking (serving different content to crawlers) violates Google's webmaster guidelines and can result in manual penalties.
After setting up redirects, update all internal links, sitemaps, and canonical tags to point directly to the final destination URL. This reduces unnecessary redirect hops for both users and crawlers, and avoids wasting crawl budget on redirect chains.
Deep inspect any URL: TLS certificate, timing waterfall, response headers, and body analysis.
Scan any URL for missing security headers and get a letter grade.
Full reference for all HTTP status codes including 3xx redirect codes.
Validate SPF records against RFC 7208 with lookup limit and policy analysis.
Look up DNS records and verify your domain's configuration.
Check if a URL is flagged for malware or phishing by 17 security vendors.
Audit 70+ on-page SEO factors including link validation, meta tags, and structured data.