Why is Google now consolidating all Search Console data under the canonical URL?

What exactly changes with this data consolidation under the canonical URL?

Before this change, Search Console displayed performance separately for each indexed URL — particularly distinguishing between mobile and desktop versions if they differed. You could clearly see impressions, clicks, and CTR for m.example.com and www.example.com, for example.

Now, all this data is merged under the URL that Google considers canonical. If you have a desktop version on www.example.com and a mobile version on m.example.com, but Google chooses www.example.com as canonical, it is this URL that will concentrate all the metrics — including those generated by the mobile version.

How does Google determine which URL to display in the reports?

Google applies its logic of canonical URL selection, which may differ from your rel=canonical tag. The engine analyzes technical signals (redirects, canonical tags, sitemaps), as well as user signals and content consistency.

The crucial point: it’s not you who decides which URL appears in Search Console, it’s Google’s algorithm. You can suggest a canonical via your tags, but Google reserves the right to select another one if its signals point elsewhere.

What is the impact on reading mobile vs desktop performance?

The consolidation makes it impossible to distinguish performance by device directly in the standard report. You no longer see if your mobile version generates 70% of the clicks while the desktop stagnates. Everything is aggregated.

To regain this granularity, you must use device filters in Search Console. But be careful: even with these filters, the data remains tied to the canonical URL — you filter performance by device, not by the actual URL visited.

• Automatic consolidation: all variant URLs are merged under the canonical chosen by Google
• Loss of direct visibility: it’s impossible to see at a glance which URL variant performs without filtering by device
• Dependence on filters: mobile/desktop segmentation now requires active manipulation in the interface
• Possible divergence: the displayed canonical URL may differ from the one you declared via rel=canonical
• Impact on analysis: automated reports or raw CSV exports aggregate everything without distinguishing the source

Is this statement consistent with practices observed in the field?

Yes, and it’s even a formalization of a behavior that has been gradually rolled out. Since the switch to mobile-first indexing, Google has standardized its approach to handling data in Search Console. Previously, inconsistencies between mobile and desktop versions created duplicates in reports — sometimes the same page appeared twice with different metrics.

In practice, this consolidation simplifies reading for well-structured sites but creates opaqueness for those who still maintain distinct URLs by device. The problem: Google does not explicitly state how it handles edge cases — sites with active m-dots, AMP, regional variants with cross-domain canonical tags.

What nuances should be added to this announcement?

First point: consolidation does not mean that Google ignores your variants. It crawls them, potentially indexes them, and uses them to serve results. But from a reporting perspective, it unifies everything under a single entity to avoid data fragmentation.

Second nuance: this logic applies only to the performance report. In the URL inspection tool, you can still check the status of a specific URL — mobile or desktop — and see which canonical Google assigns to it. Therefore, consolidation is a matter of metric presentation, not technical processing.

[To be verified] Google remains vague on how it handles cases where the canonical URL changes frequently. If your site switches between several canonicals depending on algorithm updates or migrations, how are the histories managed? No official documentation details this scenario.

In what cases can this rule cause problems?

If you are still operating a distinct m-dot site (m.example.com) with slightly different content or structures, you lose the ability to directly compare the performance of the two versions in Search Console. You need to cross-reference with Analytics to reconstruct the puzzle.

Another problematic case: sites with cross-domain canonicals. Imagine you syndicate content across multiple domains with a canonical link to the main site. Search Console will consolidate everything under the main domain — but if you manage properties separately, some data may not appear where you expect it.

What should you actually do to adapt your analysis?

First step: check which canonical URL Google has actually selected for your strategic pages. Use the URL inspection tool in Search Console on each variant (mobile, desktop, with or without www, http vs https). Compare the canonical declared by Google with the one you defined via rel=canonical.

If you find discrepancies, strengthen your canonical signals: consistency of the rel=canonical tag across all pages, clean 301 redirects, declaration in the XML sitemap. But keep in mind that Google may still choose another URL if its internal signals (internal links, backlinks, history) point elsewhere.

How can you regain device granularity in your reports?

Systematically use the "Device" filters in the performance report. Create separate segments for mobile, desktop, and tablet, then export the data to analyze it in a pivot table. It’s tedious, but it’s the only way to reconstruct the device-by-device view.

If you automate your reports through the Search Console API, add the "device" dimension to your queries to segment data right at extraction. Don’t settle for raw exports that aggregate everything — you would lose most of the analytical detail.

What mistakes should you avoid when interpreting consolidated data?

Never assume that the URL displayed in Search Console is the one users are actually visiting. It’s the canonical URL chosen by Google, not necessarily the destination URL. If you draw conclusions about a page's performance without cross-referencing with Analytics, you risk missing critical issues — for example, a broken mobile version that continues to receive traffic but does not show up in your reports.

Another pitfall: don’t confuse data consolidation and deprioritization of one variant. Just because Search Console displays everything under the desktop version doesn’t mean Google mainly serves that version. With mobile-first indexing, it's often the opposite — but data is still attached to the desktop canonical if that’s the one Google chose.

• Audit declared canonical URLs vs. those selected by Google through the inspection tool
• Always filter by device in the performance report to segment mobile/desktop
• Automate data extraction via the API with the "device" dimension enabled
• Cross-reference Search Console data with Analytics to validate the consistency of visited URLs
• Document discrepancies between declared canonical and Google canonical to prioritize technical fixes
• Ensure that all relevant properties (www, non-www, http, https) are validated in Search Console to avoid losing any data