How do Canonical and Alternate Links Properly Connect Your Desktop and Mobile Versions?

Is This Recommendation Still Relevant?

This guideline from John Mueller pertains to the old m-dot architecture, where sites maintained two distinct versions: one for desktop (www.example.com) and one for mobile (m.example.com). The rel='alternate' on the desktop version signals to Google the existence of a mobile variant, while the rel='canonical' on the mobile version indicates which version is the primary one.

Since Google has switched to mobile-first indexing for the vast majority of the web, this setup has lost relevance for most sites. Responsive design, where a single URL serves all versions, has become the recommended standard. Therefore, you no longer need either alternate or canonical links between versions.

Why Does This Configuration Still Exist?

Some sites, particularly legacy media or complex e-commerce platforms, still maintain m-dot versions for technical or strategic reasons. In these specific cases, Mueller's recommendation remains valid. The bidirectional annotation allows Google to understand the relationship between the two versions.

Without these properly implemented tags, Google risks indexing both versions as duplicate content, failing to display the correct version based on the device, or diluting ranking signals between the two URLs. The main risk is losing mobile traffic by serving the desktop version to smartphone users.

What Is the Exact Mechanism of This Annotation?

The setup is mirrored: each desktop page contains a <link rel='alternate' media='only screen and (max-width: 640px)' href='https://m.example.com/page'> tag in its <head>. Simultaneously, the corresponding mobile page contains <link rel='canonical' href='https://www.example.com/page'>.

This dual annotation informs Google that these two URLs represent the same content, adapted for different contexts. The canonical from the mobile version consolidates the signals towards the desktop version, deemed the primary one. The alternate allows Google to substitute the mobile URL in mobile SERPs.

• m-dot architecture only: this configuration applies only to sites with separate desktop/mobile URLs
• Bidirectional annotation mandatory: both tags must be present to function correctly
• Responsive design preferred: Google officially recommends responsive over separate URLs
• Mobile-first indexing: Google now indexes the mobile version, changing the historical dynamic
• Risk of duplication: without correct annotation, both versions may be indexed independently

Does This Statement Align With Observed Practices?

Let's be honest: this recommendation is technically accurate but contextually outdated. It dates from a time when separate URLs were common, before Google pushed heavily for responsive and mobile-first indexing. Today, less than 5% of the sites I audit still use an m-dot architecture.

For the few sites involved, the guideline does work effectively. However, it creates a significant maintenance burden: each new page requires two URLs, two templates, and perfect synchronization of annotations. Implementation errors are common, especially during redesigns or large content deployments.

What Nuances Should Be Considered About Mobile-First Indexing?

The crucial point that Mueller does not address here: with the generalized mobile-first indexing, Google now uses the mobile version for indexing and ranking, even for desktop searches. This evolution completely reverses the historical logic where the desktop was the primary version. [To be verified]: the relevance of defining the desktop as canonical in this context.

In practice, I observe that for still-active m-dot sites, Google manages this inherited configuration correctly, but the SEO performance is often lower than that of a responsive equivalent. Ranking signals remain fragmented between the two versions despite the canonical, and Core Web Vitals are generally degraded on the separate mobile version.

In Which Cases Is This Configuration Still Justifiable?

Three scenarios still legitimize the use of separate URLs: very large legacy sites where a responsive migration would cost several million, platforms with radically different experiences between mobile and desktop (some e-commerce pure players), and sites in a gradual migration phase towards responsive.

For all other cases, the expert recommendation is clear: migrate to responsive. The benefits in terms of maintenance, SEO signal consistency, and user performance far outweigh the cost of migration. If you maintain an m-dot architecture out of habit rather than technical necessity, you are accumulating technical debt.

What Should You Do If You Have an m-Dot Architecture?

The first step: audit the completeness of your annotations. Crawl your site with Screaming Frog or Oncrawl, extract all alternate and canonical tags, and then verify that each pair is complete and bidirectional. Typical errors include: desktop pages without alternate, mobile pages without canonical, URLs that do not match exactly.

Next, check in the Search Console that Google detects both versions and does not flag any canonical conflicts. Analyze impressions by device: if you are losing mobile traffic while your rankings are stable, it is often an annotation issue that serves the wrong version.

What Critical Errors Must Absolutely Be Avoided?

The most frequent mistake is implementing the canonical from the mobile version to the desktop but forgetting the alternate on the desktop. Google then receives contradictory signals and may choose to ignore your preferences. The result: indexing duplication, position cannibalization, and declining mobile traffic.

Another classic trap is using relative URLs instead of absolute ones in the tags. Annotations should contain the full URL with protocol and domain. A relative URL will be ignored or misinterpreted by Google. Also, check that URL parameters are consistent between the two versions (trailing slash, tracking parameters, etc.).

How Can You Verify That Your Configuration Works Correctly?

Use the URL inspection tool in Search Console to test a few representative pages. Google indicates which version it considers canonical and whether it detects alternates. If the declared version does not match your setup, you have an implementation issue.

Also, test under real conditions: perform a mobile search for your main queries and check that the URL displayed in the SERPs is the m-dot version, not the desktop version. Repeat the process on desktop. If Google serves the wrong version, your annotations are not working.

• Crawl the entire site to extract all alternate and canonical tags
• Check that each desktop page has an alternate pointing to its mobile version
• Ensure that each mobile page has a canonical pointing to its desktop version
• Make sure URLs are absolute (protocol + full domain)
• Test representative URLs via the URL inspection tool in Search Console
• Analyze impressions by device in Search Console to detect anomalies