An HTTP to HTTPS redirect checklist

Make HTTPS work before adding the redirect

Visit the HTTPS version directly and check the certificate for every hostname you intend to serve. A request to an HTTPS alias needs a valid TLS connection before it can receive an HTTP redirect. A redirect cannot repair a certificate mismatch on that first connection.

Include the bare domain, www and any public subdomains in your migration inventory. Check where TLS terminates: the certificate your CDN serves to visitors may be different from the one installed on the origin.

Preserve the resource during the upgrade

For a public page, redirect its HTTP address to the corresponding HTTPS resource. Keep the path and any query parameters the application needs. An old deep link should not silently become a visit to the homepage.

Mozilla recommends upgrading to HTTPS on the same host before redirecting to a different host so the original host can set HSTS. Review this alongside your hostname policy instead of combining rules solely to achieve the fewest possible hops.

http://example.com/guides/caching
  → https://example.com/guides/caching
  → final response

Reference: MDN: TLS configuration and HTTP redirection

Update links and check the rendered page

Review navigation, templates, canonical URLs and sitemap entries for old HTTP addresses. On a permanent move, use redirect behavior that matches that intent. Google documents permanent redirects as a signal for choosing the destination URL.

Then open the page in a browser. RedirectPath follows HTTP responses but does not load stylesheets, scripts or images. A successful trace therefore does not establish that the page is free of mixed-content problems or that every interactive flow still works.

Reference: Google Search Central: Permanent redirects

Verify a representative set of URLs

Choose examples from the URLs people already use, including bookmarked content and links in external systems. The root page alone is a poor migration test.

1. Check the certificate and direct HTTPS response for each supported hostname.
2. Trace the HTTP homepage, a deep page and a URL with a harmless query string.
3. Confirm that the path survives and the final response contains the expected page.
4. Test browser flows and plan HSTS only after HTTPS works reliably across its intended scope.