What is HSTS (HTTP Strict Transport Security)?
HSTS is an HTTP response header that tells browsers to connect to a site only over HTTPS for a set period, blocking downgrade attacks.
HSTS (HTTP Strict Transport Security) is a security policy a site declares with the Strict-Transport-Security response header. Once a browser has seen it over a valid HTTPS connection, the browser refuses to use plain HTTP for that host until the policy expires: typed http:// links are upgraded internally before any request leaves the device, and certificate errors can no longer be clicked through. The mechanism is defined in RFC 6797.
The header
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age— how long, in seconds, the browser should remember the policy (31536000 = one year).includeSubDomains— apply the policy to every subdomain too.preload— signals consent to inclusion in browsers’ built-in preload list. It isn’t part of the RFC; it’s used by the HSTS preload list maintained by the Chromium project and shared with other major browsers.
In Nginx, send it on HTTPS responses only:
server {
listen 443 ssl;
server_name www.example.com;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}
Why it matters
Without HSTS, a visitor who types example.com makes a first request over HTTP and depends on your 301 redirect to reach HTTPS. On a hostile network, that first unencrypted request can be intercepted and the user kept on a fake HTTP version — an SSL-stripping attack. HSTS closes that gap for returning visitors, and the preload list closes it for first visits too.
There is a performance benefit: for HSTS-aware browsers the HTTP-to-HTTPS hop disappears, because the browser upgrades the URL itself (developer tools show it as an internal 307 redirect). HSTS isn’t a ranking factor, but it completes a clean HTTPS setup that Google and users already expect.
Rolling it out safely
- Confirm every page and subdomain works over HTTPS with a valid certificate.
- Start with a short
max-age, such as 300 seconds, and watch for problems. - Increase to a week, a month, then a year.
- Add
includeSubDomainsonly once every subdomain — including old staging hosts, mail and intranet tools — supports HTTPS. - Submit for preloading last, and only if you are sure. The preload list requires a
max-ageof at least one year,includeSubDomainsandpreload, and removal takes months to reach users’ browsers.
Common mistakes
- Sending the header over HTTP, where browsers ignore it by design.
- Preloading a domain while an HTTP-only subdomain still exists, which then becomes unreachable in browsers.
- Setting a long
max-agebefore HTTPS is stable, locking visitors out if the certificate breaks. - Assuming HSTS replaces the server-side redirect. Keep the redirect for first-time visitors, crawlers and clients that don’t support HSTS.
How to check
The Security Headers Checker grades your Strict-Transport-Security header along with the other security headers, and gives copy-paste fixes for Apache, Nginx and Cloudflare. The SSL Checker confirms the certificate and HTTP-to-HTTPS redirect HSTS depends on.
Frequently asked questions
Is HSTS a ranking factor?
No. HSTS is a security measure, not a ranking signal. It complements HTTPS, which is a lightweight signal, and it removes the HTTP-to-HTTPS redirect hop for returning visitors.
What max-age should I use for HSTS?
Start small, such as 300 seconds, while you test. Once HTTPS works everywhere, move to one year (31536000 seconds), which is also the minimum for the preload list.
Can I undo HSTS?
Send the header with max-age=0 to clear it in browsers that see it. Removal from the preload list is possible but slow, which is why you should preload only when you are certain.