The HSTS SEO question usually arrives in a site audit. A tool flags the header as missing, the report files it under SEO, and someone has to decide whether it matters. The short answer is that HSTS is a security setting with a small performance side effect, not a ranking signal.
That does not make it optional for every site. It makes it a decision about security and risk, which is a better frame than chasing a score.
What is HSTS?
HSTS stands for HTTP Strict Transport Security. It is a response header, Strict-Transport-Security, that your server sends with HTTPS pages. MDN’s reference page on Strict-Transport-Security describes what it does: the header “informs browsers that the host should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be upgraded to HTTPS.”
There is a second effect that matters as much. Once a browser has seen the header, it will not let the user click through a certificate error on that host. A certificate problem that a visitor could once ignore becomes a hard stop.
The browser remembers the instruction for as long as the header says to. That memory is the whole point, and also the source of the risk.
The header and its directives
The syntax is short. A typical header, the example MDN gives for a two-year policy that covers subdomains and opts in to preloading, looks like this:
Each part does a distinct job:
| Directive | Required? | What it does |
|---|---|---|
max-age=<expire-time> | Yes | How long, in seconds, the browser should remember to use HTTPS only |
includeSubDomains | Optional | Applies the rule to every subdomain of the host as well |
preload | Optional | Signals consent to preloading; requires max-age of at least 31536000 (1 year) and includeSubDomains |
One rule catches people out in testing. “Browsers ignore the header if sent over HTTP”, as MDN puts it. The header only takes effect when it arrives over a secure connection, so adding it to your HTTP responses does nothing. Your HTTP to HTTPS redirect still has to do the first visit’s work.
Is HSTS necessary for SEO?
Not for rankings. There is no Google statement that rewards the header, and it would be wrong to claim one. Search engines judge the HTTPS version of your pages, and HSTS does not change what those pages contain.
Where it helps is the path a returning visitor takes. Without HSTS, someone who types your domain without the scheme, or follows an old http:// link, makes a request over HTTP and gets redirected. With HSTS remembered, the browser upgrades the request itself before it leaves the device. That removes one redirect hop for those visitors and means the insecure request never happens.
- Security. It closes the window in which a first request over HTTP could be intercepted or tampered with, for any visitor whose browser already holds the policy.
- Speed. A skipped redirect is a small saving, but it applies on every affected visit.
- Consistency. It reinforces the HTTPS version you already chose as canonical.
It does not replace the redirects themselves. First-time visitors and crawlers still rely on a permanent redirect from HTTP to HTTPS, which is why the choice between redirect types still matters; see 301 vs 302 redirects. And it does nothing about insecure resources inside your pages, which is a separate problem covered in our guide to mixed content.
The preload list and why it is hard to undo
A browser only learns your HSTS policy after its first secure visit. Preloading closes that gap. Google runs the HSTS preload service at hstspreload.org, and major browsers use the list, so a domain on it is treated as HTTPS-only before a visitor has ever been there.
The cost is commitment. Preloading requires includeSubDomains, so every subdomain you own must serve HTTPS properly. An old staging host, an internal tool on a subdomain, a mail or marketing service pointed at your domain: if any of them only work over HTTP, preloading will make them unreachable in browsers that use the list.
Getting off the list is not instant either. Removal has to propagate into browser releases, and visitors’ browsers that cached a long max-age keep enforcing it until it expires. That is why the preload directive should come last, not first.
How to roll HSTS out safely
The safe pattern is to start small and lengthen the policy once nothing breaks.
- Confirm HTTPS works everywhere. Every page, every subdomain you plan to include, and a valid certificate on each.
- Start with a short
max-ageand withoutincludeSubDomains. A mistake then expires quickly. - Watch for problems. Check monitoring, support requests and any services on subdomains.
- Lengthen the policy and add
includeSubDomainsonce you are confident every subdomain is ready. - Consider preload last, with a
max-ageof at least a year, and only if you are sure you will never need HTTP on any part of the domain.
A cautious first header might look like this:
To check what your server actually sends, request a page over HTTPS and read the response headers. From the command line:
If nothing comes back, the header is not being sent on that response. Check more than the home page: headers are often set per server block or per application, so one template, subdomain or CDN rule can be missing it while the rest of the site is covered. It is also worth confirming the value you see matches the one you configured, because a plugin, a CDN setting and the web server can each add their own copy. Where two conflicting headers appear, fix the configuration so only one source sets it.
HSTS is a natural step during a move to HTTPS or a hostname change. If you are standardising on one version of the domain at the same time, our guide to www vs non-www covers that choice, and the wider checklist sits in site migration SEO. Add HSTS after the redirects and certificates are stable, not during the switch.
Who should use HSTS
Any site that is fully on HTTPS and intends to stay there should send the header with a sensible max-age. The cost is close to nothing and the security gain is real, particularly on pages with logins, forms or payments.
Preloading is a different decision. It suits domains you control completely, where every subdomain is managed by people who know the rule exists. It is a poor fit for an organisation whose subdomains are scattered across teams and third-party services, because one forgotten HTTP-only host becomes a broken one.
One limitation is worth stating. Whether HSTS changes anything measurable for you depends on how many visitors return and how often they arrive through HTTP links or typed addresses. Analytics will not show you the redirect hops that no longer happen, so judge the header on security rather than expecting a visible change in search data.
Frequently asked questions
What does HSTS stand for?
HTTP Strict Transport Security. It is the Strict-Transport-Security response header, which tells browsers to use only HTTPS for your host.
Is HSTS a ranking factor?
No. Its SEO value is indirect: returning visitors skip the HTTP to HTTPS redirect, and the insecure first request never happens.
Is HSTS necessary if I already redirect HTTP to HTTPS?
It is not required, but it is recommended. The redirect still handles first visits; HSTS stops later requests going out over HTTP at all.
What does HSTS preload require?
A max-age of at least 31536000 seconds (1 year) and the includeSubDomains directive, so every subdomain must serve HTTPS.
The takeaway HSTS is a security header, not a ranking lever. Send it on a fully HTTPS site, start with a short max-age, and treat preloading as a near-permanent commitment.
