HTTPS Migration SEO Checklist — No Rankings Lost

Most developers treat HTTPS migration as a server task — get a certificate, flip a config switch, done. In reality it's a full site migration that touches every URL on your site, your canonical signals, your internal linking structure, your XML sitemap, and your Google Search Console properties. Miss any of these and you either haemorrhage link equity through redirect chains or spend weeks watching rankings slowly recover while Google re-processes the new signals.

The good news: this migration is well-understood, and every failure mode is predictable. The checklist below covers pre-migration planning, migration day steps in the correct order, and the post-migration verification work that most guides skip.

Pre-migration Checklist

Complete these before touching the server.

1. Inventory your current canonical URLs — Run the SEO Analyzer on your HTTP site to export all indexed URLs and their current canonical tags. This is your baseline — you'll need to verify every URL has a working HTTPS equivalent after migration.

2. Check your current backlink profile — Your existing backlinks point to HTTP URLs. After migration, 301s will pass equity, but you should know which high-value URLs have the most backlinks so you can prioritise verifying their redirects work correctly.

3. Test your SSL certificate — Use the SSL Checker to verify the certificate is valid, covers the correct domains (www and non-www), and is not expiring soon. A certificate that expires two weeks after migration is a problem you do not want to handle at the same time as indexing recovery.

4. Plan your canonical domain — Decide now: https://www. or https:// (no-www). Every variant must redirect to this canonical form. Changing your mind after migration means another round of redirects and another re-indexing cycle.

Migration Day Checklist

Execute these steps in order. Skipping ahead — for example, updating internal links before verifying redirects work — creates a window where your site has broken internal links.

Step 1: Install and verify the SSL certificate — Ensure it covers both www and non-www variants. Most certificate providers issue a single cert that covers both, but verify explicitly. A cert that only covers www.example.com will show a security error on example.com.

Step 2: Set up server-level 301 redirects — All HTTP URLs must redirect to their HTTPS equivalents. All non-canonical variants must redirect to the canonical form (e.g. non-www → www if you chose www as your canonical domain). This is typically done in your web server config (Apache .htaccess, nginx server block, or CDN redirect rules).

Step 3: Verify single-hop redirects — Use the Redirect Tracer to check key URLs. The correct redirect is one hop: http://example.com/page → https://www.example.com/page. Multi-hop chains such as http://example.com/page → https://example.com/page → https://www.example.com/page are two hops — they waste crawl budget, slow users, and each hop loses a small amount of link equity.

Step 4: Fix internal links — Update all internal links from HTTP to HTTPS. Every href="http:// in your HTML that points to your own domain now creates an unnecessary redirect hop on every click. The Link Checker can scan your site after migration to surface remaining HTTP internal links that were missed.

Step 5: Update canonical tags — Every <link rel="canonical"> must point to the HTTPS URL. An HTTP canonical on an HTTPS page sends a contradictory signal: the page is served over HTTPS but declares its canonical as an HTTP URL. Google will not penalise you for this, but it creates unnecessary ambiguity in how it processes the page.

Step 6: Update the sitemap — Every URL in sitemap.xml must be HTTPS. A sitemap full of HTTP URLs submitted after migration tells Google you still consider those HTTP URLs authoritative. Use the Sitemap Validator to verify no http:// URLs remain, then submit the updated sitemap in Google Search Console after adding the HTTPS property.

Step 7: Fix mixed content — Open your site in Chrome and check the Console tab in DevTools for mixed content warnings. Images, scripts, stylesheets, and iframes loaded over HTTP on an HTTPS page trigger browser security warnings and in some configurations prevent the page from loading. Update all resource URLs to HTTPS, or use protocol-relative URLs (//example.com/resource) where you need to support both protocols.

Post-migration Checklist

Google Search Console — add HTTPS property: GSC treats HTTP and HTTPS as completely separate properties. You cannot simply switch your existing property. Add https://www.yourdomain.com (and https://yourdomain.com) as new properties and complete ownership verification. Your existing HTTP property data is still visible there for historical reference.

Re-submit sitemap: Submit the HTTPS sitemap in the new HTTPS GSC property. This is what signals to Google that the HTTPS site is the one to index, and it gives Googlebot a prioritised list of URLs to re-crawl.

Monitor Coverage report: Over the next two to four weeks, watch the Coverage report in the HTTPS property for indexing errors. A spike in "Redirect error" or "Soft 404" indicates migration issues — often pages that weren't covered by the redirect rules.

Update hreflang: If you have hreflang tags (for multi-language or multi-region sites), every URL in them must be updated to HTTPS. Hreflang URLs are treated as absolute and must match the canonical URL exactly — HTTP hreflang on an HTTPS site creates a mismatch.

Update external links where possible: Contact major partners, directory listings, or aggregators that have HTTP links to your site. The 301s pass equity, but direct HTTPS links are more efficient and eliminate the redirect hop for users arriving from those links.

Common Post-migration Ranking Drops

Redirect chains: Every extra hop in a redirect chain loses a small amount of link equity and adds latency for users. The most common chain pattern after HTTPS migration is: http://example.com/page → https://example.com/page → https://www.example.com/page. This happens when the HTTP → HTTPS rule and the non-www → www rule are applied sequentially instead of being combined into a single rule. Use the Redirect Tracer to audit key URLs and confirm all chains are exactly one hop.

Partial migration (some pages still HTTP): If your redirect rules don't cover all URL patterns — for example, if a URL contains query parameters or special characters your rule didn't anticipate — some pages remain HTTP. Those pages receive no equity transfer and stay indexed as HTTP. The Link Checker can surface internal links to HTTP pages that weren't migrated.

Google delay: Google takes one to four weeks to re-crawl and re-index a fully migrated site at scale. Some ranking fluctuation in the first two weeks is normal — this is Google re-processing URLs, not evidence of a problem. If rankings have not stabilised after four weeks, audit for the issues above. Sites with many pages (10,000+) may take longer.

Tools for Verifying the Migration

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.