Un client m'appelle l'an dernier, paniqué. Son site e-commerce vend des chaussures de randonnée et il vient de voir un concurrent apparaître dans les résultats Google avec une fiche produit ornée d'étoiles, d'un prix barré et d'une mention de disponibilité. Lui : un simple lien bleu. Il me demande combien ça coûte, d'acheter "ce truc avec les étoiles". Je lui réponds que ça ne coûte rien, que c'est une balise, et qu'il aurait pu le faire depuis longtemps. Il n'avait jamais entendu parler de schema.org.
C'est le point de départ de ce guide du balisage schema.org pour le SEO : la plupart des sites n'en ont pas, ou en ont un bancal qui génère des erreurs silencieuses. Et pourtant, en 2026, ces données servent à deux publics à la fois — Google, et les moteurs de réponse IA qui citent vos pages.
Points clés à retenir
- Le balisage schema.org est un vocabulaire ajouté au HTML pour décrire le contenu, pas pour le décorer.
- JSON-LD est le format à privilégier, recommandé explicitement par Google.
- Un balisage incohérent avec le contenu visible peut déclencher une action manuelle.
- Le test des résultats enrichis et le validateur de balisage sont deux outils différents, souvent confondus.
- Les moteurs IA s'appuient de plus en plus sur ce balisage pour extraire des réponses citables.
Schema.org, concrètement : ce que c'est et ce que ça n'est pas
Schema.org est un vocabulaire partagé par Google, Bing et Yahoo depuis 2011. Il permet de munir une page HTML d'étiquettes lisibles par machine : « ceci est un produit », « ceci est son prix », « ceci est une recette avec un temps de cuisson de 25 minutes ». Vous ne créez rien de visible ; vous traduisez votre contenu en langage compréhensible par un robot.
Pourquoi JSON-LD écrase microdata et RDFa
Trois formats existent. Dans la pratique, un seul s'impose : JSON-LD, un bloc de script placé dans la page, à part du HTML. Il est recommandé par Google, se maintient plus facilement, et n'oblige pas à polluer chaque balise.
| Format | Où il vit | Maintenance | Recommandation Google |
|---|---|---|---|
| JSON-LD | Bloc <script> séparé | Facile, isolé du contenu | Oui, format conseillé |
| Microdata | Dans les attributs HTML | Verbeux, fragile au refactoring | Supporté |
| RDFa | Attributs HTML | Peu courant côté SEO | Supporté |
Mon avis, que je défendrai bec et ongles : si vous démarrez aujourd'hui, il n'y a aucune raison de choisir autre chose que JSON-LD. J'ai repris un jour un site en microdata où le développeur avait imbriqué des propriétés sur douze niveaux de balises. Une refonte du template a tout cassé. On a perdu deux mois de données produit.
Quels types baliser en premier quand on part de zéro
On me pose souvent la question dans cet ordre : « par quoi je commence ? ». Réponse honnête : par ce qui a un impact visible ou stratégique. Pas par la liste complète des types disponibles, qui en compte des centaines.
Organization, Product, FAQPage : le trio de départ
- Organization : identité de l'entreprise (nom, logo, réseaux). Utile sur la page d'accueil et la page contact.
- Product : prix, disponibilité, avis. C'est ce qui déclenche les étoiles et le prix barré dans les résultats.
- FAQPage : questions-réponses. Attention, Google a considérablement réduit l'affichage de ce type en résultats enrichis, mais il reste précieux pour les moteurs de réponse.
- Article et BreadcrumbList : pour un blog ou un site éditorial, c'est le socle.
- LocalBusiness : indispensable si vous avez une adresse physique que des gens cherchent.
J'ai longtemps cru que baliser FAQPage suffisait à sortir en encadré. Après plusieurs mois de tests sur un site de services, aucun changement visible côté Google. En revanche, les extraits cités par les moteurs IA ont augmenté nettement sur les pages ainsi balisées. Ce n'est pas une preuve statistique, juste mon observation répétée.
Exemples JSON-LD prêts à copier
La théorie ne sert à rien sans code. Voici un bloc minimal pour une Organization, à placer dans le <head> :
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Chaussures Rando",
"url": "https://exemple.fr",
"logo": "https://exemple.fr/logo.png",
"sameAs": ["https://www.linkedin.com/company/exemple"]
}Et un bloc Product, avec les propriétés qui comptent réellement pour l'affichage :
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Chaussure de randonnée GTX",
"image": "https://exemple.fr/photo.jpg",
"description": "Chaussure imperméable pour sentiers techniques",
"brand": {"@type": "Brand", "name": "Exemple"},
"offers": {
"@type": "Offer",
"price": "129.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock"
}
}Trois pièges à connaître : priceCurrency en majuscules (EUR, pas eur), availability qui attend une URL schema.org complète, et l'oubli fréquent de image qui bloque l'affichage enrichi.
Valider et déboguer : l'étape que tout le monde saute
Un balisage non testé est un balisage cassé. Les outils de validation ne sont pas interchangeables, et c'est là que beaucoup se perdent.
Le test des résultats enrichis n'est pas le validateur de balisage
Le test des résultats enrichis de Google vérifie si votre page est éligible à un affichage enrichi. Le validateur de balisage schema.org, lui, vérifie la syntaxe et la conformité du vocabulaire, sans se soucier des règles Google. Une page peut passer le second et échouer au premier. C'est fréquent : le validateur ne connaît pas les règles d'éligibilité.
Enfin, la Search Console, dans sa section « Améliorations », remonte les erreurs détectées à grande échelle. C'est là qu'on voit les problèmes réels, pas seulement ceux d'une page testée à la main.
Les erreurs qui coûtent cher (et que je vois partout)
Le balisage trompeur est le pire des cas. Une propriété qui annonce un prix différent de celui affiché, une note moyenne inventée, une date de publication falsifiée : c'est le chemin direct vers une action manuelle. J'ai vu un site de formation afficher des avis clients fictifs en JSON-LD. Résultat quelques semaines plus tard : une pénalité manuelle, et six mois de travail pour la levée.
Autres erreurs courantes, dans le désordre :
- Dupliquer un même type sur la même page avec des valeurs contradictoires.
- Baliser une FAQ dont les questions ne sont pas visibles à l'écran.
- Injecter le JSON-LD via du JavaScript qui s'exécute trop tard pour les robots.
- Oublier de mettre à jour le balisage quand le contenu change — le prix affiché bouge, le JSON-LD non.
La règle est simple : ce que vous déclarez doit être vrai et visible. Pas de raccourci. Franchement, ça paraît évident, et pourtant c'est la source d'erreur numéro un dans les audits que je mène.
Pourquoi le balisage compte encore plus en 2026
Un client m'a raconté sa surprise : il a posé une question à un assistant IA sur les meilleures chaussures pour terrain boueux, et l'outil a cité un concurrent. Pas lui. L'assistant avait lu la page du concurrent, comprise grâce à ses données structurées, et extrait le prix, la pointure et le matériau. La page de mon client, sans balisage, était trop ambiguë pour être citée proprement.
Les moteurs de réponse s'appuient sur ce vocabulaire pour extraire des faits. Une page bien balisée devient une source fiable, citée directement. Une page sans structure reste du texte qu'il faut deviner. Le bénéfice est cumulatif : les mêmes données servent à Google et aux assistants.
Faut-il tout baliser, alors ?
Non. Mieux vaut trois types justes et à jour que dix types approximatifs. La cohérence compte plus que le volume.
Une balise ne remplace pas une réponse
Le balisage ne crée pas de contenu. Il ne fera jamais apparaître une fiche produit qu'un internaute juge médiocre. Tout ce qu'il fait, c'est rendre lisible par machine ce que vous avez déjà écrit pour un humain. Si le contenu sous-jacent est vague, le meilleur JSON-LD du monde restera muet.
Alors avant d'ajouter une balise, posez-vous une question : est-ce que ma page répond vraiment à quelque chose ? Si la réponse est non, le schéma ne sauvera rien. Et si elle est oui, il vaut la peine de prendre dix minutes pour le dire aussi aux robots.
