DEV Community: faikidine

Stop optimizing your site for humans, they don't read it anymore

faikidine — Sat, 15 Aug 2026 18:22:42 +0000

I'm a computer science student. I work on side projects, and these days I'm building a small platform to help content creators. And like others before me, I noticed something: what we publish on the Internet isn't really read by humans anymore. It gets read by AIs, digested, then served back to a human as a recap. Since then, I've been optimizing everything I put online for them. Here's why.

Look at Google: ask a question, and the first thing you see is no longer a list of links — it's an "AI Overview" that answers you directly. Most of the time, that's enough: you leave without visiting a single site. The numbers back it up: when an AI Overview shows, only 8% of people still click a result, versus 15% without one (Pew Research, 68,879 real searches). As for me, sometimes I don't even type keywords anymore: I ask full questions, because I know an LLM will answer.

The new visitor doesn't click, it reads

In the human's place arrives a new kind of visitor: the AI agent. ChatGPT, Claude or Perplexity visit the page on their behalf, keep the essentials and hand back a summary. The volume is still modest — around 1% of web traffic (Conductor) — but it's climbing fast (+357% in a year, Similarweb) and it converts hard: 15.9% for traffic coming from ChatGPT, versus 1.76% for Google organic (Seer Interactive). Low volume, huge intent: now is when there's a head start to be had.

LLMO, and what it isn't

The SEO community has a name for this: LLMO, Large Language Model Optimization. In one sentence: SEO optimizes for ranking; LLMO optimizes for meaning, structure, and extractability by AIs.

The key point for developers: an LLM doesn't "browse". It sees neither your hero section, nor your animations, nor your dark mode. It receives text, splits it into tokens, and every token has a cost. Your beautiful interface is, from its point of view: useless noise, billed by the token, stretching the context; zero benefit.

The real cost: tokens

I ran the test on a real page of my own platform — dunga.io/midwiq — with OpenAI's tokenizer. The same information, three representations:

Full page (HTML + UI/UX): 1,904 tokens — and nearly 2,900 on the legacy GPT-4 tokenizer
Minimal semantic HTML: 521 tokens
Clean Markdown: 283 tokens

That's 85% fewer tokens — up to ×10 depending on the tokenizer. Which makes sense: navigation, CSS, JavaScript artifacts… none of it carries any information, but the agent pays for it anyway. Clean Markdown removes all of it.

llms.txt: the obvious fix that isn't

The fashionable answer is called llms.txt: a Markdown file at the root of your site, meant to guide AIs. On paper, appealing. In the data, it doesn't hold up.

SE Ranking (300,000 domains analyzed): no measurable effect on citations — of the 50 domains most cited by AI, only one had the file. Limy: out of 500 million AI bot visits over 90 days, 408 requested llms.txt; bots crawl the HTML directly. And Google has ruled: no support — John Mueller even compared it to the old meta keywords tag.

The problem isn't the intention, it's the architecture: agents don't go looking for a side file, they read the URL you hand them. That's where the right representation needs to be served.

And yet, I have one on my site — and I stand by it, for two reasons. First: when a convention emerges on the web, I'd rather follow it; that's how conventions end up becoming standards. Second: mine isn't trying to get cited, it serves as the README of the machine interface — it's where an agent learns that every page exists as .md, and how to ask for it. Let's be honest: according to the numbers, right now, it does nothing. But it's one static file, zero maintenance — if the standard takes off, we're ready; if it dies, we've lost nothing.

What it looks like in practice (e.g. dunga.io)

That's what I did on dunga.io, the small smart-links platform (fanlinks, link-in-bio, deeplinks) I'm building for creators and artists. A link page is the textbook case: a name, some links, a bio — three useful pieces of information drowned in design.

Every link page exists as a semantic HTML version and a Markdown version, generated on the fly at request time — always up to date, nothing to store. And it's not even the server doing the work: an edge middleware (a few dozen lines running on the CDN, before everything else) looks at the User-Agent. A human gets the design, a social crawler gets its Open Graph card, an AI agent gets the stripped-down version. Same URL, three representations — 100% of the information, ~15% of the tokens. You can see it for yourself: add .md or ?format=md to any public dunga.io page. And the creator didn't have to lift a finger. That's the part I care about: LLMO shouldn't be one more chore for creators — it's a platform's responsibility.

Your turn

I don't know whether the term "LLMO" will survive past 2027. But the gap between a 2,000-token DOM and 300 tokens of Markdown isn't going anywhere. Three simple things to try this week:

Check your logs: filter by AI User-Agent (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot) and measure that traffic.
Tokenize one of your pages: run the raw HTML through a tokenizer and compute the useful-tokens / total-tokens ratio.
Serve an alternative representation on the same URL: content negotiation on the User-Agent fits in a few lines of middleware.

And the trap I only discovered by testing with real agents: the Content-Type. Serving text/markdown is clean on paper — except some LLM fetchers refuse any response that isn't HTML. And the reverse is worse: raw Markdown labeled text/html gets flattened by their HTML parser — line breaks swallowed, the whole content on a single line. What ended up working for me: convert the Markdown into minimal semantic HTML (headings, lists, links — zero CSS, zero scripts) served by default, and only return true text/markdown to clients that ask for it (Accept: text/markdown, or an explicit .md in the URL). Two details that go with it: a Vary: User-Agent, Accept header, without which your CDN will eventually serve the robot version to a human; and check that your own anti-bot layer isn't quietly strangling the non-human readers of your public pages — mine was, and I found out late.

Here's the gist:

// middleware.ts — Vercel Edge (same logic on 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; // human → the app, as before

  const md = await buildMarkdown(url.pathname); // your content, stripped down
  if (wantsMd) return respond(md, "text/markdown"); // explicit ask: real Markdown
  return respond(mdToMinimalHtml(md), "text/html"); // agents: minimal semantic HTML
}

const respond = (body: string, type: string) =>
  new Response(body, {
    headers: {
      "Content-Type": `${type}; charset=utf-8`,
      Vary: "User-Agent, Accept", // NEVER mix human/robot caches
    },
  });

buildMarkdown and mdToMinimalHtml are the part that depends on your product: the first builds the Markdown from your data (served by your backend, not from your DOM), the second converts it into basic HTML — headings, lists, links, nothing else.

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

faikidine — Sat, 15 Aug 2026 18:10:28 +0000

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 :

Regardez vos logs : filtrez par User-Agent IA (GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot) et mesurez ce trafic.
Tokenizez une de vos pages : passez le HTML brut dans un tokenizer et calculez le ratio tokens utiles / tokens totaux.
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.