A production guide to HTTPS migration

Moving an established site to HTTPS changes its origin, cache behaviour, redirects, cookies, integrations and search records. The certificate is one component of the migration; the work is proving that every request and dependency behaves correctly before all HTTP traffic is made permanent.

Inventory the estate before selecting a date

List every public hostname, redirecting alias, administration address, API endpoint and static asset domain. Include marketing tools, payment services, embedded media, feeds, mobile applications and partner integrations. An obsolete subdomain can still be present in an email template or hard-coded application.

Confirm which browsers and operating systems remain supported. Select certificates with a SHA-256 signature and verify the complete intermediate chain from outside the server network. SNI permits multiple certificates on one address, but older client requirements may still influence hosting design. Test TLS 1.2 and retain only the older protocol support that documented users genuinely require.

Make the application scheme-aware

Remove hard-coded http:// references from templates, stylesheets, scripts, structured data and generated documents. Prefer root-relative paths for local assets and explicit HTTPS URLs for external services. Protocol-relative URLs can ease a transition but preserve uncertainty; once a service supports HTTPS, state the required scheme.

Test behind the production proxy or load balancer. The application must interpret the forwarded protocol from trusted infrastructure without accepting a spoofed header from the public internet. Otherwise it may generate HTTP links, enter a redirect loop or omit secure cookies even though the user connected over HTTPS.

Find active and passive mixed content

Browsers block insecure scripts, stylesheets and frames more aggressively than images, but both classes undermine a complete migration. Crawl rendered pages as well as stored HTML because JavaScript, CSS and content-management fields can introduce URLs after the initial response. Exercise authenticated templates, validation errors, print views and old campaign pages.

Use Content Security Policy reporting to observe insecure requests before enforcing a restrictive policy. Do not rely on automatic request upgrading as a substitute for correcting source data: the external resource may not exist over HTTPS, and a silently upgraded request can still fail for users.

Move one canonical origin

Choose the final hostname and HTTPS form, then redirect every HTTP variant to it in a single 301 hop. Avoid chains such as HTTP non-www to HTTP www to HTTPS www. Preserve the path and meaningful query string, but do not reproduce malformed or tracking-only parameters without review.

Update canonical links, hreflang references, XML sitemaps, feeds and internal navigation to the final HTTPS URLs. Register and verify the HTTPS property in the current search-management tools, submit the new sitemap and monitor crawl errors and indexed URL counts. Keep the HTTP property available for comparison during the transition.

http://example.com/path
  301 → https://www.example.com/path

canonical:
  https://www.example.com/path

Review cookies, sessions and caches

Mark session and authentication cookies Secure so they are never returned over plaintext HTTP. Confirm domain and path scope, expiry and logout behaviour. Existing users may carry cookies created before the migration, so test upgrades from an active HTTP session as well as clean browsers.

Verify cache keys at the CDN, reverse proxy and application layer. HTTP and HTTPS responses must not be combined while behaviour differs. Purge old redirects and absolute URLs deliberately, and check that personalised or authenticated responses retain their existing cache controls.

Introduce HSTS after HTTPS is stable

HTTP Strict Transport Security tells supporting browsers to use HTTPS without attempting a plaintext connection. It also makes a broken certificate or unavailable HTTPS service harder for users to work around. Begin with a short max-age after all included hosts are proven, then increase it through subsequent releases.

Do not add includeSubDomains until every subordinate hostname is inventoried and HTTPS-capable. Preload submission creates an even longer-lived commitment and should be a separate, reviewed decision rather than an item copied from a generic header configuration.

Release with evidence and a rollback boundary

Rehearse the migration in an environment that uses the production proxy, certificate chain and redirect rules. On release, monitor TLS negotiation failures, redirect volume, application errors, conversion, third-party callbacks and search crawling. Compare by browser and device so an old-client failure is not hidden inside the aggregate.

Keep the ability to remove the HTTP redirect while problems are investigated, but do not treat returning sensitive traffic to plaintext as an acceptable long-term rollback. Once a long HSTS policy has reached users, DNS or application rollback cannot make those browsers use HTTP. Increase that commitment only after the HTTPS service has completed a full operating cycle.