What should I check before enabling HSTS?

`includeSubDomains` applies the policy to every name under the domain, including ones that have nothing to do with the website.

List them: application subdomains, documentation, status pages, mail hosts with a web interface, internal tools, legacy systems, anything on an appliance.

Certificate Transparency logs are the practical source, since DNS cannot be enumerated. Any name that has ever had a publicly trusted certificate appears there.

Each one must serve HTTPS with a valid certificate, or it becomes unreachable for anyone whose browser holds the policy.

This is the step that decides whether `includeSubDomains` is safe, and it is the one most often skipped.

The certificate covers every name in use, including ones that only redirect. A certificate for `www` alone breaks the apex before its redirect can run.

The chain is complete, so clients that do not cache intermediates can validate it.

Renewal is automated and monitored. HSTS turns an expired certificate from a warning page into a page visitors cannot bypass at all.

No mixed content, since a policy that forces HTTPS while the page loads plain-HTTP resources produces blocked resources rather than an upgrade.

The plain-HTTP form of every hostname redirects to HTTPS, because HSTS does not replace that redirect for the first visit.

Start with a short `max-age` — hours, not months — and no `includeSubDomains`. Verify nothing broke.

Raise the duration gradually: hours, then days, then weeks, checking at each step.

Add `includeSubDomains` only once every subdomain has been confirmed, and treat it as a separate stage with its own verification.

Consider `preload` last, and understand that it is a different commitment: removal from the browser preload list ships in a browser release and reaches users over months.

At every stage, the question is the same: if this turned out to be wrong, how long would it take to recover?

The policy lives in the browser. Removing the header stops refreshing it and does not remove what is already stored.

The documented retraction is to serve `max-age=0` over HTTPS and wait for visitors to receive it — which requires HTTPS to still be working.

A browser holding a one-year policy refuses plain HTTP for that domain for up to a year, whatever the server now says.

That asymmetry is the entire reason for the staged rollout above.

`curl -sI https://example.com | grep -i strict` shows the header as served. Note that browsers ignore it entirely when it arrives over plain HTTP, so it must be on the HTTPS response.

Check it on subdomains too once `includeSubDomains` is set, since the policy applies there whether or not those hosts send it.

VeriFixScan reports `transport.hsts` and `transport.hsts_directives` for the policy and its options, and `transport.hsts_preload_list` for list membership.

`transport.certificate_coverage` and `transport.mixed_content` cover the two preconditions that decide whether enabling it is safe.