HTTPS and HSTS: the baseline every site needs

WebAudit 360 TeamWebAudit 360 TeamJuly 4, 20265 min read
HTTPS and HSTS: the baseline every site needs

Of all the checks in an audit, this is the one with the least room for debate. HTTPS isn't an optimization or a nice-to-have. It's the floor. Browsers flag plain HTTP sites as "Not secure," search engines have used HTTPS as a ranking signal for years, and any page that collects so much as an email address over HTTP is leaking it in plain text. If a page fails this check, fixing it jumps the queue.

It's also the one technical check we weight most heavily, because the downside of getting it wrong touches trust, security, and ranking all at once.

What HTTPS actually does

HTTPS encrypts the connection between a visitor's browser and your server. Without it (plain HTTP), everything sent back and forth (form inputs, passwords, the pages someone reads) travels as readable text that anyone on the network path can intercept or tamper with. With it, that traffic is encrypted and verified against a certificate that proves the site is really yours.

For visitors, the payoff is privacy and the little padlock that signals "this is safe." For you, it's trust, security, and a search ranking that isn't being held back.

The two levels we check

1. Is the page served over HTTPS at all? If it loads over http://, that's a hard fail. Every modern site should be HTTPS-only, with HTTP requests redirected to HTTPS so no one lands on the insecure version.

2. Is HSTS enabled? Even on an HTTPS site, there's a gap: the very first request a browser makes might go to http:// before redirecting. HSTS, the Strict-Transport-Security header, closes that gap by telling browsers "always use HTTPS for this domain, never even try HTTP." Our check passes only when you're on HTTPS and sending HSTS; HTTPS without HSTS is "good, but finish the job."

How to get it right

  1. Get a certificate. These are free and automated now: Let's Encrypt, or built into most hosts and CDNs (Cloudflare, Netlify, Vercel, and friends issue them for you). There's no cost reason to skip HTTPS anymore.
  2. Redirect HTTP to HTTPS. Add a permanent (301) redirect so every http:// request lands on https://. Otherwise the insecure version stays reachable.
  3. Add the HSTS header. Something like:
    Strict-Transport-Security: max-age=31536000; includeSubDomains
    max-age is how long (in seconds) browsers should remember to force HTTPS, and a year is standard. includeSubDomains extends it to everything under your domain.
  4. Check for mixed content. After going HTTPS, make sure the page isn't still loading images, scripts, or styles over http://. Those "mixed content" warnings undermine the secure padlock. Update internal references to https:// or protocol-relative paths.

A note of caution on HSTS

HSTS is powerful precisely because browsers obey it stubbornly. Once a browser sees your HSTS header, it will refuse to connect over HTTP for the duration of max-age, even if you later have a certificate problem. So:

  • Make sure HTTPS is fully working across your whole domain before enabling includeSubDomains.
  • Start with a shorter max-age if you're nervous, then raise it once you're confident.
  • Only consider HSTS preloading (getting baked into browsers) when you're certain every subdomain is HTTPS-ready. It's hard to undo.

This pairs naturally with your other security headers. HSTS is one of that family, and once you're adding response headers it's worth doing the set together.

Common mistakes

  • Leaving HTTP reachable with no redirect, so the insecure version still loads.
  • HTTPS without HSTS, leaving the first-request gap open.
  • Mixed content, a secure page pulling in insecure assets, breaking the padlock.
  • Certificate expiry, because auto-renewal silently failed. Monitor it.
  • Enabling includeSubDomains or preload before every subdomain is HTTPS-ready.

FAQ

Does HTTPS affect SEO?

Yes. It's been a confirmed (if modest) Google ranking signal for years, and browsers actively warn users away from non-HTTPS sites, which hits engagement. It's a baseline, not an edge.

Is a free certificate good enough?

Completely. Free certificates from Let's Encrypt (and built-in host/CDN certs) provide the same encryption as paid ones. For most sites there's no reason to pay.

What does HSTS add if I already have HTTPS?

It removes the brief window where a browser's first request could go over HTTP before redirecting, and it prevents downgrade attacks. HTTPS becomes enforced rather than merely available.

Can HSTS lock me out if something breaks?

Browsers will refuse HTTP for the max-age duration, so a certificate failure becomes a hard outage. Make sure HTTPS is solid before setting a long max-age or enabling preload.

Key Takeaways

  • HTTPS encrypts the connection between browser and server; without it, form inputs, passwords, and page content travel as readable text that anyone on the network path can intercept.
  • HSTS, sent via the Strict-Transport-Security header, closes the gap where a browser's first request could still go over HTTP, and it prevents downgrade attacks.
  • Certificates are free and automated through Let's Encrypt and most hosts and CDNs, so there is no cost reason to skip HTTPS.
  • A full HTTPS setup needs a certificate, a 301 redirect from HTTP to HTTPS, the HSTS header, and a check for mixed content that loads assets over http://.
  • HSTS is enforced stubbornly: browsers refuse HTTP for the entire max-age, so confirm HTTPS works across the whole domain before enabling includeSubDomains or preload.

Want to confirm your site is HTTPS with HSTS, end to end? Run a free audit. It's the highest-weighted technical check we run. More in the Technical explainers.

← Back to the blog