HSTS preload is easy to join and slow to leave

Strict-Transport-Security is a header telling a browser to use HTTPS for this host and to refuse anything else for a stated period. It works on the second visit, because the first one is what teaches the browser the rule.

Preloading closes that gap by shipping the rule inside the browser itself. Your domain goes into a list compiled into Chrome, and from there into the other browsers that consume it, so the very first request a user ever makes to your site is already forced to HTTPS. No initial plaintext request, nothing for an intermediary to intercept and rewrite.

It is a genuine security improvement and it is the closest thing in web operations to a decision you cannot take back this quarter.

What it costs to get in

The submission requirements are specific: serve a valid certificate, redirect HTTP to HTTPS on the same host if you listen on port 80, serve every subdomain over HTTPS, and send a header on the base domain with a max-age of at least one year, the includeSubDomains directive, and the preload token (hstspreload.org, submission requirements, consulted 1 August 2026).

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Four requirements, and the third one is doing more work than it appears to.

includeSubDomains means every subdomain, including the ones you forgot

Not the subdomains of the website. Every name under the domain, whether or not it has anything to do with the site, whether or not you know it exists.

The list on a typical client domain, once you go and look, includes some of these: a webmail interface on mail., a legacy intranet on old. reachable only from the office, a marketing microsite somebody built on campaign. in 2021, a monitoring endpoint, a printer or a device with a self-signed certificate, a vendor's white-labelled portal on portal. pointing at infrastructure you do not control, and a staging copy.

Every one of those must work over HTTPS with a publicly trusted certificate, permanently, from the moment the preload entry reaches browsers. Any that does not becomes unreachable, with no click-through available, for everyone whose browser has the list.

The vendor-controlled subdomain is the one that ends badly. You do not manage that certificate, you cannot renew it, and the day it lapses the portal is hard down for your client's staff with no way past. Which is the general property of preloading: it converts every certificate problem under the domain from a warning into an outage, and removes the visitor's escape hatch: what an expiry does when there is no way to click through.

Leaving

There is a removal form. Submitting it is quick. What follows is not.

The entry has to come out of the list, the list has to be compiled into a browser build, the build has to be released, and users have to update. The project's own guidance is explicit that removal takes months to reach users through Chrome updates, and that inclusion should not be treated as easily reversible.

Then there is the population that never updates. A browser that has stopped receiving releases carries the version of the list it shipped with, indefinitely. For a consumer site that group is small. For a client whose users are on managed corporate machines or kiosk devices, it is not.

So the honest planning horizon for a preload entry is not "we can undo this if it becomes a problem". It is the lifetime of the domain.

Who should not preload

Three cases, and the first one is most of an agency's portfolio.

A domain you may not be managing in three years. Preloading is a commitment made on the client's behalf that outlasts your contract. The next agency inherits a domain where any subdomain without a valid certificate is permanently broken, and they will not know why until they lose an afternoon to it. If you do it, it goes in the handover document in bold.

A domain used for things that are not the website. Any subdomain serving a protocol or a device that cannot hold a public certificate is a subdomain you are about to make unreachable over HTTPS. Check before, not after.

A domain where the certificate process is not proven. Preloading raises the cost of a renewal failure from "visitors see a warning" to "nobody can reach anything under this domain". Enable it after the automation has run without incident for long enough to trust, not as part of a launch checklist. There is a second commitment in the same family, baked into the certificate rather than sent as a header, with the same irreversibility and a worse failure mode now that the infrastructure behind it is being switched off: Must-Staple, and the responder that no longer answers.

The ramp that keeps the option open

Everything valuable about HSTS is available without preloading, and the header is entirely reversible because it expires.

Start with a short max-age, an hour or a day, and no includeSubDomains. Confirm nothing broke. Raise it in stages. Add includeSubDomains only after auditing every name under the domain, and leave it there for a few months with the max-age still short enough that a mistake ages out on its own.

Only then, if the security benefit of protecting the very first visit is worth a permanent commitment, add the preload token and submit. That last step is the only irreversible one, and by the time you reach it you will have already collected the entire benefit for returning visitors, which is most of the benefit.

One detail that catches people during the ramp: lowering max-age does not shorten the rule for browsers that already stored the longer one until they see the new header, and they only see it over HTTPS. If the site is unreachable over HTTPS, the header that would relax the rule cannot be delivered. That is the shape of the trap, and it is why the warning your visitors are looking at has no button on it: the error code underneath tells you which fault you have.

Checking what a domain currently commits to

curl -sSI https://example.com/ | grep -i strict-transport-security

Read three things: the max-age, whether includeSubDomains is present, and whether preload is. A domain sending the preload token that was never submitted is claiming a commitment it has not made, which is harmless but usually means somebody copied a snippet without reading it. A domain sending includeSubDomains with a year-long max-age has already made most of the commitment, submitted or not, for everyone who has visited.

Add that header to the per-hostname checks you already run, because it is a setting that gets reverted by panel updates and migrations without anyone noticing, in both directions: the same class of silent configuration drift that takes renewals with it.