Cloudflare HSTS Preload: The Hard-to-Undo Directive

HSTS preload is the one TLS knob that flips the bit from “your domain asks for HTTPS” to “every browser on the planet forces HTTPS for your domain.” The catch: the shipping channel is slow in both directions. The set is instant. The unset takes a full browser release cycle.

This guide covers what HSTS preload actually does inside Cloudflare, why removing it is harder than adding it, and the order of operations that keeps you out of trouble. If you’re just turning on Cloudflare’s HSTS toggle for the first time, read this before you check the preload box.

What HSTS preload does

HSTS preload pins your domain into the list browsers ship baked in. Visitors who type http://example.com get upgraded to https://example.com before the request leaves the browser — even on first visit, even before any TLS handshake.

Cloudflare’s “HSTS” sets the Strict-Transport-Security header. The “preload” toggle adds preload to it. Once your domain shows up in the hstspreload.org canonical list, Chrome and Firefox ship it in their next browser release.

Two things follow from this model that catch operators by surprise:

1. The browser never talks to your server before deciding to use HTTPS. If your TLS config breaks (expired cert, wrong hostname, broken chain), the browser refuses to fall back. There is no user prompt, no “this site is untrusted, continue anyway” detour. HTTPS or nothing.
2. First-visit upgrades happen without your header. Without preload, HSTS only takes effect once a browser has seen your Strict-Transport-Security header at least once. Preload removes that chicken-and-egg step entirely.

The first point is also why this matters for security. HTTP-strict-transport-security defends against the first-visit downgrade attack (the captive portal that strips TLS, the coffee-shop MITM). Preload makes that defense unconditional.

Why undoing is hard

Removing from hstspreload.org is a polite request — they remove the entry within days, but the browser updates take 6-12 weeks to roll out across versions. For those 6-12 weeks, every Chrome and Firefox user on the planet will force-HTTPS to your domain, regardless of whether your TLS config is currently valid.

The mismatch is structural. hstspreload.org is a tiny Chromium-team-maintained list. Each Chrome and Firefox build ships its own frozen copy. When you delete an entry from the source list, the team that pulls upstream doesn’t ship your deletion until the next major browser release — and even then, browser releases stagger across users over the same 6-12 week window. Safari’s preload list is maintained separately and has its own cadence.

A few practical implications:

• “Undoing” preload is not a state change. It’s a multi-month probabilistic transition that runs to completion regardless of whether you fix the underlying TLS problem.
• Users on older browser builds will continue to force-HTTPS at your domain long after the source list shows no entry. You cannot speed this up.
• During the 6-12 week window, every Chrome and Firefox user is a write-only signal. You can demonstrate that HTTPS works again, but you cannot demonstrate it to a browser that already cached the preload pin.

This is genuinely different from “I turned off a feature, give it a minute.” Treat the cooldown as a one-way ratchet.

The irreversible mistakes

Three patterns show up over and over in postmortems for sites that shipped preload too early:

1. Shipping preload before TLS is solid on all subdomains

HSTS preload covers the apex and all subdomains, full stop. There is no “preload only www” option. A single staging.example.com on a self-signed cert, a forgotten jira.example.com pointing at a decommissioned Jira instance, or a dev.example.com A record left dangling at a parking IP — any one of those becomes unreachable for 6-12 weeks if preload ships. The browser will request HTTPS, the destination won’t have a valid cert, and the user sees a hard error with no bypass.

The fix is mechanical: enumerate every A and AAAA record in the zone, confirm each one has a reachable HTTPS origin with a valid cert, and confirm every subdomain that could be created (wildcard coverage, internal-only hostnames) has a sane HTTPS story before you check the preload box.

2. Shipping preload before deciding on apex vs www

If you preload both example.com and www.example.com, you’ve committed. But picking one canonical hostname (which is the standard advice — apex or www, not both) means a later migration from “we serve on apex” to “we serve on www” is going to take weeks of broken bookmarks and a 6-12 week HSTS cooldown overlapping your DNS change. The two corrections do not compose cleanly.

The cleaner move: decide the canonical hostname first, serve both with HTTPS, redirect the loser to the winner for a few months, then think about preload.

3. Shipping preload during a domain migration

Domain transfers, registrant changes, and registrars that disappear mid-migration all have one thing in common: at some point during the process, DNS and TLS are simultaneously unhealthy. Preload during this window means visitors on cached browser builds cannot reach either party during the gap. The old registrant’s users — anyone who typed the URL before the migration — are locked out until the browser release train catches up.

If you’re in the middle of any kind of registrar/DNS transition, defer preload until at least one release cycle has passed and you’ve confirmed the new registrar is stable.

The right order

The cure-before-the-disease ordering is the whole point of this guide. There is no shortcut.

1. Set up TLS on the apex and every subdomain you’d care about. Enumerate first; don’t guess.
2. Enable HSTS in Cloudflare’s dashboard without preload — observe 30 days. This lets you collect real-world evidence that the header is being set, that all subdomains respond with valid certs, and that nothing breaks under your normal traffic patterns.
3. Enable preload only after the 30-day observation shows zero TLS issues. If anything tripped — a stale A record, a misrouted subdomain, a browser console warning about mixed content — fix it and restart the 30-day clock.
4. Submit to hstspreload.org via the form on the site. Submission is what triggers the actual pin in the source list; the Cloudflare “preload” directive alone is not enough.
5. Verify removal is possible before you need it. Try removing the entry from hstspreload.org and confirm the removal pipeline is real (it is). This is a small upfront exercise that buys you a lot of confidence that the channel works in your favor if you ever need it.

The full sequence takes one calendar month of patience plus one submission. That is dramatically cheaper than 6-12 weeks of stranded subdomains.

What not to do

• Don’t enable preload on the first day you get Cloudflare. There is no benefit to skipping the 30-day observation window, and every reason not to.
• Don’t enable preload during a domain migration. The two processes do not compose; pick one at a time.
• Don’t enable preload on a hostname shared with services that don’t support HTTPS yet (e.g., MX ports, FTP). Preload is apex-wide and includes all ports; a single plaintext service sharing the hostname is enough to break the preload for everyone using HTTPS to that host.
• Don’t enable preload without measuring visit patterns first — a long-tail operator with infrequent visits and a shaky TLS setup might regret the 6-12 week undo window more than they benefit from the first-visit upgrade.

A general rule of thumb: preload is for domains where TLS is permanent, well-tested, and not about to change. If any of those three is false, the 30-day observation window is doing real work — don’t skip it.

Verification checklist

#	Command	What it proves
1	curl -sSI https://<your-domain>/ | grep -i strict-transport	HSTS header present
2	curl -sSI https://<your-domain>/ | grep preload	preload directive sent
3	https://hstspreload.org/ has your domain	Shipped in browsers
4	Every subdomain has its own valid cert	No stranded-hostname trap

Run checks 1 and 2 against the apex. Check 3 against the source list — note that “in the source list” still takes a release cycle to reach users, but it confirms your submission was accepted. Check 4 against every A and AAAA record in the zone, including any you forgot you had; this is the one check operators skip and then regret.

Sources

• Cloudflare HSTS docs
• hstspreload.org
• ABS companion: Cloudflare Tunnel Setup for a Static Site

Last verified: 2026-07-14; HSTS preload not yet enabled on agenticbotsitter.com (operator has deferred).