Moving a Site to HTTPS: Redirects, Mixed Content and HSTS
Serving a site over HTTPS protects visitors' data and is expected by browsers and search engines. A migration from HTTP is mostly mechanical, but missed details cause duplicate URLs, broken resources or browser warnings. Treat it like any other URL change: map every old address to its new one and update every signal that refers to them.
Certificates and redirects
Install a valid certificate covering every hostname in use, and set up automatic renewal before the switch. Then redirect each HTTP URL with a permanent redirect to the same path on HTTPS, not to the home page. Keep the redirects in place indefinitely; old links will keep arriving for years.
Verify the HTTPS version as its own property in search consoles if the tool does not cover both protocols in one domain property.
Updating references and fixing mixed content
Update canonical tags, hreflang annotations, sitemaps and internal links to the HTTPS URLs. Pages loaded over HTTPS that request scripts, styles or images over HTTP produce mixed content; browsers block or warn about these resources. Search the code and database for hard-coded http:// references.
A Content-Security-Policy upgrade-insecure-requests directive can help during cleanup, but fixing the references is the lasting solution.
Rolling out HSTS carefully
The Strict-Transport-Security header tells browsers to use HTTPS for a host for a set period. Start with a short max-age, confirm everything works, then increase it. Add includeSubDomains only when every subdomain supports HTTPS.
Submitting a domain to browser preload lists is hard to undo, so treat it as a final step rather than part of the initial migration.
Strict-Transport-Security: max-age=300
# after verification
Strict-Transport-Security: max-age=31536000; includeSubDomains