JSON-LD pour Google vs RAG : la distinction que personne n'explique

Le JSON-LD est souvent présenté comme la solution pour apparaître dans ChatGPT, Perplexity ou Gemini. La réponse courte : non, pas directement. Une étude académique récente montre que le JSON-LD seul n'apporte que +0,27 sur une échelle de 1 à 5 dans les systèmes RAG : un gain statistiquement significatif mais pratiquement négligeable.

Ce chiffre surprend. Mais il s'explique par une réalité architecturale que beaucoup ignorent : il y a deux mondes distincts dans lesquels votre JSON-LD est lu (ou pas lu) de façon radicalement différente.

Lorsque vous publiez du JSON-LD sur votre page, ce n'est pas un signal universel qui se propage de la même manière vers tous les systèmes. La façon dont ce balisage est traité dépend entièrement de l'architecture du système qui ingère votre contenu. Et ces architectures sont fondamentalement différentes.

Google a développé depuis 2011 (lancement de Schema.org) une infrastructure spécifique pour traiter les données structurées. Lorsque Googlebot crawle votre page, il ne se contente pas de l'indexer comme un bloc de texte. Il exécute un second processus : l'extraction des balises <script type="application/ld+json">.

Ce JSON-LD est traité de façon indépendante du reste du contenu de la page. Il est validé (est-ce que le type Schema.org est cohérent ?), structuré (quelles sont les propriétés de cette entité ?), puis indexé dans le Knowledge Graph de Google. C'est ce pipeline qui alimente les knowledge panels, les rich snippets (étoiles, prix, disponibilités), les FAQ enrichies, et le graphe d'entités qui fait qu'une marque ou une personne est "comprise" par Google au-delà du simple texte.

C'est pourquoi le JSON-LD reste utile pour le SEO classique. Non pas parce que Googlebot "lit mieux" votre contenu grâce à lui, mais parce qu'il alimente un système d'indexation totalement différent, conçu spécifiquement pour exploiter ces métadonnées structurées.

Les systèmes RAG (Retrieval-Augmented Generation) qui alimentent ChatGPT, Perplexity, les assistants agentiques, ou n'importe quel pipeline LangChain/LlamaIndex fonctionnent selon une logique radicalement différente : ils traitent votre page web comme un seul bloc de texte.

Concrètement, voici ce qui se passe :

1. La page est récupérée en HTML brut (ou converti en texte)
2. Le texte est découpé en chunks de ~500 à 2 000 tokens
3. Chaque chunk est converti en vecteur d'embedding (dense + sparse)
4. La requête de l'utilisateur est vectorisée de la même façon
5. Les chunks les plus proches vectoriellement sont passés au LLM comme contexte

Dans ce pipeline, votre bloc <script type="application/ld+json"> est du texte comme un autre. Pire : il est généralement placé en fin de <head> ou en fin de <body> : soit après les ~20 000 premiers caractères que le système indexe. L'étude WordLift le confirme avec des chiffres précis : dans leur corpus, 82% des pages HTML brutes et 88% des pages HTML+JSON-LD dépassent la limite d'embedding de 20 000 caractères. Le JSON-LD est positionné en médiane à 18 510 caractères : exactement à la limite de troncature.

Résultat : le gain de précision apporté par le JSON-LD dans un RAG flat-text est de +0,27 sur une échelle de 1 à 5, soit un effet de taille d=0,18 : statistiquement significatif dans l'étude (349 requêtes, p=0,024) mais pratiquement négligeable. Pas de quoi justifier une stratégie GEO basée sur le JSON-LD.

Voici les résultats complets de l'étude des 7 conditions testées sur 2 443 évaluations :

Deux observations importantes :

1. C3 et C6 sont presque identiques (4,69 vs 4,70). Une Enhanced Page bien structurée en RAG standard donne le même résultat qu'une Enhanced Page avec un agent RAG multi-hop. L'agent ne fait pas de miracle sur du contenu déjà bien structuré · il compense surtout les mauvais formats.

2. Le RAG agentique sur HTML brut (C4 : 4,36) dépasse le RAG standard sur HTML+JSON-LD (C2 : 3,89). Autrement dit, un agent bien configuré sur du contenu non structuré bat du JSON-LD dans un RAG standard. Ce n'est pas la technologie, c'est l'architecture de retrieval qui compte.

La véritable découverte de l'étude, c'est ce que contient concrètement une "Enhanced Entity Page" pour obtenir +29,6% de précision. Ce n'est pas de la magie de format. C'est de l'information matérialisée en langage naturel.

Voici les 5 composants d'une Enhanced Entity Page selon l'étude :

Le gain ne vient donc pas d'une présentation différente des mêmes données, mais de la matérialisation des données liées. En HTML brut (C1), votre page contient des références à des entités liées sous forme d'URI opaques que le LLM ne peut pas interpréter sans les déréférencer. L'Enhanced Page résout ces liens et expose les données connectées en texte lisible · créant un document auto-suffisant.

La distinction fondamentale est la suivante : un LLM comprend ce que tu écris explicitement, pas ce que tu "structures implicitement". Le JSON-LD est une structure implicite · lisible par un parseur, invisible pour un embedding. L'Enhanced Entity Page, c'est cette même logique entité relations contexte traduite en phrases claires et directes.

1. Écrire des phrases relationnelles (le plus important)

C'est le changement le plus impactant. Les LLM s'appuient sur les relations explicites entre entités pour construire leurs réponses.

2. Répéter intelligemment les entités

Un LLM traite chaque phrase de façon relativement indépendante lors du retrieval. Les pronoms et références anaphoriques créent des ambiguïtés dans les embeddings.

3. Transformer le JSON-LD en texte

Si vous avez du JSON-LD, sa valeur pour les RAG n'existe que si l'information est aussi présente en langage naturel.

4. Structurer la page comme une base de connaissances

Organisez l'information en blocs thématiques clairs. Cela crée une densité d'information exploitable par les chunks d'embedding.

5. Utiliser des formats LLM-friendly

Certains formats sont nativement mieux compris et plus facilement retrievés par les systèmes RAG.

6. Créer des liens sémantiques en texte

Les relations entre entités doivent être écrites explicitement, pas juste liées via des balises HTML ou JSON-LD.

Si on résume les implications pratiques de cette étude :

Gardez le JSON-LD pour Google. Il continue d'alimenter les rich snippets, knowledge panels et le graphe d'entités de Google. Ne le supprimez pas. Mais ne vous attendez pas à ce qu'il améliore votre visibilité dans ChatGPT ou Perplexity.

Pour les RAG, la structure visible compte. Ce qui booste la précision des LLMs, c'est du contenu que le LLM peut lire et extraire directement : résumés factuels en langage naturel, liens visibles et labellisés, navigation claire, contenu auto-suffisant. Pas des métadonnées cachées dans un script.

Les fichiers .md et les balises alternate vont dans le bon sens. Servir une version Markdown de votre contenu · comme le fait rankit.fr avec <link rel="alternate" type="text/markdown">, c'est exactement ce principe appliqué : rendre votre contenu directement lisible par les agents qui préfèrent du texte structuré propre au HTML parsé.

Les agents RAG compensent les mauvais formats, ils n'amplifient pas les bons. Si votre contenu est bien structuré (Enhanced Page), l'agent agentique n'apporte rien de plus (+0,01 de C3 à C6). Si votre contenu est mal structuré (HTML brut), l'agent agentique compense (+0,74 de C1 à C4). Investissez donc dans la structure du contenu plutôt que dans des configurations d'agents complexes.

L'étude WordLift (arXiv:2603.10700) apporte des données empiriques solides sur une question que le secteur GEO traitait encore de façon intuitive. Elle confirme que le JSON-LD n'est pas une solution miracle pour ChatGPT, mais simplifions : il n'est pas globalement inutile non plus. Ce sont deux systèmes différents avec deux modes d'ingestion différents.

La réalité est plus nuancée et plus utile : le JSON-LD reste indispensable pour le SEO classique (Google, Bing, rich results) et ne sert à rien dans les RAG flat-text. Ce sont deux systèmes différents avec deux modes d'ingestion différents. La stratégie qui émerge de cette étude n'est pas "moins de JSON-LD" mais "JSON-LD + contenu structuré visible" : les deux couches servant des pipelines distincts.

Ce que l'étude ne tranche pas, et que les prochains 12 mois de déploiement de Google AI Mode vont clarifier, c'est si Google va progressivement adopter la même architecture flat-text pour son RAG interne, ou s'il continuera à exploiter son avantage de parseur dédié. Si le premier scénario se confirme, la frontière entre les deux mondes décrits ici pourrait se réduire rapidement.

À propos de l'auteur

Frédéric Jézégou Consultant SEO & GEO

Fondateur de Rankit.fr · Dicocitations SASU · Pornichet (44)

Freelance SEO Senior, 20 ans d'expérience. J'aide les PME à renforcer leur visibilité sur Google tout en intégrant les nouveaux enjeux liés aux moteurs IA. Mon expertise couvre à la fois le SEO classique et les stratégies émergentes de présence dans les IA (GEO), que j'exploite de manière complémentaire selon les objectifs. Approche basée sur des données réelles : logs serveur, tests en compétition, audits de sites.

LinkedIn GEO & IA Search Me contacter