Données structurées et GEO : quels schémas poser en 2026

C’est le point de départ obligatoire, et il est presque toujours escamoté. Google a publié un guide dédié à l’optimisation pour la recherche par IA générative, mis à jour le 13 juillet 2026, avec une section entière consacrée aux idées reçues.

La formulation officielle tient en une ligne : les données structurées ne sont pas une obligation pour la recherche par IA générative, leur usage restant recommandé pour l’éligibilité aux résultats enrichis. Deux précisions techniques du même guide déplacent le vrai sujet. D’abord, les fonctionnalités d’IA de Google reposent sur les systèmes de classement existants, via une récupération de pages depuis l’index et une distribution ramifiée de requêtes qui génère plusieurs recherches associées à partir d’une seule question. Ensuite, pour figurer dans ces fonctionnalités, une page doit être indexée et éligible à un affichage avec extrait. Le levier principal reste donc l’exploration, l’indexation et la qualité du contenu.

Côté moteurs tiers, soyons précis sur ce qu’on ne sait pas : ni OpenAI, ni Perplexity, ni Anthropic ne publient de documentation établissant qu’un type schema.org déclenche une citation. C’est la même conclusion que dans les neuf leviers pour être cité par ChatGPT, où le balisage ne figure pas parmi les facteurs dominants. Toute affirmation contraire relève de l’hypothèse commerciale, pas de la source.

Quatre fonctions, toutes vérifiables, aucune magique. Lever l’ambiguïté d’identité : un nom commercial peut désigner trois entreprises, et une entité déclarée avec un identifiant stable ne laisse pas le moteur deviner laquelle il décrit. Déclarer la nature exacte de ce que vend la page : une prestation n’est pas un produit, un logiciel packagé n’est pas un service sur devis.

Ouvrir l’éligibilité aux résultats enrichis encore actifs, qui est l’usage que Google recommande explicitement et qui se mesure dans la Search Console. Et maintenir la cohérence entre pages : une entreprise décrite deux fois avec des valeurs divergentes est un signal négatif, qu’une définition unique réutilisée par référence élimine à la racine.

Ce que le balisage ne fait pas : il n’achète aucune citation, ne compense aucune absence de notoriété et ne sauve aucun contenu générique. C’est le même arbitrage que pour l’ensemble du GEO, détaillé dans le guide Generative Engine Optimization : la structure aide à être compris, elle ne remplace pas la légitimité.

L’entrée n’est pas la liste alphabétique des schémas, c’est votre arborescence. Pour chaque gabarit, une seule question : de quoi cette page parle-t-elle vraiment, et quelles informations y sont visibles ?

Le paysage a bougé, et une partie de la littérature française n’a pas suivi. Il faut séparer deux colonnes qu’on confond sans cesse : le gain d’affichage dans les résultats Google, et l’apport à la compréhension machine. Un schéma peut avoir perdu tout affichage enrichi et rester utile à la seconde.

Google a cessé d’afficher les résultats enrichis de type FAQ le 7 mai 2026. Le rapport dédié dans la Search Console et le support dans le test des résultats enrichis ont été retirés en juin 2026, le support dans l’API Search Console en août 2026. Le balisage reste valide au sens de Schema.org et ne déclenche aucune pénalité, mais il n’achète plus aucune surface d’affichage.

Trois conséquences pratiques. Ne retirez pas le balisage existant, il ne coûte rien et le format question-réponse reste une structure facile à interpréter pour une machine. N’ajoutez plus de FAQPage en espérant un gain visuel, il n’y en a plus. Et si vous suiviez des performances via ce rapport, vos séries historiques s’arrêtent à ces dates : changez d’indicateur avant de commenter une baisse qui n’en est pas une.

C’est ici que se joue la différence entre un site correctement décrit et une collection de blocs posés côte à côte. La plupart des guides s’arrêtent à la liste des types. Or ce sont les relations qui rendent un site interprétable.

Six propriétés portent l’essentiel du travail. `@id` est l’ancre de chaque entité : sans identifiant stable, aucune relation n’est possible et chaque page recrée un doublon de ce qu’elle voulait renforcer. `sameAs` recoupe votre identité avec des sources extérieures. `provider` et `publisher` rattachent prestations et contenus à votre entreprise. `mainEntityOfPage` désigne la page qui fait autorité sur une entité. `isPartOf` reconstitue l’arborescence. `about` relie les sujets traités à des références publiques.

De là découle la règle qui évite l’erreur la plus coûteuse : une entité, une seule définition. Votre entreprise est décrite complètement à un seul endroit, et partout ailleurs on pointe vers son identifiant. Le jour où deux pages décrivent le même nœud avec des valeurs différentes, le moteur ne choisit pas la bonne : il constate une incohérence. Le générateur de Schema Markup produit ce graphe relié plutôt que des blocs indépendants.

La quasi-totalité des exemples disponibles en ligne sont e-commerce, et ils poussent `Product` partout. Pour une agence, un cabinet, un prestataire, c’est une erreur de nature.

Le test est factuel, pas commercial. Si vous ne pouvez renseigner ni référence, ni marque, ni prix affiché, vous n’avez pas un produit : `Product` laissera vides les propriétés attendues et ne produira aucun affichage enrichi. `Service` décrit une prestation et se contente de `provider`, `serviceType`, `areaServed` et `audience`.

Restent les spécificités françaises, souvent négligées. Votre raison sociale balisée, votre SIREN et vos mentions légales doivent dire la même chose que votre `Organization`. Une incohérence entre le balisage et le bas de page est exactement ce qu’une machine repère sans effort.

Non, et c’est la distinction que presque personne ne fait. Un balisage franchit quatre niveaux successifs, et réussir les trois premiers ne dit rien du quatrième. La syntaxe se vérifie avec n’importe quel analyseur JSON. La conformité Schema.org se vérifie avec le Schema Markup Validator. L’éligibilité aux résultats enrichis se vérifie avec le test de Google. La sincérité sémantique ne se vérifie avec aucun outil.

Deux enseignements. Un test au vert prouve que votre code est lisible, jamais que votre page est bien décrite. Et le seul niveau qui produise un effet est aussi le seul qu’aucun outil ne mesure, ce qui explique pourquoi tant de sites techniquement irréprochables restent mal compris.

La conséquence est contre-intuitive : ajouter des balises peut dégrader votre situation. Poser un FAQPage sur une page sans questions, un `Product` sur une prestation ou un `AggregateRating` sans avis affichés introduit des déclarations que la page ne soutient pas. Les consignes générales de Google exigent que le contenu balisé soit visible par l’utilisateur ; y contrevenir expose à une action manuelle et dégrade la confiance accordée à l’ensemble du balisage du site.

Avant d’ajouter quoi que ce soit, relevez l’existant. Sur un site installé depuis quelque temps, il y a presque toujours plus de balisage que prévu, et souvent émis par plusieurs sources concurrentes.

Quatre étapes reproductibles. Extraire le JSON-LD brut d’un échantillon d’une page par gabarit, pas de toutes vos pages. Compter les entités dupliquées : cherchez combien de blocs `Organization` sortent sur une même page et si leurs valeurs coïncident, car deux définitions divergentes sont le symptôme le plus courant d’un empilement d’extensions. Comparer le déclaré au visible pour chaque propriété vérifiable — prix, note, horaires, auteur, date. Passer les deux validateurs officiels.

Si vos pages sont rendues en JavaScript, vérifiez le balisage tel que le robot le reçoit, pas tel que le navigateur l’affiche : l’outil d’inspection d’URL de la Search Console montre le HTML effectivement exploré. C’est le même réflexe que pour l’audit SEO technique en dix points, où l’écart entre rendu et exploré explique la moitié des anomalies.

Un déploiement réussi tient à l’ordre des étapes, pas à la quantité de code. Auditer l’existant avant toute écriture. Cartographier les gabarits, pas les pages : un site de 400 pages tient généralement sur six ou sept modèles. Trancher les identifiants de chaque entité une fois, et les consigner. Générer le JSON-LD dans la couche qui produit les gabarits, pour que chaque nouvelle page hérite du balisage sans intervention. Relier les entités par leurs identifiants plutôt que les redéfinir. Vérifier la correspondance entre déclaré et visible, gabarit par gabarit.

Le piège le plus répandu se trouve à la première étape. Sur un CMS installé de longue date, il est fréquent que plusieurs extensions émettent chacune leur schéma sans se coordonner. Le résultat n’est pas un balisage deux fois meilleur, c’est un site qui déclare deux entreprises différentes portant le même nom. Choisissez une source de génération unique et désactivez les autres.

Reste la maintenance, que personne n’anticipe. Un changement de marque, le départ d’un auteur, une refonte de l’offre ou une migration invalident une partie du graphe. Prévoyez une revue à chaque événement de ce type, sans quoi votre balisage décrira fidèlement l’entreprise que vous étiez. L’audit du site surveille en continu les écarts entre ce que vos pages déclarent et ce qu’elles montrent.

C’est la première chose qu’une direction demande, et le sous-thème le plus absent des articles positionnés sur la question. Posez un état initial avant de toucher au site : impressions, clics, pages citées, présence dans les réponses générées sur vos requêtes de marque. Constituez deux groupes de pages comparables, l’un que vous baliserez, l’autre laissé strictement en l’état. Ces pages témoins sont le cœur du dispositif : sans elles, vous ne séparerez jamais l’effet de votre chantier de celui d’une mise à jour d’algorithme.

Laissez passer un cycle d’exploration complet avant toute lecture, puis suivez quatre indicateurs : le taux de mention de votre marque, le taux de citation avec lien, les URL effectivement citées, et les erreurs d’attribution — les cas où un moteur vous prête une offre qui n’est pas la vôtre. Côté Google, l’instrument officiel a changé en 2026 : la Search Console expose désormais un rapport de performances dans les fonctionnalités d’IA générative, distinct du rapport web classique. Google met explicitement en garde contre les outils tiers qui prétendent utiliser des métriques internes : aucun n’y a accès.

Reste la limite intellectuelle, et il faut la poser franchement : corrélation n’est pas causalité. Une progression de vos citations doit aussi au contenu publié, aux liens obtenus et à la notoriété de votre marque. La formulation honnête est plus prudente et plus utile : le balisage lève des ambiguïtés mesurables, et se juge sur un écart entre pages comparables, jamais sur une courbe avant/après. Méfiez-vous des facteurs multiplicateurs du type « quatre fois plus de citations grâce au balisage » : exigez de savoir sur combien de pages, sur quelle durée, et comparé à quoi.

Trois natures d’erreurs bien différentes se cachent derrière le tableau ci-dessous. Une erreur de syntaxe casse le bloc et se voit immédiatement. Un avertissement signale une propriété recommandée manquante, sans rien casser. Une mauvaise modélisation sémantique passe tous les validateurs sans déclencher la moindre alerte : le code est correct, il décrit simplement autre chose que votre page.

C’est la troisième qui coûte le plus cher, précisément parce qu’aucun outil ne la signale. Un site peut afficher un balisage vert sur tous les validateurs et décrire une entreprise qui n’existe pas, un produit qu’il ne vend pas, un auteur que personne ne connaît.

Le sujet mérite d’être tranché, parce qu’il consomme un budget qui manque ailleurs. La recherche Google ignore les fichiers llms.txt, y compris pour ses fonctionnalités d’IA générative ; d’autres services les prennent en charge, ce qui reste une raison valable d’en maintenir un, et le guide llms.txt détaille quand ça vaut les dix minutes que ça coûte. Le découpage du contenu en micro-blocs est inutile côté Google, qui traite plusieurs sujets sur une même page. La réécriture de style pour les modèles l’est tout autant. La multiplication de mentions de marque fabriquées est inefficace et exposée aux systèmes anti-spam.

Ce qui reste utile est plus ennuyeux et plus solide : un HTML sémantique raisonnable, un contenu explorable, une bonne expérience de page, peu de duplication, et un balisage sincère.

S’ajoute une confusion de vocabulaire qui fausse la moitié des discussions. Un moteur de recherche classe des pages et renvoie une liste. Un moteur de réponse compose une réponse et cite ses sources, généralement en récupérant des pages au moment de la question. Un modèle conversationnel génère du texte à partir de ce qu’il a appris, sans nécessairement consulter le web. Le balisage aide à la compréhension dans les deux premiers cas et n’a aucune prise directe sur le troisième — une distinction posée dans le glossaire GEO, AEO et SEO.

Douze points à vérifier avant de considérer un chantier de balisage comme terminé. Aucun ne demande d’outil payant, et les quatre derniers sont ceux qu’on saute systématiquement.

Cet article est écrit et vérifié par l’équipe GetRerank. Les positions attribuées à Google proviennent de sa documentation officielle. Les exemples de graphe JSON-LD sont fournis comme point de départ à adapter, pas comme configuration universelle. Aucun résultat client n’est utilisé comme preuve, et aucun facteur multiplicateur n’est avancé sur l’effet du balisage.

Sources : Google Search Central, « Optimiser votre site Web pour les fonctionnalités d’IA générative dans la recherche Google », mis à jour le 13 juillet 2026 ; « Fonctionnalités d’IA et votre site Web », mis à jour le 31 décembre 2025 ; « Consignes générales concernant les données structurées » ; « Comprendre le fonctionnement des données structurées » ; documentation FAQPage et calendrier de retrait des résultats enrichis FAQ (affichage le 7 mai 2026, rapport et test en juin 2026, API en août 2026). Schema.org pour le vocabulaire de référence, le Schema Markup Validator et le test des résultats enrichis de Google pour la validation.