Should you really cross rel='canonical' and rel='alternate' between desktop and mobile versions?

Why does Google require this dual setup?

The principle is based on cross-confirmation logic. The canonical tag on mobile indicates to Google that the reference version is on desktop, while the alternate tag on desktop signals the existence of an alternative mobile version.

This bidirectionality allows Google to validate the relationship between the two URLs and avoid ambiguities. Without this dual signal, the engine might interpret both versions as duplicate content, dilute authority between them, or index the wrong version depending on user context.

In what context does this setup apply?

This recommendation applies exclusively to M-dot sites, which means those that maintain two distinct URLs: one for desktop (example.com) and one for mobile (m.example.com).

Responsive design, where a single URL serves the same adaptive content, does not require any of these tags. Dynamic serving (same URL but different HTML based on user-agent) only requires the header Vary: User-Agent, without canonical/alternate.

How does Google use these signals for indexing?

The engine uses these tags to determine which version to prioritize for indexing depending on the search context. With mobile-first indexing, Google crawls the mobile version first, but the canonical indicates that the reference content remains on desktop.

This creates a balance: Google indexes the mobile content for mobile users, but preserves the authority and ranking signals from the desktop version. Without these tags, the engine could crawl both versions independently, fragment backlinks, and dilute PageRank between the URLs.

• M-dot setup only: two distinct URLs require canonical + alternate
• Responsive design: no tags needed, one URL for all devices
• Dynamic serving: header Vary: User-Agent is sufficient, no canonical/alternate
• Mobile-first indexing: the canonical mobile→desktop guides Google on the reference version
• Preventing duplicate content: cross signals avoid cannibalization between versions

Is this recommendation still relevant in practice?

Let’s be honest: M-dot configuration is an architecture that is becoming extinct. Most modern sites have migrated to responsive design, making this dual tag unnecessary. The few sites that still maintain two distinct URLs are often legacy platforms or e-commerce giants with historical technical constraints.

That said, for sites still in M-dot, this configuration remains critical. Field observations show that the absence of these tags creates real indexing problems: fluctuations between versions in the SERPs, loss of ranking on mobile, or blatant duplicate content flags in Search Console. [To confirm]: Google has never published quantitative data on the direct SEO impact of these missing tags.

What inconsistencies do we see between theory and practice?

The first problematic point: Google recommends pointing the mobile canonical to desktop, but with mobile-first indexing, the mobile version serves as the basis for ranking. This contradiction creates a confusion about which version is truly prioritized in the eyes of the engine.

The second inconsistency observed: some sites with perfectly configured canonical/alternate tags still encounter indexing issues. Google sometimes crawls both versions independently, ignores the canonical, or displays the wrong version in mobile SERPs. The bidirectional configuration is not an absolute guarantee, it remains a signal among others.

In what cases does this rule become counterproductive?

If your mobile version offers substantially different content from the desktop version (not just a responsive adaptation, but reduced, simplified, or restructured content), the mobile→desktop canonical poses a problem. Google will index the poor mobile content while pointing to a desktop URL, creating a gap between what the engine sees and what the URL represents.

Another problematic case: sites that maintain an AMP version in addition to M-dot and desktop. Adding AMP to the equation complicates the chain of tags (desktop ↔ mobile ↔ AMP) and multiplies the risks of configuration errors. The more complex the stack, the higher the probability of contradictory signals.

What should you concretely do for an existing M-dot site?

The first step: audit the bidirectional consistency of your tags. Each desktop page should have an alternate pointing to its mobile equivalent, and each mobile page should have a canonical pointing to its desktop equivalent. Just one error in this chain is enough to create ambiguities.

Use Screaming Frog or an equivalent crawler to extract all canonical and alternate tags, then cross-reference the data in Excel. Look for asymmetries: desktop pages without corresponding alternates, mobile pages without canonicals, or worse, canonicals and alternates pointing to different URLs creating relationship triangles.

How to detect and correct frequent errors?

Classic error: URL parameters (tracking, sorting, filters) create variations that break the bidirectional relationship. Example: example.com/product pointing to m.example.com/product, but m.example.com/product?sort=price canonicalizing to example.com/product?sort=price which has no alternate. The mapping becomes inconsistent.

Another pitfall: redirects between versions. If example.com/page redirects to example.com/page/ (trailing slash), but m.example.com/page points its canonical to example.com/page (without slash), Google sees a canonical pointing to a URL that redirects, weakening the signal. Ensure that canonical and alternate always point to the final URLs after redirects.

Should you maintain this architecture or migrate to responsive?

If you are launching a new project, forget the M-dot. Responsive design eliminates all this technical complexity, reduces maintenance costs, and aligns perfectly with mobile-first indexing. No valid reason exists to create an M-dot architecture today.

For existing sites in M-dot, migrating to responsive is often complex: a complete front-end redesign, managing 301 redirects to preserve authority, updating internal linking, modifying sitemaps. This transition requires rigorous planning, as a poorly managed migration can destroy years of SEO gains.

This type of technical migration requires a sharp expertise in web architecture and SEO. The stakes are high: preserving organic traffic, transferring authority between URLs, managing indexing during the transition. If your internal team has not previously managed this type of project, hiring an SEO agency specialized in technical migrations can secure the operation and avoid costly mistakes.

• Crawl both versions (desktop and mobile) to extract all canonical and alternate tags
• Check bidirectional consistency: each alternate must have its corresponding canonical and vice versa
• Ensure canonical and alternate point to the final URLs after redirects
• Test the configuration in Search Console: check that Google indexes the correct version based on context
• Audit URL parameters: ensure that variations (filters, sorting, tracking) do not introduce inconsistencies
• Plan a migration to responsive if the M-dot architecture becomes a technical or financial bottleneck