HTTP Redirects Explained

An HTTP redirect is a response that directs a client to another URL, usually through a 3xx status and a Location header. Redirects support moved pages, canonical hostnames, login flows, regional routing and HTTP-to-HTTPS upgrades. Because each hop adds another request and can change method semantics, chains deserve inspection rather than being treated as a single destination.

The redirect process

A client requests URL A. The server responds with a redirect status and a Location value. That value can be an absolute URL or a relative reference resolved against A. The client decides whether to follow it, constructs the next request and repeats until it receives a non-redirect response, reaches a limit, encounters an unsupported target or detects a loop.

The Redirect Checker shows each hop and validates it before connecting. This is important for a server-side diagnostic: a public URL can redirect to a private address, local hostname or disallowed port. Safety must be checked again for every Location target.

301 and 308: permanent redirects

301 Moved Permanently tells clients that a resource has a lasting new location. User agents and caches may remember it, and search systems may treat the target as a strong canonicalization signal. It is not an irrevocable command to every intermediary, and changing a widely cached permanent redirect can take time to propagate.

308 Permanent Redirect expresses a similar permanent move while explicitly preserving the request method and body. That distinction matters for non-GET methods. Historical browser behavior around 301 commonly changes POST to GET, even though contemporary specifications describe more nuance.

302 and 307: temporary redirects

302 Found is traditionally used for a temporary destination. In widespread browser behavior, a POST followed through a 302 may become a GET. 307 Temporary Redirect was defined to make method preservation unambiguous: a POST remains a POST, with its body, when automatically followed.

Method preservation is not automatically safer. Redirecting a sensitive request to another origin can disclose its body if a client follows it, which is why applications should constrain destinations and clients apply security rules. Diagnostic tools that use HEAD or GET do not demonstrate what every application will do with POST.

303: see another resource

303 See Other directs the client to retrieve another resource with GET (or HEAD). It is useful after a successful form submission: the server processes the POST, then redirects to a result page that can be refreshed without resubmitting the form. This pattern is often called POST/Redirect/GET.

Relative Location values

A Location field does not have to repeat the full scheme and hostname. From https://example.com/old/page, a value of /new resolves to the same origin, while next resolves relative to the current path. Scheme-relative values beginning // retain the current scheme but replace the authority. Correct URL resolution is safer than string concatenation.

Redirect chains and latency

A chain such as HTTP → HTTPS → www → final path requires several request/response cycles. Each new origin may need DNS resolution, a connection and TLS negotiation. Connection reuse can reduce the cost in a browser, but unnecessary hops still delay reaching content and create more failure points.

Server-side timings in a checker include its own network path and may include DNS, connection and TLS work. They are not a browser Core Web Vitals measurement. Compare chain shape and status first; treat individual milliseconds as a temporary observation.

HTTP to HTTPS

Redirecting plaintext HTTP to HTTPS is common and useful, but the initial HTTP request is not protected by TLS. HSTS can tell a browser that already knows the policy to upgrade future navigation locally. Browser preload programs can establish that knowledge before a first visit for accepted domains. The HTTPS endpoint must still present a trusted certificate for the requested hostname.

A final HTTPS URL is one useful result, not a full transport audit. Check certificate validity with the SSL Certificate Checker and read the TLS guide.

Loops and broken destinations

A loop occurs when redirects eventually revisit a URL or keep generating new redirect URLs without reaching content. Conflicting rules between an application, reverse proxy and CDN are a frequent cause—for example, one layer adds www while another removes it. Scheme detection can also fail behind a proxy if forwarded-protocol headers are not trusted and normalized correctly.

Clients impose redirect limits even when a loop is not obvious. A chain that exceeds the limit is operationally broken for that client. Redirecting to an invalid certificate, unsupported scheme, private network target or malformed URL also stops a careful checker.

Canonicalization and user experience

Redirects can consolidate alternate hosts, retired paths and tracking links onto a preferred URL. Search systems may use permanent redirects as one canonical signal, but no status code guarantees ranking or indexing. Sitemaps, internal links and canonical metadata should normally point directly to the intended final URL rather than rely on chains.

For users, preserve meaningful paths and query data when appropriate, avoid bouncing between equivalent forms, and do not redirect every missing page to the homepage. A clear 404 can be more honest and useful than an unrelated successful destination. Test logged-in and logged-out states because authentication middleware can introduce different chains.

Redirects versus status checking

The Website Status Checker summarizes the final status, content type, elapsed time and redirect count. The Redirect Checker focuses on every intermediate response and Location. Together they answer “where did the request go?” and “what happened at the end?” without pretending to render the page or evaluate its content.