Outrings
Security and email authentication

What is HSTS and should I enable it?

It forces browsers to use HTTPS for your domain. Almost always worth it — with two decisions that are genuinely hard to reverse.

3 min read
Short answer

HSTS is a header telling browsers to use HTTPS for your domain for a set period, refusing HTTP entirely. Enable it once HTTPS works everywhere. Be deliberate about includeSubDomains and preload, because both are difficult to undo.

The gap it closes

You redirect HTTP to HTTPS, so you are covered — except for the first request. Someone typing example.com makes a plain HTTP request before your redirect arrives, and that request can be intercepted and answered by someone else. The redirect never reaches them.

HSTS means the browser remembers, and converts the request to HTTPS before it leaves the machine. There is nothing to intercept.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
DirectiveMeaning
max-ageSeconds to remember. 31536000 is one year, the usual choice.
includeSubDomainsApplies to every subdomain, including ones you forgot about.
preloadRequests inclusion in a list shipped inside browsers, so even a first-ever visit is protected.

Rolling it out safely

  1. Confirm HTTPS works on the main domain, with a valid certificate and no mixed content.
  2. Start with a short max-age — max-age=300 — and confirm nothing breaks.
  3. Raise it in stages: a day, a week, then a year.
  4. Only add includeSubDomains after verifying every subdomain serves HTTPS, including internal tools, staging environments and legacy hosts you may not think of as part of the site.
  5. Consider preload last, and only if you are confident this is permanent.

The parts that are hard to undo

  • You cannot recall it. A browser that received max-age=31536000 will refuse HTTP for a year. Publishing a shorter value only affects browsers that visit again and receive it.
  • includeSubDomains covers everything. An internal tool on legacy.example.com with no certificate becomes unreachable for everyone who has visited your main site.
  • Preload removal is slow. Getting off the preload list requires a request and then waiting for browser releases to ship. Months, realistically.
The practical rule: max-age=31536000 on the main domain is a safe, high-value change for essentially every site. includeSubDomains requires an actual inventory of your subdomains, not a belief about them. preload is a commitment to HTTPS-only, permanently, across the whole domain.

What it does not do

HSTS forces the transport and nothing else. It does not validate your certificate beyond normal rules, does not stop content injection on your own site, and does not protect a user whose first-ever visit happens before the header is received — that last gap is exactly what preload addresses, and it is the only reason preload exists.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • Whether HSTS is present, its max-age, and whether subdomains and preload are declared.
  • Whether HTTP actually redirects to HTTPS, and in how many hops.
  • Whether the certificate would support subdomain enforcement.
  • Whether any resource on the page still loads over HTTP.

For agents and scripts, the same measurement is at /api/v1/security?url=yoursite.com — see the API documentation.

Related questions

What max-age should I use?

One year — 31536000 — once you are confident. Start much shorter during rollout so a mistake expires quickly rather than persisting for twelve months.

Should I preload?

Only if you are certain your domain and every subdomain will serve HTTPS indefinitely. The security benefit is real but modest over plain HSTS; the reversal cost is high.

Does HSTS affect SEO?

Not directly. Indirectly it helps by removing a redirect hop for returning visitors, which is marginally faster.

Read next

All 50 guides · How every check works · API for agents