Si vous pensez que le Markdown est un langage utile pour les moteurs de recherche, bonne chance pour travailler chez Google.
Et voilà pourquoi.
La scène se passe dans l’épisode 111 de Search Off the Record, le podcast de l’équipe Search Relations de Google.
John Mueller y mène un faux entretien d’embauche de son collègue Martin Splitt (comme il est taquin !), sur une question que les deux entendent à répétition : faut-il convertir son site en Markdown, ou publier un fichier llms.txt, pour faciliter la tâche des modèles de langage ?
Si on écoute John et Martin : ceux qui misent sur le Markdown pour bien se positionner « ne devraient peut-être pas l’utiliser ».
Mais ils disent aussi pourquoi.
Un des concepteurs de llms.txt explique que cela n’est pas fait pour faciliter l’indexation dans les moteurs de recherche
Le llms.txt est un fichier texte placé à la racine d’un site, qui liste ses pages jugées importantes pour qu’un modèle de langage les repère.
La proposition a été formulée en septembre 2024 par Jeremy Howard. Mueller affirme avoir échangé avec l’une des personnes à l’origine de cette proposition, sans la nommer, et en livre une lecture sévère : l’intention initiale n’était pas d’aider les moteurs ou les LLM (large language models, les modèles de langage) à découvrir un contenu, mais de servir un système qui connaît déjà le site et cherche à savoir ce qu’il contient.
Utiliser llms.txt comme levier de visibilité « n’a aucun sens », selon lui.
La raison est structurelle : un fichier rempli par le propriétaire d’un site revient à proclamer que l’on possède le meilleur site, avec la liste des pages que tout le monde devrait visiter.
Un système d’IA ne peut, par construction, accorder le moindre crédit à cette autodéclaration pour départager des sites concurrents. Le fichier n’expose aucun mécanisme de découverte. C’est exactement la limite que chez Neper on pointe depuis longtemps : si un site est correctement structuré, ce type de béquille devient inutile.
Le vrai langage à utiliser reste le HTML, y compris pour l’entraînement des IA
Le point de bascule du podcast est là.
Le HTML (HyperText Markup Language, le langage de balisage natif des pages web) n’est pas présenté comme une option héritée que l’IA rendrait caduque, mais comme la base.
John Mueller va jusqu’à le qualifier de chose primordiale à mettre en place pour être correctement exploré et indexé, et même pour qu’un système d’IA puisse réutiliser le contenu lors de son entraînement.
L’argument repose sur l’histoire de l’infrastructure :
- Les crawlers (robots qui parcourent et téléchargent les pages) traitent le HTML depuis des décennies.
- Convertir du HTML en texte brut est une opération triviale, prise en charge par de nombreuses bibliothèques logicielles.
- Aucun moteur ne pouvait se permettre d’ignorer le web existant pour n’ingérer que des fichiers Markdown.
Autrement dit, le problème que le Markdown prétend résoudre a déjà été réglé, et depuis longtemps.
Martin Splitt complète d’une remarque utile : le Markdown (format texte léger créé en 2004 par John Gruber et Aaron Swartz, qui balise titres, listes et liens avec quelques symboles) reste un excellent format de travail en amont.
Lui-même publie ses sites en Markdown depuis 2012, mais via un générateur de site statique qui produit du HTML. Personne ne s’en aperçoit, et c’est précisément le but: le Markdown est utile au milieu de la chaîne de production de l’information, pas à sa sortie vers le grand public.
Le « cruft » que l’on veut supprimer est justement un signal très très utile
L’attrait du Markdown auprès des praticiens de l’IA tient à sa sobriété : moins de balises, moins de tokens (unités de texte que traite un modèle, et qui pèsent dans son coût de calcul).
Un fichier HTML ouvert dans un éditeur de texte paraît illisible, saturé de balises et de styles, ce que les développeurs appellent le « cruft ».
Le Markdown, lui, isole le texte de ce contexte.
Le piège est que ce « superflu » apparent porte une part de l’information.
Quand on convertit une page en Markdown, on évacue la navigation, l’en-tête, le pied de page, les barres latérales, et donc le maillage interne (l’ensemble des liens qui relient les pages d’un même site). Or ces liens disent au moteur comment une page se rattache au reste du site, à quelles catégories elle appartient, quelles autres pages existent sans être citées dans le corps du texte.
John Mueller insiste : ces signaux sont critiques pour la découverte et l’exploration. Les retirer pour « faire propre » revient à amputer la structure même qui permet de comprendre un site. La lisibilité gagnée pour un humain pressé se paie en contexte perdu pour la machine, à rebours de l’effet recherché.
Les versions parallèles, ou le retour de la leçon du dynamic rendering
L’idée séduisante consiste à maintenir deux versions d’un contenu : une riche pour les visiteurs, une épurée en Markdown ou en texte pour les machines. Le podcast la démonte en convoquant un précédent connu des techniciens : le dynamic rendering (technique qui consistait à servir une version pré-rendue aux robots et une autre aux navigateurs).
Présenté un temps comme une solution de contournement acceptable, le dynamic rendering a surtout produit des problèmes :
- une dualité de versions coûteuse à maintenir,
- des bugs difficiles à diagnostiquer,
- un risque de divergence entre ce que voit l’utilisateur et ce que voit le robot.
Le Markdown parallèle rejoue ce scénario, avec une aggravation.
Si la version humaine casse, un visiteur le signale. Si la version réservée aux machines casse, personne ne s’en plaint, et beaucoup de systèmes automatisés ne détectent même pas la panne : ils trouvent du texte, en concluent que c’est ce qu’il fallait indexer, et avalent une page défectueuse.
La duplication multiplie la surface d’erreur tout en supprimant le mécanisme d’alerte. Pour Google, c’est une mauvaise affaire sur toute la ligne.
Découverte ou agent : deux problèmes que l’on confond
Le dernier apport du podcast est conceptuel, et c’est peut-être le plus utile pour clarifier le débat. Mueller sépare nettement deux situations que le discours ambiant mélange en permanence.
La première est la découverte : trouver, parmi des millions de sites, celui qui vend la photographie ou la paire de chaussures recherchée. Cette étape reste entièrement liée aux pages HTML classiques. Un fichier autodéclaratif n’y joue aucun rôle, puisqu’un système ne va pas interroger un site et cinq concurrents pour leur demander qui a la meilleure offre selon eux.
La seconde concerne un agent (programme autonome agissant pour le compte d’un utilisateur) déjà présent sur un site et cherchant à y accomplir une tâche. Là, des mécanismes comme llms.txt, divers fichiers JSON normalisés, ou le WebMCP (interface programmatique permettant à un agent de dialoguer avec un service) peuvent avoir une utilité. Mueller reconnaît qu’aucun de ces formats ne s’est encore imposé, et que l’unification prendra du temps. La nuance est décisive : ces propositions répondent à un problème d’exécution une fois sur le site, jamais à un problème de visibilité en amont.
Reste un cas où le Markdown garde une valeur sur le site lui-même : la documentation d’API destinée aux développeurs, qu’un agent comprend plus facilement en texte structuré. La bonne pratique consiste alors à conserver une source unique en Markdown qui génère le HTML, pour éviter toute divergence. Hors de ce périmètre, l’avis des deux ingénieurs tient en une phrase : pour le web grand public, du HTML normal, et rien d’autre comme préalable.
Pour aller plus loin
- Transcript officiel de l’épisode 111 de Search Off the Record (Google)
- Search Off the Record sur Spotify
- Google Exposes The Fundamental Flaw Of LLMs.txt (Search Engine Journal)
- Google: HTML The Standard For SEO, Not Markdown Files (Search Engine Roundtable)
- La proposition llms.txt, page de référence (llmstxt.org)
- How To Scrape A Website To Markdown For LLMs (Firecrawl), pour l’argument inverse de l’efficience en tokens