Welcome to HSTS Guide

HTTP Strict Transport Security, or HSTS, is one of those headers that’s boring right up until it saves you from a nasty downgrade attack. If you run a Hono app over HTTPS, you should probably send it. The browser sees the header once over a secure connection, remembers it, and refuses to talk to your site over plain HTTP for the configured period. That cuts off a whole class of “strip HTTPS and hope the user doesn’t notice” nonsense. ...

HTTP Strict Transport Security, or HSTS, is one of those headers that looks trivial until you ship the wrong value and lock yourself into a bad decision for months. If you deploy on Netlify, adding HSTS is easy. Adding it safely takes a bit more thought. This guide covers the practical side: what HSTS actually does, how to configure it on Netlify, how to avoid common mistakes, and how I’d roll it out on a real production site. ...

HTTP Strict Transport Security is one of those headers that looks trivial until you ship it wrong and lock users into a bad config for months. If you run apps on Azure or GCP, the main challenge usually is not the header itself. It’s figuring out where to set it so it’s applied consistently, survives redirects, and doesn’t get stripped by a proxy, CDN, or app server. This guide is the practical version: what to send, where to send it, and copy-paste examples. ...

How HSTS Affects SEO HSTS does not directly improve rankings. That’s the short version. Google is not handing out bonus points because you send Strict-Transport-Security. But HSTS absolutely affects the things that do impact SEO: crawl efficiency, duplicate URL handling, redirect behavior, mixed protocol issues, and how cleanly your site behaves during HTTPS migrations. If you run a production site, HSTS is less about “SEO optimization” and more about removing protocol ambiguity. Search engines like predictable sites. HSTS helps force that predictability. ...

HTTP Strict Transport Security looks simple: send one header, force HTTPS, move on. In practice, HSTS failures are boring, subtle, and easy to miss until production traffic hits an unexpected edge case. I’ve seen teams “enable HSTS” and still leave redirect loops, missing subdomains, CDN overrides, and preload-breaking configs in place. The header was technically there, but the deployment was not actually trustworthy. If you want to audit HSTS properly, compare multiple methods. No single check catches everything. ...

GitHub Pages makes HTTPS easy. HSTS is where people usually get tripped up. The short version: if you use the default *.github.io domain, GitHub handles HTTPS and HSTS for you. If you use a custom domain, you need to understand what GitHub controls, what your DNS provider controls, and one annoying limitation: you generally can’t arbitrarily add or tune response headers on GitHub Pages itself. That limitation matters because HSTS is just an HTTP response header: ...

HTTP Strict Transport Security sounds simple: send one response header and browsers stop using plain HTTP for your domain. With AWS API Gateway, it’s a little messier. The short version: API Gateway can return Strict-Transport-Security, but whether HSTS actually helps depends on how clients reach your API, whether you use a custom domain, and whether any HTTP endpoint still exists in front of it. If you only remember one thing, remember this: HSTS protects browser traffic for hostnames, not APIs in the abstract. If your API is consumed by server-to-server clients, mobile apps, or SDKs, HSTS is mostly irrelevant. If your API is called from browser-based apps on a custom domain, then it absolutely matters. ...

HSTS report-only mode sounds like something browsers should support. They don’t. That’s the first thing worth clearing up, because a lot of developers go looking for a Strict-Transport-Security-Report-Only header and assume they just haven’t found the right syntax yet. There is no standardized HSTS report-only header implemented by browsers in the way Content-Security-Policy-Report-Only works. So if you’re trying to safely “test” HSTS before enforcing it, the real answer is a mix of: ...

HSTS looks deceptively simple. One header, one line, done. That’s exactly why teams get it wrong. I’ve seen production rollouts where HSTS was added in a hurry, tested once in Chrome, and then forgotten until something broke: login subdomains stopped working, staging got pinned to HTTPS, or preload got enabled before the company actually controlled every edge of its domain. The header itself is easy. The operational blast radius is where people mess up. ...

Moving a site from HTTP to HTTPS sounds easy until you do it on a real production system with old links, mixed content, proxies, CDNs, and a few mystery services nobody wants to touch. Then HSTS enters the picture and raises the stakes, because once browsers cache that policy, mistakes stop being easy to undo. That does not mean HSTS is risky in a bad way. I’d still recommend it for most public sites. But I would not enable it blindly on day one with a one-year max-age and preload unless I was very sure the whole stack was clean. ...