Faut-il implémenter des données structurées même si Google ne les utilise pas encore ?

Ryan Levering répond ici à une question récurrente : faut-il perdre du temps à implémenter des schemas qui ne génèrent aucun rich result visible aujourd'hui ? La réponse officielle est sans ambiguïté — ce n'est jamais contre-productif.

Cette déclaration s'inscrit dans une logique de développement produit chez Google. Le moteur détecte les volumes de données structurées disponibles sur le Web pour prioriser ses roadmaps de features.

Pourquoi Google encourage-t-il des données qu'il n'utilise pas encore ?

La mécanique est simple : Google développe de nouvelles fonctionnalités en fonction de la disponibilité et de la qualité des données structurées dans son index. Si 3% du Web a balisé un type de contenu vs 40% pour un autre, devinez lequel sera prioritaire pour un nouveau rich snippet.

En bref, vous votez avec votre code. Plus un schema est répandu, plus Google a de raisons de l'exploiter dans la SERP.

Quels types de données structurées sont concernés ?

Tous les schemas Schema.org supportés par Google mais sans feature dédiée actuellement. Par exemple : MedicalEntity, Course (hors carrousel), SoftwareApplication (hors app mobile), EducationalOccupationalCredential, et des dizaines d'autres.

Google maintient une liste officielle des types supportés — mais supporté ne signifie pas affiché. C'est toute la nuance.

• Aucun risque de pénalité à baliser du contenu même si Google ne l'affiche pas
• Les données non exploitées sont crawlées, indexées, et servent de signal statistique à Google
• C'est un pari sur l'avenir : vous êtes en pole position si Google lance une feature demain
• Le coût technique est marginal si vous utilisez déjà JSON-LD sur vos templates

Cette logique s'applique-t-elle à tous les sites ?

Oui, mais avec discernement. Un site e-commerce a intérêt à baliser Product même sans rich snippet — un blog perso avec 10 articles par an peut se concentrer sur Article et BreadcrumbList.

La priorité reste d'implémenter correctement les schemas qui génèrent des features actives (FAQ, HowTo, Product, Recipe, etc.). Les schemas « dormants » viennent en second rideau, pas en priorité absolue.

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. On constate depuis des années que Google teste des features sur des verticales où les données structurées sont déjà massives. Les carrousels Recipe sont apparus parce que des millions de sites avaient déjà balisé leurs recettes.

À l'inverse, des schemas nichés comme SpecialAnnouncement (lancé pour le COVID) peinent à s'imposer faute de volume critique. Google ne développe pas de features dans le vide.

Quelles nuances faut-il apporter ?

Levering dit « jamais négatif », mais attention aux erreurs de balisage. Un JSON-LD mal formé, des propriétés requises manquantes, ou du markup trompeur peuvent déclencher des actions manuelles ou dégrader la confiance algorithmique.

Le principe est : baliser large, oui — mais baliser juste. Un schema incomplet ou fantaisiste vaut pire que pas de schema du tout.

Dans quels cas cette logique ne s'applique-t-elle pas ?

Si votre budget technique est limité, concentrez-vous sur les schemas à ROI immédiat. Baliser Product avec reviews et pricing pour un e-commerce prime sur EducationalOccupationalCredential.

Autre cas : les schemas propriétaires non supportés par Google. Inventer vos propres types hors Schema.org ne sert strictement à rien pour la Search, même si c'est valide sémantiquement.

Que faut-il faire concrètement ?

Auditez vos contenus et identifiez les schemas Schema.org qui décrivent fidèlement votre offre, même sans feature Google active. E-learning ? Balisez Course. SaaS ? SoftwareApplication. Media ? VideoObject complet.

Implémentez en JSON-LD propre, testez avec le Rich Results Test et la Search Console. Pas d'erreurs critiques tolérées.

Quelles erreurs éviter ?

Ne sur-balisez pas. Un article de blog n'est pas un Product, une FAQ factice pour bourrer des mots-clés sera détectée. Google valorise la pertinence sémantique, pas le volume de markup.

Évitez aussi de dupliquer les mêmes données dans plusieurs schemas contradictoires sur une même page. Un produit ne peut pas être simultanément un Article et un Event — choisissez le type principal.

• Lister tous les types de contenus de votre site (produits, articles, vidéos, cours, etc.)
• Identifier les schemas Schema.org correspondants, feature Google ou pas
• Implémenter en JSON-LD avec toutes les propriétés requises + recommandées
• Valider via Rich Results Test et corriger toute erreur
• Monitorer la Search Console pour détecter les warnings
• Documenter vos choix de balisage pour maintenir la cohérence dans le temps

Comment prioriser si les ressources sont limitées ?

Commencez par les schemas à ROI immédiat : ceux qui génèrent des rich results aujourd'hui (FAQ, Product, Recipe, HowTo, etc.). Puis étendez progressivement aux schemas dormants sur vos contenus stratégiques.

Un crawler Screaming Frog ou OnCrawl peut automatiser la détection des contenus non balisés. Reste à prioriser selon le trafic et les objectifs business.