Official statement
Other statements from this video 21 ▾
- 2:08 Le contenu dupliqué dans les fiches d'entreprise pénalise-t-il vraiment votre SEO ?
- 2:08 Le Duplicate Content dans les annuaires d'entreprises est-il vraiment sans danger pour votre SEO ?
- 3:32 Combien de temps faut-il vraiment pour que Google stabilise son crawl après une migration HTTPS ?
- 3:40 Pourquoi Google affiche-t-il des erreurs robots.txt après une migration HTTPS ?
- 5:08 Pourquoi Google affiche-t-il parfois la version mobile sur desktop et comment l'éviter ?
- 6:18 Comment Google détecte-t-il vraiment les dates de vos articles ?
- 6:38 Google peut-il afficher la mauvaise date de vos articles dans les résultats de recherche ?
- 9:24 Faut-il vraiment privilégier les redirections 301 aux canonical lors d'un changement de domaine ?
- 11:00 Peut-on vraiment nettoyer l'historique d'un domaine pénalisé par Google ?
- 11:11 Pourquoi les liens désavoués mettent-ils plusieurs mois avant d'être pris en compte par Google ?
- 14:24 Faut-il vraiment abandonner les canonicals au profit des 301 lors d'une migration de domaine ?
- 17:09 Canonical ou 301 : quelle balise privilégier pour consolider vos URLs ?
- 19:16 Faut-il vraiment s'inquiéter quand Google affiche les URL 410 comme erreurs de crawl ?
- 22:56 Pourquoi bloquer CSS et JavaScript empêche-t-il Google de détecter votre site mobile-friendly ?
- 31:06 Les pages en noindex transmettent-elles vraiment du PageRank ?
- 34:06 Les redirections 301 suffisent-elles vraiment à maintenir la performance des URLs alternatives qui évoluent ?
- 37:14 Faut-il vraiment privilégier les redirections 301 aux canonicals pour restructurer ses URL ?
- 42:05 Pourquoi l'association URL desktop/mobile peut-elle saboter votre visibilité mobile ?
- 48:56 Faut-il vraiment s'inquiéter d'une erreur 410 en Search Console ?
- 52:06 Le noindex transmet-il vraiment du PageRank via les liens dofollow ?
- 54:34 Pourquoi Google met-il jusqu'à 24h pour détecter la levée d'un blocage robots.txt ?
Google recommends using rel='alternate' on desktop pages to point to mobile pages and rel='canonical' on mobile pages to point back to desktop pages. This setup allows the engine to display the appropriate version based on the user's device. However, this guidance dates back to the pre-mobile-first indexing era, raising questions about its current relevance.
What you need to understand
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
SEO Expert opinion
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.
Practical impact and recommendations
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
❓ Frequently Asked Questions
Dois-je encore utiliser rel=alternate et canonical si mon site est responsive ?
Que se passe-t-il si j'oublie le rel=alternate sur la version desktop ?
Le canonical depuis la version mobile vers le desktop est-il toujours pertinent avec le mobile-first indexing ?
Puis-je utiliser des URLs relatives dans les balises alternate et canonical ?
Comment savoir si mes annotations alternate/canonical fonctionnent correctement ?
🎥 From the same video 21
Other SEO insights extracted from this same Google Search Central video · duration 56 min · published on 24/09/2015
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.