How to Check a Site's HTTPS Setup Properly

The padlock is showing, so HTTPS is working. Except the padlock only tells you that this particular request was encrypted with a valid certificate. It says nothing about whether the first request was, whether the next one will be, or whether the page is quietly loading a script over plain HTTP.

Those three gaps are where HTTPS configuration actually goes wrong, and none of them are visible in the address bar.

The three things worth checking

Redirects. Someone types your domain without a scheme. The browser tries HTTP first. That request travels in plaintext before any redirect happens, and if it passes through a chain — http to https to www.https — that’s two round trips and two opportunities for interception.

HSTS. The Strict-Transport-Security header tells a browser to use HTTPS for this host for a set period, so subsequent visits never issue a plaintext request at all. It closes the gap the first redirect leaves open. The trade-off is that it’s hard to undo before max-age expires, so it needs testing before deployment rather than after.

Mixed content. A page served over HTTPS that loads an image, script or stylesheet over HTTP. Browsers block active mixed content outright, which breaks functionality, and flag passive content, which undermines the padlock the page just earned.

Why people get stuck here

• The padlock is reassuring. It confirms one request was fine and implies the whole setup is.
• Redirect chains accumulate. Each migration adds a hop, and nobody goes back to collapse them.
• HSTS feels risky. It is, if deployed carelessly — which is an argument for testing, not for skipping it.
• Mixed content hides in old content. A blog post from 2016 with an http:// image URL fails on a site that’s otherwise clean.

What a good HTTPS setup looks like

One redirect hop

http://example.com should reach https://example.com in a single 301. If your canonical host is www, redirect straight there rather than via the apex.

HSTS with a real max-age

A short max-age while testing, then a long one — a year is standard — once you’re confident. includeSubDomains extends it across everything, which is powerful and needs every subdomain to be HTTPS-capable first.

No mixed content anywhere

Including in user-generated content and old posts. Protocol-relative URLs and search-and-replace across the database are the usual fixes.

Common mistakes to avoid

• Submitting to the HSTS preload list before you’re certain every subdomain can serve HTTPS — removal takes months.
• Setting includeSubDomains when a legacy subdomain is still HTTP-only.
• Redirecting HTTPS to HTTP anywhere, which some legacy configurations still do for specific paths.
• Fixing mixed content in templates and forgetting the content database.
• Testing only the home page, when the problems usually live in older or less-visited pages.

How to do it with HTTPS Checker

The HTTPS Checker looks at the configuration layer rather than the certificate.

1. Enter the apex domain rather than a deep page.
2. Check the redirect reaches HTTPS in one hop.
3. Read the HSTS header values, including max-age and whether subdomains are included.
4. Fix any mixed content before enabling HSTS preload, since preload is difficult to reverse.

MDN’s guide to Strict-Transport-Security covers the header in detail. Other security tools are in the tools directory.

Frequently asked questions

Why does a redirect chain matter?

Each hop adds a round trip and another moment where a request is still in plaintext. Going http to https to www is two chances to be intercepted where one would do.

What does HSTS actually do?

It tells browsers to use HTTPS for this host for a set period, so later visits never issue a plaintext request. The trade-off is that it’s hard to undo before max-age expires.

What counts as mixed content?

Any subresource loaded over plain HTTP by a page served over HTTPS. Browsers block active content like scripts outright and flag passive content like images.

Final thought

Check the first request and the subresources, not the padlock. The padlock describes one response; the problems live either side of it.

Try the free HTTPS Checker