« Alexandre, les données structurées servent-elles encore à l’ère de l’IA ? »

Mis à jour le 22 octobre 2026

Depuis l’arrivée des moteurs d’IA, une idée circule beaucoup : « Ajoutez du schema.org partout, c’est ce que lisent les IA. » Certains outils vendent même des balisages « spécial ChatGPT ».

La réalité est plus nuancée, et plus intéressante. Les données structurées ne sont pas un passe-droit pour être cité. Mais bien utilisées, elles réduisent l’ambiguïté sur qui vous êtes et ce que vous proposez, ce qui est précisément ce dont un moteur a besoin pour vous recommander sans se tromper.

Cette page fait partie de mon dossier sur le robots.txt pour les IA et la lisibilité technique des sites. Elle explique ce que sont les données structurées, ce qu’en dit Google pour l’IA, quels types utiliser en priorité et comment les mettre en place proprement.

Par Alexandre Montenon, consultant SEO et GEO à Lyon

Les données structurées, c’est quoi ?

Une page web est écrite pour des humains. Un robot doit deviner que « 89 € » est un prix, que « Marie Dupont » est l’auteure, que « 12 rue de la République » est une adresse. Les données structurées lèvent cette ambiguïté en décrivant explicitement ces informations.

Google les définit comme un format standardisé pour fournir des informations sur une page et classer son contenu, en recommandant le plus souvent le format JSON-LD, et en demandant de ne pas baliser d’informations qui ne sont pas visibles par l’utilisateur.

Le vocabulaire utilisé est celui de schema.org, un projet commun aux grands moteurs de recherche. Il définit des centaines de types (Organization, LocalBusiness, Product, Article, Person, Event, FAQPage…) et leurs propriétés.

Ce que dit Google sur les données structurées et l’IA

La position de Google est sans ambiguïté. Dans son guide sur les fonctionnalités d’IA de la recherche, il écrit que les données structurées ne sont pas nécessaires pour la recherche générative et qu’aucun balisage schema.org particulier n’est requis, tout en recommandant de continuer à les utiliser dans le cadre d’une stratégie SEO globale.

Autrement formulé :

➭ il n’existe pas de balisage « IA » qui ferait apparaître votre site dans les Aperçus IA ou le mode IA ;

➭ les données structurées restent utiles pour le SEO classique et les résultats enrichis ;

➭ elles contribuent à rendre vos informations explicites, ce qui sert tous les systèmes qui lisent votre page.

Pourquoi elles restent utiles à l’ère de l’IA

Elles désambiguïsent votre entreprise

Le type Organization (ou LocalBusiness pour une activité locale, voir mon guide détaillé du schema Organization) déclare officiellement votre nom, votre logo, votre adresse, vos coordonnées et, via la propriété sameAs, vos profils officiels sur d’autres sites : LinkedIn, fiche Wikipédia, page Google, réseaux sociaux. C’est une carte d’identité lisible par les machines, qui aide à relier toutes les mentions de votre marque à la même entité (voir mon guide des entités SEO).

Elles précisent les informations sensibles

Prix, disponibilité, horaires, notes : ce sont exactement les informations que les clients demandent aux assistants, et celles qui posent le plus de problèmes d’erreur. Les déclarer explicitement, en cohérence avec le contenu visible, limite les risques de mauvaise interprétation.

Elles renforcent les signaux d’auteur

Les types Article et Person permettent d’indiquer qui a écrit un contenu, quand il a été publié et mis à jour. Ces informations contribuent à la crédibilité d’un contenu, pour les moteurs comme pour les lecteurs.

Elles servent d’autres plateformes

Bing, les réseaux sociaux, les agrégateurs et de nombreux outils lisent aussi schema.org. Un balisage propre profite à tout l’écosystème, pas seulement à Google.

Elles restent utiles pour les résultats enrichis

Étoiles d’avis sur les produits, prix, informations sur les événements, fil d’Ariane : plusieurs résultats enrichis dépendent toujours des données structurées. Google cite dans sa documentation des cas d’entreprises ayant mesuré une hausse du taux de clic sur les pages balisées, comme Rotten Tomatoes, qui fait état d’un taux de clic supérieur de 25 % sur ses pages enrichies.

Les types à mettre en place en priorité

À propos de FAQPage : Google n’affiche plus les FAQ enrichies dans ses résultats depuis mai 2026. Le balisage n’est pas nuisible et peut être lu par d’autres systèmes, mais il ne faut plus en attendre d’effet visuel dans Google.

Exemple : le balisage Organization d’une PME

Voici à quoi ressemble, dans les grandes lignes, un bloc JSON-LD Organization pour une entreprise fictive. Il se place dans le code de la page d’accueil, invisible pour le visiteur.

Sur WordPress, les extensions SEO comme Rank Math ou Yoast génèrent automatiquement une bonne partie de ce balisage, à condition de remplir correctement leurs réglages : nom de l’organisation, logo, profils sociaux, type d’activité.

Les règles à respecter

Baliser ce qui est visible

C’est la règle fondamentale de Google : ne pas déclarer dans le balisage une information que l’utilisateur ne voit pas sur la page. Un prix balisé à 49 € alors que la page affiche 59 €, des avis balisés qui n’apparaissent nulle part : c’est au mieux inutile, au pire sanctionné.

Rester cohérent partout

Le nom, l’adresse et le téléphone du balisage doivent être identiques à ceux de la page, de la fiche Google et des annuaires. Les données structurées amplifient la cohérence, mais aussi les incohérences.

Ne pas empiler les balisages contradictoires

Un thème qui génère un balisage, une extension SEO qui en génère un autre, un plugin d’avis qui en ajoute un troisième : on se retrouve avec plusieurs déclarations différentes de la même entreprise. Faites l’inventaire et gardez une seule source par type.

Tester

Google propose un outil de test des résultats enrichis, et schema.org un validateur. Après chaque modification importante, testez vos principaux modèles de pages.

Les erreurs les plus fréquentes

Un balisage Organization générique. Beaucoup de sites déclarent seulement un nom et une URL. Sans logo, adresse, coordonnées ni profils officiels, le balisage n’apporte presque rien.

Le mauvais type d’activité. Un cabinet d’avocats déclaré comme simple « Organization », un restaurant comme « LocalBusiness » générique. Schema.org propose des sous-types précis (LegalService, Restaurant, Dentist, Plumber…) : les utiliser rend la description bien plus parlante.

Des avis auto-proclamés. Baliser des notes et des avis que l’entreprise affiche sur son propre site à propos d’elle-même n’ouvre plus droit aux étoiles dans Google pour les types LocalBusiness et Organization. Ce balisage est inutile et peut même être considéré comme trompeur.

Des informations périmées. Le balisage est souvent configuré une fois, puis oublié. Une ancienne adresse ou un ancien numéro dans le JSON-LD crée exactement le type d’incohérence qui fait douter les moteurs.

Des pages produits sans prix ni disponibilité. Pour un site e-commerce, un balisage Product (voir mon guide du schema Product) sans offre (prix, devise, disponibilité) perd l’essentiel de son intérêt, alors que ce sont précisément les informations que les assistants d’achat recherchent.

Un audit annuel du balisage, page modèle par page modèle, suffit à éviter la plupart de ces problèmes.

Données structurées, llms.txt, contenu : qui fait quoi ?

Les données structurées s’inscrivent dans un ensemble plus large de signaux qui aident les machines à comprendre un site. Le contenu visible reste la source principale : c’est lui que les moteurs et les IA lisent et citent. Les données structurées précisent les informations clés de ce contenu. Le fichier llms.txt, lui, propose une présentation globale du site aux modèles de langage, sans effet démontré à ce jour.

Si vous devez prioriser, l’ordre est clair : d’abord un contenu clair et accessible aux robots, ensuite des données structurées propres sur les types essentiels, enfin les fichiers complémentaires.

Questions fréquentes sur les données structurées et l’IA