HSTS Checker Guide
Use this guide to understand what the HSTS Checker is validating, how to stage transport hardening safely, and when a site is actually ready for includeSubDomains or preload.
Overview
HSTS matters only when every relevant hostname is already healthy over HTTPS. The checker is trying to confirm that browsers can remember HTTPS-only behavior without sending users into loops, certificate errors, or broken subdomains.
Signals that deserve attention first
- max-age: Low max-age weakens persistence. High max-age is correct only when the site is already stable.
- includeSubDomains: Enable it only after validating every important subdomain.
- preload: Treat preload as a final stage, not the first step.
HSTS Directives and Rollout Risk
| Directive | Recommended use | Risk if mishandled |
|---|---|---|
| max-age=86400 | Short smoke-test period | Too little long-term protection if left in place. |
| max-age=31536000 | Strong production baseline | Locks clients into HTTPS, so certs and redirects must be healthy. |
| includeSubDomains | After subdomain validation | Breaks forgotten HTTP-only subdomains. |
| preload | After long-term stability | Slow to unwind if submitted too early. |
Practical Header Examples
Conservative rollout header
Strict-Transport-Security: max-age=86400Stronger production header
Strict-Transport-Security: max-age=31536000; includeSubDomainsRecommended Remediation Flow
- Confirm redirects and certificates first Verify HTTP to HTTPS redirects, SAN coverage, and renewal hygiene before raising max-age.
- Start lower if the estate is messy A shorter testing period is safer when you still have unknown subdomains or edge inconsistencies.
- Add includeSubDomains only after inventory review Mail, support, preview, and forgotten admin hosts commonly cause rollout pain.
- Treat preload as a final milestone Submit only after long-lived HSTS works reliably and the preload requirements are satisfied.
Troubleshooting Common Issues
Users are stuck after a certificate issue
That is expected behavior once browsers have cached HSTS. Recovery depends on restoring TLS quickly.
- Restore a valid certificate on the affected hostname immediately.
- Verify chain completeness and renewal automation.
- Avoid preload until certificate operations are predictable.
A subdomain breaks after includeSubDomains
This usually means the inventory was incomplete before rollout.
- Identify the hostname that is still HTTP-only or has certificate gaps.
- Move it to HTTPS or remove it from use before retrying a stronger policy.
- Use a lower max-age temporarily while cleaning up the estate if needed.
Validation Checklist
Post-fix validation
- Confirm the HSTS header is present on the final HTTPS response and any relevant redirect path.
- Verify certificate trust and renewal timing on the hostnames you actually care about.
- Retest important subdomains before enabling includeSubDomains or preload.
- Run the HSTS Checker again and compare the policy to the intended rollout stage.
FAQ
Should every site use preload?
No. Only mature HTTPS deployments should use it.
- Start with stable HTTPS and a long max-age first.
- Verify all subdomains before committing to preload.
- Do not preload a domain if DNS or certificate hygiene is still inconsistent.
Is HSTS useful without includeSubDomains?
Yes. It still protects the hostname that serves the header.
- Use it as an intermediate step if subdomain readiness is uncertain.
- Document which subdomains still block a stronger rollout.
- Promote the policy once the broader inventory is clean.