Should you enable HSTS immediately when migrating a domain to HTTPS?

Why does Google warn against the early activation of HSTS?

HSTS (HTTP Strict Transport Security) forces browsers to only access your domain via HTTPS, never attempting an HTTP connection. Once this header is sent, browsers memorize this directive for the specified duration (often a year).

The issue arises when you activate HSTS too early during a migration. If an SSL certificate expires, if an HTTPS configuration fails, or if an overlooked subdomain is not yet secured, visitors face a dead end: the browser categorically refuses any backup HTTP connection. You lose access to the site, as do the users.

What is a domain migration and how does HSTS complicate things?

A domain migration typically involves three simultaneous changes: a new domain name, a transition to HTTPS, and massive 301 redirects. It’s already a dense technical project.

Adding HSTS into the mix is like locking a door before testing all the locks. If your CDN improperly delivers certificates, if an old subdomain still points to an HTTP IP, or if your Let's Encrypt auto-renewal fails, HSTS turns a minor incident into a total disaster.

How can you tell when it’s safe to enable HSTS?

Monitor for at least two to four weeks after migration. Ensure that all subdomains respond correctly over HTTPS, that certificates renew automatically, and that your monitoring tools raise no SSL alerts.

Also test critical user journeys: e-commerce checkout, contact forms, customer areas. Once this validation period is over, enable HSTS with a short duration (a few weeks), then gradually increase it to a year.

• HSTS locks HTTPS access without fallback to HTTP
• Any SSL error becomes blocking for visitors if HSTS is active
• Wait 2 to 4 weeks after migration before enabling HSTS
• Start with a short duration (low max-age) then gradually increase
• Check all subdomains, certificates, and renewal processes

Is this recommendation consistent with field observations?

Absolutely. I've seen too many migrations fail due to HSTS activated too soon. The classic scenario: a migration on a Friday, HSTS in the header, a certificate expires over the weekend because an automatic renewal script only worked on the old domain.

The result? Site inaccessible until Monday, loss of SEO traffic, a sharp drop in SERPs, and a client who doesn’t understand why they can’t just "revert to HTTP." Because indeed, HSTS forbids that on the browser side, even if you remove the server header.

What nuances should be added to this directive?

Mueller's recommendation mainly targets large complex migrations with multiple subdomains, distributed infrastructure, or technical teams not well versed in HTTPS. If you’re migrating a small single-domain site with a wildcard certificate and solid monitoring, the risk is lower.

However, even in that case, there’s no rush. HSTS does not provide any documented direct SEO benefit from Google. Its purpose is purely security-related: to protect against SSL stripping attacks. Taking two extra weeks to enable it does not change your ranking at all.

When can HSTS activation be expedited?

If your infrastructure is fully managed (Cloudflare, AWS CloudFront with ACM, Netlify), if your certificates are auto-renewed, and you have already validated all subdomains over HTTPS for several days, you can shorten the waiting period.

But even then, start with a max-age of 86400 (24 hours) rather than 31536000 (one year). You will still have time to increase. However, reducing a max-age that has already been sent is pointless: browsers retain the highest value they have seen.

What should you do when migrating a domain?

Plan the migration in three distinct phases. First, migrate to the new HTTPS domain with 301 redirects, without HSTS. Let it run for at least two weeks, monitoring your server logs, Google Search Console, and uptime monitoring tools.

Next, enable HSTS with a short max-age (one week). Monitor for another week. If everything runs smoothly, move to a max-age of one month, then six months, then one year. This gradual approach limits damage in case of unexpected problems.

What critical mistakes must be avoided at all costs?

Never enable includeSubDomains in the HSTS header if you haven’t checked ALL subdomains. An old staging subdomain staging.mydomain.com still on HTTP? Visitors to that subdomain (or bots) get blocked.

Another trap: don’t enable HSTS and submit for preload at the same time. The preload is effectively irreversible, and removal takes 6 to 12 months. Validate HSTS in production for several months before considering preload.

How can you check if your HSTS configuration is ready?

Use SSL Labs to scan your domain and all critical subdomains. Check that certificates are valid, that trust chains are complete, and that automatic renewals are functioning.

Then test with a temporary HSTS header (max-age=60) on a test environment. Clear your browser's HSTS cache (chrome://net-internals/#hsts), then navigate. If everything passes, gradually extend the duration. This method provides you with a safety net before going into production.

• Migrate the domain to HTTPS first without HSTS; wait 2 to 4 weeks
• Check all subdomains, SSL certificates, and automatic renewal processes
• Enable HSTS with max-age=604800 (one week) then increase gradually
• Never enable includeSubDomains without exhaustive validation of all subdomains
• Monitor Search Console, server logs, and uptime monitoring after each step
• Avoid preload until HSTS has run without incidents for several months