HSTS preloading hardcodes your domain into browsers' source code as HTTPS-only from the very first connection, before any HSTS header is even received — a stronger guarantee than standard HSTS, but a slower, more deliberate process to set up correctly.
Prerequisites before submitting
- A valid certificate, with HTTPS working correctly across the entire domain and every subdomain
- A redirect from HTTP to HTTPS on the root domain
- The HSTS header served with
max-ageof at least one year, plus bothincludeSubDomainsandpreloaddirectives - Every subdomain, without exception, serving valid HTTPS — since
includeSubDomainsmeans the preload policy applies to literally everything under your domain
Submitting
Once the above is confirmed stable, submit your domain at hstspreload.org, which checks your current header configuration automatically and adds you to the list if everything qualifies. Removal, if ever needed, is a much slower process — it requires updating the source list and waiting for that change to propagate through new browser releases, potentially taking months, which is why confirming readiness beforehand matters so much more here than for standard HSTS.
What to do if hstspreload.org rejects your submission
A rejected submission typically lists the specific criteria your current configuration doesn't meet — max-age too short, includeSubDomains missing, or a subdomain not properly serving HTTPS — addressing the specific listed issue and resubmitting is straightforward once you know exactly what's failing.
How to check whether your domain is already on the preload list
Searching your domain directly at hstspreload.org shows its current status, whether it's already included, pending, or not yet submitted — worth checking before assuming submission is necessary, particularly for a domain that may have been added previously by a different team member.
What removal from the preload list actually involves if you later need it
Requesting removal through hstspreload.org's own removal process is possible but deliberately slower than addition, and browsers already shipped with the old list will continue enforcing the policy until they update — removal should be considered a last resort rather than a routinely reversible decision.
How to verify your site meets every preload requirement before submitting
hstspreload.org's own submission form automatically checks your current HSTS header configuration against every requirement before allowing submission, immediately flagging any unmet criteria — running this check yourself before attempting submission saves a round trip if something isn't quite ready yet.
Why organizations sometimes wait months after enabling standard HSTS before pursuing preloading
Given preloading's near-permanence, many organizations deliberately run standard HSTS with a full one-year max-age for an extended period first, building confidence that HTTPS is stable and correctly configured across every current and reasonably foreseeable subdomain, before committing to the harder-to-reverse preload list.
What to do if your submission is rejected for a reason that seems already resolved
If a resubmission is rejected for an issue you believe you've already fixed, allowing time for any relevant DNS or configuration change to fully propagate before resubmitting, and double-checking the exact current state of your HSTS header directly rather than assuming a fix took effect, resolves most repeated rejections.
How preload list changes propagate across different browser release channels
A newly accepted preload list addition first appears in browsers' developer or beta channels before reaching the stable release channel most users run, meaning full propagation across your entire visitor base takes some additional time beyond the initial list acceptance — a detail worth knowing so you don't expect instant, universal enforcement immediately upon acceptance.
A closing note on preloading as the final, optional step in a broader HTTPS hardening journey
Preloading represents the final, most committed step in a broader HTTPS hardening progression — basic HTTPS, then HSTS, then preloading — each step adding a stronger guarantee at the cost of reduced flexibility, worth pursuing deliberately and in that order rather than jumping to the strongest option immediately.
A final thought on ongoing review, not just initial setup
Reviewing your HSTS and preload configuration periodically, particularly after adding any new subdomain, ensures your site remains fully compliant with the preload list's ongoing requirements rather than assuming a one-time setup remains correct indefinitely as your site evolves.