Une cliente m'a envoyé l'autre jour un audit SEO trouvé en ligne. Verdict : « données structurées manquantes sur 87 % des pages ». Elle m'a demandé de tout baliser. Tout. Le blog, les catégories, les pages légales, la page contact. J'ai refusé.
Parce que baliser tout, c'est le meilleur moyen de n'obtenir strictement rien. Le choix des données structurées schema.org ne se fait pas à la volée : il se décide en fonction de votre type de site, de vos objectifs et de ce que Google accepte réellement d'afficher. Et surtout, il se limite à une poignée de types réellement rentables.
Je vais vous montrer comment trancher, type par type.
Points clés à retenir
- JSON-LD reste le format à privilégier : séparé du HTML, maintenable, recommandé par Google.
- Cinq types couvrent l'immense majorité des besoins réels : Article, Product, LocalBusiness, Organization, FAQPage.
- Les données structurées n'améliorent pas directement votre position, mais la façon dont votre page s'affiche.
- Un balisage incomplet ou incohérent est pire que pas de balisage du tout.
- Choisissez 2 ou 3 types, maîtrisez-les, puis élargissez.
- Chaque type a des propriétés obligatoires et d'autres recommandées : la confusion entre les deux est l'erreur n°1 que je vois.
Schema.org : lequel choisir pour votre site (et pourquoi la réponse dépend de votre métier)
La question qu'on me pose le plus souvent, formulée exactement comme ça : « C'est quoi le bon type schema.org pour mon site ? ». Comme s'il existait une réponse unique. Il n'y en a pas.
Un site e-commerce, un blog et un cabinet d'avocats n'ont rien à baliser de la même façon. Le référentiel schema.org compte des centaines de types, mais en pratique, une dizaine suffit à couvrir 90 % des cas. Encore faut-il savoir lesquels activer selon votre situation.
La grille de décision par type de site
Voici comment je tranche, concrètement, avec mes clients.
- Site e-commerce : Product (avec Offer, Price, Availability) et, si vous avez des avis visibles, AggregateRating. Le reste attend.
- Média ou blog : Article, et selon le contenu BlogPosting ou NewsArticle. J'y reviens plus bas.
- Activité locale (restaurant, artisan, cabinet) : LocalBusiness, avec adresse, horaires et géolocalisation.
- SaaS ou service B2B : Organization et, si vous publiez une FAQ utile, FAQPage.
- Site vitrine sans contenu récurrent : Organization uniquement. Sérieusement. Le reste est du bruit.
Vous remarquerez que je n'ai mentionné ni HowTo, ni Event, ni Recipe. C'est volontaire. Ces types sont utiles dans des cas ultra-spécifiques, mais ils ne font pas partie du socle de départ.
Pourquoi limiter volontairement le nombre de types
J'ai fait l'erreur inverse il y a quelques années : baliser chaque page d'un site avec un maximum de types différents, « pour être sûr ». Résultat : trois alertes Search Console en deux semaines, un type principal en conflit avec un sous-type, et zéro rich snippet obtenu. J'ai tout retiré et repris proprement. Le balisage, c'est comme le sel : trop, ça ruine le plat.
La raison est mécanique : chaque type possède ses propres propriétés obligatoires. Multiplier les types multiplie les points de rupture. Un seul champ manquant et Google ignore tout le bloc concerné.
JSON-LD, Microdata ou RDFa : quel format choisir en 2026 ?
Une fois le type choisi, encore faut-il l'écrire dans le bon format. Trois options existent. Une seule tient la route.
| Critère | JSON-LD | Microdata | RDFa |
|---|---|---|---|
| Intégration | Dans un <script> séparé | Dans le HTML, attribut par attribut | Dans le HTML, attributs étendus |
| Maintenance | Simple, isolé | Fastidieuse sur gros site | Complexe, peu d'outils |
| Compatibilité CMS | Excellente (plugins, thèmes) | Limitée | Rare |
| Risque d'erreur | Faible | Élevé (structure imbriquée) | Élevé |
| Recommandation Google | Format privilégié | Accepté | Accepté |
Pourquoi JSON-LD gagne
JSON-LD est séparé du HTML. Vous pouvez modifier votre mise en page sans casser votre balisage, et inversement. Sur un site WordPress, c'est deux minutes de configuration via un plugin. Sur un site sur-mesure, c'est un script injecté dans le <head>.
Inversement, Microdata exige de parsemer vos balises HTML d'attributs itemscope et itemprop. Dès qu'un développeur refactorise un template, il casse silencieusement vos données. Je l'ai vu se produire sur un site client dont le balisage Product a disparu pendant six semaines sans que personne ne s'en aperçoive.
Quand Microdata peut encore servir
Il reste un cas où Microdata garde un intérêt : quand votre contenu est déjà structuré en HTML sémantique et que vous voulez éviter d'ajouter du JavaScript. C'est rare. Et franchement, ce n'est pas un bon compromis en 2026.
Article, BlogPosting ou NewsArticle : le choix qui fait perdre le plus de gens
Vous publiez un blog. Vous hésitez entre Article, BlogPosting et NewsArticle. Vous choisissez Article « au cas où ». Mauvaise pioche.
Ces trois types sont liés : BlogPosting et NewsArticle héritent tous deux de Article. Ils en partagent les propriétés principales. La différence se joue sur la nature éditoriale de votre contenu.
- NewsArticle : contenu d'actualité, avec une notion de fraîcheur et de date de publication forte.
- BlogPosting : billets de blog, ton plus personnel, dates moins critiques.
- Article : catégorie générique, à utiliser quand ni l'un ni l'autre ne colle vraiment.
Mon conseil : sur un blog, balisez en BlogPosting. Sur un site média, en NewsArticle. Sur un site corporate avec des analyses de fond, Article fera très bien l'affaire.
LocalBusiness ou Organization : la confusion classique
Autre cas qui revient sans cesse. Une entreprise avec une adresse physique : elle balise tout en Organization, puis s'étonne de ne pas apparaître dans les résultats enrichis locaux.
LocalBusiness est une sous-catégorie d'Organization. Il en hérite les propriétés, mais il ajoute tout ce qui concerne l'implantation : adresse, horaires d'ouverture, zone desservie, coordonnées géographiques. Si votre activité repose sur une présence physique ou une zone d'intervention locale, vous voulez LocalBusiness. Point. Organization seul ne suffira pas à déclencher l'affichage local.
FAQPage : utile, mais à utiliser avec parcimonie
Le type FAQPage a longtemps été le raccourci favori pour apparaître dans les résultats enrichis. Il fonctionne toujours, mais Google se montre désormais plus sélectif sur ce qu'il affiche. Il faut que vos questions-réponses soient réellement visibles sur la page. Pas cachées dans un onglet, pas inventées pour l'occasion.
C'est d'ailleurs ainsi que je conçois mes propres questions fréquentes : je les écris d'abord pour le lecteur, je les balise ensuite. Jamais l'inverse.
Comment valider et prioriser sans y passer des semaines
Vous avez choisi vos types et votre format. Reste à vérifier que tout tient. C'est l'étape que je vois le plus souvent zappée.
Les outils à connaître
Deux outils suffisent. Le Rich Results Test de Google, qui vous dit quels résultats enrichis votre page peut générer. Et le Schema Markup Validator, plus généraliste, qui vérifie la validité de votre balisage au-delà des types supportés par Google.
Utilisez les deux. Le premier valide l'usage réel, le second détecte les erreurs structurelles qui empêcheraient même Google de lire votre bloc.
Les erreurs que je vois le plus souvent
- Confondre propriétés obligatoires et propriétés recommandées. Le nom de marque (brand) sur un Product, par exemple, est recommandé, pas obligatoire. Son absence ne bloque rien.
- Imbriquer mal les types. Un Product doit contenir un Offer, qui contient lui-même le prix et la devise. Si vous inversez, rien ne fonctionne.
- Baliser du contenu absent de la page. Google vérifie. Une FAQ balisée dont les questions n'apparaissent nulle part dans le HTML est un signal négatif.
- Oublier de mettre à jour après refonte. Un type Article qui pointe vers des données obsolètes induit en erreur, et vous n'avez aucun moyen de le savoir sans surveiller Search Console.
Sur ce dernier point, j'ai pris l'habitude d'ajouter une vérification systématique des données structurées à ma checklist de mise en ligne. Ça m'a coûté une après-midi à mettre en place. Depuis, ça m'a évité pas mal d'ennuis silencieux.
Données structurées et GEO : ce qui change vraiment
Un dernier point, souvent survendu. On lit partout que les données structurées améliorent la visibilité dans les IA (ChatGPT, Gemini, Claude). C'est vrai en partie, faux dans la formulation qu'on en fait.
Les données structurées ne « boostent » pas votre citation par ChatGPT. Elles rendent votre contenu plus facile à interpréter par les robots d'indexation, y compris ceux des moteurs de réponse. La nuance est importante : vous ne devenez pas plus visible, vous devenez plus compréhensible. C'est différent. Et c'est déjà beaucoup.
En pratique, ce que je constate chez mes clients, c'est que le balisage propre améliore surtout la cohérence de ce que les moteurs extraient de leurs pages. Les réponses générées citent plus fidèlement les informations exactes, notamment pour les coordonnées, les prix et les horaires. C'est un gain de précision, pas de volume.
Par où commencer, concrètement
Si vous ne devez retenir qu'une chose de cet article : commencez petit. Choisissez le type qui correspond à votre page principale, implémentez-le en JSON-LD, validez avec les deux outils, puis observez Search Console pendant deux ou trois semaines. Élargissez ensuite.
Un site avec deux types bien balisés obtient de meilleurs résultats qu'un site avec douze types mal configurés. Je l'ai vérifié sur mes propres projets, plus d'une fois.
Et si un jour on vous vend un audit qui exige de baliser toutes vos pages — pages légales incluses — posez une seule question : « Pour quel résultat enrichi affichable ? ». Si la réponse est floue, vous savez ce qu'il vous reste à faire.
