HSTS Preload — Closing the First-Visit Gap, Permanently
HSTS tells a browser to use HTTPS for a domain for a stated period, even if a link or a typed address says otherwise. Preloading goes further: the domain is compiled into browsers themselves, so the rule applies before a visitor has ever connected. This checks the header and whether the domain meets the preload requirements.
When it helps
Because the header alone leaves a real gap. A visitor who has never been to your site has no HSTS policy for it, so their first request can still go over plain HTTP and be intercepted before the redirect happens. Preloading is what closes that specific hole. It is also the only way to protect against an attacker stripping the redirect entirely on a hostile network.
Worth running automatically
Preloading deserves a warning that the check itself will give you: it is close to irreversible on any useful timescale. Removal requires a submission and then waiting for browser releases to propagate, during which every subdomain must serve valid HTTPS. If you preload with includeSubDomains and later need an internal subdomain on plain HTTP, you cannot have one. That makes continuous certificate monitoring across every subdomain a precondition rather than a nice-to-have — under preload, an expired certificate on any subdomain is a hard outage with no click-through.
What you get out of it
Closes the first-visit interception gap that the header alone leaves open, with a clear view of the commitment involved — which is the part most guides omit.