Moving a website to HTTPS is not the same as ensuring browsers always use it. A user may type an HTTP address, follow an old link, or encounter a redirect before reaching the encrypted site. HTTP Strict Transport Security, usually called HSTS, helps browsers remember that a domain should be reached through HTTPS instead.
The MDN HSTS reference explains the browser behavior and header directives. The HSTS preload service adds an important operational warning: preloading commits the domain and its subdomains to HTTPS, and removal can take months to reach users. This is infrastructure policy, not a header to paste without reviewing the domain estate.
Understand the browser's remembered policy
A valid Strict-Transport-Security header received over HTTPS tells a browser to use HTTPS for future requests to that host. The max-age value describes how long the policy should be remembered, in seconds.
The header affects future requests rather than retroactively protecting an earlier unencrypted request. Each qualifying response can refresh the remembered expiration. A long duration therefore remains an active operational commitment when visitors continue receiving the same policy.
HSTS identifies hosts by domain name, not by IP address. The MDN reference also describes its application across ports. Review the actual hostnames and services that users reach rather than assuming a policy is confined to one page or one familiar web endpoint.
Verify HTTPS before publishing the policy
Confirm that every relevant public path has a valid certificate and working HTTPS service. Include redirects, login pages, error responses, and alternate hostnames. A successful test of the home page does not establish that all entry points behave correctly.
Check the deployed edge or reverse proxy, not just the application's local configuration. A content delivery network can add, remove, or duplicate response headers, and different routes can use different serving paths.
Maintain renewal and deployment monitoring for the certificates clients actually receive. Under HSTS, browsers do not offer the normal click-through path for certificate errors. That is part of the protection, but it also makes reliable certificate operations essential to availability.
Inventory subdomains before expanding scope
The includeSubDomains directive applies the policy to subdomains of the host that sends it. A policy on the base domain can therefore affect more systems than the team responsible for the main website operates.
Inventory customer portals, legacy applications, internal tools, delegated subdomains, and third-party services using your domain names. Speak with their owners and verify HTTPS readiness. Do not interpret an empty public crawl as proof that no internal subdomains exist.
Distinguish a policy on one subdomain from a policy on its parent. MDN explains that a subdomain policy does not automatically apply upward to the parent or sideways to sibling subdomains. Accurate scope matters both when introducing protection and when planning recovery.
Stage the duration deliberately
Start with a reviewed short duration when validating a new deployment, then increase it after observing the required hostnames and workflows. The preload service recommends staged durations and waiting through each stage while checking for broken pages and operational effects.
Do not copy the service's subdomain-inclusive example until your own subdomain inventory is ready. A team may first need to validate a narrower host policy. The right staging sequence follows the actual scope you are prepared to support.
Keep the current policy, responsible owner, and planned expansion in the change record. A short test header accidentally left in production provides a different persistence guarantee from the long-term policy the team may believe it deployed.
Distinguish redirects from HSTS
An HTTP-to-HTTPS redirect is still useful, but it is not the same as a browser upgrading the request before contacting the HTTP endpoint. MDN describes redirecting insecure requests and delivering the HSTS header on the subsequent HTTPS response.
Browsers ignore HSTS headers received over insecure HTTP. Adding the header to an HTTP response does not teach the policy in the same way as receiving it over a valid secure connection.
Test both paths: the server's HTTP redirect behavior and the browser's behavior after learning HSTS. A command-line header check can inspect the response, but it does not by itself prove that a browser has stored and applied the policy as intended.
Account for the first-visit limitation
A browser that has never learned a site's HSTS policy can still make an initial HTTP request. The header cannot protect that earlier request after the fact. This is one reason the distinction between a learned policy and a preloaded policy matters.
Preloading places domains in a list distributed with browsers so the policy can apply before an ordinary first visit. That reduces the first-connection weakness for included domains, but it comes with stricter readiness and removal considerations.
Do not present ordinary HSTS as a universal guarantee for every first visit from every client. Explain what the browser knows, how it learned that information, and whether the domain is actually preloaded in the browser versions that matter to your audience.
Treat preload as a separate approval
The preload service requires a valid certificate, the appropriate HTTP redirect where port 80 is served, HTTPS across subdomains, and a qualifying header on the base domain. The header must include includeSubDomains, preload, and a sufficiently long max-age.
Adding the word preload to a response does not mean that every browser immediately contains the domain in its shipped list. Submission, acceptance, distribution, and client updates are separate stages. Verify status through the service rather than claiming protection from the header alone.
The service warns that internal subdomains are included and that removal is slow. Obtain agreement from the owners of the domain estate before requesting inclusion. Preloading should reflect a durable ability to serve HTTPS, not a short-lived effort to improve a security-check score.
Plan recovery without promising instant reversal
Setting max-age=0 over HTTPS can remove a browser's learned policy for the responding host. It only takes effect when that browser receives the secure response. An HTTP response cannot safely instruct the browser to abandon HSTS.
Subdomain policies need separate consideration. A subdomain may have its own stored policy, and a parent's subdomain-inclusive policy can still affect it. Removing one visible header is therefore not proof that every related browser policy has disappeared.
Preloaded domains have an additional removal process whose effects depend on browser distribution and updates. Keep HTTPS functioning during recovery. A plan that requires immediately switching a preloaded domain back to HTTP misunderstands the persistence the deployment intentionally created.
Verify through representative client paths
Inspect headers from the public serving path and test browser navigation with a suitable test domain or controlled profile. Confirm redirects, remembered upgrades, certificate validity, and subdomain behavior without risking real user access.
Include less common routes and hostnames. Authentication callbacks, administrative portals, and older service endpoints often reveal readiness gaps that a home-page check misses. Avoid testing recovery by deliberately breaking production certificates.
Record the deployed header and the results of the relevant checks. Repeat verification when a proxy, domain delegation, certificate provider, or hosting architecture changes. HSTS depends on ongoing service readiness rather than a one-time configuration review.
Keep the commitment owned
Make HTTPS support part of the requirements for new subdomains and third-party integrations. A future team should know that a inherited policy exists before introducing an HTTP-only tool beneath the domain.
Monitor certificate renewal, deployment, and availability, and keep the rollback limitations visible in the operating documentation. The people responding to an outage should not discover preload persistence for the first time during the incident.
HSTS is effective when its browser behavior and infrastructure scope are understood together. Establish reliable HTTPS, inventory the domain estate, expand the policy deliberately, and treat preloading as a long-term commitment. The strongest header is not the safest rollout if the organization cannot sustain what it promises.
