Données structurées JSON-LD : le balisage qui compte (et celui qui ne sert à rien)

Les données structurées décrivent le contenu d'une page dans un format que les machines comprennent sans ambiguïté : « ceci est un produit à 49 €, en stock », « ceci est un article publié le 12 mars par telle organisation ». Bien utilisées, elles débloquent des résultats enrichis dans Google (étoiles, prix, FAQ dépliées) qui améliorent le taux de clic. Mal comprises, elles deviennent un rituel sans effet. Distinguons les deux.

JSON-LD en deux minutes

Trois syntaxes existent (microdata, RDFa, JSON-LD) ; JSON-LD est celle que Google recommande, et la plus simple à maintenir : un bloc <script> indépendant du HTML visible, généré par le serveur avec les mêmes données que la page.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Fauteuil en chêne massif",
  "image": "https://www.exemple.fr/img/fauteuil.avif",
  "description": "Fauteuil artisanal en chêne massif, fabriqué en France.",
  "offers": {
    "@type": "Offer",
    "price": "489.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "38"
  }
}

La règle d'or : le balisage décrit ce que la page affiche réellement. Baliser des avis qui n'existent pas ou un prix différent de celui affiché relève du balisage trompeur — sanctionnable par une action manuelle, et détectable automatiquement.

Les types qui produisent des résultats visibles

Tous les types Schema.org n'ont pas le même rendement. Ceux qui déclenchent des affichages enrichis documentés chez Google :

À l'inverse, baliser Organization et WebSite sur toutes les pages est une bonne hygiène (logo, nom, réseaux sociaux dans le panneau de connaissance) mais n'apportera pas d'étoiles ni de trafic mesurable — il faut le savoir avant d'y investir des jours.

Ce que les données structurées ne font pas

Soyons clairs sur un point souvent survendu : le balisage n'améliore pas le positionnement. Google l'a répété : ce n'est pas un facteur de classement. L'effet réel passe par le taux de clic — un résultat avec étoiles et prix attire davantage qu'un lien bleu — et par l'éligibilité à certaines surfaces (Discover, Google for Jobs, carrousels). C'est un multiplicateur de visibilité existante, pas un créateur de positions.

Il faut aussi accepter une part d'aléa : baliser correctement rend éligible, Google décide ensuite d'afficher ou non l'enrichissement, requête par requête. Un balisage parfait sans résultat enrichi n'est pas forcément une erreur d'implémentation.

Implémenter proprement

Trois pratiques évitent l'essentiel des problèmes :

1. Générer le JSON-LD côté serveur, à partir des mêmes objets que le rendu de la page — jamais un bloc statique copié-collé qui divergera à la première mise à jour de prix.
2. Valider systématiquement : le test des résultats enrichis de Google pour l'éligibilité, le validateur Schema.org pour la syntaxe. Puis surveiller le rapport « Améliorations » de la Search Console, qui remonte les erreurs à l'échelle du site.
3. Rester sobre : baliser précisément trois types pertinents vaut mieux qu'empiler quinze types approximatifs. Les propriétés requises manquantes génèrent des avertissements qui, accumulés, dégradent la confiance dans votre balisage.

Ce qu'il faut retenir

Le JSON-LD est un investissement modeste au rendement réel mais borné : comptez quelques jours pour baliser proprement un site structuré, et attendez-en un meilleur taux de clic sur les requêtes où Google choisit d'afficher l'enrichissement — pas un bond de positions. Priorisez les types à effet visible pour votre activité, générez-les depuis vos données réelles, validez, et passez au chantier suivant.