Réponse en bref
Les données structurées sont un code qui décrit une page aux moteurs de recherche avec le vocabulaire schema.org, le plus souvent en JSON-LD. Elles rendent une page éligible aux résultats enrichis, que Google ne garantit pas, et Yandex précise qu’elles n’influencent pas directement le classement. Elles doivent reprendre ce que la page affiche et passer par le test des résultats enrichis, le Schema Markup Validator et le validateur de Yandex.
Les données structurées en clair : une étiquette écrite pour les machines
Une page sur une sortie en bateau dit tout d’un coup d’œil : nom, durée, prix, organisateur. Un moteur voit du texte et doit deviner quel chiffre est quoi. Les données structurées suppriment cette devinette en nommant, dans du code, les éléments de la page et leurs propriétés avec un vocabulaire commun, schema.org. Google Search Central les définit comme un format standardisé pour fournir des informations sur une page et en classer le contenu. Schema.org a été fondé par Google, Microsoft, Yahoo et Yandex.
Le balisage change l’éligibilité, pas la position. Les consignes générales de Google sur les données structurées disent nettement qu’elles permettent à une fonctionnalité d’apparaître, sans le garantir. L’aide de Yandex Webmaster sur le balisage sémantique ajoute qu’il n’influence pas directement le classement, même s’il peut rendre un résultat plus visible, et que son robot indexe aussi les pages sans balisage.
JSON-LD, Microdata et RDFa : trois façons d’écrire les mêmes faits
Schema.org cite RDFa, Microdata et JSON-LD parmi ses encodages. Microdata et RDFa sont des attributs posés sur les balises HTML qui affichent déjà le texte, donc sur le prix lui-même. JSON-LD est un bloc à part, dans une balise script, qui reprend les faits sans toucher à la mise en page. L’introduction de Google aux données structurées juge les trois formats aussi valables si le balisage est correct, et recommande JSON-LD quand la configuration du site le permet, comme le plus simple à mettre en place et à maintenir à grande échelle.
Raison pratique : une refonte qui réécrit toutes les balises laisse un bloc JSON-LD intact, alors que des microdonnées dans un modèle sont à refaire. L’aide Schema.org de Yandex Webmaster explique le balisage avec les attributs itemscope, itemtype et itemprop, et la page de son validateur cite les microformats, Schema.org, Open Graph, les microdonnées HTML et RDFa. Un site tout en JSON-LD gagne à passer une page dans ce validateur pour voir ce que reconnaît Yandex.
Quels types schema.org conviennent à une boutique, un service ou un voyagiste
Les petites entreprises commencent en général par elles-mêmes. La documentation de Google sur les établissements locaux demande le sous-type de LocalBusiness le plus précis possible, avec le nom et l’adresse comme propriétés obligatoires. BreadcrumbList vient ensuite ; selon Google, un fil d’Ariane indique la position de la page dans la hiérarchie du site. Les articles utilisent Article ou son type plus étroit, BlogPosting.
Ce qui se vend à un prix prend Product avec une Offer, que schema.org définit comme une offre de transférer certains droits sur un article ou de fournir un service. Google distingue l’extrait de produit, si l’on ne peut pas acheter sur la page, de la fiche marchand, si l’on peut. Côté voyage, TravelAgency est une sorte de LocalBusiness, et TouristTrip, un itinéraire composé de visites d’un ou plusieurs lieux d’intérêt, figure encore parmi les nouveaux termes de schema.org.
Certains types vieillissent vite. Selon le journal des mises à jour de Google, depuis septembre 2023 les résultats enrichis FAQ n’étaient affichés que pour des sites gouvernementaux et de santé connus et faisant autorité, et la fonctionnalité n’apparaît plus dans la recherche Google à partir du 7 mai 2026. FAQPage reste un type schema.org, mais chez Google il ne fait plus que décrire la page. Speakable est une bêta que Google limite aux actualités en anglais lues par des enceintes connectées aux États-Unis.
Comment vérifier les données structurées : trois validateurs et la Search Console
Le test des résultats enrichis de Google vient en premier. Il accepte une URL ou du code, teste par défaut comme un smartphone et montre les types de résultats enrichis pris en charge par Google qu’il a trouvés. Après la mise en ligne, les rapports de la Search Console séparent les éléments valides, sans problème critique, des non valides, qu’au moins un problème critique empêche d’apparaître en résultat enrichi. L’outil d’inspection d’URL confirme que Google a trouvé le balisage sur la page en ligne.
Le Schema Markup Validator, sur validator.schema.org, contrôle le vocabulaire lui-même. Le blog de schema.org l’a annoncé en mai 2021 comme le nouveau foyer de l’ancien Structured Data Testing Tool, conçu pour JSON-LD, RDFa et Microdata et non pour un service particulier. Le validateur de Yandex Webmaster accepte une URL ou du HTML, compare le balisage aux exigences des services Yandex et distingue les erreurs, comme un champ obligatoire vide, des avertissements, comme une date hors ISO 8601. Aucun outil ne juge l’honnêteté : selon Google, ses consignes de qualité se testent mal automatiquement.
Le cas SB Excursions : des données structurées sur un site d’excursions en cinq langues
SB Excursions est un vrai projet client : un site de 2026 que le studio VITON13 a conçu et réalisé pour une entreprise d’excursions privées à Bali. Chaque page existe en anglais, chinois, russe, espagnol et français, et une partie du site aussi en allemand. La réservation reste une conversation avec l’organisateur sur WhatsApp : la page d’une excursion mène à un message, pas à un paiement. Pour Google, cela la range du côté de l’extrait de produit, pas de la fiche marchand.
Chaque page se décrit en JSON-LD avec six types : TravelAgency, TouristTrip, Product avec Offer, FAQPage, BreadcrumbList et BlogPosting avec Speakable. Elle déclare aussi une URL canonique et relie ses versions linguistiques par hreflang et un x-default. D’après la documentation de Google sur les versions localisées, hreflang signale les variantes d’un contenu, et x-default sert quand aucune langue ne correspond au navigateur.
Le catalogue aide à garder le balisage honnête. Chaque carte d’excursion répète les mêmes faits : durée, prise en charge, étapes de l’itinéraire et prix. Google exige que les données structurées représentent fidèlement le contenu de la page, et le guide de démarrage de schema.org conseille de ne baliser, en général, que ce que voient les visiteurs. Avec quatre faits fixes par carte, un bloc TouristTrip ou Offer n’a qu’une source, et un nouveau prix sur la carte doit aussi entrer dans le balisage.
Ce qu’a trouvé le contrôle de septembre sur quinze pages d’excursions
Le 22 septembre 2026, quinze pages du site en cinq langues, rendues dans Chrome, ont subi douze contrôles. JSON-LD, une URL canonique et un seul H1 figuraient sur 15 pages sur 15, qui ont passé entièrement 9 des 12 contrôles. Lighthouse a donné 92 en SEO à l’accueil, sur téléphone comme sur ordinateur. Le 25 septembre, le sitemap comptait 2 061 URL, et un sitemap d’images séparé recense 6 738 photos.
Les corrections à venir ne touchent pas le JSON-LD : images Open Graph sur 12 pages sur 15 seulement, titres hors de 30 à 65 caractères sur 5 sur 15, et un texte de lien répété, « Details », qui explique pourquoi le SEO de Lighthouse s’arrête à 92. Au regard du journal de Google, FAQPage et Speakable décrivent toujours les pages, sans leur promettre d’affichage particulier.
Ce que le cas des excursions ne prouve pas sur les données structurées
Le rapport Search Console du propriétaire pour les trois mois jusqu’au 17 septembre 2026 affiche 1,08 k clics et 92,2 k impressions dans la recherche web de Google. Jusqu’à début août, le site recevait environ 2,7 clics par jour. À partir du 7 août, clics et impressions ont augmenté en une semaine, et du 14 août au 17 septembre la moyenne était d’environ 26 clics par jour. Il est tentant d’en créditer le balisage. Le cas s’y refuse : il ne peut pas prouver quel changement a causé la hausse, et l’indexation des nouvelles versions linguistiques comme la saison touristique ont pu jouer.
Search Console compte d’ailleurs des visites issues de Google, pas des réservations ni du chiffre d’affaires. Les demandes continuent sur WhatsApp, et ni la conversion ni le budget du projet ne sont publiés, donc le cas n’affirme rien sur les ventes. Une position moyenne de 10,8 signifie que beaucoup de requêtes montrent encore le site en deuxième page, et Lighthouse donne à la page d’accueil 65 en performance mobile, avec un LCP de 7,8 secondes. Le balisage n’est qu’une couche parmi le contenu, la vitesse et les liens, et il ne répare ni une page lente ni une réponse pauvre.
Préparer un site aux données structurées : extension, modèle ou commande
Commencez par un inventaire, pas par le code. Listez les types de page (accueil, services, produits, articles, contacts) et notez pour chacun les faits qu’il affiche : prix, adresses, horaires, durée, auteur, date. Ces faits forment tout le contenu du balisage. Vérifiez qui a accès aux modèles ou au CMS, car le balisage vit dans les modèles, pas dans des pages isolées. Un site à quelques modèles standard se contente souvent d’une extension du CMS ou d’un champ intégré pour Organization, Article et BreadcrumbList.
Commander a du sens quand l’inventaire est long : beaucoup de modèles, plusieurs langues, des prix qui changent ou des types qu’aucune extension ne propose, comme TouristTrip. Il s’agit alors d’écrire le balisage dans chaque modèle, de tester chacun avec le test des résultats enrichis, le Schema Markup Validator et le validateur de Yandex, et de remettre en ordre canonical et hreflang ; c’est la mise en œuvre de SEO technique que propose le studio VITON13, la couche même qu’il a construite pour SB Excursions. Dans tous les cas, refaites les contrôles après chaque refonte.
Checklist pratique
- Listez tous les modèles de page et notez à côté de chacun les faits que la page affiche.
- Choisissez JSON-LD, sauf si le CMS produit déjà des Microdata ou du RDFa valides à conserver.
- Passez une page de chaque modèle dans le test des résultats enrichis et le Schema Markup Validator.
- Vérifiez les mêmes pages dans le validateur de Yandex Webmaster et corrigez les erreurs avant les avertissements.
- Retirez le balisage de tout ce que la page n’affiche pas et refaites chaque contrôle après une refonte.
Questions et réponses
Les données structurées améliorent-elles le classement dans Google ou Yandex ?
Pas directement. L’aide de Yandex sur le balisage sémantique indique qu’il n’influence pas directement le classement, et Google présente les données structurées comme ce qui rend possibles des fonctionnalités de recherche, sans les garantir. Le gain est une description plus claire de la page et l’éligibilité à des résultats enrichis là où le moteur les prend en charge.
JSON-LD vaut-il mieux que Microdata pour le balisage schema d’un site ?
Google accepte JSON-LD, Microdata et RDFa s’ils sont valides, et recommande JSON-LD quand la configuration du site le permet, comme le plus simple à mettre en place et à maintenir à grande échelle. Des Microdata qui fonctionnent déjà dans un modèle peuvent rester ; le validateur de Yandex montrera ce que ce moteur reconnaît.
Faut-il garder le balisage FAQPage maintenant que Google a retiré les résultats FAQ ?
Le journal des mises à jour de Google indique que le résultat enrichi FAQ n’apparaît plus dans la recherche Google à partir du 7 mai 2026. FAQPage reste un type du vocabulaire schema.org et le journal ne demande pas de le supprimer : un balisage valide qui correspond à une FAQ visible peut rester, sans en attendre un aspect particulier dans les résultats.
Quelle différence entre une erreur et un avertissement quand on teste des données structurées ?
Dans la Search Console, un élément non valide a au moins un problème critique qui l’empêche d’apparaître en résultat enrichi, tandis que les problèmes non critiques ne touchent que son aspect. Le validateur de Yandex sépare de façon proche : une erreur signifie que le balisage n’est pas reconnu ou qu’un champ obligatoire est vide, un avertissement qu’une valeur enfreint la norme.
Combien de temps les moteurs mettent-ils à prendre en compte un nouveau balisage schema ?
L’aide de Yandex indique que des données correctement balisées et utilisées par ses services apparaissent en général au bout d’environ deux semaines, une fois les pages indexées et, si nécessaire, les données modérées. Côté Google, l’outil d’inspection d’URL de la Search Console confirme si le balisage a été trouvé sur la page en ligne.