HTTP Redirects: Reading Chains and Fixing Loops

A redirect tells a client to request a different URL. The response supplies a status code and a Location header with the next address. A redirect chain is the sequence of those responses before the final page.

In this guide: why redirects are used · status codes · reading a chain · common fixes · what the check measures · FAQ

Why websites use redirects

Redirects send a visitor from an address they requested to the address that should serve the page. They let a site change its URLs without leaving old bookmarks or links stranded, and they help keep one preferred address for each page.

• Move a page or site: send an old URL to its new location after a redesign, domain change, or content move. A permanent redirect tells clients that the new address should be used going forward.
• Use HTTPS: send an HTTP request to the encrypted HTTPS version. Enter an explicit http:// URL in the checker to see this step; entering a bare domain starts at HTTPS.
• Choose one hostname: send www.example.com to example.com, or the reverse, so visitors reach the same preferred address.
• Route a request temporarily: send visitors to a temporary location during a move or maintenance period without declaring the old address permanently replaced.
• Continue after a form submission: a 303 response can direct the browser to a results or confirmation page using GET, so refreshing that page does not repeat the original submission.

Each redirect adds another request before the final page responds. A useful redirect can still be worth that cost; the goal is to make the destination intentional and avoid unnecessary intermediate hops.

What the redirect codes mean

How to read a chain

The status-code definitions follow HTTP Semantics, RFC 9110.

Start with the final URL and HTTP status. A 200 response means the request succeeded. A 404 means the destination was not found; a 5xx response indicates a server error. A redirect code alone does not indicate a failure.

For example, http://example.com → https://example.com → https://www.example.com can be a valid route to the preferred address. Each extra step adds a request, so one direct redirect may be faster, but the chain is not automatically broken.

The Redirect Chain Checker lists each response in order. The following row is the destination of the preceding redirect. Per-hop times help identify which request took longest.

Common problems and fixes

• Redirect loop: two or more rules lead back to an earlier URL. Check for conflicting HTTPS, www, proxy, or application rules.
• Long chain: point old URLs directly to the intended final page when practical. Update internal links to use that address too.
• HTTPS to HTTP: check the destination rule and proxy scheme settings so navigation keeps using HTTPS.
• Unexpected domain: verify that the destination is intentional. Login and payment flows can legitimately cross domains.
• Failed final response: inspect the last URL, then use HTTP Headers Checker or Website Health Check to investigate.

What PacketFlo measures

Checks run from PacketFlo's server. The tool requests response headers with HEAD, falling back to GET when HEAD is unsupported. It follows HTTP redirects for public URLs, up to 20 redirects, and stops on a loop, timeout, or failed request. It does not execute JavaScript or follow HTML meta-refresh redirects.

Per-hop timing runs through receipt of the response headers; total time also includes DNS resolution and fallback requests. It is not a full page-load measurement. Your browser may take a different route because of cookies, location, cached redirects, or its own HTTPS upgrades.

Frequently asked questions