The fix, in one snippet
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now evaluates the domain against the published submission criteria of hstspreload.org, which feeds the list compiled into Chrome, Firefox, Safari and Edge. It checks that the certificate is valid, that port 80 (if it answers) redirects to HTTPS on the same host before any hostname change, that the HTTPS response for the registrable domain carries a Strict-Transport-Security header with max-age of at least 31536000 (one year), and that the header includes both the includeSubDomains and preload tokens. Scan.now cannot enumerate all your subdomains, so it also tests the www host and reminds you that every other subdomain must serve HTTPS. The check is rated info because preloading is a deliberate, hard-to-reverse choice, not a defect. The base hsts check covers the header itself.
Why it matters
HSTS is trust-on-first-use: the browser only knows to avoid HTTP after it has seen the header once, so a brand-new visitor, a freshly installed browser or a user whose policy expired is exposed on their first request. Preloading ships the policy inside the browser binary, so there is no first request over HTTP, ever. The trade-off is scope and permanence. The list requires includeSubDomains, which means every subdomain you have, including ones you have forgotten, must work over HTTPS or become unreachable in preloaded browsers. Removal from the list is possible but propagates over browser release cycles, which take months, so a site that preloads and then needs plain HTTP somewhere is stuck. The HSTS guide discusses when preloading is worth it.
How to fix it
Before submitting, inventory subdomains (certificate transparency logs at crt.sh are a good start) and confirm each serves HTTPS. Then serve the qualifying header on the apex domain over HTTPS:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadMake sure the port-80 redirect stays on the same host. This nginx pair satisfies the rule: HTTP goes to HTTPS on the same name, and the www canonicalisation happens over HTTPS afterwards.
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
return 301 https://example.com$request_uri;
}Apache:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"Cloudflare's HSTS panel has an explicit "Preload" toggle that adds the token. Finally, submit the domain at hstspreload.org and wait for the status to change from pending to preloaded. If you are not ready for a permanent commitment, keep the same header without the preload token: you still get full HSTS protection for returning visitors.
Where this fits
HSTS preload eligibility is check 11 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits TLS 1.3 support (low), where the server negotiates TLS 1.2 at best and does not offer TLS 1.3. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
HSTS preload eligibility closes one route in. The next one down is HTTP/2 support, where the server negotiates only HTTP/1.1 over TLS and does not advertise HTTP/2.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: HSTS preload eligibility (info severity)
Scanner check id: hsts-preload-readyThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
