La couche invisible : ce que les moteurs de réponse lisent vraiment

Vous relisez le texte. Vous ne relisez pas ce que la machine va citer. Entre les deux, un écart s’installe, et il ne prévient jamais.

TL;DR

Un article publié envoie deux choses. Un texte, pour le lecteur. Et une couche que personne ne lit jamais à l’œil : Schema.org, Open Graph, hreflang, canonical, llms.txt. C’est cette seconde couche qui décide de la manière dont un moteur de réponse vous cite. Quand elle est produite après le texte, par un autre outil ou une autre personne, elle finit par décrire un article qui n’existe plus. La règle qui règle le problème tient en une ligne : la couche invisible doit sortir du même geste que le texte.

Que reçoit vraiment un moteur de réponse quand vous publiez un article ?

Beaucoup plus que ce que vous croyez lui envoyer.

Nous avons mesuré ce qu’une seule page d’article expose en production sur notre propre site. Dix-neuf objets Schema.org répartis en trois blocs JSON-LD. Cinq paires question-réponse balisées en FAQPage. Trois déclarations de langue, un canonical, quinze balises meta entre l’indexation et le partage social. Et deux fichiers d’exposition, llms.txt et llms-full.txt, dont le second dépasse les 120 000 caractères.

Le lecteur, lui, voit un titre, un texte et quelques liens.

Aucune de ces lignes n’est lue par un humain. Toutes sont lues par les modèles. C’est la distinction que nous posions dans notre article sur le SEO et le GEO : le SEO optimise l’accès à la page, le GEO optimise ce que la machine en fait. L’accès dépend du texte. L’usage dépend de cette couche.

Pourquoi cette couche dérive-t-elle sans que personne ne le voie ?

Parce que la produire est facile, et que la maintenir ne l’est pas.

Baliser un site en Schema.org est un travail borné. Une journée sur vingt pages, vérifiable, sous-traitable sans grand risque. Le piège n’est pas là. Il est dans le fait que ce travail arrive presque toujours après le texte : une étape suivante, un autre outil, souvent une autre personne, parfois trois semaines plus tard.

À partir de ce moment, deux objets existent en parallèle. L’article, qui continue de bouger en relecture. Et sa description machine, qui reste figée sur l’état d’avant.

Le titre du Schema garde la formulation de la v1. La FAQ balisée pose des questions que la version publiée ne traite plus. Le résumé Open Graph vend un angle abandonné au dernier arbitrage. Rien de tout cela ne se voit à l’écran, donc rien ne déclenche d’alerte. Le contenu paraît sain. Sa représentation, elle, a glissé.

C’est le même mécanisme que la validation floue, appliqué à un objet que personne n’a jamais pensé à relire. Sauf qu’ici, l’absence de relecture n’est même pas un oubli. Personne n’a jamais décidé que quelqu’un devait relire ça.

Les quatre dérives qui coûtent le plus cher

Elles ne se ressemblent pas, et elles ne coûtent pas la même chose.

Le hreflang qui pointe vers un index. Une page traduite existe, mais la balise annonce la page de listing du blog à la place. Vous dites aux moteurs que la version anglaise de votre article est un sommaire. C’est la plus coûteuse des quatre, et la plus discrète, parce qu’aucun outil grand public ne la remonte tant que les deux pages répondent en 200.

L’entité déclarée plusieurs fois. Trois blocs décrivent votre organisation, avec trois jeux de champs et aucun identifiant commun. Le moteur ne sait pas laquelle fait foi.

Le titre balisé qui n’est pas le titre publié. Un espace avant les deux-points qui saute à la construction de la chaîne, et le headline devient « SEO et GEO:comment optimiser… » quand la page affiche « SEO et GEO : comment optimiser… ». Minuscule. Sauf que le titre qu’une IA reprendra est celui-là.

Passons à la quatrième, qui est d’une autre nature.

Le contenu absent du fichier d’exposition. Un llms-full.txt généré une fois, jamais régénéré, qui agrège les pages clés et ignore le blog. Tout ce que vous publiez ensuite reste invisible pour un agent qui s’appuie sur ce fichier.

Ajoutez à ça le cas le plus embarrassant, et le plus fréquent : un chiffre de marque qui n’est pas le même selon la source. Le site dit onze, le fichier d’exposition dit treize. Les deux sont exposés. Le moteur choisira, et il ne vous demandera pas votre avis.

Qu’est-ce qui mérite vraiment une relecture humaine ?

Trois choses. Pas plus.

La meta description d’abord : c’est la seule phrase qu’un humain écrit pour la machine et que la machine réutilise telle quelle.

Les questions de la FAQ ensuite, parce que ce sont elles qui déclenchent la citation. Une question que personne ne pose ne sert à rien, même parfaitement balisée.

Le résumé du fichier d’exposition enfin, parce qu’il décide de ce qu’un agent retiendra de la page sans jamais l’ouvrir.

Le reste ne doit pas figurer dans une checklist humaine. Canonical, réciprocité des hreflang, unicité de l’entité, cohérence des miroirs Open Graph, dates : tout ça se vérifie par script, en quelques secondes, sans jugement.

Mettre ces éléments dans une checklist de relecture ne les fait pas vérifier. Ça garantit l’inverse. Une checklist de trente lignes dont vingt-sept sont mécaniques finit cochée d’un bloc, et les trois lignes qui demandaient un arbitrage passent avec les autres.

À quoi ressemble un contrôle qui sert à quelque chose ?

Il compare deux sources plutôt que d’inspecter une seule.

Vérifier que le headline du Schema existe ne prouve rien. Vérifier qu’il est identique au H1 rendu prouve quelque chose. Même logique pour la FAQ : la présence d’un bloc FAQPage ne dit rien, sa correspondance verbatim avec les sous-titres réellement affichés dit tout. Un hreflang se contrôle en ouvrant la cible et en vérifiant qu’elle pointe en retour.

Le contrôle se fait sur le HTML servi en production, pas sur le brouillon. Entre les deux, il y a un thème, un cache, parfois un plugin, et chacun peut réécrire ce que vous pensiez avoir publié.

Un détail de méthode qui a son importance : chercher une chaîne dans le HTML avec un simple grep produit un faux positif exactement dans le cas qu’il devait détecter, puisque le texte injecté par JavaScript est présent en clair dans le <script>. Il faut retirer les scripts et les styles avant de comparer quoi que ce soit, ou passer par un extracteur réel.

FAQ

Est-ce qu’un bon plugin SEO ne fait pas déjà tout ça ?

Il génère la couche, ce qui est la partie facile. Il ne vérifie pas qu’elle correspond encore au texte publié, parce qu’il n’a aucune idée de ce que le texte disait avant. La dérive vient du décalage entre deux versions, pas de l’absence de balisage.

À quelle fréquence faut-il régénérer un fichier llms.txt ?

À chaque publication et à chaque modification substantielle, pas selon un calendrier. Un fichier régénéré tous les trimestres décrit un site vieux de trois mois. Si la régénération n’est pas déclenchée par la publication elle-même, elle finira par ne plus être déclenchée du tout.

Le texte masqué en CSS est-il lu par les moteurs de réponse ?

Oui, et c’est contre-intuitif. Les principaux crawlers d’IA n’exécutent pas le JavaScript, donc aucune règle CSS ne s’applique de leur point de vue : un bloc en display:none leur arrive comme du texte normal. La conséquence pratique est qu’il faut vérifier ce qu’un site cache, pas seulement ce qu’il montre.

Faut-il traiter les posts LinkedIn de la même façon ?

Un post n’a pas de Schema, mais il a une couche invisible : la carte que la plateforme construit à partir de la page mise en lien. Les balises Open Graph de cette page font partie du livrable du post. Un lien dont l’aperçu affiche un résumé périmé, c’est un post à moitié écrit.

Par où commencer quand tout est à reprendre ?

Par le hreflang et le canonical, dans cet ordre. Ce sont les deux seuls éléments qui peuvent envoyer un moteur sur une autre page que la vôtre. Le reste dégrade la qualité de la citation, ceux-là en changent la destination.

Ce que ça change dans le workflow

Une seule règle, et elle est structurelle.

La couche invisible sort du même geste que le texte. Pas d’une étape suivante, pas d’un second outil, pas d’un rattrapage de fin de sprint. Le jour où un contenu est modifié, sa couche est régénérée avec lui, et un contrôle automatique compare les deux avant publication.

Ce qui reste humain se réduit alors à trois arbitrages, et ces trois-là méritent le temps qu’on leur donne. Tout le reste devient une condition de sortie, au même titre qu’un test qui passe avant un déploiement.

La question à se poser sur votre dernier article publié n’est pas de savoir si la FAQ a été écrite. C’est de savoir qui l’a relue.