Fix HSTS Missing includeSubDomains
Your site sends a Strict-Transport-Security (HSTS) header, but it leaves out the includeSubDomains directive. That means the HTTPS-only policy protects only the exact hostname the browser saw, not your subdomains. An attacker can still hijack a first, unencrypted request to a subdomain like blog. or app. and downgrade it to HTTP. The fix is to add includeSubDomains once you've confirmed every subdomain works over HTTPS with a valid certificate.
What this means
HSTS (HTTP Strict Transport Security) is a response header that tells browsers to connect to a host over HTTPS only, never plain HTTP, for a set number of seconds. Once a browser has seen it, it silently upgrades every request to that host and refuses to try HTTP at all.
A complete header looks like this:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Your audit flagged hsts_no_subdomains because the header is present and valid, but the includeSubDomains token is missing. Without it, the HTTPS-only rule applies only to the exact hostname that served the header, usually your apex domain (example.com) or www. It does not cover blog.example.com, app.example.com, api.example.com, or any other subdomain.
This is a notice, not a broken-site error. HTTPS still works everywhere. But your HSTS policy has a gap: every subdomain sits outside it, so each one can still be hit by the downgrade attack HSTS exists to prevent.
Why it matters
The point of HSTS is to close the "first request" gap. Without it, when someone types blog.example.com (no https://), the browser first tries plain HTTP, then follows your redirect to HTTPS. An attacker on the same network can intercept that initial HTTP request and stop the redirect from happening. That is the classic SSL-stripping man-in-the-middle downgrade. HSTS with includeSubDomains tells the browser to skip HTTP entirely for the apex and every subdomain, so there is no first request to hijack.
Leaving subdomains out matters more than it looks. Subdomains often host the highest-value targets: login portals, admin panels, APIs, and staging environments. A cookie set with Domain=.example.com is shared across subdomains, so a downgrade attack on one unprotected subdomain can leak a session that also works on your secured apex. Protecting only example.com while api.example.com stays exposed defeats much of the benefit.
For search and AI answer engines, HSTS is not a direct ranking factor, but it is part of a clean security posture. Google has treated HTTPS as a lightweight ranking signal for years, and fully enforced HTTPS avoids the mixed-content and redirect issues that waste crawl budget. AI crawlers like GPTBot, PerplexityBot, and Google-Extended fetch over HTTPS and follow the same redirect chains, so site-wide enforcement keeps those fetches fast and unambiguous. It also gates entry to the HSTS preload list, which requires includeSubDomains and is the strongest form of this protection.
How to fix it
- 1
Confirm every subdomain already works over HTTPS
This is the critical prerequisite. Once a browser sees includeSubDomains, it refuses plain HTTP for every subdomain for the full max-age window. If any subdomain (blog, app, api, mail, staging, an old microsite) is HTTP-only or has an expired or invalid certificate, it becomes unreachable in browsers that saw the header. Inventory your DNS records and load each subdomain over https:// to confirm a valid certificate before you change anything. Wildcard certificates or per-subdomain certificates both work; you just need full coverage.
- 2
Add includeSubDomains to your header
Append the directive to your existing HSTS header. A solid production value is
Strict-Transport-Security: max-age=31536000; includeSubDomains(one year). Directives are separated by semicolons, are case-insensitive, and order does not matter. Keep max-age at 31536000 or higher, since short values weaken the protection. Serve the header on HTTPS responses only; browsers ignore HSTS delivered over plain HTTP by design. - 3
Apply it on your server or platform
On Nginx, add
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;inside the HTTPS server block. Thealwaysflag ensures it is sent on redirects and error responses too. On Apache, useHeader always set Strict-Transport-Security "max-age=31536000; includeSubDomains". On Cloudflare, enable HSTS under SSL/TLS > Edge Certificates and tick 'Apply HSTS policy to subdomains (includeSubDomains)'. Make sure the header is served by the apex host, since that is the origin browsers use to apply the subdomain rule. - 4
Ramp max-age if you're worried about lock-in
Because includeSubDomains is hard to walk back, cautious teams roll it out in stages. Start with a short value such as
max-age=300; includeSubDomains(five minutes) and confirm nothing breaks across your subdomains. Then step up to a day, a week, and finally a year. HSTS is enforced per browser and cannot be cleared remotely, so this staged approach limits the blast radius if you discover a forgotten HTTP-only subdomain. - 5
Verify the header is live
Check the response header directly. Running
curl -sI https://example.com | grep -i strict-transport-securityshould return your header with includeSubDomains. Test a subdomain the same way. Re-run this audit or check the DevTools Network tab to confirm the notice clears. In Chrome, you can inspect and reset a host's HSTS state at chrome://net-internals/#hsts if you need to re-test during rollout. - 6
Optional: submit to the HSTS preload list
For maximum protection, add the preload directive (
max-age=63072000; includeSubDomains; preload) and submit at hstspreload.org. Preloading bakes your domain into browsers so the very first request is HTTPS-only, with no prior visit needed. This is a long-term commitment: preload requires includeSubDomains, a two-year max-age, and an HTTP-to-HTTPS redirect on port 80, and removal can take months to propagate through browser updates. Only preload once you are certain every current and future subdomain will always support HTTPS.
Frequently asked
It is a notice, not a critical error. Your site still works and HTTPS is enforced on the host that sends the header. But it leaves every subdomain outside your HSTS policy, so subdomains like app. or api. remain open to the HTTP downgrade attacks HSTS is meant to stop. If your subdomains handle logins, sessions, or APIs, fixing it is worth doing.
Only if a subdomain does not fully support HTTPS. Once a browser sees the directive, it refuses plain HTTP for the apex and all subdomains for the entire max-age window. Any subdomain that is HTTP-only or has an invalid or expired certificate becomes unreachable in that browser. Audit your DNS records and confirm each subdomain serves a valid certificate over HTTPS before you add the directive.
You cannot clear it remotely from users' browsers, which is the trade-off. You can send a new header with max-age=0 to tell browsers to expire the policy, but it only takes effect the next time each browser successfully connects over HTTPS to that host. If a subdomain is fully broken over HTTPS, the browser may never reach it to receive the reset. This is why you verify HTTPS coverage first and why staged max-age rollouts are recommended.
includeSubDomains extends your HTTPS-only rule to all subdomains, but only after a browser has visited the host at least once and cached the header. preload goes further by embedding your domain in browsers' built-in HSTS list, so the protection applies from the very first request. Preload requires includeSubDomains plus a two-year max-age and the preload token, and you submit it at hstspreload.org.
Not directly. HSTS itself is not a documented ranking factor. Its value is enforcing clean, consistent HTTPS, which supports the HTTPS signal Google has used for years and avoids mixed-content and redirect problems that waste crawl budget. AI crawlers like GPTBot and PerplexityBot fetch over HTTPS and follow redirects the same way, so site-wide enforcement keeps those fetches clean. Treat it as security hygiene that complements SEO, not a growth lever on its own.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.