Check whether a site forces HTTPS
A site can serve HTTPS and still accept plain HTTP on the side. An HTTP to HTTPS redirect is the server rule that sends every http:// request to its https:// equivalent, so no visitor stays on the unencrypted version by accident.
What a fail costs
On CheckWeb this is one of the heaviest checks there is: weight 3 on the Security axis, and a critical gate. A site with no HTTPS, or one that does not redirect to it, has its overall score capped at 40 out of 100, no matter how fast, well-optimized, or clean everything else is. Serving traffic over plain HTTP is the kind of exposure that outweighs the rest, and the score reflects that.
How it looks in the report
Under the Security axis, this shows as "HTTPS & HTTP→HTTPS redirect". A healthy site shows PASS with the evidence "HTTPS available; HTTP redirects to HTTPS". A fail here is one of the few things that caps the whole score, so it sits near the top of the fix list.
HTTPS & HTTP→HTTPS redirect
HTTPS available; HTTP redirects to HTTPS
Exposed vs correct
Exposed
http:// loads without redirecting, or the site has no HTTPS at all. Traffic and cookies travel in the clear, and the browser marks the site "not secure".
Correct
Every http:// request returns a 301 redirect to the https:// version.
How to fix it
- Get a certificate first if there is none: Let's Encrypt issues them free.
- Nginx: a port-80 server block that returns `301` to `https://$host$request_uri`.
- Apache: a rewrite or `Redirect permanent` to the https:// URL.
- App, host, or CDN: a force-HTTPS toggle at the platform or edge does the same.
- Then add HSTS so browsers skip the http:// step entirely on future visits (HSTS guide).
- Verify: re-scan and watch the cap lift.
Check whether a site forces HTTPS
Paste a URL to see whether a site redirects HTTP to HTTPS and whether the score is capped by it. Fix, re-scan, confirm.
Check my websiteFAQ
- Why does this one check cap the whole score at 40?
- Because everything else is conditional on it. On a site reachable over plain HTTP, passwords, session cookies, and form contents travel in the clear on any network between the visitor and the server, and a good header set does not change that. A score that stayed high while this failed would be misleading, so the cap applies no matter how well the rest scores.
- Is redirecting the home page enough?
- No. The redirect has to cover every path, because attacks target the pages that carry data, such as a login form or a checkout step, not the front page. Redirecting the whole host in one rule is also less work than maintaining a list of paths.
- Should the redirect be 301 or 302?
- 301, a permanent redirect. Browsers and search engines cache it, so repeat visitors stop touching the HTTP version at all, and the canonical HTTPS URL is the one that accumulates search signals.
- Does a redirect make HSTS unnecessary?
- No. The redirect still requires one plain HTTP request to happen first, and that request is the interception window. HSTS closes it by making the browser rewrite the URL to HTTPS before anything leaves the machine, which is why the two belong together rather than as alternatives.