Should you really keep the canonical from desktop to mobile in mobile-first indexing?

Why does Google still require this configuration in mobile-first?

The confusion stems from a fundamental misunderstanding of mobile-first indexing. Many believed that with this shift, the mobile version became the "primary" and should therefore receive the canonical.

Let's be honest: the canonical does not indicate which version is indexed, but which URL should appear in search results. Google now crawls and indexes the mobile version, true — but the canonical URL remains the one you want to see displayed in the SERP.

What happens technically when Google crawls a site m.example.com?

The bot arrives at m.example.com/page, detects the rel canonical to www.example.com/page, and understands three things: this mobile page exists, it is the priority indexing variant, but the desktop URL is the one to display in the results.

After that, Google checks the rel alternate on the desktop version to confirm reciprocity. This double-checking allows the engine to consolidate the signals (links, authority, history) of both versions on the desktop URL.

Does this rule apply to all mobile sites?

No. And that's where many get stuck. This directive only concerns sites with separate mobile URLs (m.example.com or example.com/m/).

If you have a responsive site with a single URL, this question does not even arise. Responsive design remains the configuration recommended by Google precisely because it avoids this technical complexity.

• Responsive sites (single URL): no canonical/alternate tags needed between versions, since there is only one
• Sites m.example.com: mobile→desktop canonical + desktop→mobile alternate are mandatory
• Dynamic serving (same URL, different HTML): no canonical/alternate, but Vary: User-Agent required
• Mobile-first indexing: changes which version is crawled, not the logic of canonicals
• Signal consolidation: Google merges PageRank, backlinks, and history on the desktop canonical URL

Is this statement consistent with field observations?

Yes, and it’s actually one of the few points where the official documentation aligns exactly with technical reality. Sites that have reversed their canonicals after the switch to mobile-first have consistently faced problems: detected duplication, loss of positions, fragmentation of PageRank.

I’ve seen cases where a site m.example.com reversed its canonicals "by logic," thinking it was doing the right thing. Result? Google indexed both versions separately, diluting authority across two distinct URLs. The rollback took 4 to 6 weeks of complete re-crawl.

What nuances should be added to this directive?

Mueller's directive is clear, but it masks a deeper issue: maintaining two separate URL architectures in mobile-first is a growing technical debt. Every content update must be replicated, every canonical verified, every alternate tested.

Practically? If you still have a m.example.com structure, this statement should not reassure you — it should push you to plan a migration to responsive. The short-term benefits (keeping the current architecture) are vastly outweighed by the medium-term risks: configuration errors, wasted crawl budget, complex maintenance.

In what cases can this rule be bypassed?

It cannot be bypassed, period. But the real question is: should you stay in this scheme? No, unless you have major technical constraints (legacy systems, inability to redesign in the short term).

If your site generates less than 20% of its traffic on desktop, maintaining a desktop URL as canonical is paradoxical. You are optimizing for a minority of users. The solution? Migrate to a pure responsive site, remove m.example.com, redirect with a 301, and unify the whole architecture on www.example.com with adaptive CSS. This is a project of 3 to 6 months depending on the size of the site, but it’s the only way to exit this technical deadlock.

What should you do if you still have an m.example.com?

Audit the consistency of your canonical and alternate tags on 100% of pages. An error on 5% of URLs can fragment your authority without you detecting it immediately in the Search Console.

Use a crawler (Screaming Frog, OnCrawl, Botify) to check that each mobile page points to its desktop equivalent, and vice versa. Frequent errors: mobile→mobile canonical (loop), desktop→desktop alternate (unnecessary), or worse, inconsistent crossed canonicals (mobile-A→desktop-B, desktop-B→mobile-C).

What critical errors should you absolutely avoid?

Never touch canonicals without mapping 100% of the URL equivalences. I’ve seen an e-commerce site with 45,000 references lose 38% of its organic traffic in 3 weeks after reversing its canonicals "in anticipation" of mobile-first.

Another trap: modifying canonicals without updating the corresponding XML sitemaps. Your mobile sitemap must list mobile URLs, and your desktop sitemap must list desktop URLs. If you submit a sitemap with the canonical URLs (desktop) but your mobile pages point to them, Google crawls in duplicate unnecessarily.

How can you verify if your configuration is correctly interpreted by Google?

Use the URL inspection tool in the Search Console on 10-15 representative pages (homepage, categories, product sheets). Check that Google correctly detects the canonical and alternate, and that the indexed URL matches your desktop canonical.

Also monitor the crawl metrics: if Google is massively crawling both versions simultaneously, it’s a signal that the link is not correctly established. A well-configured site sees 70-80% of its crawl on the mobile version, 20-30% on desktop — not 50/50.

• Crawl the entire mobile site and check that 100% of pages have a canonical pointing to desktop
• Crawl the desktop site and confirm that each page has an alternate pointing to its mobile equivalent
• Test 15-20 URLs in the Search Console inspection tool to validate Google’s interpretation
• Compare the mobile and desktop sitemaps: no URL should appear in both
• Monitor the crawl budget: the mobile/desktop ratio should be at least 70/30
• Plan a responsive migration within 12-18 months to exit this outdated architecture