JSON-LD : ce que c’est, les types schema.org qui comptent encore, et comment l’implémenter

Qu’est-ce que le JSON-LD ?

JSON-LD (JavaScript Object Notation for Linked Data) est une façon de décrire le contenu d’une page de manière lisible par les machines, dans un seul bloc <script type="application/ld+json"> inséré dans le HTML de la page. Ce bloc est invisible pour les visiteurs. Les machines le lisent au lieu de deviner le sens de la page à partir de la mise en page et du style.

Trois qualités expliquent pourquoi il s’est imposé. Il est séparé : le balisage vit dans un seul bloc, pas disséminé dans le HTML comme les anciens formats microdata et RDFa, ce qui permet de le templater et de le maintenir sans toucher à la page visible. Il est explicite : le champ priceCurrency vaut EUR, sans place pour l’interprétation. Et c’est le format recommandé : Google désigne JSON-LD comme sa syntaxe préférée pour les données structurées depuis des années, et la quasi-totalité des outils actuels le suppose.

Qu’est-ce que schema.org, et quel est son rapport avec JSON-LD ?

Schema.org est le vocabulaire, JSON-LD est la grammaire. Schema.org est un dictionnaire commun de types (Product, Organization, Article, FAQPage…) et de propriétés (price, logo, author…) que les machines reconnaissent. Il a été fondé en 2011 par Google, Microsoft, Yahoo et Yandex, précisément pour que le web n’ait pas besoin d’un dialecte différent par moteur de recherche. JSON-LD est le format dans lequel vous écrivez ce vocabulaire.

Ce dictionnaire est immense (environ 800 types), et cette ampleur trompe. Seul un petit sous-ensemble déclenche une fonctionnalité visible dans les résultats de recherche, et rien n’oblige à utiliser le reste. Le vrai travail consiste à choisir la poignée de types que les machines exploitent réellement, et à les implémenter correctement.

Pourquoi les données structurées comptent-elles encore en 2026 ?

Parce que trois publics de machines différents les lisent, et chacun rapporte différemment.

Les résultats enrichis et les fiches marchands de Google. Un balisage correct rend les pages éligibles à des apparitions enrichies dans les résultats : extraits produit avec prix, disponibilité et étoiles, en-têtes d’articles, fils d’ariane, et, pour les boutiques, aux fiches marchands gratuites de Google, où les données produit (livraison et retours compris) sont tirées directement du balisage. Éligibilité, pas garantie : Google décide au cas par cas ce qu’il affiche. Mais les résultats avec données enrichies se distinguent visiblement, et cet avantage en taux de clic n’a jamais été retiré.

L’écosystème IA au sens large. Microsoft a déclaré publiquement, par la voix de Fabrice Canel, principal product manager, en mars 2025, que le balisage schema.org aide ses modèles à comprendre le contenu web, au bénéfice de Bing et Copilot. Google, de son côté, a affirmé en mai 2026 que les données structurées ne sont pas nécessaires pour les AI Overviews ni pour le mode IA. Une étude d’Ahrefs portant sur 1 885 pages ayant ajouté du JSON-LD n’a trouvé pratiquement aucun changement dans la fréquence à laquelle les systèmes d’IA les citaient. La synthèse honnête : les données structurées ne font pas citer par l’IA, c’est le contenu qui fait cela. Mais elles suppriment l’ambiguïté sur ce que disent vos pages, pour toute machine qui lit le HTML brut, la même couche que décrit notre article sur le fichier llms.txt. Lever l’ambiguïté est une assurance bon marché, pas un levier de croissance.

Le graphe de connaissances : les machines apprennent qui vous êtes. Un bloc Organization avec des liens sameAs pointant vers votre fiche Wikidata, votre page Wikipédia et vos profils officiels aide les machines à relier votre domaine à une entité unique et sans ambiguïté. Cette couche d’identité compte chaque année davantage : quand un assistant IA doit décider si « Example Store » mentionnée dans un forum est bien vous ou une homonyme, ce sont les données d’entité qui font foi. Nous détaillons ce mécanisme dans notre article sur le graphe de connaissances et Wikidata.

Quels types schema.org Google récompense-t-il encore, et lesquels sont retirés ?

La liste active est plus courte que ne l’admettent la plupart des guides, car Google a passé la période 2023–2026 à élaguer. Voici ce qui reste, et ce que cela rapporte :

Et le registre des retraits : le balisage qui ne déclenche plus rien de visible chez Google.

Deux précisions gardent ce tableau honnête. Le balisage retiré n’est pas pénalisé : Google l’ignore simplement, et les types non pris en charge ne produisent aucune erreur. Et retirer la récompense visuelle n’efface pas le sens du balisage : le balisage FAQPage continue d’étiqueter vos questions et réponses pour toute autre machine qui lit votre HTML. C’est pourquoi nous continuons de le recommander comme dernière étape après avoir écrit un contenu de questions-réponses authentique, un sujet que nous développons largement dans notre article sur le balisage FAQ.

Quels types une boutique en ligne doit-elle privilégier ?

Dans l’ordre du meilleur retour sur effort :

1. `Product` avec un `Offer` complet. Le cœur commercial : nom, image, description, marque, GTIN, prix, devise, disponibilité, plus les frais de livraison et la politique de retour (OfferShippingDetails, MerchantReturnPolicy), que les fiches marchands de Google affichent directement. Les boutiques dont les données produit sont balisées apparaissent sur des surfaces où les boutiques non balisées n’apparaissent tout simplement pas.
2. `Organization` avec `sameAs`. Un seul bloc, valable pour tout le site, qui relie votre nom, votre logo et vos profils officiels, y compris votre entité Wikidata si elle existe. C’est le travail le moins coûteux que vous puissiez faire pour une identité lisible par les machines.
3. `BreadcrumbList`. Trivial à mettre en place, affiché dans les résultats, et donne gratuitement aux machines la hiérarchie de votre site.
4. `FAQPage` sur les pages produit, livraison et service. Plus d’étoiles chez Google, mais cela étiquette votre contenu le plus citable pour l’écosystème élargi, et l’écrire vous oblige à produire un contenu en forme de réponse.
5. `Article` sur vos guides et articles de blog. Gains modestes, coût quasi nul une fois templaté.
6. `LocalBusiness`, si vous avez des magasins physiques. Horaires, adresse et coordonnées géographiques pour la recherche locale.

Comment mettre en œuvre le JSON-LD, en pratique ?

1. Auditez ce que vous avez déjà. La plupart des plateformes (Shopify, WooCommerce, Wix et les autres) émettent déjà du JSON-LD par défaut, et les extensions SEO en ajoutent. Passez vos pages clés dans validator.schema.org avant d’ajouter quoi que ce soit : l’erreur la plus courante en contexte professionnel, ce sont trois extensions qui émettent trois blocs Product contradictoires.
2. Travaillez par gabarit, pas page par page. Décidez quels types appartiennent à chaque gabarit de page (produit, catégorie, article, contact), et générez le balisage à partir des mêmes données qui affichent la page visible. Le JSON-LD écrit à la main devient obsolète ; le JSON-LD templaté ne le peut pas.
3. Reflétez exactement le contenu visible. Le balisage décrit ce qui est sur la page : le même prix, les mêmes affirmations. Baliser un contenu que les visiteurs ne peuvent pas voir viole les règles de Google, et c’est le chemin classique vers une action manuelle.
4. Reliez vos entités. Donnez au bloc Organization valable pour tout le site un @id, et référencez-le depuis vos produits (brand, publisher), afin que les machines voient un graphe connecté plutôt que des fragments isolés.
5. Validez deux fois. validator.schema.org vérifie le vocabulaire ; le Rich Results Test de Google vérifie l’éligibilité aux fonctionnalités propres à Google. Les deux outils sont gratuits et prennent quelques secondes.
6. Surveillez dans Search Console. Les rapports d’amélioration montrent quelles pages ont un balisage valide, invalide ou manquant, et vous alertent quand un changement de gabarit le casse silencieusement.
7. Gardez-le vivant. Le prix et la disponibilité changent en permanence, d’où l’importance de l’étape 2. Un bloc JSON-LD qui affirme un ancien prix est pire que l’absence de balisage : c’est une donnée fausse servie avec l’assurance d’une machine.

À quoi ressemble un JSON-LD correct ?

Deux exemples compacts et réalistes. D’abord, le bloc d’identité valable pour tout le site :

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example-store.com/#organization",
  "name": "Example Store",
  "url": "https://www.example-store.com/",
  "logo": "https://www.example-store.com/logo.png",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.instagram.com/examplestore",
    "https://www.linkedin.com/company/example-store"
  ]
}

Ensuite, une page produit avec les détails d’offre que les fiches marchands exploitent :

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ridgeline Trail Shoe",
  "image": "https://www.example-store.com/img/ridgeline-trail.jpg",
  "description": "Lightweight trail-running shoe with a 6 mm drop and a grippy outsole, built for wet terrain.",
  "brand": { "@type": "Brand", "name": "Ridgeline" },
  "gtin13": "5701234567890",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "214"
  },
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": "4.90", "currency": "EUR" },
      "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "DE" }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "DE",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

Ce qui rend ces exemples corrects, et non simplement décoratifs : chaque valeur reflète quelque chose de visible sur la page, la note existe uniquement parce que des avis sont affichés à cet endroit, et les identifiants (gtin13, @id) sont les points d’ancrage que d’autres systèmes utilisent pour reconnaître ce produit et cette entreprise à travers le web.

Quelles sont les erreurs JSON-LD les plus courantes ?

• Baliser un contenu absent de la page : notes aspirationnelles, FAQ invisibles. Violation des règles, risque de spam, bénéfice nul.
• Des doublons contradictoires, quand plateforme, extension et thème émettent tous du balisage. Les machines rencontrent trois prix différents et n’en croient aucun.
• Des données obsolètes : un balisage qui affirme le prix de la saison dernière, écrit à la main une fois, puis oublié.
• Des erreurs de syntaxe : une virgule superflue invalide silencieusement tout le bloc. C’est pourquoi la validation doit faire partie du flux de travail, pas seulement de la semaine du lancement.
• Un effort orphelin : implémenter des types exotiques que rien ne consomme, pendant que Product manque de GTIN et de données de livraison.
• Espérer un bonus de classement. Les données structurées ne sont pas un facteur de classement. Elles changent votre apparence et ce que savent les machines, pas votre position.

Pour conclure

Les données structurées en 2026 demandent plus de sang-froid que le battage médiatique qui les entoure. Google a retiré les étoiles FAQ, les panneaux how-to et une demi-douzaine d’autres récompenses. Pourtant, le balisage produit alimente une vraie visibilité dans les fiches marchands, le balisage d’entité nourrit le graphe de connaissances, et chaque robot d’IA qui lit votre HTML brut rencontre votre JSON-LD avant votre texte. Dans notre étude de 99 boutiques en ligne norvégiennes (en norvégien) menée en août 2026, 56 % des sites lisibles n’avaient aucun JSON-LD, et 12 boutiques sur 99 n’avaient ni données structurées, ni entité Wikidata, ni aucun signal pour les agents : invisibles pour les machines sur toutes les mesures que nous testons.

L’opportunité est la même que celle qui traverse tout ce que nous publions, et que nous détaillons dans notre guide SEO, AEO, GEO et AIO : le plancher est vide. Écrivez des pages qui méritent d’être décrites, puis décrivez-les avec précision : données produit complètes, identité reliée, balisage qui reflète ce qui est visible. Cela ne fera pas aimer votre marque par les machines. Cela garantit simplement qu’en vous lisant, elles vous comprennent correctement, et pour l’instant, cela seul vous place devant la moitié du marché.