Arrêtez d'optimiser votre site pour les humains (ils ne le lisent plus)

Je suis étudiant en informatique. Je bricole des projets des fois et en ce moment je monte une petite plateforme pour aider des créateurs de contenus. Et comme d’autres avant moi, j'ai remarqué un truc : ce qu'on publie sur Internet n'est plus vraiment lu par des humains. C'est lu par des IA, digéré, puis resservi à un humain sous forme de récap'. Depuis, j'optimise tout ce que je mets en ligne pour elles. Voici pourquoi.

Regardez Google : posez une question, et la première chose qui s'affiche n'est plus une liste de liens, c'est un « Aperçu IA » qui vous répond directement. La plupart du temps, ça suffit — vous repartez sans visiter un seul site. Les chiffres le confirment d’ailleurs : quand un Aperçu IA s'affiche, seuls 8 % des gens cliquent encore sur un résultat, contre 15 % sans (Pew Research, 68 879 recherches réelles). Moi parfois, je ne tape même plus des mots-clés : je pose des questions entières, parce que je sais qu'un LLM va me répondre.

Le nouveau visiteur ne clique pas, il lit

À la place de l'humain débarque un nouveau genre de visiteur : l'agent IA. ChatGPT, Claude ou Perplexity visitent la page à sa place, gardent l'essentiel et lui en font le résumé. Le volume reste modeste — autour de 1 % du trafic web (Conductor) — mais il grimpe vite (+357 % en un an, Similarweb) et il convertit très fort : 15,9 % pour le trafic venu de ChatGPT, contre 1,76 % pour l'organique Google (Seer Interactive). Peu de volume, énormément d'intention : c'est maintenant qu'il y a une avance à prendre.

Le LLMO, ce que ce n'est pas

La communauté SEO a un nom pour ça : LLMO, Large Language Model Optimization. En une phrase : le SEO optimise pour le classement ; le LLMO optimise pour le sens, la structure et l'extractibilité par des IA.

Le point clé pour les développeurs : un LLM ne « navigue » pas. Il ne voit ni votre hero section, ni vos animations, ni votre dark mode. Il reçoit du texte, le découpe en tokens, et chaque token a un coût. Votre magnifique interface est, de son point de vue : du bruit inutile, facturé et qui allonge le contexte ; aucun avantage.

Le vrai coût, les tokens

J'ai fait le test sur une page réelle de ma propre plateforme : dunga.io/midwiq , avec le tokenizer d'OpenAI. La même information, trois représentations :

• Page complète (HTML + UI/UX) : 1 904 tokens — et près de 2 900 sur le tokenizer GPT-4 legacy
• HTML sémantique minimal : 521 tokens
• Markdown épuré : 283 tokens

Soit 85 % de tokens en moins — jusqu'à ×10 selon le tokenizer. Logique : navigation, CSS, artefacts JavaScript… tout ça ne porte aucune information, mais l'agent le paie quand même. Un Markdown propre supprime tout.

llms.txt : la fausse bonne solution

La réponse à la mode s'appelle llms.txt : un fichier Markdown à la racine du site, censé guider les IA. Sur le papier, séduisant. Dans les données, ça ne tient pas.

SE Ranking (300 000 domaines analysés) : aucun effet mesurable sur les citations — sur les 50 domaines les plus cités par l'IA, un seul avait le fichier. Limy : sur 500 millions de visites de bots IA en 90 jours, 408 ont demandé llms.txt ; les bots crawlent le HTML directement. Et Google a tranché : pas de support, John Mueller l'a même comparé à la vieille balise meta keywords.

Le problème n'est pas l'intention, c'est l'architecture : les agents ne vont pas chercher un fichier annexe, ils lisent l'URL qu'on leur donne. C'est donc là qu'il faut servir la bonne représentation.

Et pourtant, j'en ai un sur mon site — et je l'assume, pour deux raisons. La première : quand une convention émerge sur le web, je préfère la suivre ; c'est comme ça que les standards finissent par en devenir. La seconde : le mien ne cherche pas à être cité, il sert de README de l'interface machine — c'est là qu'un agent apprend que chaque page existe en .md, et comment la demander. Soyons honnêtes : d'après les chiffres, aujourd'hui, ça ne sert à rien. Mais c'est un fichier statique, zéro entretien — si le standard décolle, soyons prêts ; s'il meurt, on n'a rien perdu.

Ce que ça donne en pratique (ex : dunga.io)

C'est ce que j'ai fait sur dunga.io, la petite plateforme de smart-links (fanlinks, link-in-bio, deeplinks) que je crée pour des créateurs et artistes. Une page de lien, c'est le cas d'école : un nom, des liens, une bio — trois infos utiles noyées dans du design.

Chaque page de lien existe en version HTML sémantique et en version Markdown, générées à la volée au moment de la requête — toujours à jour, rien à stocker. Et ce n'est même pas le serveur qui s'en occupe : un middleware edge (quelques dizaines de lignes exécutées sur le CDN, avant tout le reste) regarde le User-Agent. Un humain reçoit le design, un crawler de réseau social reçoit sa carte Open Graph, un agent IA reçoit la version épurée. Même URL, trois représentations — 100 % de l'information, ~15 % des tokens. Vous pouvez le voir vous-même : ajoutez .md ou ?format=md à n'importe quelle page publique dunga.io. Et le créateur n'a rien eu à faire. C'est le point auquel je tiens : le LLMO ne devrait pas être une tâche de plus pour les créateurs, c'est une responsabilité de plateforme.

À vous de jouer

Je ne sais pas si le terme « LLMO » survivra à 2027. Mais l'écart entre un DOM de 2 000 tokens et 300 tokens de Markdown, lui, ne bougera pas. Trois choses simples à tester cette semaine :

1. Regardez vos logs : filtrez par User-Agent IA (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot) et mesurez ce trafic.
2. Tokenizez une de vos pages : passez le HTML brut dans un tokenizer et calculez le ratio tokens utiles / tokens totaux.
3. Servez une représentation alternative sur la même URL : une négociation de contenu sur le User-Agent tient en quelques lignes de middleware.

Et le piège que je n'ai découvert qu'en testant avec de vrais agents : le Content-Type. Servir du text/markdown, c'est propre sur le papier — sauf que certains fetchers LLM refusent toute réponse qui n'est pas du HTML. Et l'inverse est pire : du Markdown brut étiqueté text/html se fait aplatir par leur parseur HTML — sauts de ligne avalés, tout le contenu sur une seule ligne. Ce qui a fini par marcher chez moi : convertir le Markdown en HTML sémantique minimal (titres, listes, liens — zéro CSS, zéro script) servi par défaut, et ne renvoyer le vrai text/markdown qu'aux clients qui l'annoncent (Accept: text/markdown, ou .md explicite dans l'URL). Deux détails qui vont avec : un en-tête Vary: User-Agent, Accept, sans quoi votre CDN finira par servir la version robot à un humain ; et vérifiez que votre propre anti-bot n'étrangle pas en douce les lecteurs non humains de vos pages publiques — le mien le faisait, je l'ai découvert tard.

Voilà l'essentiel :

// middleware.ts — Vercel Edge (même logique sur Cloudflare Workers, Nginx, etc.)
const AI_UA = /GPTBot|ChatGPT-User|OAI-SearchBot|ClaudeBot|Claude-User|PerplexityBot|CCBot/i;

export default async function middleware(req: Request) {
  const url = new URL(req.url);
  const wantsMd =
    url.pathname.endsWith(".md") ||
    url.searchParams.get("format") === "md" ||
    /text\/markdown/i.test(req.headers.get("accept") || "");
  const isAgent = AI_UA.test(req.headers.get("user-agent") || "");
  if (!wantsMd && !isAgent) return; // humain → l'app, comme avant

  const md = await buildMarkdown(url.pathname); // votre contenu, épuré
  if (wantsMd) return respond(md, "text/markdown"); // demande explicite : vrai Markdown
  return respond(mdToMinimalHtml(md), "text/html"); // agents : HTML sémantique minimal
}

const respond = (body: string, type: string) =>
  new Response(body, {
    headers: {
      "Content-Type": `${type}; charset=utf-8`,
      Vary: "User-Agent, Accept", // ne JAMAIS mélanger les caches humain/robot
    },
  });

buildMarkdown et mdToMinimalHtml, c'est la partie qui dépend de votre produit : le premier construit le Markdown depuis vos données (servis par votre backend, pas depuis votre DOM), le second le convertit en HTML basique — titres, listes, liens, rien d'autre.

Comments

[Djeloune Ahmed Bedja]

Good job dude, keep going on 🔥