Schema Markup : des données structurées sans spam

Un bloc JSON-LD valide peut réussir le Rich Results Test et ne produire aucun rich result. Ce n'est pas un échec du test. Les données structurées décrivent le contenu sous une forme lisible par une machine ; elles ne remplacent pas le contenu, ne garantissent pas une fonctionnalité de recherche et ne sont pas un bouton de classement.

L'erreur courante est de commencer par « quel type de schema ce site doit-il ajouter ? ». Une meilleure question de départ est : quelle entité cette page décrit-elle principalement, quels faits les visiteurs peuvent-ils réellement voir, et quelle présentation Google prend-il actuellement en charge pour ce contenu ?

Données structurées, Schema.org et schema markup

Les données structurées sont des informations organisées dans un format lisible par une machine. Schema.org fournit un vocabulaire de types d'entités et de propriétés. Le schema markup est la mise en œuvre de ce vocabulaire sur une page avec JSON-LD, Microdata ou RDFa.

Google Search prend en charge les trois formats pour de nombreuses fonctionnalités et recommande couramment JSON-LD car il est séparé du HTML de présentation et plus facile à maintenir. Le format ne peut pas sauver des données inexactes. Un Product en JSON-LD parfaitement formé qui déclare un prix absent de la page enfreint quand même les attentes de cohérence.

Le schema améliore-t-il le classement ?

Le schema ne doit pas être vendu comme un facteur de classement direct. Les données structurées peuvent aider les systèmes à comprendre une page et la rendre éligible à certains rich results. Une présentation plus visible peut influencer le taux de clics dans certaines situations, mais Google ne garantit pas l'affichage même lorsque le balisage est correct.

Les résultats dépendent aussi de :

• La possibilité d'explorer et d'indexer la page.
• La conformité du contenu aux règles de Search et aux règles propres à la fonctionnalité.
• L'exactitude, l'exhaustivité, l'actualité et la visibilité des données.
• La requête, l'appareil, la localisation et le choix de présentation de Google.
• Le maintien de la prise en charge de la fonctionnalité dans la documentation actuelle.

La disponibilité des rich results change. Consultez la galerie de recherche officielle plutôt que de vous fier à un ancien article ou à la liste de types d'un plugin.

Choisir un type à partir du contenu principal de la page

Ne balisez pas chaque page avec tous les types qui semblent vaguement liés. Identifiez l'entité principale :

• Un article éditorial : Article, BlogPosting ou un sous-type adapté.
• Une page produit achetable : Product avec offre, prix et disponibilité réels.
• Un établissement physique : LocalBusiness ou un sous-type exact.
• Une recette : Recipe.
• Une page centrée sur une vidéo : VideoObject.
• Un profil d'organisation : Organization.
• Un chemin hiérarchique : BreadcrumbList.

Une catégorie qui liste des produits n'est pas automatiquement un Product. Un guide d'achat d'ordinateurs portables ne doit pas se présenter comme un produit simplement parce qu'il traite de plusieurs modèles. Le type doit représenter ce que la page fournit réellement.

Partir des données sources, pas d'une chaîne JSON

Un schema maintenable est généré à partir des mêmes sources que celles qui rendent la page visible :

Si un modèle affiche le prix de la base de données alors que le JSON-LD stocke un nombre saisi à la main dans le CMS, ils divergeront dès la première promotion. Les données structurées doivent être une autre représentation de la même vérité, et non un second dépôt de contenu.

Un exemple minimal de BlogPosting

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/image-seo#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/image-seo"
  },
  "headline": "Image SEO and alt text",
  "image": [
    "https://example.com/images/image-seo-1200x630.png"
  ],
  "datePublished": "2026-06-10T08:00:00+07:00",
  "dateModified": "2026-06-15T09:30:00+07:00",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/alex#person",
    "name": "Alex Nguyen",
    "url": "https://example.com/authors/alex"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example",
    "url": "https://example.com/"
  }
}
</script>

Cela illustre seulement la structure. Lors de la mise en œuvre, vérifiez les propriétés obligatoires et recommandées dans la documentation actuelle d'Article. Ne copiez jamais en production des dates, URL ou auteurs d'exemple.

@id relie des entités stables

Un @id n'a pas besoin d'être une page distincte qu'un visiteur ouvre. C'est un identifiant stable dans le graphe, généralement une URL absolue avec un fragment :

• https://example.com/#organization
• https://example.com/#website
• https://example.com/authors/alex#person
• https://example.com/products/a#product

Lorsque le publisher d'un article et l'Organization du site entier référencent le même @id, les systèmes peuvent les traiter comme une seule entité plutôt que comme des objets sans lien portant le même nom.

Les identifiants doivent rester stables d'un rendu à l'autre. Ne générez pas un UUID aléatoire à chaque requête. N'utilisez pas un même @id pour des entités différentes comme l'organisation et son site web.

Plusieurs éléments sur une même page

Une page peut contenir plusieurs éléments de données structurées valides :

• WebPage décrit la page.
• BlogPosting décrit l'article.
• BreadcrumbList décrit son chemin.
• Organization ou Person est référencé comme publisher ou author.
• VideoObject décrit une vidéo principale intégrée.

Les objets peuvent être séparés ou reliés dans @graph. L'exactitude des relations et l'absence de contradictions comptent plus que la disposition. Lorsqu'une vidéo n'est qu'une publicité sans rapport, ajouter VideoObject pour viser une fonctionnalité vidéo dénature la page.

Il n'est pas nécessaire de répéter un gros objet Organization dans chaque nœud. Définissez une entité de référence et référencez son @id pour garder le graphe lisible.

Propriétés obligatoires et recommandées

La documentation d'une fonctionnalité sépare les propriétés obligatoires des recommandées. Une donnée obligatoire manquante rend l'élément inéligible. Les champs recommandés peuvent améliorer l'exhaustivité, mais seulement lorsque des données réelles existent.

Un bon principe est moins de propriétés, exactes et complètes. N'ajoutez pas :

• aggregateRating sans vraies notes.
• Un priceValidUntil fabriqué pour supprimer un avertissement.
• « Admin » comme auteur lorsqu'aucun profil ni aucune responsabilité éditoriale n'existe.
• Un logo générique comme image d'un contenu sans rapport.
• Des liens sameAs vers des profils que l'entité ne possède pas.

Un avertissement n'est pas un ordre d'inventer des informations. Il indique qu'une propriété recommandée est absente ; l'équipe produit doit décider si une source fiable existe.

Le contenu balisé doit être visible et cohérent

Google exige que les données structurées représentent le contenu principal et interdit le balisage d'informations cachées aux lecteurs. Exemples à risque :

• Le JSON-LD indique 99 $ alors que la page dit « contactez-nous ».
• Le schema signale InStock alors que l'achat est désactivé.
• Le balisage déclare cinq avis cinq étoiles qui ne sont pas affichés.
• Les réponses d'une FAQ n'existent que dans le JSON-LD.
• Une offre d'emploi expirée conserve un validThrough futur.

« Visible » ne veut pas dire que chaque propriété technique doit devenir du texte brut sur la page. Les URL, identifiants et relations de graphe peuvent rester des métadonnées. Mais les affirmations destinées aux utilisateurs, comme le prix, la note, les détails d'un événement, les questions et l'auteur, doivent correspondre à l'expérience.

Le schema Product révèle vite les problèmes de données

Les prix et les stocks changent souvent. Le balisage Product doit être créé dans la même requête ou le même pipeline que l'interface. Uniformisez :

• La devise avec le code ISO approprié.
• Des prix numériques sans symbole monétaire dans les champs de données.
• La disponibilité avec l'URL schema.org correcte.
• Les offres rattachées à la bonne variante.
• Des canoniques de variantes et des identifiants de produit cohérents.
• Des notes agrégées uniquement à partir d'avis légitimes de ce produit.

Pour les produits à variantes, lisez la documentation actuelle sur les variantes de produit plutôt que de combiner arbitrairement couleur, prix et SKU dans un seul objet. Si une page ne vend pas l'article ou n'a pas d'offre réelle, ne créez pas de fausse offre pour faire disparaître les erreurs.

LocalBusiness ne peut pas fabriquer des établissements

Chaque établissement a besoin d'un vrai nom, d'une adresse, d'un téléphone, d'horaires, d'une zone de service et d'une URL. Sa page de destination doit apporter une valeur correspondante. Créer 200 pages de villes quasi identiques et y ajouter LocalBusiness ne crée pas 200 bureaux.

Les faits du schema doivent concorder avec les pages de contact, les fiches d'entreprise et les données internes gérées. Lorsque les horaires de jours fériés changent, mettez à jour l'interface et le JSON-LD à partir de la même source.

Les avis et les notes sont des zones de spam à haut risque

Ne balisez pas :

• Des avis rédigés par l'entreprise à son propre sujet.
• Des notes copiées d'un autre produit.
• Des scores agrégés sans avis sources.
• Des témoignages de l'entreprise utilisés comme notes de chaque service.
• Des données cachées présentes uniquement dans des scripts.

Enfreindre les règles de qualité peut supprimer l'éligibilité aux rich results et peut conduire à une action manuelle liée aux données structurées. Cela n'efface pas forcément tout le classement web, mais le risque ne vaut pas une rangée d'étoiles décoratives.

Le schema FAQ n'est pas une valeur par défaut pour chaque article

Les FAQ visibles restent utiles aux lecteurs, mais le balisage ne doit pas être activé simplement parce qu'un plugin propose une case à cocher. L'éligibilité et la disponibilité peuvent changer selon l'époque, le secteur et les règles. Avant un déploiement large :

1. Confirmez que le type figure toujours dans la galerie de recherche et s'applique au site.
2. Lisez l'intégralité des consignes propres à la fonctionnalité.
3. Assurez-vous que chaque question et chaque réponse apparaissent sur la page.
4. Évitez de répéter des FAQ identiques sur des milliers d'URL.
5. Mesurez les résultats au lieu de considérer « valide » comme un succès.

Le schema ne doit pas dicter la structure éditoriale. Rédigez une FAQ lorsque les lecteurs en ont besoin, puis déterminez si un balisage pris en charge convient.

Tester en trois couches

Couche 1 : JSON et syntaxe du schema

Un parseur doit pouvoir lire le JSON-LD : virgules, accolades, échappements et types de données doivent être corrects. Un guillemet non échappé dans le nom d'un produit peut invalider tout le bloc.

Couche 2 : Rich Results Test

Cet outil vérifie les types pris en charge par Google et signale erreurs et avertissements. Résolvez les erreurs ; évaluez les avertissements au regard des données réellement disponibles. « Valide » signifie techniquement éligible au moment du test, sans garantie d'affichage.

Couche 3 : page en production et Search Console

Inspectez l'URL déployée avec l'inspection d'URL, examinez le HTML réel et suivez les rapports de rich results. Un test en préproduction ne peut pas révéler toutes les défaillances de cache, de langue, de feature flag, de consentement ou de données produit en production.

Lancez le SEO Checker pour échantillonner les signaux de la page et un audit SEO gratuit pour trouver des métadonnées ou des canoniques anormales avant d'accuser le schema.

Tester les données incomplètes et hostiles

Un modèle semble souvent parfait avec un produit exemple complet et échoue aux limites :

• Pas d'image.
• Prix nul ou non publié.
• Deux devises.
• Noms contenant des guillemets et des sauts de ligne.
• Auteur manquant.
• Date de modification antérieure à la publication après une migration.
• Nombre d'avis égal à zéro.
• Produit retiré.
• Une page en anglais qui reçoit par erreur des données d'organisation en vietnamien.

Créez des fixtures pour ces cas. Vérifiez que le JSON s'analyse, que les URL absolues utilisent la bonne langue, que les propriétés obligatoires n'apparaissent que lorsque c'est éligible et qu'un objet est omis lorsque les données essentielles sont indisponibles.

Défaillances de mise en œuvre courantes

Deux plugins génèrent la même entité

Le thème émet Article, un plugin SEO émet BlogPosting et un plugin d'avis crée un autre Product avec un ID différent. Le résultat contient des auteurs, images ou notes contradictoires. Recensez chaque script application/ld+json et attribuez un propriétaire unique à chaque entité.

Le schema contient des URL de préproduction

Des variables d'environnement ou des caches peuvent faire pointer @id, image et canonique vers un domaine de test. Recherchez dans le HTML de production tous les noms d'hôte inattendus.

Les langues sont mélangées

Une page anglaise peut avoir un titre en anglais mais un fil d'Ariane et un nom d'organisation en vietnamien. Définissez quels champs sont partagés et lesquels sont localisés ; vérifiez inLanguage lorsqu'il est utilisé.

Le JavaScript injecte le balisage trop tard

Google peut rendre le JavaScript, mais dépendre d'une requête client défaillante ou bloquée rend les données moins stables. Lorsque le serveur détient déjà les faits, rendre le JSON-LD dans le HTML initial est généralement plus simple et plus fiable.

Le schema sert à masquer un contenu faible

Un balisage détaillé ne peut pas compenser une page produit vide ou un article copié. Les données structurées décrivent de la valeur ; elles ne créent pas de valeur absente de la page.

Surveiller après le déploiement

Traitez le schema comme un contrat de mise en production :

• Tests unitaires des générateurs avec des fixtures.
• Validation ou snapshots des modèles principaux.
• Crawl de la préproduction et de la production pour compter éléments et erreurs.
• Alerte lorsque la couverture du balisage chute brutalement.
• Suivi des rapports d'améliorations et des actions manuelles.
• Enregistrement des dates de mise en production pour comparer CTR, impressions et erreurs.

Lorsque Google change la prise en charge d'un type de rich result, inutile de paniquer et de supprimer toutes les instructions schema.org utiles. Distinguez le balisage d'entité qui clarifie le contenu de celui qui n'est maintenu que pour une seule fonctionnalité de recherche. Comparez le coût de maintenance au bénéfice réel.

Checklist avant publication

• Le type représente-t-il le contenu principal ?
• La fonctionnalité est-elle prise en charge dans la documentation actuelle de Google ?
• Les propriétés obligatoires sont-elles complètes et issues de vraies données ?
• Les affirmations importantes sont-elles visibles pour les visiteurs ?
• Les URL, images et valeurs @id sont-elles absolues, explorables et sur le bon domaine ?
• La canonique et mainEntityOfPage identifient-elles la même URL stratégique ?
• Les dates, prix, disponibilités et notes se mettent-ils à jour automatiquement ?
• Un autre plugin crée-t-il un objet en double ?
• Le Rich Results Test réussit-il ?
• Des données manquantes peuvent-elles invalider le JSON ?
• La production et Search Console ont-elles été vérifiées ?

Conclusion

Un bon schema markup est une description honnête et structurée du contenu visible. Il commence par le modèle de données et la propriété des sources, plutôt que par un extrait JSON-LD copié. Choisissez un type exact, utilisez des identifiants stables, fournissez des propriétés réelles et complètes, testez les cas limites et surveillez après la mise en production.

Ne fabriquez pas de notes pour supprimer des avertissements, ne balisez pas des affirmations cachées et ne promettez pas les rich results comme une certitude. Lorsque l'interface et les données structurées sont générées à partir de la même vérité, le schema devient de l'ingénierie maintenable plutôt qu'une couche décorative fragile.

Références : introduction aux données structurées de Google Search Central, consignes générales sur les données structurées et documentation de Schema.org.