Ce qu'un modèle de langage lit vraiment de votre site

Par Aurélie Ducasteaux · 3 septembre 2026

Le test qui prend deux minutes

Avant toute considération de méthode, faites ceci sur votre page la plus importante.

Ouvrez-la, désactivez JavaScript dans les réglages de votre navigateur, rechargez. Puis affichez le code source de la page, celui qui est envoyé par le serveur, et cherchez-y une phrase de votre texte.

Trois résultats possibles. La phrase est là : votre contenu est lisible par tout le monde. La phrase n'est pas là mais la page s'affiche encore : le texte est injecté par du script, et une partie des robots ne le verra pas. La page est blanche : votre site n'existe que pour ceux qui exécutent du code.

C'est le contrôle le plus rentable de tout ce qui touche à la visibilité auprès des assistants, et il ne coûte rien.

Pourquoi ce test compte

Les moteurs de recherche classiques savent exécuter du JavaScript, avec un délai et de façon imparfaite. Les robots de collecte des assistants sont plus frustes : beaucoup lisent le HTML brut et s'arrêtent là.

La conséquence est directe. Un site construit entièrement côté navigateur peut être correctement indexé par Google et complètement invisible pour un assistant. Ce n'est pas une hypothèse : c'est ce que montre la comparaison entre ce que renvoie le serveur et ce que voit un visiteur.

La correction est technique et elle n'est pas anodine : rendre les pages côté serveur, ou pré-générer le HTML. Sur un site vitrine construit avec un outil classique, la question ne se pose pas. Sur une application monopage, c'est un chantier.

Ce qu'un robot voit d'une page

Une fois le HTML récupéré, la plupart des robots en extraient le texte et jettent le reste. Ce qui survit à cette extraction :

Le texte des paragraphes, des titres et des listes. C'est l'essentiel de ce qui est traité.

La hiérarchie des titres. Un `h1`, des `h2`, des `h3` correctement imbriqués donnent une carte du document. Une page où tous les titres sont des `div` mis en forme donne un bloc de texte sans structure.

Le texte des liens. L'intitulé, pas l'adresse. Un lien écrit « cliquez ici » n'apporte rien ; un lien écrit « le calcul du fond perdu » dit ce qu'il y a au bout.

Les tableaux, souvent mal. Un tableau HTML propre est convertible en texte structuré. Un tableau fait de blocs alignés en CSS se transforme en suite de mots sans relation.

Les attributs de remplacement des images. C'est tout ce qui subsiste d'une image. Une infographie sans description textuelle disparaît entièrement.

Ce qui ne survit pas : la mise en page, les couleurs, les contenus dépliables chargés par script, le texte présent uniquement dans une image, et tout ce qui exige une interaction.

La structure qui se cite bien

Puisqu'un assistant retient des extraits courts, la forme du texte détermine ce qui peut être extrait.

Une question en intertitre, une réponse juste en dessous. Le paragraphe qui suit un `h2` formulé comme une question est un candidat naturel à l'extraction, à condition qu'il se suffise à lui-même.

Des paragraphes autonomes. Un paragraphe qui commence par « Cela signifie que… » n'est pas extractible : il dépend du précédent. Le même paragraphe reformulé avec son sujet complet l'est.

Les faits en début de paragraphe. Un chiffre, une date, une valeur en tête de paragraphe est plus facilement associé à la question que le même chiffre en fin de développement.

Le vocabulaire complet, au moins une fois. Un modèle qui reformule la question ne cherche pas forcément vos mots. Écrire une fois la formulation complète, sans abréviation ni pronom, aide à la correspondance.

Cette liste décrit aussi, exactement, une page bien écrite pour un lecteur pressé. Ce n'est pas une coïncidence : les deux publics scannent.

Les données structurées : ce qu'elles font

Le balisage en JSON-LD décrit le contenu d'une page dans un format lisible par une machine : un article, son auteur, sa date, une question et sa réponse, une organisation, un lieu.

Ce que cela apporte, de façon vérifiable, c'est la compréhension par les moteurs classiques et l'éligibilité à certains affichages enrichis. C'est documenté par Google.

Ce que cela apporte auprès des assistants est moins établi, et je préfère l'écrire ainsi plutôt que d'affirmer. Ce qui est raisonnable de penser : un balisage `Person` avec un lien vers une page d'auteur, un balisage `Organization` avec une adresse, un balisage `FAQPage` avec des questions et des réponses fournissent des affirmations explicites que rien n'oblige à déduire du texte. Cela ne peut pas nuire, et cela coûte peu.

Une règle qui vaut dans tous les cas : ne balisez que ce qui est visible sur la page. Un balisage qui décrit autre chose que le contenu est une contradiction, et sur les moteurs classiques c'est une violation documentée des règles.

Le fichier llms.txt : ce qu'il est et ce qu'il n'est pas

C'est une proposition apparue en 2024 : un fichier texte à la racine du site, en Markdown, qui présente le site et liste ses pages importantes avec une phrase de description. L'idée est de fournir aux modèles une carte lisible plutôt que de leur laisser parcourir un site entier.

Ce qu'il faut en dire honnêtement : c'est une convention proposée par une communauté, pas un standard adopté, et aucun des grands fournisseurs d'assistants n'a documenté publiquement qu'il l'utilisait pour le classement ou la sélection de sources.

Faut-il en produire un ? Le coût est faible : un fichier de quelques dizaines de lignes, généré automatiquement à partir de la structure du site. Le bénéfice est incertain. Je le fais, en sachant que je le fais sans preuve, et je ne facturerais pas ce travail comme une prestation de visibilité.

Ce qui est certain, en revanche : le fichier de directives pour robots, lui, est bien lu, et il décide de qui a le droit de collecter. Les robots des assistants portent des noms distincts de ceux des moteurs classiques, et ils se traitent séparément. Vérifiez ce que votre fichier autorise : beaucoup de sites bloquent ou autorisent par défaut sans que personne n'ait tranché.

Le jumeau Markdown, une piste concrète

Une pratique qui se répand : publier, à côté de chaque page HTML, une version en Markdown à une adresse prévisible. Le texte y est propre, sans navigation, sans mise en forme, sans script.

L'intérêt n'est pas théorique. Un robot qui récupère cette version obtient exactement le contenu éditorial, sans avoir à démêler le HTML. Et un humain qui veut citer votre page en dispose aussi.

Le coût dépend entièrement de votre outil : nul si le site est généré, réel s'il faut l'ajouter à un système existant. Là encore, je le fais sans certitude d'effet, parce que le coût marginal est faible et que le résultat est propre.

Ce que je vérifierais en priorité

Cinq points, dans cet ordre, et ce sont tous des vérifications plutôt que des chantiers.

Le contenu est-il dans le HTML envoyé par le serveur. Les titres sont-ils de vrais titres, correctement imbriqués. Les images qui portent de l'information ont-elles une description textuelle. Le fichier de directives autorise-t-il ou bloque-t-il les robots des assistants, et est-ce une décision. Et les faits publiés portent-ils leur source et leur date.

Les quatre premiers sont techniques et se règlent une fois. Le cinquième est éditorial et se tient dans la durée, et c'est celui qui fait la différence.

Ce qui arrive aux tableaux, aux listes et aux encadrés

Trois formes de contenu se comportent très différemment à l'extraction, et cela oriente la façon d'écrire.

Les tableaux HTML propres survivent bien. Un `table` avec des en-têtes correctement déclarés se convertit en texte structuré où chaque valeur reste associée à sa colonne. C'est l'une des rares formes complexes qui passent intactes, et c'est un argument pour utiliser de vrais tableaux plutôt que des colonnes simulées en CSS.

Les listes à puces passent bien, à condition d'être de vraies listes. Une suite de paragraphes commençant par un tiret n'en est pas une pour une machine.

Les encadrés et les blocs mis en avant perdent leur statut. Un encadré qui contient l'information la plus importante de la page devient, à l'extraction, un paragraphe comme les autres, parfois placé n'importe où dans le flux. Si une information est essentielle, elle doit l'être par sa position dans le texte et par sa formulation, pas par sa mise en forme.

Les contenus dépliables dépendent de leur fabrication. Un élément `details` dont le contenu est dans le HTML est lu. Un panneau chargé par script au moment du clic ne l'est pas. La différence n'est pas visible à l'écran, elle l'est dans le code source.

L'ordre du contenu dans le code, qui n'est pas toujours celui de l'écran

Un piège discret, et il concerne beaucoup de sites récents.

Les grilles CSS permettent d'afficher un bloc à un endroit et de l'écrire à un autre dans le code. Visuellement, l'introduction est en haut ; dans le HTML, elle peut se trouver après trois blocs de navigation latérale et deux encarts.

Un robot qui lit le HTML linéairement reçoit donc un ordre différent de celui que voit un lecteur. Sur une page où la réponse principale se trouve dans le premier paragraphe visible mais au milieu du code, l'extraction se fait mal.

Le contrôle est le même que pour le reste : affichez le code source et lisez le texte dans l'ordre où il apparaît. S'il raconte quelque chose de cohérent, tout va bien. S'il commence par un menu de quarante liens et un pied de page, la structure du document mérite d'être revue.

C'est un vieux principe, antérieur de vingt ans aux assistants : le document doit avoir du sens sans sa feuille de style. Il redevient utile pour une raison nouvelle.