Why HSTS preloading needs stricter criteria than the header alone

A normal HSTS header protects visitors only after their first HTTPS visit to a site — the very first request, before the browser has ever seen the header, is still vulnerable to a downgrade attack. The HSTS preload list solves that gap by baking a fixed list of HTTPS-only domains directly into the browser itself, so protection applies from the first request ever, with no bootstrap gap. Because being on that list is essentially permanent and hard to reverse (removal can take months to propagate to already-shipped browsers), the eligibility bar is deliberately strict: a full year of max-age, subdomains included, and an explicit opt-in `preload` directive — all three exist specifically to make sure a site isn't added to an irreversible, browser-baked list by accident.

Why passing these three checks still isn't the same as being preloaded

This tool verifies the header itself meets the three technical prerequisites, but actual inclusion on the preload list requires submitting the domain at hstspreload.org, where Google's team (and automated checks) verify the site — including that every subdomain genuinely serves valid HTTPS, since `includeSubDomains` makes a real promise about the entire domain tree, not just the one URL checked here. A domain can pass every check this tool runs and still fail submission if some subdomain isn't actually HTTPS-ready, which is exactly why this tool frames a clean result as meeting the "basic criteria" rather than confirming preload status outright.