Données structurées et schema.org : quoi poser en 2026

Google a publié le 15 mai 2026 un guide d’optimisation pour les fonctions d’IA générative, mis à jour le 10 juillet 2026, avec une section entière consacrée aux idées reçues. La formule tient en une ligne : les données structurées ne sont pas requises pour la recherche par IA générative et il n’existe aucun balisage schema.org spécial à ajouter ; il reste conseillé de les utiliser, car elles ouvrent l’éligibilité aux résultats enrichis.

Deux précisions du même guide déplacent le vrai sujet. Les fonctions d’IA de Google reposent sur les systèmes de classement existants : elles récupèrent des pages dans l’index et lancent plusieurs recherches associées à partir d’une seule question (le « query fan-out »). Et pour y figurer, 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, 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 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, pas de la source.

À quatre choses, toutes vérifiables. 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. Google écrit d’ailleurs que le balisage Organization l’aide à distinguer votre organisation des autres et peut influencer le logo affiché. Déclarer la nature exacte de ce que vend la page : une prestation n’est pas un produit, un logiciel n’est pas un service sur devis.

Ouvrir l’éligibilité aux résultats enrichis encore actifs, ce qui se mesure dans la Search Console. Et maintenir la cohérence entre pages : une entreprise décrite deux fois avec des valeurs différentes est un signal confus, qu’une définition unique réutilisée par référence élimine.

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 l’arbitrage de tout le Generative Engine Optimization : la structure aide à être compris, elle ne remplace pas la légitimité.

Partez de votre arborescence, pas de la liste des schémas. Pour chaque gabarit, une seule question : de quoi parle vraiment la page, et quelles informations y sont visibles ? Puis séparez deux colonnes qu’on confond sans cesse : le gain d’affichage dans Google, et l’aide à la compréhension. Un schéma peut avoir perdu tout affichage enrichi et rester utile à la seconde.

Google n’affiche plus les résultats enrichis FAQ depuis le 7 mai 2026. L’avis publié dans sa documentation FAQPage annonçait le retrait du rapport Search Console et du test des résultats enrichis en juin 2026, puis du support dans l’API Search Console en août 2026 ; la documentation elle-même a été retirée le 15 juin. Le balisage reste valide au sens de schema.org et ne déclenche aucune pénalité.

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

Le mouvement est général. Le journal des mises à jour de Google montre le retrait des résultats HowTo en septembre 2023, la fin du fil d’Ariane sur mobile en janvier 2025, puis l’abandon d’autres types moins utilisés fin 2025. Un schéma choisi pour son affichage peut perdre cet affichage du jour au lendemain ; un schéma choisi parce qu’il décrit la page reste juste.

Ce sont les relations qui rendent un site interprétable, pas la liste des types. 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. `sameAs` recoupe votre identité avec des profils extérieurs. `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. Quand 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 plupart des exemples en ligne viennent de l’e-commerce et poussent `Product` partout. Pour une agence, un cabinet ou un prestataire, c’est une erreur de nature. Le test est factuel : si vous ne pouvez renseigner ni référence, ni marque, ni prix affiché, vous n’avez pas un produit. `Service` décrit une prestation avec `provider`, `serviceType`, `areaServed` et `audience`.

En France, votre raison sociale, votre SIREN et vos mentions légales doivent dire la même chose que votre `Organization`. Un écart entre le balisage et le bas de page est exactement ce qu’une machine repère sans effort.

Non. 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, avec le Schema Markup Validator. L’éligibilité aux résultats enrichis, avec le test de Google. La fidélité du balisage à la page ne se vérifie avec aucun outil.

Un test au vert prouve que votre code est lisible, jamais que votre page est bien décrite. D’où la conséquence contre-intuitive : ajouter des balises peut dégrader votre situation. Un FAQPage sans questions affichées, un `Product` sur une prestation ou un `AggregateRating` sans avis visibles déclarent ce que la page ne montre pas. Les consignes générales de Google exigent que le contenu balisé soit visible ; y contrevenir expose à une action manuelle.

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, souvent émis par plusieurs sources. Extrayez le JSON-LD d’une page par gabarit. Comptez les blocs `Organization` sur une même page et comparez leurs valeurs : deux définitions divergentes sont le symptôme classique d’un empilement d’extensions. Comparez le déclaré au visible pour chaque propriété vérifiable (prix, note, horaires, auteur, date). Passez enfin les deux validateurs.

Si vos pages sont rendues en JavaScript, vérifiez le balisage tel que le robot le reçoit : l’outil d’inspection d’URL de la Search Console montre le HTML effectivement rendu. C’est le même réflexe que dans l’audit SEO technique en dix points, dont le balisage est l’un des contrôles.

L’ordre compte plus que la quantité de code. Auditer l’existant. Cartographier les gabarits, pas les pages : un site de plusieurs centaines de pages tient en général sur quelques modèles. Fixer une fois pour toutes l’identifiant de chaque entité. Générer le JSON-LD dans la couche qui produit les gabarits, pour que chaque nouvelle page hérite du balisage. Relier les entités par leurs identifiants plutôt que les redéfinir. Vérifier gabarit par gabarit que le déclaré correspond au visible.

Le piège le plus répandu : plusieurs extensions d’un même CMS qui émettent chacune leur schéma. Le résultat n’est pas un balisage deux fois meilleur, c’est un site qui déclare deux entreprises sous le même nom. Gardez une seule source de génération. Prévoyez enfin une revue à chaque changement de marque, d’offre, d’auteur ou à chaque migration ; l’audit du site signale en continu les écarts entre ce que vos pages déclarent et ce qu’elles montrent.

Relevez un état initial avant de toucher au site : impressions, clics, présence dans les réponses générées sur vos requêtes de marque. Constituez deux groupes de pages comparables, l’un balisé, l’autre laissé en l’état. Sans ces pages témoins, vous ne séparerez jamais l’effet de votre chantier de celui d’une mise à jour de Google.

Laissez passer un cycle d’exploration complet, puis suivez quatre indicateurs : le taux de mention de votre marque, le taux de citation avec lien, les URL citées, et les erreurs d’attribution (un moteur qui vous prête une offre qui n’est pas la vôtre). Côté Google, la Search Console propose depuis juin 2026 des rapports de performances dédiés à l’IA générative. Google met aussi en garde contre les outils tiers qui prétendent utiliser ses métriques internes : aucun n’y a accès.

Corrélation n’est pas causalité : une hausse des citations doit aussi au contenu publié, aux liens obtenus et à la notoriété. Le balisage se juge sur un écart entre pages comparables, jamais sur une courbe avant-après. Devant un « quatre fois plus de citations grâce au balisage », demandez sur combien de pages, sur quelle durée, et comparé à quoi.

Une erreur de syntaxe casse le bloc et se voit tout de suite. Un avertissement signale une propriété recommandée manquante, sans rien casser. Une mauvaise modélisation passe tous les validateurs : le code est correct, il décrit simplement autre chose que votre page. C’est la plus coûteuse, précisément parce qu’aucun outil ne la signale.

La recherche Google ignore les fichiers llms.txt, y compris pour ses fonctions d’IA ; d’autres outils les lisent, et le guide llms.txt dit qui exactement et quand ça vaut les dix minutes que ça coûte. Le découpage du contenu en micro-blocs, la réécriture de style pour les modèles et les mentions de marque fabriquées sont tout aussi inutiles. Ce qui reste utile est plus ennuyeux et plus solide : un HTML lisible, un contenu explorable, une bonne expérience de page, peu de duplication et un balisage fidèle.

Une confusion de vocabulaire fausse aussi les débats. Un moteur de recherche classe des pages. Un moteur de réponse compose une réponse et cite ses sources, en récupérant des pages au moment de la question. Un modèle conversationnel sans recherche génère du texte à partir de ce qu’il a appris. 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 SEO, GEO et AEO : les différences.

Douze points à vérifier avant de considérer le chantier terminé. Aucun ne demande d’outil payant, et les quatre derniers sont ceux qu’on saute le plus souvent.

Article mis à jour le 4 octobre 2026 : dates des documents Google corrigées, statut du fil d’Ariane, d’Article et d’Organization précisé, sources liées. Sources consultées le 4 octobre 2026 : Google, optimiser pour les fonctions d’IA générative (publié le 15 mai 2026, mis à jour le 10 juillet 2026) ; Google, fonctionnalités d’IA et votre site (10 décembre 2025) ; Google, consignes générales sur les données structurées ; Google, journal des mises à jour de la documentation (FAQ : 8 mai et 15 juin 2026 ; fil d’Ariane : 22 janvier 2025) ; Google, avis de retrait FAQPage, copie archivée du 10 mai 2026 ; Google, retrait des résultats HowTo (2023) ; Google, données structurées Article et Organization ; Google, rapports IA générative de la Search Console (3 juin 2026). Vocabulaire : schema.org ; validation : Schema Markup Validator et test des résultats enrichis.