A downgrade in the middle
An https URL that redirects to http puts everything after that point in clear text, and stops the browser sending cookies marked Secure — which breaks sessions in ways that look unrelated to the redirect.
A browser follows the chain and renders the destination. Everything that happened on the way is discarded, which is where the faults live.
An https URL that redirects to http puts everything after that point in clear text, and stops the browser sending cookies marked Secure — which breaks sessions in ways that look unrelated to the redirect.
Strict-Transport-Security on an http response is ignored by specification. It looks configured, and it protects nobody.
A session cookie set by a redirect rather than by the destination is set by whatever answered the redirect. It works, and it is where most session fixation on login flows begins.
A meta refresh or a script setting the location does not appear in the HTTP chain at all, but costs a whole page load and is treated less reliably by search engines.
| Code | Meaning | Method | Cached |
|---|---|---|---|
| 301 | Moved permanently. Crawlers transfer ranking signals to the destination. | May be changed to GET by clients. | Yes, aggressively — hard to undo once browsers have it. |
| 302 | Found; temporary. The original URL stays in the index. | May be changed to GET. | No, unless headers say otherwise. |
| 303 | See other — fetch the destination with GET. | Always becomes GET. | No. |
| 307 | Temporary redirect, method preserved. | Preserved — a POST stays a POST. | No. |
| 308 | Permanent redirect, method preserved. | Preserved. | Yes. |
The method column matters more than it looks. A form posting to a URL that answers 301 or 302 may have its POST turned into a GET and its body dropped, which presents as a form that silently does nothing. 307 and 308 exist precisely to avoid that, and are the right choice anywhere a non-GET request might arrive.
The canonical arrangement for a site is a single redirect from anything to the one correct URL: scheme, host and path settled in one hop. Chains grow because the rules are written separately and each only knows its own concern — the https rule redirects to http://www, the www rule redirects to https://www, and a visitor pays for both.
Worth keeping in mind that a redirect is not the only way to express a preference. A canonical link element tells search engines which URL is authoritative without costing a round trip, and HSTS removes the http hop for returning visitors entirely — with preloading, for first-time visitors too. The redirect remains necessary as the fallback, but it should not be the mechanism doing all the work.
Once the chain is right, the thing that governs how fast the destination actually arrives is the response itself. The website response test breaks that into DNS, connect, TLS and time to first byte, each timed separately, so a slow network can be told apart from a slow TLS configuration or a slow application.
301 — or 308, which also preserves the request method — if the move is permanent. It is cached by browsers, and search engines consolidate the ranking signals of the old URL onto the new one. A 302 or 307 tells caches and crawlers the move is temporary, so the original URL stays in the index and the redirect is re-requested every time. Nothing in the response says which is correct; only you know whether the old address is coming back. The common mistake is a canonical host or scheme rule left on 302 because that is a framework default.
Almost always because each rule was added separately and none of them was taught about the others: one forcing https, one forcing www, one adding a trailing slash, one choosing a locale. Each hop is a full round trip — DNS, TCP, TLS, request — before anything renders, which on a mobile connection can be most of a second before the first byte of the real page. The fix is one rule that lands on the final URL in a single redirect.
Browsers are required to ignore it. If they honoured an HSTS header on a plain HTTP response, anyone able to modify that response — which is anyone on the path, since it is not encrypted — could set a long-lived policy for your domain and take the site offline for every visitor who received it. So the header does nothing on an http response, and it is a configuration that looks right and achieves nothing. Send it on the https responses only; the http response needs nothing but the redirect.
Not in itself — rebrands, URL shorteners and vanity domains all do it legitimately. It is worth confirming it is intended, because a redirect to somewhere unexpected is also what a compromised site or a hijacked domain looks like. This tool reports a cross-domain ending as information for that reason: it is a fact worth seeing rather than a fault.
Because that is what a browser does with a bare hostname, and the http hop is the one most likely to be misconfigured. Starting at https would skip the upgrade entirely — along with the possibility that the http response does not redirect at all, or redirects to the wrong host, or carries a cookie or an HSTS header it should not. If you want the chain from a specific URL, paste the full URL and it will be used as given.
That is a client-side redirect — a meta refresh in the markup or a script setting the location. It does not appear in the HTTP chain, because at the HTTP level nothing redirected. It costs a full page load before the move happens, and search engines treat it less reliably than a 301. This tool looks for both in the final document and reports them, which is the only way to see that hop short of loading the page yourself.
A site that answers slowly at 3pm, a certificate that expires on a Sunday, a redirect chain that grew a hop nobody noticed. We monitor and operate infrastructure around the clock, which is the difference between knowing and being told by a customer.