How HTTP Redirects Work, and Why the Chain Matters

A redirect is simply a response with a 3xx status code and a location header pointing somewhere else. The browser, or any other client making the request, is expected to make a fresh request to that new address rather than treating the first response as the final answer. This happens automatically and, for a single redirect, is barely noticeable, but each one adds a full extra round trip to the server before the actual content ever starts loading.

• 301 Moved Permanently tells the browser, and importantly search engines, that this address has permanently moved, and any bookmarks or indexed links should be updated to point at the new one.
• 302 Found signals a temporary redirect, meaning the original address is still the canonical one and should not be replaced in bookmarks or search indexes.
• 307 Temporary Redirect behaves like 302 but explicitly guarantees the request method and body are preserved on the follow up request, which 302 technically leaves ambiguous for older clients.
• 308 Permanent Redirect is the same guarantee as 307, applied to a permanent rather than temporary move.

Using 302 for a change that is actually permanent is a common, mostly harmless mistake, though it can genuinely slow down how quickly search engines update their index to point at the new address.

Each redirect in a chain requires a complete separate connection, including DNS resolution and, for HTTPS, a full handshake, before the next address is even known. A page reached through three or four redirects can lose a noticeable fraction of a second before a single byte of the actual content arrives, which matters more than it sounds on a slow mobile connection. Redirect chains commonly build up gradually over years, one migration leaving a redirect to a domain that later gets migrated again, without anyone going back to update the original link to point straight at the final destination.

curl -IL https://example.com

The -L flag tells curl to follow redirects rather than stopping at the first one, and combined with -I it prints the headers, including the status code and location, at each step along the way.

The HTTP Headers tool follows redirects automatically and reports the final URL along with how many hops it took to get there, which is a fast way to spot an unnecessarily long chain worth shortening directly at the source. The Redirect Checker tool goes a step further and lists every hop individually, with the status code and address at each step, which is more useful when a chain is longer than one or two hops and you need to see exactly where each one hands off to the next.