Can migrating to HTTPS really be done without losing rankings?

What does Google really say about HTTPS migrations?

Google distinguishes between two scenarios here: a simple HTTPS migration and a complete site move (domain change, structural redesign). The official stance is that moving from HTTP to HTTPS on the same domain should not trigger a loss of rankings, unlike a domain change which partially resets some signals.

This statement aims to reassure teams that are still hesitant to migrate to HTTPS for fear of breaking everything. The underlying message is that the transfer of SEO signals works properly when the migration is technically clean. Google considers HTTP and HTTPS as versions of the same site, not as two distinct entities.

How does Google transfer signals during an HTTPS migration?

The engine detects permanent 301 redirects from HTTP to HTTPS and gradually transfers ranking signals: domain authority, backlinks, crawl history, behavioral data. This process takes time, typically a few weeks, but does not cause a sudden reset like during a domain change.

Google uses XML sitemaps, internal links, and external backlinks to identify new HTTPS URLs and consolidate signals. If redirects are properly set up and the HTTPS site is technically sound, the transition should be invisible in terms of rankings.

Why do some HTTPS migrations still cause losses?

Google's statement relies on an assumption: that the migration is perfectly executed. However, many teams make mistakes: chain redirects, misconfigured SSL certificates, mixed content (HTTP and HTTPS on the same page), canonical tags still pointing to HTTP, or robots.txt blocking HTTPS URLs.

These technical errors prevent the clean transfer of signals. Google may also temporarily index both versions (HTTP and HTTPS), creating duplication and diluting signals. In these cases, the migration does lead to drops in traffic, but it's not Google penalizing; it’s the implementation that fails.

• The HTTPS migration is not treated as a complete domain change: signals are preserved if the technique is followed.
• Redirects from HTTP to HTTPS transfer authority and backlinks without significant loss.
• Google needs time to recrawl the entire site and consolidate signals on HTTPS URLs.
• Technical errors during migration are the main cause of traffic losses, not the HTTPS transition itself.
• Active post-migration monitoring (Search Console, server logs, Screaming Frog crawl) allows for quick fixes before they impact rankings permanently.

Does this statement align with real-world observations?

Yes and no. When an HTTPS migration is technically impeccable, there is indeed little to no loss of organic traffic. Signals transfer gradually, and after 4 to 6 weeks, rankings stabilize at the pre-migration level, or even slightly higher due to the minor ranking boost from HTTPS confirmed by Google.

However, the reality is that very few migrations are perfect. On medium to large sites (thousands of pages), there are almost always redirect errors, residual mixed content, or external backlinks continuing to point to HTTP without being properly redirected. In these cases, temporary drops of 10 to 30% in organic traffic are observed, which correct themselves once the errors are identified and fixed.

What nuances should be added to this statement?

Google does not specify the duration of signal transfer. In practice, it typically takes between 2 and 8 weeks depending on the site size and crawl frequency. During this period, there may be normal ranking fluctuations, which some SEOs misinterpret as a penalty related to the HTTPS migration.

Another nuance: Google talks about “transferred signals,” but does not mention mixed content or invalid SSL certificates, which can trigger security alerts in browsers and cause drops in organic click-through rates. A poorly configured HTTPS site can lose traffic not because of rankings, but due to degraded behavioral factors. [To verify]: Google has never published numerical data on the percentage of HTTPS migrations that go smoothly.

In what cases does this rule not apply?

If you use the HTTPS migration to massively revamp the site structure (changing URLs, removing entire sections, redesigning the internal linking), then you step outside the framework of a “simple HTTPS migration.” In this case, Google treats it as a complex site move, significantly increasing the risk of ranking losses.

Another critical case: sites with millions of pages and a limited crawl budget. Google can take several months to recrawl the entire site on HTTPS, delaying the complete transfer of signals. Meanwhile, some pages remain indexed in HTTP, others in HTTPS, creating index cannibalization. A crawl prioritization strategy (via the XML sitemap and server logs) becomes essential.

What should you do concretely before migrating to HTTPS?

First of all, audit the current state of the HTTP site: list all URLs, identify external backlinks, check existing redirects, and document baseline SEO performance (traffic, rankings, indexed pages). This audit serves as a baseline to measure post-migration impact.

Install a valid SSL certificate (minimum TLS 1.2, ideally TLS 1.3) across the entire domain, including subdomains if necessary. Test the certificate with tools like SSL Labs to ensure there are no security alerts. Then configure permanent 301 redirects from all HTTP URLs to their HTTPS equivalents at the server level (Apache, Nginx), never in JavaScript.

What errors should you absolutely avoid during the transition?

The most common mistake: forgetting to redirect all URL variants. It’s not enough to redirect the homepage and a few popular pages. All indexed URLs must have their individual 301 redirect, otherwise Google will continue to see 404 errors or orphaned HTTP pages.

A second classic error: mixed content. If your HTTPS site still loads resources (images, CSS, JS, iframes) over HTTP, browsers will display security alerts, and Google may consider the migration incomplete. Use a crawler like Screaming Frog to detect all mixed content before going live.

How can you verify that the migration went well?

Within 48 hours of the switch, check in Google Search Console that HTTPS URLs are starting to be crawled and indexed. Add a new Search Console property for the HTTPS version if it hasn’t been done already, and monitor coverage errors. Also verify that XML sitemaps now point to the HTTPS URLs and resubmit them.

Check the server logs to ensure that Googlebot is actively crawling the HTTPS URLs and that the 301 redirects are being followed correctly (status code 301, not 302). Monitor organic traffic and rankings of key pages daily for at least 4 weeks. If you notice any abnormal drops, immediately conduct a technical audit to identify the errors.

• Install a properly configured and valid SSL/TLS certificate
• Redirect all HTTP URLs to HTTPS using permanent 301 redirects at the server level
• Eliminate all mixed content (HTTP resources on HTTPS pages)
• Update XML sitemaps with HTTPS URLs and resubmit in Search Console
• Verify that canonical tags point to HTTPS URLs
• Monitor Search Console, server logs, and analytics daily for 4 weeks post-migration