HTTP Status & Redirect Checker

The HTTP Status & Redirect Checker shows every step a URL takes before reaching its final destination. For each hop it lists the HTTP status code (301, 302, 307, 308, and so on) and the address it moved to, so you can see the intermediate path your browser never reveals on screen.

It is handy for diagnosing misconfigured permanent redirects, forced http→https upgrades, www canonicalization, redirect loops, and the long redirect chains that hurt SEO. Just enter a URL and the server safely makes the request on your behalf, returning the exact status codes and the path it followed. Results are briefly cached for speed.

Status codes at a glance

• 2xx: Success. 200 OK is a normal final response.
• 3xx: Redirect. 301 and 308 are permanent; 302 and 307 are temporary.
• 4xx: Client error, such as 404 (not found), 403 (forbidden), 410 (gone).
• 5xx: Server error. 500, 502, and 503 indicate a server-side problem.

How redirect chains affect SEO

A multi-step redirect chain slows page loads, dilutes link signals, and can cause crawlers to stop following partway through. Where possible, collapse the chain so the origin links directly to the final destination, and use 301 or 308 for permanent moves.

301 versus 302

A 301 is a permanent move, so search engines transfer indexing and link equity to the new address. A 302 is temporary and tries to keep the original URL in place. For permanent changes like a domain migration or URL restructure, always use 301. To also inspect the cache and security headers of the final response, view the full header set with the HTTP header checker.

3xx redirect codes and method preservation

Even though they all mean “moved,” each code differs in caching and whether it preserves the request method. The gap between 302/303 and 307 matters most for POST requests: pick the wrong one and a form submission silently turns into a GET, dropping the body.

How to read a real trace

Entering http://example.com/page might produce a chain like this:

• 1. http://example.com/page → 301 → https://example.com/page (forced http→https)
• 2. https://example.com/page → 301 → https://www.example.com/page (www canonicalization)
• 3. https://www.example.com/page → 200 OK (final destination)

The problem here is that steps 1 and 2 are split into two separate 301s. Combining the http→https upgrade and www canonicalization into a single server rule that jumps straight to https://www.example.com/page removes one hop. The trace should end on 200 OK; if the last line is a 404 or yet another 3xx, the redirect points at the wrong destination.

Common pitfall

The most common trap is registering only the HTTP (non-HTTPS) URL and leaving it there. If search engines and external links still point at http://, every visit incurs an extra 301 hop that leaks speed and link equity — and you will miss this hidden hop unless you actually run the trace. Likewise, using a 302 for a permanent move keeps search engines on the old address instead of transferring the index, so always use 301 (or 308 when you need the method preserved) for domain and URL changes.