Hypertext Transfer Protocol (HTTP) Redirect Checker

Redirects are the quiet routing rules behind many ordinary web visits. A typed address might start on plain HTTP, move to HTTPS, switch from a bare domain to a www host, add or remove a trailing slash, pass through a short-link host, and finally arrive at the page a person actually sees. The browser hides most of that trip once the final page loads, but each hop can affect security, crawl signals, cache behavior, and page-load delay.

An HTTP redirect is a server response in the 3xx range that points the client to another URI, usually through a Location header. The status code describes the kind of handoff. 301 and 308 are normally used for permanent moves, while 302, 303, and 307 are commonly used when the destination is temporary, conditional, or request-specific. A redirect chain is the ordered set of these request-and-response steps until a non-redirect response, a stop condition, or an error ends the route.

Redirects are useful when they are deliberate and short. A migration from http://example.com to https://www.example.com/ should usually be one clean permanent hop. A campaign link may need a temporary handoff, but extra hosts and mixed redirect types can make analytics harder to trust. Old canonical rules can also fight each other, such as one rule adding www while another removes it, which creates a loop instead of a landing page.

Hop

One request and response in the visible route.

Location

The redirect target named by the server. Relative values are resolved against the current URL.

Final response

The last observed response, which might be a successful page, an error, or an unfinished redirect.

HSTS

HTTP Strict Transport Security, a policy that tells browsers to use HTTPS for future visits to the host.

Request details can change the path. Some origins treat HEAD differently from GET. Mobile and crawler user agents may be sent to different hosts. Regional routing, cookies, authentication, CDN cache state, and bot rules can also change what a client sees. That is why redirect checks are best read as evidence for one observed request, not as proof that every visitor or crawler will see the same chain.

HTTP traces do not capture every kind of navigation. JavaScript redirects, meta refresh tags, consent walls, logged-in journeys, and browser history changes happen outside the server-side redirect exchange. A clean HTTP path is still valuable, but it should be paired with browser testing when the real user journey depends on scripts, sessions, or geography.

How to Use This Tool:

Use the checker to capture one HTTP route, then compare the summary, hop table, charts, and replay command before sharing or acting on the result.

1. Enter one address in URL. Bare domains are accepted and start as HTTP so scheme upgrades are visible. If several lines are pasted, only the first non-empty URL is traced and the extra-line warning tells you what was ignored.
2. Choose Method preference. HEAD is a lightweight first pass for headers and route shape. Use GET when the route differs for a full fetch or when the target rejects header-only requests.
3. Select User-Agent profile. Tool default, Desktop browser, Mobile browser, Googlebot, and Custom string help compare routes that vary by client identity.
4. Open Advanced when the default trace needs tuning. Timeout per hop accepts 200 to 4000 milliseconds, Max redirects accepts 1 to 20, and Validate TLS certificate should normally stay on for production checks.
5. Leave Fallback GET on 405 enabled when starting with HEAD unless you specifically need to prove that HEAD fails. When the fallback is used, Method path records the change.
6. Press Check. If validation fails, fix the URL format first. If the live lookup fails or times out, retry with a slower per-hop timeout only after checking that the address is public and not session-gated.
7. Read Route Brief first. It combines Final URL, Final status, Route health, Redirect mix, Total time, Final security, Host handoffs, Method path, and the primary recommendation.
8. Use Hop Ledger for the step-by-step chain, Signal Table for HSTS, canonical, cache, robots, server, and redirect hints, Hop Timeline and Latency Curve for speed shape, and Replay Command when you need a comparable cURL run.

Use the available exports only after the method, user-agent profile, timeout, and redirect ceiling match the question you are documenting.

Interpreting Results:

Final URL and Final status tell you where the observed chain ended. A 2xx final status means the route reached a successful response. A 4xx or 5xx final status means the redirect path may be syntactically valid while the destination still fails. A visible 3xx, Limit note, repeated URL, timeout, or invalid target means the trace is incomplete and should not be treated as a settled destination.

Route health is a triage score, not a protocol standard. It drops for incomplete traces, failing destinations, extra redirects, temporary redirects, slow hops, insecure finals, missing HSTS on HTTPS, host handoffs, HTTPS downgrades, and repeated URLs. Use it to prioritize cleanup, then use the hop-level evidence to decide what actually needs to change.

Charts help separate route shape from route cost. Hop Timeline shows which individual hop is slow. Latency Curve shows how cumulative delay grows as the chain progresses. A route with one slow hop needs a different fix from a route with several small but unnecessary hops.

Technical Details:

HTTP redirection is governed by response status, request method, and a usable target URI. A Location header can contain an absolute URI or a relative reference. Relative references are resolved against the current request URI, so /new has a different final meaning on different hosts.

Method handling matters because route tests often start with HEAD. HEAD asks for the headers that a GET request would have received without transferring a response body. Some servers do not implement HEAD consistently, and a 405 Method Not Allowed on HEAD may not mean the page is unavailable to browsers. The optional fallback records that distinction by retrying with GET and preserving the visible method path.

Rule Core

Trace Processing Core

The observed chain starts from the normalized HTTP or HTTPS URL, sends the selected method and user-agent string, follows redirect responses manually, resolves relative Location values, and stops when a non-redirect response appears or a timeout, hop ceiling, invalid target, or failed request prevents another hop.

Formula Core

Route health starts at 100 and subtracts bounded penalties for route problems. The score is diagnostic, not a standard published by HTTP specifications.

L is 1 when a limit note exists, F is 1 when the final status is not 2xx, R is redirect count, T is temporary redirect count, S is the number of hops above 300 milliseconds, I is 1 when the final URL is not HTTPS, H is 1 when final HTTPS lacks HSTS, C is host handoff count, D is 1 when any HTTPS hop downgrades to HTTP, and P is 1 when a repeated URL appears.

Verdicts are assigned after scoring and hard failure checks. A limit note produces Incomplete trace. A non-2xx final response produces Broken destination. Insecure final paths or HTTPS downgrades produce Upgrade security. A direct successful HTTPS route with HSTS and no slow hop can produce Direct secure path, while a short stable chain with a score of at least 85 can produce Clean redirect path.

Privacy Notes:

The target URL, method choice, user-agent selection or custom string, timeout, redirect ceiling, TLS-validation choice, and HEAD fallback setting are sent to run a live server-side trace. The target site sees the request from the checking service, not from your current browser session.

Do not test secret-bearing URLs such as password-reset links, magic-login links, signed downloads, private dashboards, bearer-token URLs, or internal hosts. A URL can disclose path names, query strings, campaign identifiers, and access tokens even when the page content is not downloaded.

The trace does not include your browser cookies, local login state, extensions, or region unless the target route itself exposes different behavior to the checking service. For account-specific or location-specific paths, confirm the result in a controlled browser or monitoring environment that matches the real audience.

Worked Examples:

A tidy HTTP-to-HTTPS migration

A bare domain starts at HTTP, redirects once to the canonical HTTPS host, finishes at 200 OK, and shows Final security as HTTPS + HSTS. With no slow hops or host surprises, Route health can land in the clean range. The next check is to repeat the route with crawler and mobile profiles before calling the migration complete.

A chain with leftover temporary redirects

A campaign URL returns two 302 responses before landing on the final page. The destination may work, but the temporary redirect count and latency chart show route debt. Keep temporary hops only when the destination genuinely changes by campaign, device, or request context.

A route that rejects HEAD

An origin returns 405 Method Not Allowed to HEAD, then succeeds after fallback to GET. Method path records the fallback, and the hop table shows where it happened. Monitoring should use GET when it needs to match normal browser behavior.

A loop that never settles

A legacy login route alternates between two URLs until the redirect ceiling is reached. Limit note marks the result as incomplete, and Hop Ledger reveals the repeated pair. The last visible row is not a destination; the redirect rules need to be repaired before the landing page can be judged.

FAQ:

Glossary:

Hop

One request-and-response step in the observed redirect chain.

Location header

The HTTP response header that names the next URI for a redirect.

Permanent redirect

A 301 or 308 response that indicates a lasting move.

Temporary redirect

A 302, 303, or 307 response used for context-specific or non-permanent handoffs.

HSTS

HTTP Strict Transport Security, a response policy that tells browsers to prefer HTTPS for future visits to a host.

Limit note

A stop reason such as timeout or max_redirects showing that the trace ended early.

References:

• RFC 9110: HTTP Semantics, IETF, June 2022.
• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax, IETF, January 2005.
• HEAD request method, MDN Web Docs.
• Strict-Transport-Security header, MDN Web Docs.