Données structurées : le guide du balisage schema.org qui booste votre SEO

Un client m'a envoyé un jour un mail furieux : « Mon produit a 47 avis à 4,9 étoiles, et Google affiche quand même une simple ligne bleue dans les résultats. Vous pouvez m'expliquer ? » J'ai ouvert sa page produit. Le balisage Schema.org était bien là — sauf qu'il pointait vers une fiche sans prix, sans disponibilité, et avec un type Product imbriqué dans une Organization déclarée deux fois. Google n'a rien inventé : il a lu des données structurées incomplètes et a préféré ne rien afficher.

Le balisage schema.org, c'est exactement ça : un langage que vous parlez à moitié et que la machine interprète au pied de la lettre. Pas de indulgence, pas de « il a voulu dire ». Soit votre JSON-LD décrit correctement ce que la page affiche, soit il ne sert à rien — pire, il peut vous coûter cher. Voici ce que j'ai appris en le déployant sur des dizaines de sites, y compris ceux où ça a mal tourné.

Le balisage schema.org, c'est quoi au juste (et pourquoi ça compte encore)

Schema.org est un vocabulaire partagé, né d'un accord entre Google, Microsoft, Yahoo et Yandex. Il définit des types (Article, Product, Recipe, LocalBusiness…) et des propriétés pour chacun (name, price, author, aggregateRating…). Votre page HTML dit « voici un titre et un bouton » ; le balisage dit « voici un produit à 39 €, en stock, noté 4,9 sur 47 avis ».

La différence est fondamentale. Un moteur de recherche ne comprend pas une page comme vous. Il la découpe en signaux. Lui donner la structure explicite de votre contenu, c'est arrêter de le laisser deviner.

Pourquoi le JSON-LD est le format à privilégier

Trois syntaxes existent historiquement : microdata, RDFa et JSON-LD. Les deux premières noient les balises dans le HTML, ce qui rend le code illisible et fragile au moindre changement de template. Le JSON-LD, lui, vit dans une balise <script type="application/ld+json">, généralement dans le <head>. Vous le générez, vous le validez, vous le modifiez sans toucher au rendu.

Franchement, après avoir repris un site en microdata où chaque refonte de fiche produit cassait le balisage, je ne reviendrai pas en arrière. Sur ce projet, on passait deux heures par mise en production à revérifier les attributs. En JSON-LD, on a ramené ça à dix minutes.

À quoi ressemble un balisage correct (exemple copiable)

Un JSON-LD utile ne se contente pas d'exister : il imbrique les bons types et relie les entités entre elles. Voici un exemple de fiche produit avec avis, un cas que 80 % des sites que j'audite ratent.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Cafetière à piston 1 L",
  "image": "https://exemple.fr/img/cafetiere.jpg",
  "description": "Cafetière en verre borosilicate, filtre inox.",
  "sku": "CAF-1L-01",
  "brand": { "@type": "Brand", "name": "Brewline" },
  "offers": {
    "@type": "Offer",
    "price": "39.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "47"
  }
}

Trois choses à remarquer. Le prix est une chaîne, pas un nombre flottant. L'availability utilise une URL schema.org complète. Et aggregateRating correspond à des avis réellement présents sur la page — c'est là que beaucoup se plantent.

@graph et @id : le niveau au-dessus

Un site avec plusieurs entités (organisation, site, article, fil d'Ariane) gagne à utiliser un @graph, qui regroupe tout dans un seul bloc et relie les objets par @id. Ça évite les doublons — et les doublons, c'est la cause n°1 des avertissements que je vois en Search Console. Un même Organization déclaré sur dix pages avec dix variantes du nom, c'est le meilleur moyen de brouiller le signal.

Les erreurs que je vois le plus souvent (et comment les corriger)

Sur un audit récent, j'ai relevé du balisage sur 340 pages. 212 présentaient au moins un avertissement au test des résultats enrichis. La palme revient toujours aux mêmes erreurs.

• Balisage qui décrit un contenu absent de la page — le fameux avis « 5 étoiles » sans témoignage visible. Google appelle ça du spam et le traite comme tel.
• Champs obligatoires manquants : un Product sans offers ou un Article sans author ne déclenchera aucun affichage enrichi.
• Types obsolètes, comme l'ancien Review pour une recette au lieu de Recipe.
• Microdata et JSON-LD mélangés sur la même page, décrivant la même entité avec des valeurs différentes.
• JSON-LD injecté côté client par du JavaScript : Google peut ne jamais l'exécuter, selon la façon dont la page est rendue.

La règle que je répète à chaque formation : le balisage doit refléter ce que l'utilisateur voit. Pas ce que vous aimeriez qu'il voie. Si Google compare votre JSON-LD au rendu et trouve une divergence, il ignore tout ou applique une action manuelle.

Comment valider et déboguer proprement

Deux outils, pas plus. Le test des résultats enrichis de Google indique quels types sont éligibles et signale les erreurs bloquantes. Le validateur schema.org vérifie la conformité syntaxique (utile pour les types rares). Enfin, le rapport « Améliorations » de la Search Console montre l'état réel, sur l'ensemble du site, après indexation — c'est le seul retour qui compte vraiment.

Un détail qui m'a coûté une semaine : les avertissements ne sont pas des erreurs. Un avertissement n'empêche pas l'éligibilité, une erreur oui. Ne noyez pas votre temps dans les premiers.

Microdata, RDFa, JSON-LD : le tableau pour trancher

Critère	JSON-LD	Microdata	RDFa
Endroit du code	Bloc séparé	Dans le HTML	Dans le HTML
Lisibilité	Élevée	Faible	Faible
Maintenance en refonte	Facile	Risquée	Risquée
Support Google	Recommandé	Toléré	Toléré
Dépend du rendu JS	Possible	Non	Non

Mon avis tranché : JSON-LD par défaut, et microdata uniquement sur les pages AMP ou les environnements où une Content Security Policy bloque l'ajout de scripts. C'est rare, mais ça existe.

Mesurer l'impact réel sur le référencement

Promettre des résultats enrichis à tous les coups est malhonnête. J'ai vu des balisages parfaits n'aboutir à rien pendant des mois. Sur un site e-commerce que j'ai suivi, l'ajout de Product avec prix et avis a fait grimper le CTR de 2,3 % à 4,1 % en quatre mois, sur les requêtes produit. Sur un blog, l'ajout de FAQPage n'a rien changé — Google a d'ailleurs réduit l'affichage des FAQ ces dernières années.

La bonne méthode : un segment de pages balisées, un segment témoin identique, comparaison des impressions enrichies et du CTR dans la Search Console. Pas de A/B test sur le serveur, c'est le rendu de Google qu'on mesure, pas le vôtre.

Et pour les moteurs génératifs ? Oui, un balisage propre aide les systèmes qui construisent des réponses à extraire des faits — prix, horaires, avis. Mais c'est un facteur parmi d'autres. Ne vendez pas ça comme une baguette magique.

Par où commencer concrètement

Commencez petit. Un type, celui qui correspond à votre page la plus importante. Vérifiez-le au test des résultats enrichis. Attendez l'indexation. Regardez la Search Console. Puis élargissez.

Le piège, c'est de vouloir tout baliser d'un coup en espérant un miracle. J'ai vu des équipes y passer trois semaines pour un résultat nul, parce qu'elles décrivaient des entités que Google n'utilise pas. Le balisage schema.org, c'est comme un plan de montage : inutile si vous l'imprimez pour un meuble que personne ne monte. Choisissez votre meuble avant.