Why HTTPS Alone Is Not Enough
Most sites moved to HTTPS years ago, but HTTPS by itself leaves a small, dangerous gap. The very first time a browser visits your domain, it often tries the insecure version first, then follows your redirect to the secure one. That initial unencrypted request is a window an attacker on the same network can exploit to intercept the connection before the redirect ever happens. HTTP Strict Transport Security, or HSTS, closes that window by instructing the browser to only ever connect to your site over HTTPS, no insecure first hop allowed.
HSTS is delivered through a single HTTP response header, Strict-Transport-Security, and an HSTS checker reads that header from your live site and decodes it. It tells you whether the header is present at all, how long the policy lasts, whether it covers your subdomains, and whether you have opted into the browser preload list that hardcodes your domain as HTTPS-only into the browsers themselves. The result is a clear picture of how completely your site enforces secure connections.
This is a security and trust feature first, but it touches SEO because Chrome and quality scanners reward proper HTTPS enforcement, and because a man-in-the-middle attack that succeeds because HSTS was missing can poison your rankings overnight through injected content or malware warnings.
The Three Parts of the Header the Checker Parses
The Strict-Transport-Security header is short but every piece carries weight. The first and required part is max-age, a number of seconds telling the browser how long to remember that this site is HTTPS-only. The checker reads this value and converts it to something human, because a max-age of a few minutes is almost useless while the recommended value is roughly a year. A short max-age means the protection evaporates quickly if a user does not return, leaving the insecure-first-request gap open again.
The second part is includeSubDomains, a flag that extends the HTTPS-only rule to every subdomain under your domain, not just the exact host. Without it, the policy protects only the hostname that sent the header, leaving any subdomains exposed. The checker reports whether this flag is present, which matters enormously for sites that run apps, blogs, or login portals on subdomains. The third part is preload, a flag that signals your intent to be included in the browser preload list, which is the strongest form of HSTS because it removes even the very first request from the equation.
Understanding Preload-List Eligibility
The HSTS preload list is a database baked directly into Chrome, Firefox, Safari, and other browsers. Domains on it are treated as HTTPS-only from the user's very first visit, before any connection is made, because the browser already knows the policy. This is the gold standard, but getting on the list has strict requirements that the checker evaluates so you know whether you qualify before you submit. The header must include the preload directive, must set includeSubDomains, and must have a max-age of at least the minimum the list requires, which is a year in seconds.
On top of the header rules, your site must serve a valid certificate, redirect from HTTP to HTTPS on the same host, and serve the HSTS header on the HTTPS root. The checker flags which of these conditions are met and which are missing, so the output is not just yes or no but a readiness report. Treat preload eligibility as a deliberate decision rather than a box to tick, because once you are on the list, removing your domain is slow and your entire domain and all subdomains are committed to HTTPS forever.
How to Read the Output
Start with presence. If there is no Strict-Transport-Security header, you have no HSTS protection at all, regardless of how good your HTTPS setup otherwise looks, and that is the first thing to fix. If the header is present, read max-age next. A value far below a year is a warning: the policy is technically active but too short to be robust, and it disqualifies you from preload. The checker translates the raw seconds so you do not have to do the math.
Then read includeSubDomains and preload as two independent flags. Missing includeSubDomains is fine for a single-host site but a real gap for anyone running subdomains. The preload flag should only be set if you genuinely intend to join the list and have confirmed every subdomain can serve HTTPS, because preloading a domain whose subdomains are not all HTTPS-ready will break those subdomains in browsers. The eligibility summary ties it together, telling you whether your current header would be accepted by the preload list.
The Mistakes That Cause Real Damage
The most dangerous mistake is setting preload and includeSubDomains before every subdomain is ready for HTTPS. Once browsers see the preload directive and the domain lands on the list, any subdomain that cannot serve a valid HTTPS connection becomes completely unreachable in those browsers, with no insecure fallback. This has taken internal tools and legacy subdomains offline for users for weeks. The safe sequence is to roll out HTTPS everywhere first, verify it, then raise max-age, then add includeSubDomains, and only finally add preload.
A subtler mistake is a too-short max-age that gives a false sense of security. People copy a header with a small value from a tutorial and assume they are protected, when in reality the policy expires before most users return. Another is setting the header only on the bare domain and forgetting that includeSubDomains is what actually covers the rest of the estate. Finally, some teams add preload to the header without ever submitting to the official list, which does nothing on its own; the directive is a precondition for submission, not the submission itself.
HSTS, Trust Signals, and AI-Era Search
HSTS does not directly move you up the rankings, but it lives in the same neighborhood of signals that modern search and AI systems use to gauge whether a site is well run and safe. Chrome's security and best-practices audits check for it, and those audits feed the page-experience picture. More importantly, HSTS prevents the kind of compromise that destroys search visibility: a successful interception that injects spam, redirects users, or triggers a malware warning can get a site flagged in Safe Browsing and dropped from results, and recovering is slow and painful.
As AI answer engines and assistants increasingly act on behalf of users, the integrity of the connection between user and site matters more, not less. A site that enforces HTTPS rigorously is a site whose content cannot be tampered with in transit, which protects the accuracy of what AI systems read and cite from you. Strong transport security is part of being a dependable source in an ecosystem where machines, not just people, are consuming your pages.
How HSTS Fits With Your Other Headers and Redirects
HSTS does not work in isolation, and reading its header alongside the rest of your setup is what turns a passing check into real protection. The header only takes effect when the browser receives it over a valid HTTPS connection, so it must be served on your secure responses, not on the plain HTTP version. If your HTTP site does not redirect to HTTPS in the first place, the browser may never reach the response that carries the policy, and HSTS never engages. The redirect and the header are partners: the redirect gets the user onto HTTPS once, and HSTS keeps them there forever after.
This is also where common misconfigurations hide. Sending HSTS from the HTTP response is meaningless, because browsers ignore the header unless it arrives over a secure connection, yet plenty of servers are set up to add it everywhere indiscriminately. A redirect chain that bounces through several hops before landing on HTTPS weakens the guarantee and slows the first load. The cleanest pattern is a single redirect from HTTP straight to the canonical HTTPS host, with HSTS set on that HTTPS response, and then the same header consistently present on every subsequent page.
It also pairs naturally with the other security headers a scanner looks for, like Content-Security-Policy and the frame and content-type protections. HSTS guarantees the channel is encrypted, while those other headers govern what may run inside the page once it loads. Treating them as one coherent set, rather than ticking each off in isolation, is what produces a genuinely hardened site rather than a partial one that passes some audits and fails others. When you re-run this checker, glance at whether the rest of that set is present too, because they protect against complementary threats.
What to Do After You Run the Check
If the header is missing, add Strict-Transport-Security to your HTTPS responses with a max-age of around a year, after confirming your entire site genuinely works over HTTPS. Re-run the checker to confirm the header is now present and the max-age reads correctly. If the header exists but the value is short, raise it, because a long max-age is what makes the protection durable and unlocks preload eligibility.
If you want the strongest possible protection, work toward preload deliberately: confirm every subdomain serves HTTPS, add includeSubDomains, raise max-age past the minimum, add the preload directive, and only then submit to the official preload list. Use the checker's eligibility summary as your pre-flight checklist before submitting, because fixing a botched preload after the fact is far harder than getting it right the first time. Re-check periodically, since a server migration or config change can silently drop the header and quietly reopen the gap you closed.