HSTS preload is a trap until it is not

HSTS preload is a trap when you enable it too early, and it stops being one only after HTTPS has been stable for a long time. The HSTS header tells a browser to use HTTPS on the next visit. Preload goes further and puts your domain in a list that ships inside Chrome and Firefox, so you cannot clear it with a cPanel click. Do not submit during a migration. Start with a small max-age, keep preload off until you mean it forever, and treat removal as slow.

Header control versus the preload list

You control the Strict-Transport-Security header on your site. You can lower max-age, remove the directive, and wait for browsers to forget it. Preload is a submission to a public list that browsers bake into their releases. Removal exists, but it takes a long time to reach every user. Treat preload as a one-way door with a long hallway behind it.

IncludeSubDomains plus preload is a larger promise. Apex and www are different names, and preload often expects includeSubDomains. A forgotten blog or staging name still on HTTP can break for anyone on a current browser. Inventory every hostname first. Do not preload a name whose certificate still fails on phones, a site with a long redirect chain, or a shop you plan to move soon.

Why migration weekends go wrong

You pointed DNS at a new host and AutoSSL has not finished yet. Old HSTS headers may still sit in browsers, and preload may already live in the binary. Visitors cannot click through an HTTP fallback the way they could before. That is the trap, and it becomes an outage if you submitted months ago and moved today.

Do not enable preload on the Friday of a cutover. Saturday you may need HTTP-01 on a name you forgot, or you may find a missing intermediate that only phones notice. Fix the certificate chain before you raise max-age. If you already submitted, say so in the first line of your support ticket. We cannot un-ship Chrome for you.

Turn HSTS on in this order

1. Confirm HTTPS works on apex and www, including phones. Use curl on both http and https; one clean 301 is the goal.
2. Set HSTS with a small max-age measured in minutes, then days. Leave the preload flag off.
3. Wait weeks while nothing breaks. Raise max-age only after that. Inventory subdomains before includeSubDomains.
4. Submit to the preload list only if you still want it, and never during a host or DNS move.

Read the header you actually send:

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

The header is what matters. A blog post that says “add preload” is not a header on your server. If the preload token is already in your header and you have not submitted, remove it until you intend to. The submission crawler looks for that token, and leaving it on is how an automated scanner can submit you as a favor.

On cPanel accounts we issue certificates with AutoSSL and Let’s Encrypt when DNS points here correctly. Get that boring and reliable first. Preload is optional polish for sites that will stay on HTTPS without exception for the long haul.