Donnes structurées, Schema.org, JSON-LD, ...
Comment y voir clair dans ces notions proches en GEO ?
Quand on parle d’optimisation pour les moteurs IA (ChatGPT, Gemini, Perplexity, Claude, …), trois termes reviennent en boucle : données structurées, Schema.org et JSON-LD. Ils sont souvent utilisés comme des synonymes. Ce n’est pas le cas : ils appartiennent à trois niveaux différents qu’on empile sans toujours le préciser. Comprendre cette hiérarchie permet d’agir au bon niveau et d’éviter de passer pour un prestataire qui confond l’outil et l’objectif.
Les données structurées : le concept de base
« Données structurées » (structured data) est le terme parapluie. L’idée est simple : enrichir une page web de métadonnées lisibles par les machines qui décrivent explicitement son contenu. Plutôt que de laisser Google ou un LLM inférer ce qu’est votre entreprise, vous lui dites explicitement : « ceci est une entreprise belge de services », « ce texte est une FAQ », « ce prestataire est actif depuis 2007 ».
Les données structurées ne sont ni une technologie ni un fichier : c’est l’intention. Tout le reste — vocabulaire, format, syntaxe — n’est que la façon de concrétiser cette intention.
Schema.org : le dictionnaire commun
Pour que vos métadonnées soient comprises par Google, Bing, OpenAI et les autres, il faut parler la même langue. Ce dictionnaire commun s’appelle Schema.org. Co-géré depuis 2011 par Google, Microsoft, Yahoo et Yandex, il définit l’ensemble des types et propriétés disponibles : Organization, Service, FAQPage, areaServed, foundingDate, provider…
D’autres vocabulaires ont existé comme Dublin Core, FOAF, GoodRelations, l’ancien Data-Vocabulary.org de Google (abandonné en 2020) mais pour le SEO et le GEO en 2025, Schema.org est le seul vocabulaire pertinent.
JSON-LD : la syntaxe recommandée
Une fois qu’on sait quoi décrire (les données structurées) et avec quels mots (Schema.org), il reste à choisir comment l’écrire dans le code de la page. Trois formats coexistent :
- JSON-LD : un bloc
<script type="application/ld+json">inséré dans le HTML, indépendant du contenu visible. Format recommandé par Google, le plus propre à maintenir. - Microdata : des attributs HTML (
itemscope,itemtype,itemprop) imbriqués directement dans les balises. Plus difficile à maintenir, source d’erreurs orphelines, notamment générées automatiquement par Elementor. - RDFa : même logique que Microdata, avec une syntaxe issue du web sémantique (
typeof,property). Rare en pratique.
Les trois formats expriment le même vocabulaire Schema.org. Le choix du format ne change pas ce qui est dit, seulement sous quelle forme. Pour un site WordPress/Elementor, le JSON-LD inséré dans un widget HTML est la solution la plus robuste.
En résumé : La formule à retenir
Je fais des données structurées (concept) en utilisant le vocabulaire Schema.org (dictionnaire) sérialisé en JSON-LD (syntaxe).
Les trois termes ne sont pas interchangeables : le premier désigne l’objectif, le deuxième le référentiel, le troisième l’implémentation technique.
Les quatre briques clés d'un bloc JSON-LD
À l’intérieur de chaque bloc JSON-LD, quatre propriétés structurent l’information :
@context: déclare le vocabulaire utilisé ("https://schema.org"). Sans lui, le parser ne sait pas à quoi se référer.@type: précise le type d’entité décrit (Service,FAQPage,Organization…).@id: identifiant unique de l’entité. Il permet de référencer une entité sans la redéfinir : par exemple, pointer vers l’organisation mère depuis une page de service sans dupliquer ses propriétés.@graph: tableau regroupant plusieurs entités liées dans un seul bloc. C’est l’approche adoptée par Yoast SEO.
Pourquoi ça compte en GEO ?
Il faut distinguer ce qui est établi de ce qui est hypothétique.
En SEO classique, le lien est documenté : les données structurées alimentent les rich results Google (FAQ, avis, fil d’Ariane, produits). L’impact est mesurable.
En GEO, la situation est plus nuancée. Aucun modèle (OpenAI, Anthropic, Google, Perplexity) n’a publiquement confirmé exploiter le JSON-LD comme signal de citation prioritaire. Ce qu’on peut avancer raisonnablement :
- Le JSON-LD désambiguïse les entités : il permet à un modèle d’extraire des faits précis plutôt que de les inférer depuis du texte ambigu.
- Il rend l’information redondante et non ambiguë, ce qui facilite son extraction.
- Mais la majorité des LLM lisent avant tout le contenu textuel rendu. Un contenu bien rédigé reste le levier dominant.
En GEO, les données structurées sont un complément de désambiguïsation : utile, recommandé, mais pas suffisant seul. Un bloc JSON-LD sans contenu textuel solide ne produira pas de citation.
Ce que ça change concrètement pour votre site
- Ai-je décrit toutes mes entités clés ? — Votre organisation, chacun de vos services, votre zone géographique, votre date de création. Si ces informations ne sont déclarées nulle part en JSON-LD, Google et les LLM les infèrent — parfois mal.
- Mon contenu visible est-il exploitable ? — Des réponses directes, des définitions explicites, des FAQ bien formulées. C’est ce que les IA génératives citent.
- Mes entités sont-elles cohérentes entre elles ? — Même
@idpour votre organisation sur toutes vos pages,sameAspointant vers Wikidata, Google Business Profile, LinkedIn. La cohérence du graphe d’entités construit la confiance à long terme.
Matixis accompagne les entreprises belges et francophones sur ces trois dimensions — de l’audit de visibilité IA à l’implémentation technique des données structurées. Parlons-en.
Votre marque est-elle déjà citée par les IA ?
La plupart des entreprises belges ne le savent pas :
un audit de visibilité IA prend 48h et vous donne une réponse précise.