Redirect Checker
The Redirect Checker traces server-side HTTP redirects from up to 10 source URLs to their terminal responses within a five-fetch limit per URL.
What the Redirect Checker checks
List each bounded fetched URL in order with its hop number, keeping the submitted source, intermediate locations and terminal response distinguishable throughout the redirect path.
Show the HTTP status and declared Location value behind every followed server-side redirect, including relative locations resolved against the response URL that supplied them.
Stop repeated URL identities as a loop and cap total fetched or returned hops at five. A limit result stays distinct from a confirmed terminal response.
Report the final effective URL and HTTP status, with terminal meta refresh markup identified as page evidence. The checker does not execute JavaScript or treat client-side navigation as an HTTP hop.
When to use this tool
Run the Redirect Checker to diagnose unexpected destinations, loops or multi-hop paths that add latency and obscure the final resource.
Example
Example: inspect http://example.com/old-page to trace each 301 or 302 response through its final HTTPS destination.
Issues and fixes
When the hop table shows avoidable intermediate responses, update the source link, canonical or redirect rule to point directly to the intended final URL. Keep a required migration hop only when it serves a real compatibility need, then retest the original source.
A repeated normalized URL means the chain cannot reach a terminal resource. Inspect the two or more conflicting application, proxy, CDN or protocol rules shown in the evidence, correct the cycle and retest every affected entry point.
A client or server error at the final destination means the redirect resolved but the resource did not succeed. Repair that destination or change the redirect target. Preserve the reported status instead of labelling every distinct failure simply broken.
What the result includes
The report lists each bounded fetched URL, status and Location target, plus the terminal response and any terminal meta refresh markup.
Limitation: The Redirect Checker makes bounded HTTP requests for up to 10 public source URLs and follows at most five total fetches per source. It records server-side status and Location evidence, stops loops and reports a limit without inventing a terminal response. It may identify meta refresh markup only on the terminal response; it does not render the page, execute JavaScript or reproduce browser-internal navigation. Network, TLS, authentication, blocked-network and response-limit failures remain transport evidence. The result describes the observed path, not whether every crawler has cached or processed it.
Frequently asked questions
What is the difference between permanent and temporary redirect status codes?
HTTP 301 and 308 describe permanent redirects, while 302, 303 and 307 describe temporary or method-specific redirects. The Redirect Checker reports the actual status on every hop. Whether a status is correct depends on whether the source URL should remain the long-term public location.
How many redirect hops are too many?
The shortest correct path is one redirect from the old URL to the final URL. This checker stops after five total fetches so loops and long chains stay bounded. Remove avoidable intermediate hops when they add latency, create conflicting destinations or prevent the terminal response from being reached.
Monitor URLs over time
Turn a one-off diagnostic into ongoing index monitoring and change alerts.