HTTPS Redirect Checker Guide: Make Sure Plain HTTP Really Forwards to HTTPS

A site that offers HTTPS but leaves its plain-HTTP version working has done half the job. Visitors who follow an old link, type the address without the secure prefix, or click a bookmark saved years ago arrive over plain HTTP, and their traffic is readable and alterable on the network until they somehow reach the secure version. The fix is a redirect: every plain-HTTP request should be answered with an instruction to retry the same address over HTTPS, automatically and immediately. The HTTPS Redirect Checker reads redirect data you paste, such as a chain of responses for an address, and reports whether the redirect goes to HTTPS, whether it preserves the destination, and whether it takes extra hops or loops. It works on pasted data, so it judges the chain you show it; it does not fetch your live site, and the chain you paste must be the one your server really produces.

A correct redirect has three properties. First, it goes from HTTP to HTTPS, not to another HTTP address. Second, it preserves the path: a request for a specific article over HTTP should land on that same article over HTTPS, not on the homepage. Third, it does it in one hop, with the right status code, usually a 301 for a permanent redirect, so browsers and search engines learn the secure address and stop using the insecure one. A redirect that fails any of these properties is a partial fix. A redirect to the homepage loses the visitor's destination and the value of the link they followed. A redirect that goes HTTP to HTTP to HTTPS wastes a round trip and leaves an extra insecure hop in the chain. A redirect that loops, sending the visitor back and forth between two addresses, never arrives at all, and browsers eventually give up with an error.

How to read a redirect chain

Read the chain hop by hop, noting the address and status code at each step. The first address should be the plain-HTTP version of the page. The next address should be the same path over HTTPS, with a 301 status. If there are further hops, ask why: a common legitimate extra hop is a change of domain spelling, such as a non-www address redirecting to a www address, but even then the chain should be short, ideally two hops at most, and every hop should be over HTTPS after the first. Watch for a hop that returns to HTTP, which defeats the purpose, and for a hop whose path changes unexpectedly, which suggests a misconfigured rule catching the request. Count the hops as you read: each hop is a round trip, and on a slow mobile connection each round trip is real, noticeable delay.

Worked example

Take a sample address, with values clearly labelled as an illustration: a visitor requests an article over plain HTTP. In the correct case, the chain has 1 hop: the HTTP address returns 301 to the HTTPS address of the same article, and the HTTPS address returns 200. Total hops: 1 redirect plus the final page, which is the minimum possible. In a faulty case, the chain has 3 hops: HTTP article to HTTP homepage, then HTTP homepage to HTTPS homepage, then HTTPS homepage to HTTPS article, if that last hop exists at all. That is 3 redirects instead of 1, which is 3 times the redirect work, and the visitor's original destination was lost at the first hop and only recovered, if at all, by luck. Suppose each hop costs 0.3 seconds on a mobile connection: the correct chain costs 0.3 seconds of redirect time, while the faulty chain costs 0.9 seconds, a difference of 0.6 seconds, before the page itself even starts loading. Now consider a loop case: HTTP article to HTTPS article to HTTP article, repeating forever. Browsers typically stop after about 20 hops, so the visitor waits through 20 wasted round trips, about 6 seconds at 0.3 seconds per hop, and then sees an error. The arithmetic shows why chains and loops are not cosmetic: they cost time, and loops cost the visit entirely.

Mistakes to avoid

The first mistake is redirecting everything to the HTTPS homepage, which is easy to configure and terrible for visitors following deep links. The second is creating a loop by configuring the redirect on a server that sits behind a load balancer or proxy that strips the HTTPS indication, so the server thinks every request is plain HTTP and redirects forever; this is a common and confusing fault, and it is fixed in the proxy configuration, not by adding more redirect rules. The third is using a temporary 302 redirect for what is a permanent move to HTTPS, which means browsers and search engines keep trying the insecure address. The fourth is checking the homepage only: deep pages, old sections, and subdomains can have different or missing redirects. The fifth is pasting a redirect chain from another site, or from a cached result, and treating it as evidence about your own server; always paste a fresh chain from your server's real response.

Putting it into practice

Test the redirect for the homepage, several deep pages, and each subdomain, and confirm each one lands on the same path over HTTPS in a single hop with a 301 status. After confirming the redirect, consider adding an HSTS header, which makes browsers go directly to HTTPS in future, skipping the redirect entirely. Re-test after server, proxy, or CDN changes, which are the moments redirect rules most often break. For related checks, the HTTPS Checker covers the secure connection itself, the HSTS Checker covers the header that enforces HTTPS, and the HTTP Status Code Checker explains the redirect status codes. The companion guide on Fix Redirect Chains Loops explains chains and loops generally, and it applies directly to HTTPS redirects as well.

Key points

  • A plain-HTTP request should redirect to the same address over HTTPS, in a single hop
  • A redirect to the homepage instead of the same page loses the visitor's destination
  • Redirect loops and chains leave visitors stuck or slow, and must be fixed, not tolerated
  • A checker reads pasted redirect data, it does not fetch a live site or prove the live redirect works

In short: every plain-HTTP address should forward to the same address over HTTPS, once, permanently. Test deep pages and subdomains, not just the homepage, fix loops at their proxy or server cause rather than by adding rules, and add HSTS once the redirect is proven.