HSTS: HTTP Strict Transport Security for SEO

What HSTS actually does, the Strict-Transport-Security header syntax (max-age, includeSubDomains, preload), the browser-only internal redirect crawlers never see, why it doesn't replace your 301s, and how preload can lock you in — from Patrick Stox.

First published: Jul 3, 2026 · Last updated: Jul 17, 2026 · Advanced
AIAuthored byAI v2
1 evidence signal on this page

HSTS (HTTP Strict Transport Security) is a Strict-Transport-Security response header — honored only when it arrives over a secure connection — that tells a browser to always use HTTPS for your domain going forward, closing the insecure gap that a new visitor's first request still makes over HTTP before your 301 fires. It's a browser-layer, per-client policy on top of your server-side redirects, not a replacement: RFC 6797 has the browser rewrite the URI to HTTPS internally before any request goes out (often shown as an internal 307-style redirect, though the RFC doesn't mandate a specific status code), so no server ever sees the HTTP form and crawlers still need your real 301 to understand the move and carry link equity. The header has three directives — max-age (required), includeSubDomains, and preload. Preload bakes your domain into the browser itself via hstspreload.org (requiring max-age of at least a year, includeSubDomains, and the preload flag) and is close to irreversible — removal is a separate submission that takes months to reach users. HSTS is also deliberately unforgiving: a browser that knows you as an HSTS host will hard-fail with no click-through if your certificate ever breaks. So enable it only once HTTPS is genuinely solid across every subdomain, and treat preload as a one-way door.

TL;DR — HSTSHSTS (HTTP Strict Transport Security) is a response header that tells browsers to always connect to your site over HTTPS — even when a user types or clicks an http:// link — closing the insecure-first-request gap that a plain 301 redirect leaves open. is the Strict-Transport-Security response header, honored only when a browser receives it over a secure connection, and stored per-client as future policy for that host. It closes the “first request problem” a 301 alone leaves open: the initial HTTP request from a new visitor is insecure until the redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. fires, and that’s the window an SSL-stripping attacker wants. Three directives: max-age (required, seconds), includeSubDomains, preload. When a browser enforces HSTS it rewrites the URI to HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' internally, before any request reaches a server — RFC 6797 doesn’t mandate a specific status code for that rewrite, though tools often surface it as a 307 — so your server-side 301s are still mandatory for search engines and link equityPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems.; HSTS is on top of them, not instead. PreloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. bakes your domain into the browser via hstspreload.org (requires max-age ≥ 31536000, includeSubDomains, and preload) and is close to irreversible — removal is a separate submission that takes months to reach users. And HSTS is designed to hard-fail on any cert error, so enable it only when HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' is robust across every subdomain.

The HTTPS hubHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' introduces HSTS as a browser-layer protection that sits on top of your 301s. This page is the deep dive: the exact header syntax, the internal redirect that trips SEOs up, the preload list’s near-irreversibility, and the real-world ways HSTS locks people out.

The problem HSTS actually solves: the first request

Picture a properly migrated site. Every http:// URL 301-redirects to its https:// twin, the certificate is valid, canonicals point to HTTPS. Looks airtight. It isn’t, quite.

When a brand-new visitor types yoursite.com (no scheme) or clicks an old http://yoursite.com link, the browser’s first request goes out over plain HTTP. Your server answers with the 301, and every request after that is secure. But that one initial round-trip happened in the clear — and that’s exactly the window an SSL-stripping attacker on the same network wants. They intercept the HTTP request, keep the victim on HTTP while they proxy HTTPS to your server, and read or rewrite everything.

HSTS eliminates that window for anyone who has visited before. web.dev is direct about the mechanism: “use Strict Transport Security to tell clients they should always connect to your server using HTTPS, even when following an http:// reference. This defeats attacks like SSL Stripping, and avoids the round-trip cost of the 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank..” (web.dev). That last clause matters for performance too: a returning browser skips the HTTP→HTTPS round-trip entirely. Evidence for this claim After receiving HSTS, a browser upgrades future HTTP attempts to HTTPS before sending the request. Scope: MDN documents user-agent enforcement after the header has been learned; first-visit protection requires preload or a prior secure visit. Confidence: high · Verified: MDN: Strict-Transport-Security header

Two boundary conditions worth being precise about. First, HSTS is stored, per-client policy — it lives in that one browser’s own state for that host, learned from a header delivered over a secure connection; the same header sent on an HTTP response is ignored outright (an attacker who can inject or strip headers on plain HTTP could otherwise neutralize it), and a client that has never received it — a fresh install, a different browser, a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. — has no policy to enforce. Second, the rewrite is scheme-and-port aware: an implicit port 80 request becomes an implicit port 443 request, but if the original URI named an explicit non-default port, the browser keeps that same port number and simply contacts it over HTTPS instead.

The header syntax

TIP Check the live HSTS policy before considering preload

The missing-header result says only that the final HTTPS response did not carry Strict-Transport-Security. It does not mean adding preload immediately is safe.

Use my HTTP Header Checker to inspect the redirect chain and final HSTS value from the public edge before increasing max-age or adding subdomains. HTTP Header Checker Free

  1. Confirm HTTP reaches HTTPS with a server-side permanent redirect.
  2. Inspect Strict-Transport-Security on the final response and inventory every covered subdomain.
  3. Increase max-age gradually; add includeSubDomains and preload only after certificate operations are proven.
Missing HSTS is a finding; safe policy scope is a separate operational decision.

HSTS is one response header with up to three directives. Per MDN, the forms are:

Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000; includeSubDomains
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age=<seconds> — required. “The time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS” (MDN). 31536000 is one year; 63072000 is two. The clock resets on every response that carries the header, so an active site continually renews its policy. This is relative, per-client state: simply removing the header doesn’t immediately clear it — a browser that already learned the policy keeps enforcing it until its stored max-age runs out. To turn HSTS off for clients that already learned it, you have to actively serve max-age=0 over a secure response; the browser then forgets the policy on its next secure visit. (max-age=0 clears a learned policy only — it does not remove a domain from the separate preload list.)
  • includeSubDomains — optional. “If this directive is specified, the HSTS policy applies to all subdomains of the host’s domain as well” (MDN). Powerful and dangerous in equal measure — see the lockout scenarios below.
  • preload — optional. A flag that signals your intent to be on the browser preload list. It does nothing on its own; it’s a prerequisite for submitting to hstspreload.org. Evidence for this claim HSTS preload requires at least a one-year max-age, includeSubDomains, and preload; removal can take months to reach users. Scope: The Chromium preload service documents submission and removal behavior; requirements can change and should be rechecked before submission. Confidence: high · Verified: Chromium: HSTS Preload List Submission

The behavior, again from MDN: “Before loading an http URL, the browser checks the domain name against its HSTS hosts list. If the domain name is a case insensitive match for an HSTS host or is a subdomain of one that specified includeSubDomains, then the browser replaces the URL scheme with https.”

The internal upgrade crawlers never see (this is the SEO crux)

Here’s the single most misunderstood thing about HSTS, and the reason it can’t replace your redirects.

When a browser upgrades an http:// request under HSTS, it rewrites the URI to HTTPS internally, before any network request is made — RFC 6797 requires the scheme substitution itself but does not mandate a particular status code for it (RFC 6797 §8.3), so a given browser or crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. tool may represent that internal step however it likes — many display it as an internal 307, but that’s client/tool-specific, not a protocol guarantee. What matters for SEO is simpler and holds regardless of the label: no server is contacted for the HTTP version, so no crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. ever sees it. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. and BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. don’t carry a learned HSTS policy around the way a returning human’s Chrome does — they hit your server fresh, and what they need to see there is a real, server-side 301. Evidence for this claim RFC 6797 requires the user agent to rewrite a known-HSTS-host HTTP URI to HTTPS internally, but does not mandate any specific redirect status code for that internal rewrite; how a given browser or crawling tool represents that step (e.g., as an internal 307) is a client/tool implementation detail, not a protocol requirement. Scope: RFC 6797 Section 8.3 ("URI Loading and Port Mapping") specifies the UA MUST replace the URI scheme with https; it does not prescribe an HTTP status code for that internal substitution, since no HTTP exchange occurs for it. Section 7.2's suggestion of status code 301 addresses ordinary server-side redirect behavior, not this internal client-side rewrite. Confidence: high · Verified: RFC 6797 §8.3 — URI Loading and Port Mapping

So the rule is blunt: HSTS does not replace your server-side 301s. The 301 is what search engines use to understand the protocol move and to consolidate signals (301 and other permanent redirects don’t cause a loss in PageRank, per Google). The browser-only internal upgrade is a user-experience and security layer on top. You need both, doing different jobs:

  • 301 (server-side): for crawlers, indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and link equity.
  • Internal 307-style upgrade (browser-side, from HSTS): for returning humans and SSL-stripping protection — the exact status representation varies by client/tool.

Any guide that tells you HSTS “handles the redirect so you can drop your 301” is wrong in a way that will quietly cost you.

HSTS preload: the near-permanent version

max-age protects returning visitors, but it has a bootstrap problem: a first-time visitor who has never received your header is still exposed on that initial request. Preload solves it by hardcoding your domain into the browser’s source itself, so the browser knows you’re HTTPS-only before it has ever connected.

You opt in at hstspreload.org. The requirements are exact:

  1. “Serve a valid certificate.”
  2. “Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.”
  3. “Serve all subdomains over HTTPS” — including in particular the www subdomain if a DNS record exists.
  4. On the base domain’s HTTPS response, an HSTS header where “the max-age must be at least 31536000 seconds (1 year),” “the includeSubDomains directive must be specified,” and “the preload directive must be specified.” (hstspreload.org)

That’s why the two-year example above (max-age=63072000; includeSubDomains; preload) is the shape people submit — note these are the exact submission requirements as published by hstspreload.org; treat them as the current bar, not a permanent constant, and re-check the live page before you submit.

It helps to keep four distinct states straight, since people conflate them constantly:

StateWhat’s actually true
Token presentYour header includes preload. This is a flag only — it does nothing by itself and doesn’t put you on any list.
EligibleYour site meets all four hstspreload.org requirements above (cert, redirect, subdomains, header shape). Still not on the list.
Submitted / pendingYou’ve submitted at hstspreload.org and it’s queued for inclusion in an upcoming browser release. Not yet enforced for real users.
Actually listedThe domain is baked into a given browser’s shipped build. Enforcement only exists for users on that build — rollout isn’t instant or universal across browsers.

Removal runs the same four states in reverse, and just as slowly: removing the preload directive from your header makes you eligible for the removal form, then submission is pending, and the domain stays enforced for any user on a browser build that still ships it — until that build cycles out.

Now the part that turns preload into a one-way door. From the submission site itself: “Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.” (hstspreload.org). And its own advice: “Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains in the long term.”

Practical translation: preload is a genuinely great security posture, but if you ever need to serve anything — a legacy subdomain, an acquired brand, an internal tool — over plain HTTP again, you’re stuck waiting on browser release cycles to reach every user. Kinsta’s guide puts the operational reality plainly: it can be a difficult and time-consuming process to get your domain removed. Treat preload as permanent.

Why HSTS is designed to hurt when things break

HSTS’s strictness is not a bug — it’s the entire security guarantee. web.dev spells out the tradeoff: “Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration, (such as an expired certificate). HSTS is explicitly designed this way to ensure that network attackers can’t trick clients into accessing the site without HTTPS.” (web.dev).

The conclusion Google draws is the sentence I’d tattoo on anyone about to flip this on: “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (web.dev).

“Hard-fail” means exactly that: no “proceed anyway” link, no click-through. On a normal HTTPS page, an expired cert throws a scary interstitial that a determined user can bypass. On an HSTS host, the browser refuses outright. So the failure mode of a missed certificate renewal changes category — from “traffic dips because people are scared off” to “the site is unreachable for every returning visitor.”

Real-world lockout scenarios

The ways HSTS bites in practice almost always trace back to includeSubDomains or preload getting ahead of your actual HTTPS coverage:

  • The forgotten subdomain. You set includeSubDomains on example.com, but legacy.example.com (an old app, a status page, a vendor tool) only speaks HTTP or has a cert that doesn’t cover it. Every browser that saw the header now refuses to load that subdomain. Nothing changed on that server — the policy reached down and broke it.
  • The wildcard-cert gap. A *.example.com wildcard covers foo.example.com but not foo.bar.example.com (a wildcard is one DNS label deep). If a deeper subdomain relies on HTTP or a mismatched cert, includeSubDomains locks it out.
  • The expired cert on an HSTS host. Renewal automation fails, the cert lapses, and instead of a bypassable warning you get a site that’s down for everyone whose browser remembers your policy — until you get a valid cert back and they reconnect and receive a fresh secure response. There is no faster override.
  • Preload regret. You preloaded, then a business need forces an HTTP-only service under the domain. Rolling that back is two separate, non-instant jobs, not one: serving max-age=0 over HTTPS only clears the learned policy for clients that reconnect before their old max-age would’ve expired anyway, while getting the domain out of the preload list is a distinct submission that still takes browser release cycles — months — to reach users, independent of anything you change on your server.
  • Local dev / staging collisions. Preloading example.com with includeSubDomains can make dev.example.com or a localhost-style internal host under the same apex refuse HTTP, breaking local workflows in surprising ways.

None of these are reasons to avoid HSTS. They’re reasons to stage it: short max-age first, add includeSubDomains only after auditing every subdomain, and reserve preload for when you’re certain.

HSTS is not a ranking play (and doesn’t touch canonicalization)

To be clear on the SEO framing: HSTS is not a ranking signal. HTTPS itself is a deliberately tiny oneHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' — Google called it a “very lightweight signal” affecting fewer than 1% of queries — and HSTS is a layer on top of HTTPS, not a separate ranking input. It also doesn’t directly control canonicalizationHow search engines pick one canonical URL among duplicates and consolidate signals onto it. or indexing. Google’s own documentation is more specific than a flat “doesn’t matter,” though: Google prefers HTTPS as canonical over an equivalent HTTP page except when there’s an invalid certificate, insecure page dependencies, an HTTPS page that redirects to HTTP, or an HTTP rel="canonical" tag (Google: consolidating duplicate URLs). HSTS cannot fix or override any of that. It’s a browser-side policy with no influence on Google’s canonicalization logic — a bad certificate or a broken redirect chain can still push Google toward an HTTP canonical regardless of what your HSTS header says. Canonicalization is driven by your 301s, your certificate, your rel="canonical", and your internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. — HSTS earns its place for security, user trust, and closing the SSL-stripping gap — do it for those reasons, keep your 301s and certificate genuinely solid, and you’ll never see HSTS itself on a rankings report either way.

If you’re running the broader HTTP→HTTPS move, HSTS is the last thing you switch on, not the first — it belongs after the migration has settled, as part of the wider site migrationA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. discipline.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.