HSTS, or HTTP Strict Transport Security, is a response header that tells browsers to only ever connect to your site over HTTPS, never plain HTTP, for a set period. It closes a real attack window: without it, a user typing your domain or clicking an http link makes an insecure first request that can be intercepted and downgraded. With HSTS, the browser refuses HTTP entirely and upgrades automatically. It is a small header with a large security payoff and is widely expected on any site handling logins or payments.

max-age is the number of seconds the browser should remember to use HTTPS only for your domain. A common production value is 31536000, which is one year. Short max-age values weaken protection because the rule expires quickly, while a long value keeps users protected between visits. The checker reads your max-age, converts it to a human-readable duration, and flags values that are too short to be meaningful or are set to zero, which disables HSTS.

includeSubDomains extends the HTTPS-only rule to every subdomain of your domain, not just the exact host that sent the header. This is important because an insecure subdomain can undermine the security of the whole site through cookies and trust. It is also a requirement for the HSTS preload list. The checker reports whether this directive is present and warns that adding it commits all current and future subdomains to HTTPS, so you must be sure they all support it.

The preload list is a list, maintained by Google and shipped inside major browsers, of domains that should be treated as HTTPS-only from the very first visit — even before any header is seen. This eliminates the insecure first-request window entirely. To qualify, your header must include a long max-age of at least 31536000, the includeSubDomains directive, and the preload directive, and your whole domain must serve HTTPS. The checker evaluates all three conditions and tells you if you are eligible to submit.

It can be, because preload is hard to undo quickly. Once your domain is baked into shipped browser versions, removing it takes a long time to propagate, and during that window every subdomain must serve valid HTTPS or it becomes unreachable. So before submitting, confirm every subdomain — including ones used by third parties — supports HTTPS and that you intend to stay HTTPS-only indefinitely. The checker flags the preload directive so you can confirm this is a deliberate, well-tested choice.

Indirectly and positively. Google favors HTTPS, and HSTS reinforces a clean, consistent HTTPS setup with no insecure variants for crawlers to stumble on. It also helps avoid duplicate-content confusion between http and https versions when combined with proper redirects and canonicals. While HSTS itself is not a documented ranking factor, the secure, redirect-clean configuration it encourages supports the HTTPS signal Google does use.

The most common reasons are that the header is only sent on HTTPS responses and your test hit an HTTP redirect first, that it is set on a different host than the one you tested, or that a CDN or proxy is stripping it. HSTS must be served on the HTTPS response from the canonical host. The checker follows redirects to the final HTTPS response and reads the header there, so if it still reports missing, verify your server or CDN is actually emitting Strict-Transport-Security.