Does Google really merge HTTP and HTTPS into a single canonical URL?

What does this automatic merging really mean?

When Google detects two identical versions of content on HTTP and HTTPS, its algorithm does not treat them as two distinct pages. It consolidates signals (backlinks, PageRank, authority) towards a unique canonical URL that it chooses itself unless you guide it otherwise.

This merging occurs at the indexing level. The incoming links pointing to http://example.com/page and https://example.com/page both contribute to the ranking of the version Google considers canonical. The engine aggregates signals rather than diluting them between two URLs.

Why doesn’t Google always just favor HTTPS?

For years, Google has favored HTTPS as a ranking signal. However, this statement reveals a nuance: automatic merging does not guarantee that HTTPS will always be chosen as canonical. If your internal linking heavily points to HTTP, or if conflicting signals exist, Google may hesitate.

This is precisely why Mueller recommends not relying on automatic merging. Without explicit direction (redirect or canonical), you relinquish control over indexing to the algorithm’s interpretation.

What risks are there if we let Google handle it alone?

The main issue: instability. Google can change its mind about which version to canonize, especially if signals evolve. One day HTTPS is canonical, the next day HTTP takes the lead if a major site links to the non-secure version.

Another risk: Search Console and analytics data become less reliable. If Google flip-flops between versions, your click and impression curves fracture. You lose visibility on actual performance.

• Automatic consolidation of signals towards a unique canonical URL chosen by Google
• No guarantee that HTTPS will always be favored without explicit direction
• Risk of flip-flopping if signals (backlinks, internal links) are conflicting
• Limited control over indexing without a 301 redirect or rel=canonical
• Impact on Search Console metrics if the canonical version changes frequently

Is this statement consistent with real-world observations?

Yes, and it is confirmed by real cases. We regularly see sites where HTTPS and HTTP coexist in indexing, with flip-flops between versions depending on updates. Automatic merging exists, but it is neither instant nor always stable.

The critical point: Mueller says "Google tends to merge." "Tends" is not "guarantees." In practice, this merging can take several weeks after migrating to HTTPS, or may never occur if strong signals keep HTTP in contention. [To verify]: Google does not provide any specific timeline for this consolidation.

What nuances should be added to this rule?

Merging works well when the content is strictly identical. If the HTTPS and HTTP versions differ (even slightly: internal links, canonical tags, meta tags), Google may treat them as distinct pages. This is a common pitfall after a careless migration.

Another nuance: Mueller mentions "all links contribute to ranking." This is true for consolidated PageRank, but not for the anchor text. If 80% of your backlinks point to HTTP with the anchor "natural referencing" and 20% to HTTPS with the anchor "SEO," the consolidation favors the majority. You cannot finely control the distribution of anchors without a redirect.

When does this merging fail?

When the site sends conflicting signals. A typical example: a 301 redirect from HTTP→HTTPS is in place, but the XML sitemap only lists HTTP URLs. Google sees the redirect but the sitemap tells it, "index HTTP." The result: indecision, flip-flop.

Another frequent failure: missing HSTS on the server side. Google may hesitate to canonize HTTPS if the site does not enforce HTTPS at the protocol level. Without HSTS, HTTP remains technically accessible, thus potentially indexable.

What concrete steps should be taken to secure canonization?

First, implement a permanent 301 redirect from all HTTP URLs to HTTPS. This is the most reliable method: it transfers PageRank, clearly guides Google, and prevents hesitation. The redirect should be configured at the server level (Apache, Nginx) or via a CDN.

Next, add self-referencing canonical tags on every HTTPS page. Even if the redirect exists, the canonical reinforces the signal. Format: <link rel="canonical" href="https://example.com/page" /> on all HTTPS pages.

What mistakes should be avoided during HTTPS migration?

Never let HTTP and HTTPS coexist without redirects. Some sites activate HTTPS but leave HTTP accessible "for old backlinks." Classic mistake: Google indexes both, dilutes signals, and you lose ranking.

Another trap: using a 302 (temporary) redirect instead of a 301. The 302 does not optimally transfer PageRank. Google may interpret this as a temporary situation and keep HTTP in the index.

How can I check that my site is properly consolidated on HTTPS?

Use Search Console to check which version is indexed. Add both properties (http:// and https://) and compare the indexed pages. If HTTP still contains URLs in index weeks after migration, it’s a signal of failure.

Run a Screaming Frog or Oncrawl crawl in "Spider" mode to identify any internal links still pointing to HTTP. Each internal HTTP link is a conflicting signal sent to Google. Clean them all.

• Implement a permanent 301 redirect from HTTP to HTTPS at the server level
• Add self-referencing canonical tags on all HTTPS pages
• Enable HSTS to enforce HTTPS at the protocol level
• Update the XML sitemap to include only HTTPS URLs
• Check in Search Console that HTTP is no longer indexed after 4-6 weeks
• Crawl the site to eliminate all residual HTTP internal links