In one paragraph
HSTS preload not ready means an observed HSTS header lacks one or more values this check expects for preload eligibility. It does not mean ordinary HSTS is ineffective or that preloading is mandatory. Review your entire subdomain estate before adding includeSubDomains and preload, verify the current submission requirements, and treat list inclusion as a separate process from editing a header.
Why it matters
Ordinary HSTS is learned from a valid HTTPS response and remembered for its lifetime. A browser that has not learned it may still attempt an initial HTTP request. A preload list supplies prior knowledge in participating browsers, reducing reliance on that first successful HTTPS exchange.
The wider commitment matters more than the header's length. includeSubDomains covers descendants of the host issuing the policy. Preloading an apex domain therefore commits its subordinate web hosts to working HTTPS for browsers applying the entry, including internal or delegated hosts you may have forgotten.
Preloading is optional hardening. A site can have a sound HTTPS configuration and long-lived HSTS without it. Do not describe failure to preload as a broken security baseline or an automatic search-ranking problem.
How WebAuditOS evaluates this finding
The supplied check grades HTTPS pages that already send HSTS. max-age of at least 31,536,000 seconds, includeSubDomains, and preload satisfy its header-shape requirement. A missing or insufficient value warns informationally. Without an HSTS header, this specific rule is not graded.
It does not establish list membership, verify all submission requirements, or inspect the apex when a different host was scanned. The documented token matching and max-age parsing have limits, including quoted-age handling. A pass on www does not prove example.com is eligible or actually preloaded.
How to fix it
- Decide whether preloading fits your operations. Identify who controls DNS, certificates, delegated subdomains, internal browser services, and future hostname creation. Do not add a consent token to satisfy an informational finding before this decision is owned.
- Inventory subdomains using DNS and operational records, not memory alone. Confirm valid HTTPS for applicable existing web hosts and understand the effect on HTTP-only tools. A third-party CNAME does not transfer the responsibility for your hostname's certificate to the browser.
- Establish reliable HTTPS and a staged HSTS rollout first. Increase max-age deliberately and test includeSubDomains only after the wider scope is ready. A host-only trial does not exercise every descendant's compatibility.
- Once ready, serve the required policy from the base domain's HTTPS responses. A typical eligible header is:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadThe header alone does not submit the domain or verify eligibility. Keep it on relevant HTTPS redirect responses too, not merely the eventual landing page.
- Check the current requirements at the official preload service. They include a valid certificate, HTTPS for subdomains, same-host HTTP-to-HTTPS redirection if listening on port 80, and the required HSTS values on the base domain. If www exists in DNS, it must satisfy the stated HTTPS requirement as well.
- Submit only when the eligibility checks pass and the organisation accepts the scope. Inclusion and propagation depend on the service and browser release processes. Do not tell users that adding preload makes the first visit protected immediately.
- Check actual list status separately from the header scan. Test apex, www, important subdomains, and certificate renewal. Retain independent monitoring so an HTTPS outage is detected before users encounter a non-bypassable failure.
- Keep a documented removal and incident plan. Removal is possible but slow; do not assume removing the token or sending max-age=0 updates preloaded browser state instantly.
What the fix can break
A host without working HTTPS can become inaccessible to affected browsers when a parent policy applies. includeSubDomains causes that commitment even before list inclusion for browsers that have learned the parent header.
Preload expands the reach of that commitment beyond prior visitors and makes rollback dependent on distribution updates. Some older installations may keep stale list state. A removal request is not an immediate emergency switch.
Leaving a justified non-preloaded HSTS configuration in place is a legitimate outcome. Document that decision instead of weakening the meaning of readiness or pretending a header-only pass certifies your entire DNS estate.
Questions
Does adding preload automatically put the domain on the list?
No. It signals readiness or consent under the service's process, but submission, acceptance, and distribution are separate. Verify actual status.
Is preloading required for every website?
No. It is an optional commitment with operational consequences. Ordinary HSTS and correct HTTPS remain useful without it.
Why did www pass while the submission failed?
The scanner inspected an observed page header; submission checks the base domain and other requirements. Those are different scopes.
What should I review next?
Review missing HSTS and HTTPS redirects before considering preload complete.