The site is not set up for HSTS preloading
Updated
What this check looks for
Browsers only learn to force HTTPS after the first visit. Preloading builds that instruction into the browser itself, so even the very first visit is secure.
Why it matters
Nothing is wrong here — preloading is optional and deliberately hard to undo. It is offered because it closes the one gap HSTS cannot: the very first request a browser ever makes to your site.
When the check passes, your report says: “The HSTS header carries everything the preload list requires”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- Web security
- Module
- Web security headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Submit to the preload list only once every current and future subdomain is committed to HTTPS.
Preloading protects the very first visit, and it is the least reversible header decision a site can make.
List every hostname under the domain and confirm each serves a valid certificate over HTTPS.
Run
max-age=31536000; includeSubDomainsfor a period with nothing breaking before addingpreload.Make the bare domain redirect HTTP to HTTPS on the same host, and send the full header —
max-age=31536000; includeSubDomains; preload— on its HTTPS responses, redirects included.Submit the bare domain at hstspreload.org, and keep serving the header for as long as you stay on the list.
How to confirm it worked
curl -sSI https://‹host›/ | grep -i strict-transport-security — expect max-age of at least 31536000, includeSubDomains and preload
Repeat the request against your bare domain, then check the domain's status at hstspreload.org.
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹detail›
The preload list requires max-age of at least ‹required max age›, includeSubDomains, preload, and a redirect from HTTP to HTTPS on the same host. Removal takes months and browsers ship the list in their binaries, so treat submission as a decision rather than a setting.
This check reads the header ‹host› sends; it does not look the domain up on the list. A pass means the header carries what the list asks for, not that the domain has been submitted or accepted — hstspreload.org shows the actual status. Only the registrable domain can be submitted (example.com, not www.example.com), and the list reads the header on that bare domain's HTTPS response, including on any redirect it serves to www.
Inclusion covers every name under the domain, at every depth, for visitors who have never been to the site. Before submitting, every hostname must already serve HTTPS with a valid certificate: internal tools, staging names, webmail, anything still in DNS — and anything created later. A forgotten plain-HTTP subdomain stops working for everyone at once, and stays broken until a removal reaches their browsers. hstspreload.org recommends reaching the final header in stages — five minutes, then a week, then a month — waiting out each stage's max-age before raising it.
The list is compiled into Chrome, and Firefox, Safari and Edge maintain lists based on it. Removal is a request to the list, then a browser release, then every installed browser updating; the list's maintainers say that takes months to reach users.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.