HTTPS Migration Technical Checklist

Why HTTPS matters

HTTPS encrypts the connection between a visitor's browser and your server, so login details, form submissions, and the integrity of your pages cannot be read or tampered with in transit. It is also the baseline modern browsers expect: features like geolocation, service workers, and progressive web app APIs only run over a secure connection, and HTTP/2 and HTTP/3, which load resources far more efficiently than HTTP/1.1, are effectively HTTPS-only in mainstream browsers.

Google has treated HTTPS as a lightweight ranking signal for years and labels insecure pages in Chrome. The signal is modest on its own, but the surrounding effects matter more: visitors who see a "Not secure" warning are likelier to bounce. Securing the site removes a liability more than it boosts rankings.

The migration checklist

Work through these steps in order. HTTPS should be serving correct content before you force browsers and crawlers onto it.

1. Get a valid TLS certificate. Obtain a certificate covering every hostname you serve, including www and non-www variants and subdomains. Install it, confirm the full chain is presented, and set up automatic renewal.
2. Update internal links and resources to HTTPS. Point links, images, scripts, stylesheets, and fonts in your templates and database at HTTPS, or use root-relative paths, to prevent mixed content before redirects are even in place.
3. 301 redirect all HTTP to HTTPS. Add server-side permanent (301) redirects from every HTTP URL to its HTTPS equivalent, keeping each path identical so only the protocol changes.
4. Update canonicals, hreflang, and sitemaps. Rewrite canonical tags, hreflang annotations, and every XML sitemap URL to HTTPS; stale HTTP references here send mixed signals to search engines.
5. Update Search Console and analytics. Add and verify the HTTPS property in Google Search Console (a Domain property covers all variants), submit the updated sitemaps, and point analytics at the HTTPS URLs.
6. Update robots.txt and your CDN. Make sure the HTTPS robots.txt does not block the new URLs and references the HTTPS sitemap. In your CDN, enable HTTPS for origin and edge, refresh certificates, and purge caches.
7. Fix mixed content. Crawl the live HTTPS site and resolve any asset still loading over HTTP, which browsers block or flag and which undermines the padlock you just earned.
8. Add HSTS. Once HTTPS is stable across every page and subdomain, send the HTTP Strict Transport Security header so browsers connect over HTTPS automatically. Start with a short max-age, raise it after testing, and add preload only when certain.

For help choosing the right status code, see our guide to 301 vs 302 redirects.

Avoiding traffic loss

Most HTTPS migrations that lose traffic lose it through redirect mistakes, not the move itself. Three habits keep risk low.

First, use one-hop redirects. An HTTP URL should reach its final HTTPS URL in a single step. A request bouncing through www, then non-www, then HTTPS wastes crawl budget and slows users. Our explainer on redirect chains and loops shows how to flatten them.

Second, do not change URLs and protocol at the same time. If you also want to restructure paths or consolidate content, do that as a separate project before or after the switch. Changing both at once makes it harder to tell which change caused any movement.

Third, monitor closely. Keep both the HTTP and HTTPS Search Console properties open during the transition to watch indexing move across, and check crawl stats, server logs, and analytics.

Post-migration verification

After the cutover, confirm the migration took. Request a sample of HTTP URLs and verify each returns a single 301 to the matching HTTPS URL ending in a 200. Crawl the HTTPS site for broken links, redirect chains, and mixed content, and check that canonicals point to HTTPS and robots.txt blocks nothing new.

In Search Console, watch the HTTPS property pick up impressions while the HTTP property winds down, and use URL inspection to confirm key pages are indexed on HTTPS. Verify the certificate chain validates and the padlock shows with no warnings. Watch organic traffic for several weeks; brief fluctuation during reprocessing is normal, but a sustained drop points to a redirect or canonical problem worth investigating.

FAQ