Canonical URL data attribution

Search Console usually assigns a page's clicks, impressions, and position to the canonical URL selected by Google—not necessarily to the URL shown to or opened by the visitor. This consolidation prevents desktop, mobile, parameter, protocol, and other duplicate variants from fragmenting the same page's performance.

It also creates a common source of confusion: a URL can receive visits from Google while showing little or no performance data under its own address in the Pages table.

What is a canonical URL?

When Google finds multiple URLs with duplicate or very similar primary content, it groups them and selects one representative URL. That is the Google-selected canonical.

Common duplicate groups include:

• HTTP and HTTPS versions.
• www and non-www hosts.
• Desktop and separate mobile URLs.
• URLs with tracking, sorting, filtering, or session parameters.
• Print or alternate-format pages.
• The same product or article reachable through several paths.
• Regional pages whose primary content is effectively the same language and content.

Duplicate content inside a site is normal and is not inherently a spam violation. Canonicalization helps Google choose which version to index and normally show. Google's canonicalization overview explains that the canonical becomes the primary source used to evaluate the duplicate cluster.

User-declared versus Google-selected canonical

The user-declared canonical is the URL the site indicates through a rel="canonical" element or HTTP header. Other signals include redirects, sitemap inclusion, and consistent internal links.

The Google-selected canonical is the representative URL Google's indexing systems actually choose. A declared canonical is a strong signal, not an absolute directive. Google can choose another URL when signals conflict or it considers another page more representative.

Google describes the main signals in this order:

• Permanent redirects are a strong signal.
• rel="canonical" annotations are a strong signal.
• Sitemap inclusion is a weaker signal.
• Signals can reinforce one another when they consistently name the same URL.

Internal links should also point consistently to the preferred canonical. Do not use robots.txt, temporary removals, or noindex as substitutes for canonicalization. See Google's canonical implementation guidance.

Which URL receives Performance credit?

Google's metric documentation says that click, impression, and position data for page variants is generally assigned to the Google-selected canonical. The Performance Pages dimension therefore represents canonicalized reporting, not a literal list of every URL that appeared or received a visit.

Example:

1. Google shows https://m.example.com/guide to a mobile user.
2. Google has selected https://www.example.com/guide as canonical.
3. The mobile user clicks and lands on the mobile URL.
4. Search Console normally credits the click, impression, and position to the www canonical.
5. The Device dimension can still classify the interaction as mobile.

Google notes that some cases can be assigned to the actual URL rather than the canonical, so treat canonical attribution as the normal rule rather than an irreversible guarantee for every result type.

The final linked URL and a later redirect are different questions

The Pages dimension groups data around the URL linked by the Search result, after Search-result-side redirects and canonical processing. If the site redirects the user after the landing event, that later redirect does not reassign the original impression or click.

This matters when analytics records the final post-redirect landing URL while Search Console credits the Google-selected canonical. Joining page-level GSC and analytics data requires a maintained URL mapping rather than a raw string match.

Why a duplicate URL is absent from the Pages table

The most likely explanations are:

• Its metrics were consolidated under another Google-selected canonical.
• The URL row fell outside Search Console's top-row limits.
• The URL belongs outside the selected property scope.
• The page had no eligible recorded performance in the selected dates and Search type.
• A URL filter used the duplicate instead of the credited canonical.

Absence from the Pages table does not prove that Google never crawled the URL, never showed it, or that no user opened it.

Use Crawl Stats or server logs to investigate actual requested URLs. Crawl Stats explicitly reports actual URLs requested by Google rather than assigning them to canonicals.

How to find the Google-selected canonical

1. Open the property that includes the URL.
2. Enter the exact duplicate or suspected canonical in URL Inspection.
3. Use the indexed result, not only the live test.
4. Expand Page indexing.
5. Compare User-declared canonical with Google-selected canonical.
6. Inspect the selected canonical as a separate URL when it is inside a property you can access.

The live test cannot predict canonical selection. Google chooses a canonical during indexing, so the authoritative field exists in indexed inspection data. This limitation is documented in the URL Inspection guide.

What if the selected canonical is in another property?

Performance follows the canonical. If Google selects a canonical that is outside the current Search Console property, data can appear absent from the property containing the duplicate.

Examples include:

• A subdomain duplicate canonicalized to the root domain.
• An HTTP property whose pages canonicalize to HTTPS.
• A regional or syndication URL canonicalized to another host.
• A directory URL-prefix property whose canonical sits outside that directory.

Add and verify the property that contains the canonical when you control it. A Domain property is often useful for consolidating visibility across protocols and subdomains, but path-specific URL-prefix properties can still be useful for organizational reporting.

If the canonical belongs to a domain you do not control, you cannot use your property to see that other property's private performance data.

How canonical changes affect trend analysis

When Google changes its selected canonical, page-level performance can move from one URL row to another without an equivalent change in total property clicks or impressions.

Warning signs include:

• One URL loses nearly the same amount another URL gains.
• Property totals remain stable while page totals shift.
• URL Inspection shows a new selected canonical.
• A migration, redirect, template, internal-link, or canonical-tag release occurred near the change.
• Analytics landing-page traffic and GSC credited-page data diverge.

Create a canonical cluster that maps all relevant variants to the preferred URL, then analyze the cluster total across the change. Do not interpret one disappearing URL row as a traffic loss until property totals and destination URLs are checked.

How to troubleshoot an unwanted canonical

1. Compare the content

Google may not consider the declared target sufficiently similar, or it may believe another URL is more complete and useful. Compare titles, primary content, media, structured data, internal navigation, language, and rendered output.

2. Align every signal

• Use a self-referencing canonical on the preferred page.
• Point duplicate canonicals to the preferred page.
• Use a permanent redirect when the duplicate should not remain accessible.
• Include preferred canonical URLs in XML sitemaps.
• Link internally to preferred URLs.
• Avoid chains, loops, and conflicting declarations.
• Keep hreflang canonicals within the same language when possible.

3. Confirm access and indexability

The preferred canonical should return a successful response, be crawlable, and normally be indexable. A canonical pointing to an error, blocked, empty, or noindex page sends conflicting signals.

4. Reinspect after Google recrawls

A live test can confirm current markup and access, but only later indexed data can confirm a new Google-selected canonical. Requesting indexing does not force Google's choice or guarantee when it changes.

Canonical attribution and report filters

When investigating a duplicate:

1. Inspect it to find the selected canonical.
2. Filter the Performance report by the canonical URL.
3. Check Page aggregation and the selected property scope.
4. Segment by Device rather than expecting separate mobile and desktop URL rows.
5. Compare property totals before and after canonical changes.

Do not add the duplicate and canonical rows together without confirming whether any data is already consolidated. Double-counting can result.

Common mistakes

• Assuming the HTML canonical tag is always the URL Google selected.
• Filtering Performance by the landing URL from GA4 without mapping it to Google's canonical.
• Treating a duplicate's missing row as proof that it had no Search visibility.
• Blocking duplicates in robots.txt, preventing Google from reading their canonical signals.
• Using noindex or the Removals tool as a canonicalization method.
• Sending sitemap, internal-link, redirect, and canonical signals to different URLs.
• Using the live URL test to claim canonical selection has changed.
• Comparing page-level rows without checking whether the canonical moved.

Official sources

• What are impressions, position, and clicks?
• Performance dimensions and canonical aggregation
• What is canonicalization?
• How to specify a canonical URL
• URL Inspection tool
• Duplicate URL
• Page Indexing report canonical statuses
• Crawl Stats report