Cloudflare

HSTS looks simple until you have more than one environment. On paper, it’s one header: Strict-Transport-Security: max-age=31536000; includeSubDomains In real teams, that header touches local development, preview deployments, staging subdomains, internal tools, CDNs, load balancers, and production rollback plans. That’s where people get burned. I’ve seen teams enable HSTS in production, break staging, lock developers out of test hosts, and then discover they can’t “just turn it off” because browsers cached the policy exactly like they were supposed to. ...

HSTS on Cloudflare Pages looks easy right up until it isn’t. You add a Strict-Transport-Security header, verify it in the browser, and move on. Then a week later you realize preview URLs behave differently, your apex domain redirects through a weird chain, or someone turned on preload without thinking about subdomains that still speak plain HTTP. I’ve seen this pattern a lot: HSTS gets treated like a checkbox. It’s not. On Cloudflare Pages, it’s simple to enable, but easy to misconfigure in ways that are annoying at best and production-breaking at worst. ...

If you’re using Cloudflare in front of your site, turning on HSTS is one of those small changes that can meaningfully tighten security with almost no ongoing maintenance. But it’s also one of those settings that’s easy to misunderstand, and if you flip it on carelessly, you can absolutely lock yourself into HTTPS behavior before your site is fully ready. So let’s do this the practical way: what HSTS actually does, what Cloudflare changes, the safe rollout path, and exactly where to click. ...