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

Pourquoi cette question de duplication se pose-t-elle en premier lieu ?

Beaucoup de sites utilisent encore des architectures où le même contenu est présent deux fois dans le DOM — une version desktop et une version mobile masquée via CSS (display:none). Cette approche, héritée d'anciennes pratiques de responsive design, génère naturellement la question : faut-il dupliquer aussi les données structurées ?

La tentation est forte d'intégrer les balises schema.org dans chaque version du template, par souci de cohérence apparente. Sauf que cette logique ne tient pas face à la réalité du crawl Google : le bot ne fait pas de distinction entre "version mobile" et "version desktop" au niveau des données structurées. Il lit le DOM complet, peu importe les règles CSS.

Qu'est-ce que Google lit réellement dans ce cas de figure ?

Quand Googlebot analyse une page contenant deux fois le même bloc de contenu (un visible, un masqué), il voit les deux dans le HTML brut. Si vous avez dupliqué vos JSON-LD ou microdata, le moteur détecte donc deux ensembles identiques de données structurées pour le même élément.

Le risque principal n'est pas une pénalité directe, mais une désynchronisation progressive — l'équipe édito met à jour une version, oublie l'autre, et vous vous retrouvez avec des marqueurs contradictoires. Google doit alors arbitrer, ce qui peut mener à des rich snippets erratiques ou absents.

Dans quels contextes cette problématique est-elle critique ?

Cette situation touche principalement les sites e-commerce et médias ayant conservé une architecture de templating ancienne. Les CMS qui génèrent séparément le rendu mobile et desktop (approche devenue rare mais pas disparue) sont particulièrement concernés.

Les sites en responsive pur, où le HTML est unique et seul le CSS change selon la taille d'écran, n'ont évidemment pas ce problème. De même, les architectures modernes en composants React/Vue avec SSR unifié évitent cette duplication à la source.

• Une seule inclusion suffit : même si le contenu apparaît deux fois dans le DOM, les données structurées ne doivent figurer qu'une fois.
• Le risque principal est la désynchronisation : maintenir deux versions augmente les erreurs éditoriales et techniques.
• Google lit le DOM complet : les règles CSS (display:none) n'empêchent pas le crawl des données structurées.
• Privilégiez l'intégration côté serveur : générez les JSON-LD une seule fois en backend plutôt que de les dupliquer dans le templating front.

Cette recommandation est-elle alignée avec les pratiques observées sur le terrain ?

Oui, et c'est même l'une des rares déclarations Google parfaitement cohérente avec ce qu'on observe en audit. Les sites qui dupliquent leurs schema.org entre versions mobile et desktop rencontrent effectivement des problèmes de rich snippets instables — tantôt affichés, tantôt absents, sans logique apparente.

La Search Console remonte d'ailleurs souvent des warnings "Duplicate markup" dans ces configurations. Google ne pénalise pas directement, mais l'algorithme peine à arbitrer entre deux sources identiques, ce qui dégrade la fiabilité des extraits enrichis. Les tests A/B menés sur des migrations montrent un gain de stabilité après nettoyage.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller parle ici d'un cas précis : contenu strictement identique dupliqué pour des raisons de compatibilité mobile. Si votre version mobile affiche réellement un contenu différent (condensé, réorganisé, avec d'autres prix ou disponibilités), alors oui, les données structurées doivent refléter cette différence.

Autre point : cette règle concerne les données structurées sur page (JSON-LD, microdata), pas les fichiers externes type sitemap produits ou flux merchant. Ces derniers suivent leur propre logique et peuvent légitimement contenir des variations selon le contexte. [A verifier] : Google n'a jamais clarifié si cette recommandation s'applique aussi aux balises Open Graph dupliquées, bien que la logique soit probablement similaire.

Dans quels cas cette règle ne s'applique-t-elle justement pas ?

Si vous utilisez des URLs distinctes pour mobile et desktop (architecture m.example.com vs www.example.com), chaque URL doit évidemment porter ses propres données structurées. La déclaration de Mueller vise uniquement les sites responsive avec un seul HTML contenant deux rendus CSS.

De même, pour les applications JavaScript complexes qui montent/démontent dynamiquement des composants selon la taille d'écran, la question ne se pose pas dans les mêmes termes — le rendu final côté serveur (ce que voit Googlebot) ne devrait contenir qu'une seule version des marqueurs, générée à la volée.

Que faut-il faire concrètement si mon site duplique actuellement les données structurées ?

Première étape : auditer l'ensemble de vos templates pour identifier où se situent les duplications. Cherchez les balises <script type="application/ld+json"> présentes deux fois dans le même DOM, ou les attributs microdata (itemscope, itemprop) répétés sur des blocs masqués en CSS.

Ensuite, décidez quelle version conserver — généralement, la version desktop contient les données les plus complètes, mais vérifiez cas par cas. Sur certains sites e-commerce, c'est la version mobile qui a été maintenue à jour tandis que le desktop traîne des marqueurs obsolètes. Une fois la source de vérité identifiée, supprimez l'autre et testez.

Comment vérifier que la modification n'a pas cassé l'indexation des rich snippets ?

Utilisez l'outil de test des résultats enrichis de Google avant et après modification. Comparez le nombre d'éléments détectés et les warnings remontés — vous devriez voir disparaître les alertes "Duplicate" si elles existaient.

Surveillez ensuite la Search Console pendant 2-3 semaines, particulièrement les rapports "Extraits enrichis" et "Amélioration". Une baisse soudaine d'affichage des rich snippets indiquerait que vous avez supprimé la mauvaise version ou introduit une erreur de syntaxe. En parallèle, trackez les CTR organiques sur les pages modifiées — un rich snippet bien détecté devrait maintenir ou améliorer les performances.

Quelles erreurs éviter lors de cette refactorisation ?

Ne vous contentez pas de supprimer mécaniquement tous les blocs marqués "mobile" — certains sites ont historiquement mieux maintenu cette version. Faites un diff précis des deux jeux de données avant de trancher.

Évitez aussi de laisser des balises schema.org orphelines après suppression du contenu masqué — si vous retirez un bloc product en display:none mais oubliez son JSON-LD associé, vous créez une incohérence inverse. Enfin, attention aux générateurs automatiques de données structurées côté front (plugins WordPress, modules PrestaShop) qui peuvent réinjecter la duplication au prochain déploiement si vous ne modifiez pas la configuration à la source.

• Auditer tous les templates pour identifier les duplications de JSON-LD ou microdata
• Comparer les deux versions et déterminer laquelle est la plus complète et à jour
• Tester avec l'outil Google avant/après pour vérifier l'absence de régression
• Surveiller la Search Console (rapports Extraits enrichis) pendant 2-3 semaines post-migration
• Documenter la source de vérité unique pour éviter les régressions futures lors des mises à jour du CMS
• Vérifier que les générateurs automatiques (plugins, modules) ne réinjectent pas la duplication