For most sites, enable HSTS first and treat preloading as a deliberate, later decision. Preloading hard codes HTTPS for your whole domain and all subdomains in browsers. The preload site itself states that HSTS is recommended and that preloading is not, because its added benefit is minimal.
What HSTS does, and the first visit gap
The Strict-Transport-Security header tells a browser to use HTTPS for a host for a period you set. MDN explains the weakness: HSTS takes effect only after the browser has made a secure connection and received the header. A first visit over plain HTTP, before the browser knows the host, is exposed to network attackers.
Preloading closes that gap. A domain on the preload list is known to browsers in advance, so even the first request is upgraded.
What the preload site says about value
The hstspreload.org page is candid. Many browsers automatically upgrade HTTP navigations to HTTPS regardless of a domain's HSTS policy, so preloading only adds value when those upgrades fail in the presence of an active attacker. It concludes that the benefits of preloading are minimal compared to those of HSTS, and that HSTS is recommended while preloading is not.
That does not make preloading wrong, only optional. It suits high risk domains whose owners accept the commitment.
The commitment, in a table
| Requirement | Detail from the preload site and MDN |
|---|---|
| Valid certificate | Required |
| HTTP to HTTPS redirect | On the same host, if you listen on port 80 |
| All subdomains on HTTPS | Including internal ones, and www if a DNS record exists |
| Header on the base domain | max-age at least 31536000 seconds (one year) |
| Directives | includeSubDomains and preload both present |
| Redirects | An extra redirect on your HTTPS site must still carry the HSTS header |
The internal subdomain point is where teams get hurt. A forgotten HTTP only dashboard under your domain becomes unreachable in browsers that have your domain preloaded.
A staged path
The preload site recommends ramping up max-age in stages while checking for broken pages:
max-age=300; includeSubDomainsfor five minutes.max-age=604800; includeSubDomainsfor one week.max-age=2592000; includeSubDomainsfor one month.
At each stage, fix problems, then wait the full period before moving on. Only after that, consider the one year value and the preload token. Because the policy affects every subdomain, list them first, public and internal.
Remember that backing out is slow. MDN's expiry notes say that to disable HSTS you set max-age=0, and it only takes effect when a browser makes a secure request and sees that response.
Try it yourself
Step through the web app scan and look for how transport and header checks are reported. Then run a header check against your own staging domain.
Click through it at your own pace, or open it full screen.
Quick check
Does HSTS work over plain HTTP?
No. MDN says browsers ignore the header when it arrives over HTTP, to stop a network attacker adding or expiring it.
Is preload needed for HSTS to work?
No. Normal HSTS works after the first secure visit. Preload only covers that first visit.
What happens if I stop serving HTTPS on a subdomain?
Browsers will refuse to load it over HTTP and will not offer a click through on certificate errors.
Safeguard scans dependencies and builds SBOMs, so you can see what your web stack runs on. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
