Faut-il vraiment dupliquer vos données structurées entre mobile et desktop ?

Pourquoi Google insiste-t-il sur cette duplication des données structurées ?

La raison tient à l'architecture de l'index mobile-first. Quand Google crawle votre site, il privilégie désormais la version mobile pour indexer et classer vos pages. Si vos données structurées ne sont présentes que sur la version desktop, le moteur risque de les ignorer complètement lors du crawl mobile.

Cette situation concerne spécifiquement les sites utilisant des URL distinctes pour mobile et desktop (configuration m.exemple.com ou mobile.exemple.com). Les sites responsive ne sont pas touchés puisqu'ils servent le même HTML quelle que soit l'origine de la requête. La confusion vient souvent du fait que beaucoup de professionnels pensent que les annotations rel=alternate et rel=canonical suffisent à faire comprendre à Google la relation entre les versions.

Quels types de données structurées sont concernés par cette obligation ?

Google vise ici l'ensemble des balisages schema.org générant des résultats enrichis : articles, produits, recettes, événements, FAQ, avis, offres d'emploi, breadcrumbs. Tout ce qui peut déclencher l'affichage d'un rich snippet ou d'une carte enrichie dans les SERP doit être présent sur les deux versions.

Le piège classique ? Implémenter un balisage Product complet côté desktop avec prix, disponibilité et avis, puis simplifier drastiquement la version mobile en supprimant ces données structurées sous prétexte d'alléger le code. Google crawle votre version mobile, ne trouve pas les données produit, et vos rich snippets disparaissent des résultats de recherche.

Cette exigence s'applique-t-elle vraiment à tous les sites avec versions séparées ?

La formulation de Google laisse peu de place au doute : si vous maintenez des versions distinctes mobile et desktop, les données structurées doivent être dupliquées. Cette règle s'applique même si votre trafic mobile représente 95% de vos visites et que personne ne consulte pratiquement plus la version desktop.

La logique derrière cette contrainte : Google ne peut pas deviner quelle version vous considérez comme référence. En l'absence de données structurées sur une version, le moteur considère que le contenu enrichi n'existe tout simplement pas sur cette variante, même si les annotations link rel indiquent une équivalence entre les URL.

• Les sites responsive échappent à cette obligation puisqu'ils servent le même code HTML aux deux types d'appareils
• Les configurations dynamic serving (même URL, HTML différent selon user-agent) sont également concernées et doivent dupliquer les schema.org
• La désynchronisation entre versions constitue le risque principal : une mise à jour du prix sur desktop non répercutée sur mobile crée des incohérences détectables par Google
• Les outils de test Google (Rich Results Test, Search Console) doivent être utilisés sur chaque version pour valider la présence et la cohérence des données structurées
• Le coût de maintenance double mécaniquement puisque chaque modification de contenu enrichi doit être appliquée à deux endroits distincts

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Sur le fond, oui. Les audits montrent régulièrement des sites avec versions séparées qui perdent leurs résultats enrichis après le passage à l'index mobile-first, précisément parce que les données structurées n'étaient implémentées que côté desktop. Google Search Console remonte d'ailleurs des erreurs explicites quand les schema.org sont absents de la version mobile.

Là où ça coince : Google ne précise pas comment il gère les incohérences entre versions. Si le prix d'un produit diffère entre mobile et desktop dans le balisage schema.org, quelle version prime ? Les tests terrain suggèrent que la version mobile l'emporte systématiquement depuis l'index mobile-first, mais Google n'a jamais confirmé ce comportement officiellement. [A vérifier]

Pourquoi Google n'unifie-t-il pas la lecture des données structurées entre versions liées ?

C'est la vraie question que cette déclaration esquive. Techniquement, Google pourrait parfaitement lire les annotations rel=alternate/canonical, identifier que deux URL représentent le même contenu, et consolider les données structurées trouvées sur l'une ou l'autre version. Le moteur fait déjà ce type de consolidation pour d'autres signaux.

L'explication probable tient à la granularité du crawl. Google ne crawle pas nécessairement les deux versions d'une page au même moment ni avec la même fréquence. Exiger la présence des données sur chaque version simplifie le pipeline d'indexation : le bot extrait les schema.org de la version qu'il crawle, point. Pas de dépendance, pas de consolidation complexe, pas de risque d'incohérence temporelle.

Quels sont les cas limites que Google ne mentionne pas ?

Premier angle mort : les sites utilisant du JavaScript côté client pour injecter les données structurées. Si ce JS ne s'exécute que sur desktop, la version mobile crawlée ne contiendra aucun schema.org, même si le code source est identique. Google crawle le rendu final, et si vos données structurées apparaissent uniquement après exécution JS desktop-only, elles sont invisibles pour le bot mobile.

Deuxième zone grise : les données structurées conditionnelles. Certains sites affichent des schema.org différents selon le contexte utilisateur (géolocalisation, authentification, personnalisation). Comment gérer ces cas quand mobile et desktop ont des logiques de personnalisation divergentes ? Google reste muet sur ce point. [A vérifier]

Que faut-il faire concrètement pour se mettre en conformité ?

Commencez par un audit différencié des deux versions. Utilisez le Rich Results Test de Google en mode mobile ET desktop sur vos pages stratégiques. Comparez les schema.org détectés : absences, différences de valeurs, erreurs de syntaxe. Search Console fournit également un rapport dédié aux résultats enrichis avec filtrage par type d'appareil.

Ensuite, implémentez une logique de génération unifiée. L'erreur classique consiste à coder en dur les données structurées dans les templates mobile et desktop séparément. Résultat : chaque modification exige deux interventions, et la désynchronisation guette. Privilégiez plutôt une source unique (base de données, CMS, API) qui génère dynamiquement les schema.org identiques pour les deux versions.

Quelles erreurs éviter lors de la duplication des données structurées ?

Ne tombez pas dans le piège de la simplification excessive côté mobile. Sous prétexte d'alléger le poids de page, certains développeurs suppriment des propriétés optionnelles des schema.org sur mobile. Google interprète cette différence comme un signal que le contenu mobile est moins riche, ce qui peut impacter négativement le ranking.

Évitez aussi les incohérences de données factuelles entre versions. Si votre balisage Product indique un prix de 49€ sur desktop et 45€ sur mobile, Google détecte une anomalie. Même logique pour les dates d'événements, les notes d'avis, les quantités en stock. Toute divergence chiffrée déclenche potentiellement un flag qualité qui peut supprimer vos rich snippets.

Comment vérifier que les données structurées sont correctement synchronisées ?

Mettez en place un monitoring automatisé. Des outils comme Schema Markup Validator, OnCrawl ou Screaming Frog permettent de crawler simultanément les versions mobile et desktop puis de comparer les schema.org extraits. Configurez des alertes en cas de divergence détectée sur des propriétés critiques (prix, disponibilité, ratings).

Testez également le rendu réel dans Google Search Console. La fonction Inspection d'URL vous montre exactement ce que Googlebot voit et extrait comme données structurées, version mobile comme desktop. Comparez les deux rendus : si des différences apparaissent alors que votre code source est censé être identique, c'est probablement un problème d'exécution JavaScript ou de détection user-agent.

• Auditer les deux versions avec Rich Results Test et identifier toute absence ou divergence de schema.org
• Centraliser la génération des données structurées via une source unique partagée entre mobile et desktop
• Valider la cohérence des valeurs factuelles (prix, dates, quantités) entre les deux versions
• Configurer un monitoring automatisé pour détecter les désynchronisations après chaque déploiement
• Tester le rendu Googlebot via Search Console pour confirmer que les données structurées sont bien crawlées et interprétées
• Documenter le processus de mise à jour pour garantir que toute modification schema.org est appliquée systématiquement aux deux versions