JSON-LD : la syntaxe du balisage sémantique
Les données structurées se donnent pour mission de combler l’écart d’interprétation entre l’humain et la machine.
Le but : permettre aux moteurs de recherche de comprendre précisément ce que représente chaque information, en leur assignant un rôle explicite. Côté SEO, les opportunités de visibilité à saisir sont importantes.
Après de nombreuses tentatives de « normalisation », le format JSON-LD a remporté l’arbitrage technique. Toutefois, bien que ce format paraisse plus intuitif que les précédents, le JSON-LD peut dérouter les professionnels du référencement naturel.
Cette publication vise à démystifier le format de données JSON-LD, dont la syntaxe repose avant tout sur une poignée de règles simples.
Décortiquons ensemble la syntaxe, la structure et le vocabulaire du JSON-LD, son intégration depuis un CMS ainsi que les erreurs les plus fréquentes à éviter.
Sommaire :
Un format de données, pas un langage de programmation
Provenance et liens originels avec le SEO
Quelques malentendus lexicaux à éclairer
Le JSON-LD à l'heure des moteurs de réponse
Déclarer un script en JSON-LD
Anatomie d'un balisage JSON-LD
@context : rattacher le balisage au vocabulaire schema.org
@type : déclarer l'entité (Person, Article, FAQPage, etc.)
@id : identifier une entité de façon unique (et la relier à d'autres balisages)
Les propriétés (name, author, datePublished) : la traduction du contenu en paires clé-valeur
Exemple concret en JSON-LD, ligne par ligne
Article / BlogPosting : la base pour un article de blog
Person ou Organization : identifier l'auteur
FAQPage : transformer une FAQ en résultat enrichi
Niveau 1 : le plugin SEO : génération automatique et limites
Niveau 2 : l'éditeur de code du CMS : coller un bloc <script à la main>
Niveau 3 : le balisage sur mesure : quand et pourquoi sortir du cadre du plugin
Qu’est-ce que le JSON-LD concrètement ?
Le JSON-LD est un format de données, permettant de représenter des données liées de manière sémantique.
Cette dimension sémantique est caractéristique du format JSON-LD, qui ne se contente pas uniquement de « décrire une structure » mais aide également les moteurs de recherche à comprendre ce que signifient les informations présentes sur une page et comment elles sont liées entre elles.
Dans le domaine du SEO, le JSON-LD est notamment utilisé avec le vocabulaire partagé schema.org (un projet commun lancé par Google, Bing, Yahoo et Yandex) pour indiquer explicitement aux moteurs de recherche ce que représentent les informations présentes sur une page : un article, une personne, une entreprise, un produit, un événement, etc.
A ce stade, il paraît utile de distinguer deux éléments :
JSON-LD désigne le format technique utilisé pour organiser les données ;
Schema.org désigne le vocabulaire qui donne un sens aux types et aux propriétés.
Pour résumer : le JSON-LD cherche surtout à décrire des choses et leurs propriétés de manière standardisée. Il associe la syntaxe générale JSON avec les mécanismes permettant de représenter ces données comme des données liées (Linked Data).
Un format de données, pas un langage de programmation
Avant de poursuivre, une clarification s’impose : le JSON-LD n’est pas un langage de programmation au sens classique du terme.
Contrairement à un langage de programmation comme le PHP (qui exécute des étapes pour produire un résultat), le JSON-LD est un format « déclaratif » de description de données : il ne s’exécute pas, il se contente de décrire des relations entre des entités, des types ou des propriétés.
Le JSON-LD ne contient donc aucune instruction. C’est une structure statique qui décrit des données, à la manière d’un tableau Excel exporté en texte. Les experts évoquent l’idée parlante d’un « bloc de script autonome ».
Bon à savoir : l’absence d’exécution côté JSON-LD constitue un atout pour les domaines de la sécurité et de la maintenance.
En effet, des données JSON-LD mal formées peuvent empêcher leur lecture par un moteur de recherche. Mais elles ne peuvent pas « planter » une page, ni exécuter de code malveillant (contrairement à un script JavaScript classique).
Provenance et liens originels avec le SEO
Au début des années 2000, le Web contient déjà énormément d’informations, mais les machines comprennent très mal les relations entre ces informations.
Chaque page HTML est alors considérée par les moteurs comme un document contenant du texte et des balises, qui structurent à la fois l’organisation des éléments et leur présentation. Un bon début, mais du travail reste à accomplir pour encore mieux « qualifier » les données.
Le web sémantique corrige cette problématique, en permettant aux machines d’identifier ce que représentent les données, et comment elles sont reliées : c’est l’avènement des données structurées.
Alors que le format RDF cherche basiquement à décrire les données sous une forme structurée permettant d’identifier les entités, leurs propriétés et les relations qu’elles entretiennent, le JSON poursuit un autre but : représenter et échanger des données plus simplement.
Le JSON reprend la syntaxe littérale des objets développés en JavaScript (un langage qui existait déjà depuis plusieurs années), en épurant largement la dimension exécutable (fonctions) pour ne conserver que les éléments minimalistes (structure).
Le JSON peut contenir n’importe quelle donnée sans aucune obligation de partager un vocabulaire en commun. En d’autres termes la structure est libre, le sens est implicite, connu seulement du développeur qui l'a écrite.
Plus tard, le JSON-LD ajoute une contrainte : le rattachement à un vocabulaire partagé, via la propriété @context qui renvoie directement à un vocabulaire de référence (ou dictionnaire universel) : schema.org.
Important à retenir : dans le domaine du SEO moderne, JSON-LD et Schema.org forment un duo indissociable. Ils répondent à deux besoins distincts du traitement de l’information.
A la manière d’une bibliothèque de concepts, Schema.org définit les types d’objets et les propriétés qui leur sont associées et JSON-LD est le format d’implémentation technique recommandé par Google.
Quelques malentendus lexicaux à éclairer
Le format JSON-LD signifie « Java Script Object Notation for Linked Data ». Il emprunte donc logiquement la syntaxe d’écriture des objets travaillés avec le langage JavaScript (accolades, paires "clé": "valeur", etc.), mais la relation entre les deux s’arrête là : aucun code JavaScript n’est réellement exécuté.
Si vous pensiez devoir maîtriser impérativement le langage de programmation JavaScript pour écrire du JSON-LD, rassurez-vous : ce format est tout à fait accessible aux profils non techniques (rédacteurs, consultants SEO et indépendants).
Le JSON-LD, décisif à l’heure des moteurs de réponse
Contrairement à un moteur de recherche classique, qui explore une page et en restitue un lien accompagné d’un extrait, un moteur de réponse (ChatGPT, Perplexity, Google AI Overviews) doit extraire une information de source sûre pour le reformuler directement dans sa réponse, sans renvoyer systématiquement l’internaute vers la source.
Cette contrainte change la donne : ces systèmes s’appuient largement sur la génération augmentée par récupération (RAG) et sur des graphes de connaissances, deux mécanismes qui carburent aux entités explicites plutôt qu’au texte libre.
Or c’est précisément ce que fournit le JSON-LD : une entité identifiée (@id), typée (@type) et reliée à ses attributs, sans ambiguïté d’interprétation.
Un contenu balisé réduit donc le travail d’inférence de l’IA : elle n’a plus à deviner qui est l’auteur, quelle est la date de publication ou de quoi parle réellement la page, elle le lit directement.
C’est un facteur de fiabilité qui joue en faveur de la citation par ces mêmes moteurs, en plus de son rôle historique dans le référencement naturel classique.
Comment fonctionne le JSON-LD dans une page web
Comprendre le fonctionnement du JSON-LD impose de changer de perspective par rapport au langage HTML classique.
Le JSON-LD évolue à l’intérieur d’un « conteneur » dédié, un bloc distinct à l’écart du contenu visible (donc du code source HTML), sans interférer avec l’expérience de navigation de l’utilisateur.
L’intérêt est de transmettre des informations directement interprétables par les robots d’indexation, sans modifier l’apparence visuelle du site.
Le mécanisme d’intégration du JSON-LD se présente de la manière suivante :
Le conteneur doit être étanche : autrement dit, il doit être « encadré » par une balise spécifique qui isole le code sémantique du reste du document HTML.
Une grammaire stricte : un jeu de propriétés standardisées qui organisent les données sous la forme de paires clé-valeur.
Découvrons comment ce bloc d'information prend vie au cœur de votre code source et quelles règles régissent son organisation interne.
Déclarer un script en JSON-LD
Tout balisage JSON-LD est enveloppé dans une balise HTML <script> prenant la forme suivante :
Pour intégrer et déclarer des données structurées dans une page web, la balise HTML <script> doit être accompagnée d’un attribut type, prenant la valeur "application/ld+json".
Cet attribut indique au navigateur et aux robots des moteurs de recherche (comme Googlebot) que le texte situé à l’intérieur de cette balise n’est pas un script exécutable (au sens du langage dynamique JavaScript), mais un simple bloc de métadonnées sémantiques :
Un rôle de cloisonnement : l’attribut type indique au navigateur que ce bloc ne contient pas du code JavaScript à exécuter (comme un script d'animation ou un outil d'analyse d'audience), mais des données purement descriptives. Le navigateur va donc ignorer ce bloc pour tout ce qui relève du rendu visuel de la page.
Un rôle d'aiguillage : l’attribut type signale aux robots d'indexation qu'ils se trouvent face à du contenu structuré selon la norme JSON-LD, qu'ils peuvent analyser directement pour comprendre le sens de la page.
Note utile : vous pouvez placer ce bloc <script> aussi bien dans l'en-tête du document HTML (la balise <head>) que dans le corps de la page (la balise <body>). Google traite les deux emplacements de manière équivalente.
Google recommande le format JSON-LD et précise qu’il peut être placé dans l’un ou l’autre de ces emplacements, à condition que les données décrivent correctement le contenu visible de la page.
Anatomie d’un balisage JSON-LD :
Pour comprendre comment s’organise une donnée structurée, il faut analyser ses composants fondamentaux. Chaque bloc JSON-LD s’appuie sur une structure d’objets (délimités par des accolades) et sur des mots-clés préfixés par le symbole @ (appelés « mots réservés »).
Un bloc JSON-LD, aussi long soit-il, se construit à partir de quatre briques seulement. Trois d'entre elles portent un préfixe @ (ce sont des mots-clés réservés par la spécification JSON-LD elle-même, pas par schema.org) :
@context : définit le vocabulaire et la signification des propriétés. Le vocabulaire utilisé est généralement schema.org. C'est la brique qui transforme du JSON classique en JSON-LD « lié » au Web sémantique.
@type : indique la nature de l’entité décrite.
@id : identifie l’entité de manière unique. Elle permet de référencer cette entité ailleurs dans le même document ou dans d'autres documents, et de relier plusieurs entités entre elles.
La quatrième catégorie regroupe les propriétés proprement dites (celles qui varient selon le type d'entité décrite).
Le mot-clé @context : rattacher le balisage au vocabulaire schema.org
Le mot-clé @context est obligatoirement la première donnée, et la première ligne déclarée dans un bloc JSON-LD. Sa fonction est de définir le dictionnaire de référence (ou l'espace de nommage) que vous utilisez pour décrire votre contenu.
Sans cette ligne, les mots que vous utilisez par la suite (comme headline, author ou datePublished) n'auraient aucune signification universelle pour les machines.
En indiquant "@context": "[https://schema.org](https://schema.org)", vous établissez une convention standardisée : vous informez le robot d'exploration que l'intégralité des termes et concepts employés dans le bloc doivent être interprétés selon les définitions officielles de la plateforme schema.org.
Bon à savoir : dans le contexte du web sémantique originel (Linked Data), le mot-clé @context peut pointer vers des vocabulaires personnalisés ou multiples.
Pour un usage SEO courant, une seule pointant vers schema.org suffit dans l’immense majorité des cas (inutile de complexifier cette partie sans raison technique précise).
Le mot-clé @type : déclarer l’entité (Person, Article, FAQPage, etc.)
Une fois le dictionnaire défini, le mot-clé @type (à différencier de l’attribut vu précédemment) sert à préciser la nature principale de l'entité que vous êtes en train de décrire sur la page.
Il s'agit de répondre de manière univoque à la question : « De quoi parle cette page ? ». Ce choix n’est pas cosmétique : chaque type définit un ensemble de propriétés attendues et reconnues.
Pour vous aider, sachez que le vocabulaire schema.org met à disposition des centaines de types d'entités prédéfinis. Parmi les plus courants sur un site d'information ou un blog :
Article ou BlogPosting : pour un contenu rédactionnel. BlogPosting est un type plus spécifique appartenant à la famille des contenus éditoriaux.
Person : pour décrire un individu (un auteur, un expert).
Organization : pour une entreprise, une association ou une institution.
FAQPage : pour une foire aux questions.
Product : pour une fiche produit e-commerce.
Le mot-clé @id : identifier une entité de façon unique (et la relier à d’autres balisages)
La propriété @id attribue un identifiant unique et pérenne (généralement sous la forme d'une URL absolue ou d'une URL complétée par un fragment #) à une entité donnée.
Cette notion est essentielle dans la logique du web sémantique et des graphes de connaissances (Knowledge Graphs) :
Éviter les ambiguïtés et la duplication : Si vous mentionnez un auteur nommé "Jérôme HOST", le moteur de recherche a besoin de savoir s'il s'agit du même Jerôme HOST que celui décrit sur votre page /a-propos. En lui attribuant un @id fixe (ex. [https://mon-site.com/#jean-dupont](https://mon-site.com/#jean-dupont)), vous le désignez sans confusion possible.
Interconnecter les balisages : Le @id permet de lier des blocs de données entre eux sans devoir répéter toute l'information. Vous pouvez déclarer l'entité Organization de votre entreprise sur la page d'accueil avec son @id, puis simplement faire référence à cet @id sur toutes vos pages d'articles pour indiquer qui est l'éditeur du contenu.
Les propriétés (name, author, datePublished) : la traduction du contenu en paires clé-valeur
Après avoir défini le type d'entité, il vous reste à détailler ses caractéristiques au moyen de propriétés.
En JSON-LD, la saisie s'effectue sous forme de paires "clé": "valeur" :
La clé (à gauche) correspond au nom de la propriété tel qu'il est défini par schema.org (exemple : name, author, datePublished, description).
La valeur (à droite) contient la donnée réelle tirée de votre contenu (exemple : "4 février 2026" sous le format normalisé ISO 8601 "2026-02-04").
Les valeurs peuvent être de plusieurs types :
Une chaîne de texte : "name": "Guide du JSON-LD"
Une date ou une heure au format normalisé : "datePublished": "2026-02-04T09:00:00+01:00"
Un nombre ou un booléen : "price": "49.99"
Une autre entité imbriquée : la valeur d'une propriété peut elle-même être un objet contenant son propre @type et ses propres propriétés (par exemple, la propriété author qui contient une entité de @type: "Person").
Analyse pas à pas du code ci-dessus :
Ligne 1 : L'ouverture de la balise <script type="application/ld+json"> isole le bloc sémantique du reste du code HTML de la page.
Ligne 2 et 19 : Les accolades { } englobent l'ensemble de l'objet JSON-LD.
Ligne 3 : "@context": "[https://schema.org](https://schema.org)" déclare que le vocabulaire utilisé est celui du projet schema.org.
Ligne 4 : "@type": "BlogPosting" spécifie que le sujet principal de la page est un article publié sur un blog.
Ligne 5 : "@id": "..." attribue une adresse unique à cet article spécifique dans le graphe de données de votre site.
Lignes 6 et 7 : headline et description fournissent respectivement le titre principal et le résumé de l'article (ces valeurs doivent impérativement correspondre à ce que l'utilisateur peut lire sur la page).
Lignes 8 & 9 : datePublished et dateModified transmettent les horodatages précis de création et de mise à jour au format universel ISO 8601 (Année-Mois-JourTHeure:Minute:Seconde + fuseau horaire).
Lignes 10 à 15 : la propriété author n'est pas une simple chaîne de texte, mais un objet imbriqué. Nous y déclarons une nouvelle entité de type Person, possédant son propre @id, son nom (name) et l'URL de sa page profil (url).
Lignes 16 à 22 : la propriété publisher décrit l'entité éditrice (l'organisation). Elle contient à son tour un objet ImageObject pour spécifier l'emplacement exact du logo de l'entreprise.
Les types de balisage les plus utiles pour un blog
Bien qu’il existe plusieurs centaines de types d’entités répertoriés sur schema.org, une poignée couvre l'essentiel des besoins d’un site de contenu ou d’un blog professionnel.
Certains types décrivent le contenu principal, d’autres les personnes, l’organisation éditrice ou encore la structure de navigation.
L’objectif n’est pas de tout baliser aveuglément, mais de cibler les structures que les robots d’exploration exploitent en priorité.
Article / BlogPosting : la base pour un article de blog
Pour du contenu rédactionnel, deux types principaux s’offrent à vous :
Article : la classe générique pour tout texte journalistique ou informatif.
BlogPosting : un sous-type (une spécialisation) de Article, spécifiquement pensé pour les billets de blog.
Dans la hiérarchie de schema.org, BlogPosting hérite de toutes les propriétés de Article (et de NewsArticle). Utiliser BlogPosting sur un blog permet d'apporter un degré de précision supérieur aux moteurs de recherche.
Les propriétés indispensables à inclure pour ce type sont :
headline : le titre de l'article (limité idéalement à 110 caractères).
image : une ou plusieurs URL d'images illustrant le sujet principal (Google recommande des formats haute résolution en 16x9, 4x3 et 1x1).
datePublished et dateModified : la date de première publication et la date de dernière mise à jour.
author : l'entité (personne ou organisation) ayant rédigé le contenu.
Person ou Organization : identifier l’auteur
L'évaluation de la crédibilité des contenus par les moteurs de recherche s'appuie fortement sur le concept d'E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness ou Expérience, Expertise, Autorité et Confiance).
C’est ici que les types Person et Organization prennent toute leur dimension. En rattachant une entité Person à la propriété author d'un article, vous offrez aux algorithmes des repères explicites :
name : le nom complet de l'auteur.
jobTitle : le rôle ou l'intitulé du poste (ex. "Rédacteur web SEO").
sameAs : une liste d'URL externes pointant vers des profils de référence établis (compte LinkedIn, profil Twitter/X, page Wikipédia ou notice d'autorité).
La propriété sameAs est déterminante : elle indique au robot d'indexation que la personne décrite sur votre blog est la même entité que celle enregistrée sur d'autres plateformes reconnues.
FAQPage : transformer une FAQ en résultat enrichi
Le type FAQPage signale qu'une page contient une série de questions accompagnées de leurs réponses directes.
Structurellement, une FAQPage contient une propriété mainEntity, qui héberge une liste (array) d'objets de type Question. Chaque Question possède à son tour une propriété acceptedAnswer de type Answer.
Voici un exemple de structure imbriquée :
Remarque d'actualité SEO : Google a restreint l'affichage des résultats enrichis de type FAQ (Rich Results) dans ses pages de résultats (SERP).
Cet affichage est désormais réservé en priorité aux sites gouvernementaux et de santé faisant autorité.
Cependant, continuer d’intégrer du balisage FAQPage conserve toute son utilité pour la compréhension sémantique par les agents d’IA et les Moteurs de Réponse (LLM).
Intégrer le JSON-LD depuis un CMS : trois niveaux de complexité
L'implémentation technique du balisage varie selon les outils de gestion de contenu (CMS) utilisés et le niveau de contrôle souhaité.
Niveau 1 : la génération automatique via un plugin SEO
Avec des CMS populaires comme WordPress, l'installation d'une extension SEO (Rank Math, Yoast SEO, SEOPress) constitue la solution la plus accessible.
Les avantages :
Génération automatique des blocs <script type="application/ld+json"> à partir des champs natifs du CMS (titre, extrait, auteur, date, image à la une).
Gestion native des interconnexions d'entités (le plugin associe automatiquement l'auteur de l'article à l'organisation éditrice du site).
Les limites :
Rigidité : il est souvent difficile d'ajouter des propriétés personnalisées non prévues par l'interface du plugin.
Redondances : l'activation simultanée de plusieurs extensions peut entraîner l'injection de doublons de balisage contradictoires dans le code source.
Niveau 2 : l'éditeur de code du CMS : coller un bloc <script à la main>
Si vous utilisez des plateformes comme Webflow, Wix, Shopify ou les blocs HTML personnalisés de WordPress (Gutenberg), vous pouvez injecter directement votre propre code JSON-LD.
Voici la méthode :
Rédigez votre bloc JSON-LD dans un éditeur de texte ou générez-le via un outil dédié (comme Schema Markup Generator).
Insérez un élément de type "Code HTML personnalisé" ou utilisez la section réservée aux scripts d'en-tête (<head>) dans les paramètres de la page concernée.
Collez l'intégralité du script, balises <script> incluses.
Cette approche convient parfaitement pour des pages statiques (page d'accueil, page à propos, page de services), mais devient fastidieuse sur des centaines d'articles de blog en l'absence de variables dynamiques.
Il vous revient de choisir la bonne méthode selon la taille de vote site.
Niveau 3 : le balisage sur mesure : quand et pourquoi sortir du cadre du plugin
Le développement sur mesure (via du code personnalisé en PHP, JavaScript ou via un gestionnaire de balises comme Google Tag Manager) devient nécessaire dans plusieurs configurations avancées :
Architectures Headless ou sur-mesure : le site ne repose pas sur un CMS traditionnel muni de plugins SEO.
Balisage métier complexe : vous devez décrire des relations inter-entités très spécifiques non gérées par les extensions standards.
Données dynamiques issues d'une base de données : injection de caractéristiques produits ou d'indicateurs personnalisés recalculés en temps réel.
Conclusion générale
Le format JSON-LD s'est imposé comme le standard incontournable de la structuration sémantique des données sur le Web.
En isolant le sens de l'information de sa présentation visuelle HTML, il offre une méthode propre, sécurisée et évolutive pour communiquer directement avec les algorithmes d'indexation.
À l'ère où les moteurs de recherche évoluent vers des moteurs de réponse appuyés sur l'intelligence artificielle, fournir des données claires, reliées et identifiées par des identifiants uniques (@id) ne relève plus seulement de l'optimisation SEO traditionnelle : c’est la garantie que vos contenus et vos entités seront correctement interprétés, assimilés et cités par les systèmes d'information de demain.
FAQ – Tout savoir sur le JSON-LD
Le JSON-LD est-il un langage de programmation ?
Non. Le JSON-LD est un format de données statique, sans instruction ni exécution. Il emprunte uniquement la notation d'écriture des objets JavaScript (accolades, paires clé-valeur), sans qu'aucun code ne soit réellement exécuté par le navigateur.
Le JSON-LD est-il visible par les visiteurs d'un site ?
Non. Le balisage est placé dans un bloc <script type="application/ld+json">, ignoré par le navigateur pour l'affichage et invisible pour un visiteur qui consulte la page normalement. Il reste toutefois lisible dans le code source de la page.
Faut-il connaître le HTML pour intégrer du JSON-LD ?
Des notions de base suffisent (savoir où se trouve le <head> d'une page, savoir coller un bloc de code au bon endroit). La plupart des CMS et plugins SEO génèrent le balisage automatiquement, sans intervention manuelle sur le code.
Le JSON-LD a-t-il un impact direct sur le positionnement (ranking) dans Google ?
Non, l'intégration de données structurées JSON-LD n'est pas un facteur de classement direct dans l'algorithme de Google. Cependant, elle favorise l'obtention de résultats enrichis qui augmentent le taux de clic (CTR) dans les résultats de recherche. De plus, elle aide les moteurs à mieux comprendre le contexte de vos contenus.
Est-il important de travailler le JSON-LD à l'ère des moteurs de réponse, et pourquoi ?
Oui, et pour une raison précise, distincte du référencement classique. Un moteur de réponse (Google AI Overviews, ChatGPT Search, Perplexity) ne se contente pas de classer des liens : il extrait une information d'une page pour la reformuler dans une réponse directe.
Cette étape d'extraction automatisée est précisément celle où un contenu non balisé laisse une marge d'interprétation que l'IA doit combler par déduction, avec un risque d'erreur ou de rejet pur et simple de la source jugée trop incertaine.
Le JSON-LD réduit cette marge en assignant à chaque information un rôle explicite. Cependant, contrairement aux rich results, où l'effet du balisage est visible et mesurable dans une SERP, l'impact du JSON-LD sur les LLM reste indirect et probabiliste.
Aucun moteur de réponse ne garantit qu'un balisage correct entraîne une citation. Le JSON-LD n'est donc pas une condition suffisante pour être cité, mais il retire un obstacle réel : celui de l'ambiguïté d'interprétation, sur lequel butent en priorité les systèmes qui traitent des millions de pages sans validation humaine.
Faut-il choisir entre Microdonnées, RDFa et JSON-LD ?
JSON-LD est le format officiel recommandé par Google et la majorité des moteurs de recherche. Contrairement aux Microdonnées ou au RDFa qui nécessitent de modifier les balises HTML au cœur du texte visible, le JSON-LD est regroupé dans un bloc indépendant, ce qui facilite grandement sa maintenance.
Une page peut-elle contenir plusieurs balisages JSON-LD ?
Oui, rien ne l'interdit techniquement. C'est même courant (un balisage Article généré par un plugin, un balisage FAQPage ajouté manuellement). Le risque n'est pas la multiplicité en soi, mais la contradiction entre deux blocs décrivant la même entité avec des valeurs différentes.
Que se passe-t-il si le balisage JSON-LD décrit un contenu absent de la page visible ?
Google considère cette pratique comme un balisage trompeur, à rapprocher du cloaking. La conséquence documentée va du simple refus d'afficher le rich result concerné jusqu'à une action manuelle sur le site en cas de pratique flagrante et répétée.
Peut-on inventer ses propres types ou propriétés si schema.org n'a rien de précis ?
Techniquement le JSON écrit reste valide, mais le terme inventé n'est reconnu par aucun moteur de recherche : il est silencieusement ignoré. Mieux vaut chercher le type ou la propriété schema.org existante la plus proche, quitte à perdre en précision, que d'inventer un terme hors vocabulaire.
Comment savoir si mon balisage JSON-LD est correct avant de publier ?
Deux outils de référence : le Rich Results Test de Google (qui indique aussi l'éligibilité à un affichage enrichi) et le Schema Markup Validator de schema.org (qui vérifie la conformité au vocabulaire, indépendamment de Google). Aucun des deux ne garantit un affichage réel dans les résultats de recherche.
Que faire si un plugin SEO et un balisage manuel génèrent des informations contradictoires sur la même page ?
Il faut identifier lequel des deux balisages est prioritaire et supprimer l'autre plutôt que de les laisser coexister. Google ne documente pas de règle d'arbitrage garantie en cas de contradiction entre deux blocs décrivant la même entité (dans le doute, une vérification via Search Console est préférable à une hypothèse).
Faut-il coder son JSON-LD à la main ou passer systématiquement par un plugin ?
Un plugin SEO couvre correctement les cas standards (article de blog, page produit, FAQ générique). Un balisage manuel devient nécessaire dès que le besoin sort de ces cas standards (une entité Person détaillée avec @id réutilisé sur plusieurs pages, par exemple, ou un type que le plugin ne propose pas nativement).
