HTTPS Migration Without Losing Rankings: A SEO Team Playbook

An HTTPS migration looks simple on paper — install a certificate, redirect HTTP, done. In practice, SEO teams inherit the cleanup: lost rankings from broken redirect chains, indexation drops from mixed canonicals, and crawl waste from outdated internal links. This guide walks through the exact sequence that keeps organic traffic stable during and after the switch.

Pre-migration: audit before you touch anything

Before any server changes, snapshot the current state. You need a baseline to compare against if rankings wobble post-launch.

• Crawl the full HTTP site with Screaming Frog or Sitebulb. Export every URL, status code, canonical, hreflang, and meta robots tag.
• Export top organic pages from Google Search Console (last 16 months) and Google Analytics. Save them as a CSV — this is your ranking watchlist.
• Note all subdomains: www, non-www, blog, shop, cdn, static. Each one needs its own certificate and redirect strategy.
• List every external integration that calls your site: payment webhooks, email tracking pixels, partner feeds, ad networks. They often hardcode http://.

Choose your canonical hostname

Decide now whether you're going with https://www.example.com or https://example.com. Mixing the two is the single most common cause of duplicate-content issues post-migration. Pick one, redirect the other.

Certificate setup and HTTPS configuration

A valid certificate is the floor, not the ceiling. Modern SEO benefits from HTTPS only when the implementation doesn't trigger browser warnings or weak-config flags.

1. Issue certificates for every hostname users or crawlers can hit, including www and bare domain. Let's Encrypt or your hosting provider works fine; wildcard certs help if you have many subdomains.
2. Disable TLS 1.0 and 1.1. Modern browsers flag them, and some scanners will downgrade your score.
3. Enable HSTS, but start with a short max-age (e.g. 300 seconds) until you're confident nothing breaks. Increase to max-age=31536000; includeSubDomains once stable.
4. Test the config with SSL Labs and a security header scanner like WebSentry to catch missing headers, weak ciphers, or misconfigured certificate chains before launch.

Redirects: the part that breaks rankings

This is where most migrations leak link equity. Google handles 301s well, but only if they're clean, single-hop, and consistent.

301, not 302

Use permanent 301 redirects from HTTP to HTTPS. 302s signal a temporary move and don't pass full ranking signals as reliably. Confirm at the server level — not via meta refresh or JavaScript.

Avoid redirect chains

A common pattern after migration looks like this:

http://example.com/page → http://www.example.com/page → https://www.example.com/page

Each hop wastes crawl budget and can dilute signals. Collapse it to a single redirect:

http://example.com/page → https://www.example.com/page

Test 50+ URLs across the site after launch — homepage, top categories, product pages, blog posts, paginated URLs, and parameter-heavy URLs.

Preserve URL structure

Don't combine an HTTPS migration with a URL restructure. If you must, do HTTPS first, monitor for two to four weeks, then restructure. Stacking two major changes makes diagnosis impossible if something tanks.

Update on-site references

Server-side redirects handle external traffic, but internal links should point directly to HTTPS URLs. Crawl your staging or live site and fix:

• Internal anchor links hardcoded as http://
• Canonical tags still referencing HTTP
• Hreflang annotations
• XML sitemaps (regenerate with HTTPS URLs only)
• Open Graph and Twitter card URLs
• Structured data url and @id properties
• RSS feeds and pagination rel="next/prev" if used

Kill mixed content

A single HTTP image, script, or iframe on an HTTPS page triggers a "Not Secure" warning in browsers. Worse, modern browsers block active mixed content (scripts, XHR) entirely, which can break tracking and layout.

Search your codebase and CMS for http:// references. For legacy content with hardcoded external image URLs, a temporary Content Security Policy with upgrade-insecure-requests buys time while you migrate assets:

Content-Security-Policy: upgrade-insecure-requests

Search Console and analytics setup

Google treats http:// and https:// as separate properties. Miss this step and you lose visibility into your own migration.

1. Add the HTTPS property in Google Search Console (and the www/non-www variants if not using a Domain property).
2. Submit the new HTTPS XML sitemap.
3. Use the URL Inspection tool on five to ten key pages to confirm Google sees the HTTPS version as canonical.
4. Update the default URL in Google Analytics / GA4 stream settings.
5. Update Bing Webmaster Tools, Yandex, and any rank-tracking tools.

Don't disavow or change the disavow file

Your existing disavow file carries over via the domain, but in some workflows you'll need to re-upload it under the HTTPS property. Check before assuming it transferred.

Launch day checklist

• Deploy during a low-traffic window.
• Verify 301s on 20+ URL patterns immediately.
• Crawl the live HTTPS site and compare against the pre-migration export. Status codes, titles, canonicals, and word counts should match within tolerance.
• Run a full security scan with WebSentry to confirm headers, SSL config, CSP, and cookie flags are all in order — broken security headers post-launch are common and quietly hurt trust signals.
• Submit the new sitemap and request indexing for the homepage and top five pages.
• Monitor server logs for crawler activity — Googlebot should start hitting HTTPS URLs within hours.

Post-migration monitoring (the first 30 days)

Expect a small, temporary dip in impressions during the first one to two weeks as Google reprocesses URLs. A drop greater than 15% or one that doesn't recover within three weeks signals a real problem.

Watch these signals daily for the first week, then weekly:

• Index coverage in Search Console — HTTPS valid URLs should grow as HTTP ones drop off.
• Crawl stats — a spike followed by stabilisation is normal.
• Top-page rankings from your watchlist CSV.
• Referral traffic — some referrers strip query strings on HTTP→HTTPS hops, which can distort attribution.
• Core Web Vitals — TLS adds a small handshake cost; HTTP/2 or HTTP/3 should offset it.

Common post-launch issues and fixes

• HTTP URLs still indexed weeks later: verify the 301 returns a clean response with no intermediate hops, and that the HTTP page isn't blocked by robots.txt (Google can't see the redirect if it can't crawl).
• Duplicate HTTPS and HTTP in GSC: a canonical tag somewhere still points to HTTP. Crawl and fix.
• Mixed content warnings returning: usually a CMS plugin or editor inserting HTTP image URLs. Add a database find-replace or enforce upgrade-insecure-requests.
• Dropped backlinks: reach out to top referring domains and ask them to update to HTTPS URLs. Even with 301s, direct links pass signals more cleanly.

Once the dust settles, lock in the gains: raise HSTS max-age to a year, submit your domain to the HSTS preload list, and re-scan periodically. A free scan at websentry.dev will catch regressions in headers, certificates, and CSP before they show up in your rankings.