HSTS Preload Guide: Browser List Requirements and Rollback Risk

HSTS preload is the step after a careful HSTS rollout: you ask browser vendors to ship your domain on a built-in list that forces HTTPS even on the first visit, before any response header is seen. That closes the first-request downgrade window — and makes mistakes expensive to undo.

This article covers preload-only intent. For the safe max-age ramp, use What is HSTS and how to enable it safely. For lockouts and broken subdomains, use HSTS misconfiguration fixes.

Header requirements for preload

• `max-age` at least 31536000 (one year) — longer is fine.
• `includeSubDomains` must be present.
• `preload` token must be present.
• Serve the header on the apex over HTTPS with a valid certificate.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Submission checklist

1. 1Every subdomain you own serves valid HTTPS — including forgotten staging and mail hosts under the parent.
2. 2HTTP redirects to HTTPS correctly on the apex.
3. 3You have run the long max-age with includeSubDomains in production for long enough to trust it.
4. 4Submit via the official preload list process and wait for browser releases to pick up the change.

When not to preload

• Any subdomain still needs plain HTTP.
• You cannot guarantee certificate automation on every hostname under the domain.
• You are still climbing the HSTS setup ramp.
• A partner hosts a critical subdomain you do not control.

Verify before you submit

Inspect the live Strict-Transport-Security value with a security headers check or the security headers checker. Confirm apex and key subdomains independently. Preload does not fix bad certificates — it makes them impossible to click through.

Preload is a commitment, not a badge. Earn it after a stable HSTS deployment, inventory every subdomain, and only then submit. Keep misconfiguration fixes bookmarked in case you must climb back down.