Why do your click data disappear between Search Console and Analytics after an HTTPS migration?

What really happens when Google switches your URL to HTTPS?

Google does not just passively index your pages. It actively normalizes URLs according to its own logic: protocol (HTTP vs HTTPS), subdomain (www or not), trailing slash, parameters. When you migrate to HTTPS, Google chooses the version it considers canonical and this version inherits all impression and click data in Search Console.

Specifically? If your old Search Console property was only tracking HTTP, you will notice a sharp drop in impressions. Not because your site is performing worse, but because the data is now attributed to the HTTPS version that you may not have declared as a separate property.

Why doesn’t Google automatically merge the data?

Search Console treats each protocol/subdomain combination as a separate property. This is a technical architecture issue: http://example.com and https://example.com are two distinct entities from the crawler's perspective. Google does not assume that you control both versions, even if it is obvious to you.

This separation creates a gap between what you see in Search Console and the reality of user behavior in Analytics. Analytics can automatically consolidate versions if your tracking is configured correctly, but Search Console will never do this. You must explicitly declare each version as a property to get the complete picture.

How does this logic affect your daily tracking?

Most SEOs discover the problem after the fact when they notice a discontinuity in their performance graphs. Impressions seem to plummet, clicks disappear, while actual traffic remains stable in Analytics. This is the classic sign of tracking fragmentation across multiple Search Console properties.

Even worse: if you have never created a property for your HTTPS version, you will see no data appear. Google indeed records performance, but you simply do not have access to it as long as the property does not exist in your account. Historical data is not retroactive: you will never recover the 3 months during which you did not declare HTTPS.

• Search Console never merges data between protocols (HTTP/HTTPS) or subdomains (www/non-www)
• Impressions and clicks are attributed to the canonical version chosen by Google, not the one you prefer
• Creating a property afterwards does not recover the lost history during the unmonitored period
• Analytics can consolidate versions if tracking is unified, but Search Console remains compartmentalized
• Google's canonical version does not always match your canonical tag or redirects

Is Mueller's recommendation really new?

No, and that's what is surprising. This logic of strict separation of properties has existed since Search Console was created (formerly Webmaster Tools). Mueller is merely reminding us of a fundamental that many practitioners overlook or discover too late. The real question is: why doesn’t Google still offer a unified view for the variations of the same site?

Other tools (Bing Webmaster Tools, some third-party SEO suites) allow you to group variations under one interface. Google maintains this strict separation, officially to avoid property confusion, unofficially perhaps to limit the data volumes to be processed on the server side. [To verify]: no official statement explains why this merging is not offered as an option.

What to do when Google chooses a canonical version different from yours?

This is the typical case where you have set up perfect 301 redirects, a clean canonical tag, and yet Google indexes a different version. This happens more often than one might think, especially on sites with multiple subdomains or regional variants. Search Console then shows you the version that Google has decided to index, not the one you impose.

In such situations, checking "all versions" as Mueller advises becomes critical. But beware: creating 8 different properties (HTTP/HTTPS × www/non-www × different TLDs) turns Search Console into a complex setup. The practitioner solution: use a Domain type property (DNS validation) that aggregates all variants. However, this option has its own limits, particularly the inability to filter finely by subdomain.

What are the practical limits of this advice?

Mueller suggests to "check all versions," but on a complex site, this could represent dozens of combinations. Do you really need to monitor http://www, http://non-www, https://www, https://non-www for every significant subdomain? Technically yes, practically it is unmanageable.

The real recommendation should be: enforce a canonical version through strict redirects, ensure that Google respects it in the index coverage report, then monitor only this version in Search Console. If Google persists in indexing another variant despite your signals, then yes, create a property for this "rebellious" version and investigate why your directives are not being followed. [To verify]: to what extent does Google ignore explicit canonical signals? No official stats on this.

What should you immediately configure in Search Console?

The first step: create a Domain type property (DNS validation) if you haven’t done so already. It automatically aggregates all protocol/subdomain variants. This is the cleanest solution to have an overview without juggling between 6 different properties. Keep your old URL properties active for history, but shift your daily monitoring to the Domain property.

Next, check in the Index Coverage report which version Google is actually indexing. If you see URLs being indexed massively in HTTP while you migrated to HTTPS 6 months ago, you have a problem with redirects or conflicting canonical signals. This mismatch creates the data fragmentation across properties.

How to avoid losing data during a migration?

Before any migration (HTTP→HTTPS, domain change, URLs restructuring), create the new Search Console property in advance. Do not wait until the migration is complete. Google starts accumulating data as soon as the property exists and URLs are discovered. If you create the property 3 weeks after the DNS switch, you lose 3 weeks of data permanently.

Simultaneously, keep the old property active for at least 6 months post-migration. You will see impressions/clicks gradually decline on the old one, grow on the new one. This transition period allows you to detect problems: if the old one continues to receive 40% of impressions 2 months after migration, it means Google has not fully switched, indicating incomplete redirects or broken internal links.

What strategy should you adopt for complex multi-variant sites?

On a site with several business subdomains (blog.example.com, shop.example.com, support.example.com), the Domain property is not enough. You lose granularity by subdomain. Practitioner solution: create a Domain property for the consolidated view, then a separate URL property for each strategic subdomain you want to monitor closely.

Yes, that makes 4-5 properties to manage. But it is the only way to reconcile the overall view (Domain property) and detailed analysis (URL properties). Automate monitoring through the Search Console API if you have the technical resources; otherwise, focus your daily monitoring on the 2-3 properties that generate 80% of traffic.

• Create a Domain type property (DNS validation) to aggregate all protocol/subdomain variants
• Check in the Coverage report which canonical version Google is actually indexing
• Before any migration, create the new Search Console property at least 2 weeks in advance
• Keep the old properties active for 6 months post-migration to monitor the transition
• For multi-subdomain sites: combine 1 Domain property (global view) + URL properties for each strategic subdomain
• Regularly export data via API or manually to build a unified history outside of Search Console