Implémenter le Schema.org pas à pas

Ce que le balisage change réellement

Une machine qui lit « fondée en 2011 à Nantes » doit inférer qu'il s'agit d'une date de création et d'un lieu. L'inférence fonctionne souvent, elle échoue parfois, et elle échoue davantage quand le texte est ambigu ou quand plusieurs dates coexistent sur la page.

Le balisage supprime l'inférence. Vous déclarez explicitement : ceci est une organisation, sa date de fondation est celle-ci, son adresse est celle-là. Le gain n'est pas un meilleur classement, c'est une réduction de l'incertitude, et l'incertitude est précisément ce qui empêche une entité d'être reconnue.

Corollaire important : un balisage impeccable sur une entité incohérente ne produit rien. Le balisage rend lisible ce qui existe, il ne crée pas la cohérence. C'est pourquoi il vient après la définition canonique, jamais avant.

Les quatre types prioritaires

Le type Organization est le plus important des quatre, et celui que la plupart des sites bâclent. Il porte votre identité machine : c'est lui qui permet à un moteur de rattacher toutes vos pages à une même entité, et cette entité à vos mentions externes.

Deux propriétés y méritent une attention particulière. sameAs liste vos profils officiels et fait le pont vers vos présences externes. knowsAbout déclare vos domaines d'expertise et doit reprendre exactement le vocabulaire de votre définition canonique.

Comment l'intégrer

Trois formats existent. Retenez JSON-LD et ignorez les deux autres.

Microdata et RDFa s'entremêlent au HTML, ce qui les rend fragiles à toute refonte graphique. JSON-LD s'insère dans un bloc <script type="application/ld+json">, indépendant de la mise en page, modifiable sans toucher au design. C'est aussi le format recommandé par Google.

Sur l'organisation du code, une pratique évite bien des doublons : regroupez vos nœuds dans un @graph unique par page, en donnant à chaque nœud un identifiant stable avec @id. Vos articles référencent alors l'auteur et l'éditeur par leur identifiant plutôt que de redéclarer les mêmes informations à chaque page. Une seule source de vérité, comme pour votre définition canonique.

Les blocs copiables par type sont réunis dans la ressource gabarits de données structurées commentés.

Les cinq erreurs qui rendent le balisage inutile

• Baliser une information absente de la page. Le balisage décrit le contenu visible. Déclarer un avis ou un prix qui n'apparaît nulle part est une non-conformité, sanctionnable.
• Les notes auto-attribuées. Un aggregateRating que vous générez vous-même n'est pas affiché par Google, et le déclarer sur un service que vous vendez est explicitement contraire à ses règles.
• Le balisage FAQ. Google ne l'affiche pratiquement plus depuis 2023 et il alourdit le code sans contrepartie. Structurez vos questions en HTML clair : les moteurs génératifs les extraient très bien sans balisage.
• Les identifiants instables. Un @id qui change à chaque déploiement empêche tout rattachement entre vos pages. Ancrez-les sur des URL canoniques.
• Les incohérences avec le texte. Une adresse balisée différente de celle du pied de page annule le bénéfice du balisage : vous avez ajouté une version supplémentaire au lieu d'en retirer une.

Vérifier et maintenir

Deux outils suffisent. Le test des résultats enrichis de Google signale les erreurs bloquantes et les propriétés recommandées manquantes. Le validateur Schema.org, plus strict, détecte les incohérences de typage que le premier tolère.

Contrôlez au minimum un gabarit de chaque type : une page d'article, une page auteur, une page de service, plus l'accueil. Inutile de tester toutes vos pages si elles partagent le même modèle.

Côté maintenance, le piège classique est la date de modification. Un dateModified qui ne bouge jamais alors que le contenu évolue prive vos pages du signal de fraîcheur, qui compte particulièrement pour la recherche augmentée. Automatisez-la plutôt que de la saisir à la main.