Données structurées : la liste complète des Schema Article, FAQ, Product et Breadcrumb
1. Règles générales d’écriture du JSON-LD
Google recommande la syntaxe JSON-LD, pas Microdata ni RDFa. Trois règles d’or s’appliquent.
| Règle | Bonne pratique | Erreur à éviter |
|---|---|---|
| Syntaxe | <script type=”application/ld+json”> | Utiliser Microdata ou RDFa |
| Position | head ou fin du body | Injection dynamique en JS puis attente du rendu |
| Valeur du champ | Identique mot pour mot au texte visible de la page | Le Schema indique « 999 dollars », la page indique « sur devis » |
| Types multiples | Utiliser un tableau @type ou un maillage via mainEntityOfPage | Empiler six ou sept types sans rapport sur la même page |
Pourquoi privilégier le JSON-LD : il est découplé de la structure HTML, donc la maintenance du template ne casse pas le balisage quand on modifie le DOM. Microdata est intégré dans les attributs des balises : changer une classe peut tout casser.
Deux autres points souvent négligés : d’abord, tous les champs de date doivent être au format ISO 8601, avec décalage horaire, par exemple 2026-09-21T09:00:00+08:00, et non « septembre 2026 » ; ensuite, les champs URL doivent être directement explorables par Google, sans lien vers un back-office nécessitant une connexion. Ces deux problèmes ne génèrent que des avertissements dans le Rich Results Test, pas d’erreur, et passent donc facilement inaperçus.
2. Article : pages de blog et de livre blanc
Article est le balisage de base d’une page d’article : il détermine l’apparition de la photo de l’auteur, de la date de publication et du carrousel de vignettes dans les SERP.
| Champ | Obligatoire | Exemple de valeur | Explication |
|---|---|---|---|
| @type | Oui | Article | NewsArticle pour les actualités |
| headline | Oui | 110 caractères maximum | Identique à <title> |
| author | Oui | {“@type”:”Person”,”name”:”Cui Lishu”} | Pointer aussi vers la page de l’auteur |
| datePublished | Oui | 2026-09-21T09:00:00+08:00 | Format ISO 8601 |
| dateModified | Recommandé | Identique à datePublished ou date de mise à jour | À mettre à jour lors d’un rafraîchissement de l’article |
| image | Oui | Au moins 1200×675 pixels | Influe sur la vignette du carrousel |
| publisher | Recommandé | Lien vers Organization | Inclut le champ logo |
Exemple concret : un blog B2B avait ajouté Article mais utilisait une petite image de 600×300 pour image, et le Rich Results Test signalait « image too small ». Après remplacement par une couverture en 1200×675, l’article est apparu dans le carrousel d’articles des SERP en une semaine. Les exigences de taille d’image sont détaillées dans Gouvernance des actifs médias.
author 字段不要只写公司名，要写具体作者名并指向作者页。Google 在知识面板和作者头像轮播里会读这个字段；只写”环形山”三个字，既不构成 Person，也不构成 Organization，标记会被忽略。作者页本身要在站内可访问，并在 SameAs 里挂上领英、GitHub 等外部档案。
3. FAQPage : le canal principal des réponses IA
Bien que FAQPage n’affiche plus de rich media dans les SERP des blogs d’entreprise classiques depuis 2023, il reste le canal principal par lequel ChatGPT, Gemini et Google AI Overviews lisent les questions-réponses.
| Champ | Obligatoire | Explication |
|---|---|---|
| @type | Oui | FAQPage |
| mainEntity[] | Oui | Tableau Question, 5 à 6 éléments |
| name | Oui | Question originale, identique au summary de la page |
| acceptedAnswer.text | Oui | Réponse en texte brut, identique à la réponse visible sur la page |
Point contre-intuitif : depuis août 2023, le bloc dépliable FAQPage dans les SERP ne s’affiche que sur les forums d’autorité et les sites gouvernementaux ; sur un blog B2B classique, il n’apparaît pas même si vous l’ajoutez. Il faut quand même le rédiger : le canal principal par lequel les moteurs IA lisent la FAQ est le tableau mainEntity. Pour la méthodologie de contenu FAQ, voir FAQ et questions fréquentes.
Ligne rouge : les questions-réponses dans mainEntity doivent être parfaitement identiques à la FAQ visible sur la page ; n’ajoutez pas de questions-réponses absentes de la page. C’est précisément ce que vise l’action manuelle de Google pour balisage FAQ spam.
Attention aussi à la longueur des questions et des réponses : gardez les questions entre 20 et 40 caractères, et les réponses entre 80 et 150 caractères. Une question trop courte ressemble à du bourrage de mots-clés, une question trop longue dépasse la zone d’affichage du bloc dépliable dans les SERP ; une réponse trop courte manque de densité informationnelle et ne sera pas citée par l’IA, une réponse trop longue sera tronquée.
4. Product : la zone à fort rendement des pages produit B2B
Le balisage Product détermine si la fiche produit, le prix et l’état du stock apparaissent dans les SERP. Pour les produits semi-personnalisés B2B, restez mesuré.
| Champ | Obligatoire | Points d’attention B2B |
|---|---|---|
| name | Oui | Nom complet du modèle, identique au H1 |
| image | Oui | Image principale, au moins 3 visuels produit pour plus de stabilité |
| description | Recommandé | Identique à la meta description de la page produit |
| brand | Recommandé | {“@type”:”Brand”,”name”:”…”} |
| offers.price | Lorsqu’un prix clair existe | Ne renseignez pas price pour un produit sur devis |
| offers.availability | Recommandé | InStock / PreOrder, ne marquez rien au hasard |
| aggregateRating | Lorsqu’il existe de vrais avis | Des étoiles sans avis réels déclenchent une action manuelle |
Exemple de scénario 2 : une usine d’équipements B2B renseigne offers.price=5000 sur une page produit, alors que la page indique seulement « sur devis ». Le Rich Results Test signale un avertissement d’incohérence de champ, et deux semaines plus tard, le rapport rich media de la GSC affiche zéro impression rich media pour cette page produit. Après suppression du champ price et passage d’availability à PreOrder, les impressions reviennent.
Une erreur de champ prix est la source d’accident la plus fréquente du balisage Product. Quand une page produit semi-personnalisé B2B n’affiche pas de tarif public, ne forcez pas un prix pour obtenir une fiche dans les SERP.
5. BreadcrumbList : indispensable sur tout le site
BreadcrumbList permet à Google d’afficher un fil d’Ariane à la place d’une longue URL dans les SERP ; c’est le Schema le moins coûteux pour tout le site.
| Champ | Obligatoire | Explication |
|---|---|---|
| @type | Oui | BreadcrumbList |
| itemListElement[] | Oui | Chemin complet de la page d’accueil à la page actuelle |
| position | Oui | Incrément à partir de 1 |
| name | Oui | Texte affiché dans le fil d’Ariane |
| item | Recommandé | URL absolue de ce niveau |
Le champ item doit contenir une URL absolue, jamais un chemin relatif. La hiérarchie doit correspondre au fil d’Ariane visible sur la page : accueil → rubrique → sous-rubrique → page courante, sans sauter de niveau. La page courante doit aussi figurer dans itemListElement, sinon Google ne peut pas déterminer vers quelle page pointe le fil d’Ariane.
Six. Vérifier en trois étapes avant la mise en ligne
| Étape | Outil | Délai | Critère de validation |
|---|---|---|---|
| Vérifier URL par URL | Test des résultats enrichis | Le jour précédant le déploiement | Aucune erreur, uniquement des avertissements acceptables |
| Contrôle après mise en ligne | Relancer les URL en production | Le jour de la mise en ligne | Le rendu correspond au local |
| Rapport sur les résultats enrichis | Search Console | Jours 7, 14 et 30 | Impressions non nulles, 0 erreur |
Ces quatre types de Schema constituent la base d’un site B2B. Organization et WebSite sont les deux autres à placer obligatoirement dans le head de tout le site ; pour l’ordre de priorité complet, voir Données structurées Schema. Sur un site multilingue, vérifiez aussi que les champs Schema correspondent à Localisation des chiffres et des tableaux multilingues et que les devises et les unités ne se mélangent pas d’une langue à l’autre.
La dernière source d’incident fréquente : les Schema en double générés automatiquement par les extensions. Sur un site WordPress équipé de Yoast ou Rank Math, l’extension produit par défaut des balises Article et Organization. Si vous ajoutez en plus votre propre JSON-LD, des avertissements duplicate field apparaissent. Avant la mise en ligne, passez les pages produit et les pages d’article au Rich Results Test : dès que vous voyez des champs en double, désactivez le module correspondant de l’extension et conservez votre version écrite à la main.
Sept. Contrôle mensuel après la mise en ligne du Schema
Un Schema ne se configure pas une fois pour toutes. Modification de template, ajout ou retrait de produits, changement de prix : autant d’éléments qui décalent à nouveau les champs par rapport au contenu visible de la page. Consacrer une demi-journée par mois à un contrôle coûte moins d’efforts que de réparer après un incident.
| Point de contrôle | Méthode de vérification | Fréquence | Critère de validation |
|---|---|---|---|
| Erreurs dans le rapport sur les résultats enrichis de GSC | Rapport d’expérience dans Search Console | Mensuel | 0 erreur, les avertissements sont acceptables |
| Champs cohérents avec le texte visible | Rich Results Test sur un échantillon de 10 pages | Mensuel | Aucun avertissement de champ mal apparié |
| Synchronisation du prix Product | Comparer le champ price de la page produit avec le prix affiché | Après un changement de prix | Ne pas laisser de champ price sur les produits sur devis |
| Chemin du Breadcrumb | Comparer le fil d’Ariane sur un échantillon de pages de second niveau | Après une refonte | Pas de niveau sauté, item en URL absolue |
| Schema en double | Compter les blocs ld+json dans le code source de la page | Après l’installation d’une nouvelle extension | Aucun doublon entre l’extension et la version écrite à la main |
Quand le contrôle révèle un problème, ne modifiez pas tout le site dans la précipitation : reproduisez d’abord en environnement de test pour déterminer s’il s’agit d’un problème de template ou d’une page isolée. Un problème de template touche toutes les pages : une seule correction suffit. Un problème isolé vient le plus souvent d’une erreur de saisie sur un prix ou une date : corrigez page par page. Consignez les résultats du contrôle mensuel dans un tableau d’une page ; au bout de trois mois, vous verrez quel type d’erreur revient sans cesse et vous l’inscrirez dans le manuel de rédaction pour réduire les incidents à la source.
Dernier rappel : un Schema s’adresse aux moteurs de recherche et aux moteurs IA, pas aux visiteurs. Les valeurs des champs doivent refléter honnêtement le contenu réel de la page ; n’indiquez pas de faux prix ni d’étoiles d’avis gonflées pour décrocher des résultats enrichis. Si Google déclenche une action manuelle pour données structurées trompeuses, le délai de rétablissement se compte en trimestres : le jeu n’en vaut pas la chandelle.
Sur un site multilingue, veillez aussi à la cohérence linguistique des champs Schema. Les champs JSON-LD d’une page en anglais doivent être remplis en anglais, ceux d’une page en français en français : ne mélangez pas les langues. Le champ currency doit correspondre à la devise affichée sur la page dans cette langue ; une page destinée à des clients européens ne doit pas indiquer de dollars. Utilisez systématiquement le format de date ISO 8601, pas une écriture locale ambiguë du type “9/21/2026”. Ces détails ne déclenchent aucune erreur dans le Rich Results Test, mais ils nuisent à la précision de l’extraction par les moteurs IA.
FAQ — Questions fréquentes
Peut-on écrire un headline plus long pour un Article ?
Peut-on mettre plus de questions-réponses dans un FAQPage que sur la page ?
Une page Product n’affiche pas de prix public : comment remplir offers ?
Peut-on utiliser des chemins relatifs dans le champ item d’un BreadcrumbList ?
Peut-on placer à la fois Article et BreadcrumbList sur une même page ?
Combien de temps après la mise en ligne du Schema les résultats enrichis apparaissent-ils ?
Pour conclure
Les quatre Schema essentiels forment l’ensemble minimal viable d’un site B2B : Article pour le blog, FAQPage pour les réponses aux IA, Product pour les pages produit, BreadcrumbList sur tout le site. Un balisage correct ne garantit pas les résultats enrichis, mais un balisage erroné vous en prive à coup sûr.
Trois étapes pour passer à l’action : cette semaine, auditez 5 pages modèles avec le Rich Results Test et listez les types manquants ; la semaine prochaine, ajoutez les quatre modèles JSON-LD dans le head, en alignant mot pour mot les valeurs des champs sur le texte visible ; le 30e jour, vérifiez dans le rapport Rich Media de la Search Console qu’il n’y a aucune erreur.
Une phrase à retenir : avec le Schema, ce n’est pas la quantité qui compte, c’est la précision. Des champs qui correspondent à la page, des chiffres qui correspondent au devis, des questions-réponses qui correspondent à la FAQ : c’est à ce prix que les rich media peuvent apparaître.