Do links really follow the canonical URLs on both sides?

What does it really mean to "follow links according to the canonicals"?

When Google crawls a page and detects a link, it does not work directly with the raw URL displayed in the HTML code. It first resolves the canonical of the source page, and then that of the destination page. Only then does it attribute link credit — the famous PageRank — between these two canonicals.

Let’s take a practical example: your site A has a page A1 (with a variant A1?ref=twitter that you canonized towards A1). This page A1 links to B1 on site B. If B1 has its own canonical pointing to B2, Google will count this link as going from A1 to B2, not to B1. Both sides of the link are normalized before the juice is passed.

How does this mechanism complicate migrations?

During a domain or architecture migration, old URLs are massively redirected to new ones. Search Console displays incoming backlinks with a sometimes shocking delay, and Mueller explains why: before it can transfer link data to the new domain, Google must first resolve the new canonicals.

This process can take several months — yes, several months — because Google needs to re-crawl all the migrated pages, establish the new canonicals, and only then recalculate the link graph. As long as the canonical has not switched on Google's side, the backlinks remain attached to the old URL in internal systems. Hence the apparent ambiguity in Search Console post-migration.

What are the implications for PageRank and ranking?

If Google normalizes links via canonicals, poor management of canonical tags dilutes or redirects PageRank where you don’t want it to go. Imagine mistakenly canonizing an important page to a paginated version or a less relevant variant: all backlinks pointing to that page will be credited to the chosen canonical, not to the original URL.

Another common case: external sites link to variants with parameters (utm_source, sessionid, etc.). If you have not defined an explicit canonical, Google may choose one that does not match your strategy. The result? A fragmented link graph, dispersed PageRank, and a declining ranking.

• Google resolves canonicals on both sides before counting a link (source and destination).
• During a migration, transferring backlink data in Search Console takes several months, as Google must first switch the canonicals.
• Poor management of canonical tags can dilute PageRank by redirecting credit to non-strategic URLs.
• Backlinks pointing to URL variants (parameters, trailing slash, etc.) are consolidated on the canonical chosen by Google.
• During the transition phase, Search Console may display incomplete or delayed data on incoming links.

Is this mechanism consistent with field observations?

Frankly, yes. Long migrations stabilizing in Search Console happen regularly. What Mueller describes corresponds to what we observe: after a clean migration with smooth 301 redirects, backlinks take a long time to switch in the interface. For weeks, if not months, we have one foot in the old domain on the reporting side.

What is less documented is exactly how long it takes for Google to resolve new canonicals on a large scale. Mueller mentions "several months", but we lack granularity. Is it 2 months for a site with 10,000 pages? 6 months for 500,000? [To be verified] with broader field data. Responses vary greatly depending on crawl budget, historical crawl frequency, and the technical cleanliness of the site.

What nuances should be added regarding canonical resolution?

Google does not blindly follow canonical tags. It is a directive, not an order. If you canonicalize a page A to a page B that is very different in content, Google may ignore your tag and choose its own canonical. The same goes if you canonicalize to a URL that returns a 404, or if you create a loop (A canonicalizes to B which canonicalizes back to A).

Another point: the resolution of the canonical on the destination side is critical for sites receiving backlinks. If an external site links to a non-canonical variant, Google will count that link for the canonical it has chosen — not necessarily the one you want. Hence the importance of actively controlling canonicals, especially on strategic pages with many incoming backlinks.

When does this logic pose a problem?

Take the case of a site architecture overhaul where you change URLs but keep the same domain. If you implement 301 redirects without managing the canonicals beforehand, you risk a period of uncertainty where Google hesitates between the old and new URL. Backlinks may remain attached to the old canonical for several weeks.

Another classic scenario: e-commerce sites with product variants (color, size, etc.). If each variant has its own URL and you have not canonicalized to a master URL, backlinks to different variants will be counted separately, diluting PageRank instead of concentrating it.

What should you do concretely before and during a migration?

Before redirecting anything, audit your canonicals. Make sure every important page has an explicit and coherent canonical. Check in Search Console (Coverage or Page Indexing tab) which URLs Google has retained as canonicals — sometimes, the surprise is total.

During the migration, keep the old 301 redirects active for at least 6 to 12 months, until Google has re-crawled, resolved the new canonicals, and recalculated the link graph. Do not count on an instant transfer of backlinks in Search Console: that is a slow process by nature.

How to avoid dilution of PageRank via canonicals?

Identify your pages with strong backlink capital using a tool like Ahrefs, Majestic, or Semrush. For each, check that the canonical points to the strategic URL, not to a parameterized variant or a paginated version. If there are massive backlinks pointing to variants, redirect them properly or adjust the canonicals.

For e-commerce sites or those with many filters/facets, define a clear canonical policy from the start. Example: all product variants canonicalize to the URL of the main product page. All pages with active filters canonicalize to the filter-free page. Document this policy and test it in pre-production before deployment.

Which tools to use to track the evolution of canonicals post-migration?

Search Console remains the go-to tool to check which URLs Google considers as canonicals. But beware, data may be several weeks delayed. Complement with regular crawls using Screaming Frog or Oncrawl to detect inconsistencies (canonical pointing to 404s, loops, etc.).

To track the transfer of backlinks, regularly export link data from Search Console and compare it with your third-party backlink tool. If after 3-4 months post-migration the backlinks still haven’t switched, there’s probably a problem with unresolved canonicals on Google’s side.

• Audit all canonical tags before any migration or architectural overhaul.
• Check in Search Console that Google has retained the desired canonicals for strategic pages.
• Keep 301 redirects active for at least 6 to 12 months after migration.
• Monitor the evolution of backlinks in Search Console post-migration — expect several months of delay.
• Document a clear canonicalization policy for product variants, filters, and URL parameters.
• Regularly crawl the site to detect broken or inconsistent canonicals.