Full Route Evidence
See the requested URL, status code, classification, timing, and resolved destination for every response before the final page.
Redirect Checker
TL;DR: Redirect Checker checks trace full redirect chains with status codes and timing. so you can confirm the current issue, understand when it matters, and move directly into the next fix without leaving the browser.
Trace every hop between a URL and its final destination.
Updated
Loading tool interface...
Manual redirect following that preserves every intermediate response 301, 302, 303, 307, and 308 classification per hop Resolved absolute destination for relative Location headers Per-hop response timing and total route timing Repeated-URL loop detection with a terminal reason Three-hop warning and ten-hop tracing limit HTTP-first testing when the submitted URL has no scheme
What does Redirect Checker do?
The Redirect Checker sends a server-side GET request and follows each redirect manually. The report keeps the starting URL, every intermediate response, the final URL, status code, per-hop response time, and total time together. A browser normally follows redirects before you can inspect the route. This view preserves the route so a 301, 302, 307, or 308 does not disappear behind the final page.
Read the status code before changing it: A 301 Moved Permanently and 308 Permanent Redirect both identify a lasting move. A 302 Found and 307 Temporary Redirect identify a temporary route. A 303 See Other tells a client to retrieve the next URL with GET, which is common after form submissions. This checker uses GET requests, so it shows the route but does not simulate how a POST body behaves. For non-GET requests, 307 and 308 preserve the original method and body; older 301 and 302 handling can switch the follow-up request to GET.
Keep controlled routes to one hop: A route such as `/old` to `/archive` to `/new` makes two extra requests before content loads. Update `/old` to point directly to `/new`, then update internal links so they use `/new` without any redirect. PageChecks warns when a chain exceeds three hops and stops after ten hops. The ten-hop limit prevents a broken route from consuming an unbounded request cycle.
Treat loops as hard failures: A loop can alternate between HTTP and HTTPS, `www` and non-`www`, a trailing slash and no slash, or two application routes. The checker records visited URLs and returns a loop result when a destination repeats. Fix the conflicting server, CDN, or application rules instead of adding another redirect around them.
Check HTTP and HTTPS separately: When you omit the scheme, PageChecks starts with HTTP so the upgrade to HTTPS remains visible. A clean configuration usually sends `http://example.com/page` straight to the preferred HTTPS host and path. A route through `http://www`, then `https://www`, then `https://example.com` adds avoidable requests. Enter an explicit HTTPS URL when you only need to inspect behavior after the secure request.
Verify migrations by URL intent: Retired pages should redirect to the closest replacement, not the home page. Preserve the path when only the protocol or host changed. Use 410 Gone or a true 404 when no relevant replacement exists. A blanket redirect of deleted URLs to an unrelated destination can hide broken mappings during launch QA.
Compare redirects with canonicals: The final 200 page should normally declare itself as canonical. A redirect to `/new` followed by a canonical back to `/old` sends contradictory consolidation signals. A canonical that points through another redirect also creates unnecessary work; update it to the final indexable URL.
Use timing as a routing diagnostic: The report measures each response from the PageChecks request environment. A slow first hop can reveal origin, DNS, or edge-rule delay, while a slow final hop belongs to the destination response. These timings are not Core Web Vitals and do not measure browser rendering. They isolate network time spent reaching the final document.
Inspect relative destinations: HTTP permits a `Location` header such as `/new-page` or `../section`. PageChecks resolves that value against the current URL and displays the absolute result. This exposes relative paths that land on the wrong directory, retain an obsolete host, or drop a required query parameter.
When should you use Redirect Checker?
Redirect Checker is most useful when you need a direct answer on a live URL or draft before you change templates, ship content, or rerun a wider audit.
How to Use This Tool
- 1 Enter the oldest URL in the route. Leave off the scheme when you need to expose the first HTTP-to-HTTPS redirect.
- 2 Read the hops in order and identify every 301, 302, 303, 307, or 308 before the final response.
- 3 Check each resolved destination and response time. A relative Location header should resolve to the intended host and path.
- 4 Replace loops and multi-hop chains with one direct redirect from each legacy URL to the final destination.
- 5 Use a permanent status for a lasting move and a temporary status only when the original URL will return.
- 6 Open the final page, confirm it returns 200, and verify its canonical points to that same final URL.
What should you do next?
After tracing redirects, inspect response headers and verify canonical alignment at the destination. Then move to the related checks below to confirm the fix on the live canonical page.
What You Get
Loop and Depth Limits
A repeated destination ends with a loop result. Chains longer than three hops receive a warning, and tracing stops after ten hops.
Permanent vs Temporary
Separate 301 and 308 permanent moves from 302, 303, and 307 temporary responses before a migration rule reaches production.
Protocol Upgrade Check
Start at HTTP to reveal whether the route reaches the preferred HTTPS host in one request or detours through host and slash variants.
Timing by Response
Compare hop timings to identify whether delay sits in an edge redirect, an origin rule, or the final destination response.
Frequently Asked Questions
Answers about Redirect Checker
Run the starting URL through the Redirect Checker to see every response in order. Each row shows the status code, response time, resolved destination, and whether the redirect is classified as permanent or temporary.
Keep redirects to one hop whenever you control the source and destination. PageChecks warns after three hops and stops tracing at ten; each extra request adds latency and another point where a timeout, loop, or bad `Location` header can break the route.
Use 301 for a permanent URL move and 302 for a temporary route that will revert. A migration, retired slug, or permanent HTTP-to-HTTPS move normally needs 301, while a short maintenance route or temporary campaign split can use 302.
Yes, the checker detects repeated URLs as a redirect loop and reports the chain instead of following it forever. The hop list also exposes protocol changes and repeated intermediates, so you can replace the chain with one direct redirect.
307 is temporary and 308 is permanent; both preserve the original HTTP method and request body. That method guarantee matters for POST, PUT, and API requests, although this checker traces redirects with GET requests.
A 303 See Other tells the client to retrieve the destination with GET. It is useful after a form submission when refreshing the result page must not repeat the original POST request.
Yes, a redirect can return a relative `Location` value such as `/new-page`. The checker resolves it against the current hop and displays the resulting absolute destination, which helps expose paths that resolve on the wrong host or directory.
Yes, a URL entered without a scheme starts at HTTP so the protocol redirect remains visible. Entering an explicit `https://` URL starts there instead, which is useful when you only want to inspect redirects after the secure request.