SEO & AI

De waarheid over het bestand llms.txt

Alle grote AI-partijen publiceren een llms.txt op hun documentatiesites. Geen van hen verbindt zich ertoe die van u te lezen. Ik heb de URL's stuk voor stuk getest, de officiële uitspraken en de logbestandstudies opnieuw doorgenomen. Dit is het resultaat, met feiten, uitspraken en hypothesen strikt gescheiden.

Fred Gaveau4 augustus 2026~11 min leestijd

Het begint met een eigenaardigheid. llms.txt wordt al twee jaar gepresenteerd als het bestand dat met kunstmatige intelligentie praat. En inderdaad publiceren ze er allemaal een: Anthropic, OpenAI, Mistral, Perplexity, xAI, Google gedeeltelijk. Als iemand weet waar dit bestand voor dient, zijn zij het.

Alleen heeft geen van hen ooit geschreven dat hun eigen bots het op uw site lezen. En het enige bedrijf dat zich er duidelijk over heeft uitgesproken — Google — zei nee.

Daar begint dit onderzoek. Ik heb elke URL met de hand getest, de officiële uitspraken opgezocht waar ze bestaan, en de gepubliceerde logbestandstudies gelezen. De tekst is bewust in drieën gedeeld: wat bewezen is, wat beweerd wordt, en wat speculatie blijft — de mijne inbegrepen.

Wat ik zelf heb geverifieerd

Ik heb zeventien URL's vanaf de opdrachtregel opgevraagd op 4 augustus 2026 om 13:24 UTC, met doorverwijzingen gevolgd en de HTTP-status en de omvang van de teruggegeven body genoteerd. Alle links in de tabel zijn actief: controleer het zelf, dat is nu juist het punt.

Momentopname van 4 augustus 2026, 13:24 UTC. Een bestand kan morgen verschijnen of verdwijnen — precies wat Google is overkomen.

Drie dingen springen uit die tabel.

Eén: het bestand woont op documentatiesubdomeinen, nooit op de publiekssite. docs., developers., platform. antwoorden met 200. De hoofdmappen anthropic.com en google.com antwoorden met 404. Eén uitzondering in het panel: Vercel, waarvan /docs/llms.txt doorverwijst naar vercel.com/llms.txt, echt in de hoofdmap geserveerd zoals de specificatie vraagt.

Twee: Google is versnipperd. Firebase heeft er een, Google Cloud niet, de site van de Gemini-modellen evenmin. Dat is geen beleid, dat is een ongeluk — daarover zo meer.

Drie: het formaat is uit elkaar geklapt. De specificatie beschrijft een korte index. Firebase serveert 1,7 MB, xAI 1,3 MB, de volledige variant van Vercel 7,4 MB. Een index van 1,7 MB is geen index meer: het is het corpus dat hij moest samenvatten.

Waar dit bestand vandaan komt

FEIT llms.txt is een voorstel dat op 3 september 2024 door Jeremy Howard (Answer.AI, medeoprichter van fast.ai) is gepubliceerd op llmstxt.org. Het idee: een gestructureerd Markdown-bestand in de hoofdmap — een #-titel, een samenvatting als citaat, ##-secties met geannoteerde links — dat modellen een schone inhoudskaart biedt in plaats van ze de structuur van een JavaScript-zware moderne site te laten raden.

De analogie met robots.txt en sitemap.xml is bewust gekozen, en zij heeft het idee verkocht. Maar op één beslissend punt is ze misleidend: robots.txt en sitemap.xml werden door de zoekmachines overgenomen voordat ze populair werden. Hier is het andersom.

FEIT De specificatiepagina claimt geen enkele instemming van een AI-aanbieder, noemt geen standaardisatietraject (geen IETF, geen W3C, geen WHATWG) en beschrijft zichzelf als open voor bijdragen uit de gemeenschap via een GitHub-repository. Een zelden opgemerkt detail: llms-full.txt komt in de specificatie helemaal niet voor. Het is een uit de praktijk ontstane conventie die iedereen anders invult.

De kern: leest iemand dit bestand echt?

Dat is de enige vraag die telt, en er zijn cijfers bij.

Wat de serverlogboeken zeggen

FEIT Op 5 maart 2026 publiceerde Dries Buytaert — bedenker van Drupal, CTO van Acquia — de analyse van een maand Cloudflare-logboeken. Zijn site kreeg 52 verzoeken op /llms.txt in een maand. Alle kwamen van SEO-auditgereedschap. Geen enkel kwam van een antwoordmachine of een AI-crawler. Over de volledige hostinginfrastructuur van Acquia: ongeveer 5 000 verzoeken op 400 miljoen, oftewel 0,001 %, vrijwel uitsluitend van SEO-gereedschap.

FEIT Een loganalyse van Ahrefs over 137 000 domeinen (juni 2026, overgenomen door PPC Land) concludeert dat 97 % van de llms.txt-bestanden geen enkel verzoek ontving in mei 2026. AI-ophaalbots waren goed voor 1,1 % van de waargenomen verzoeken.

FEIT Ten slotte vindt een SE Ranking-studie van 7 november 2025 over 300 000 domeinen geen meetbaar effect van llms.txt op AI-citaties. De variabele uit het voorspellende model halen verbeterde de nauwkeurigheid zelfs.

Wat Google verklaart

UITSPRAAK Google is de enige grote partij die zich formeel heeft uitgesproken. De officiële documentatie over de AI-functies in de zoekmachine (developers.google.com, bijgewerkt op 10 december 2025) schrijft het onomwonden:

UITSPRAAK Op Reddit vergeleek John Mueller llms.txt met de meta keywords-tag — juist opgegeven omdat de site hem zelf invult — en later, zoals gemeld in juni 2026: “I don't think anyone knows – it's purely speculative for now (the file has existed for years, yet none of the AI systems use it — what does it mean?)”. Hij voegt er een beslisregel aan toe die ik eerlijk vind: op de dag dat een AI-platform dat u klanten brengt om het bestand vraagt, maakt u het. Tot dan niet.

UITSPRAAK Gary Illyes van het Search-team gaf tijdens een Search Central Live in juli 2025 aan dat Google llms.txt niet ondersteunt en dat ook niet van plan is — een standpunt dat Search Engine Roundtable weergeeft.

Wat de anderen niet zeggen

ONGEVERIFIEERD Voor OpenAI, Anthropic, Perplexity en Mistral heb ik geen enkele publieke uitspraak gevonden dat hun bots de llms.txt van een externe site verwerken — en evenmin een die het uitsluit. Stilte is geen bewijs van afwezigheid, maar ook geen toezegging. Een bestand op je eigen documentatie publiceren zegt niets over wat je crawler bij u doet: twee teams, twee producten, twee problemen.

De gedocumenteerde tegenstrijdigheid bij Google

Dit is de meest onthullende episode, en ze is verifieerbaar.

GEMELD Op 3 december 2025 verscheen een llms.txt op developers.google.com/search/docs/. Hij werd opgemerkt door SEO-consultant Lidia Infante. Hij werd dezelfde dag nog verwijderd. Volgens de berichtgeving was het bestand geen besluit van het Search-team: het interne contentmanagementsysteem van Google, gedeeld door meerdere ontwikkelaarssites, was ze automatisch gaan genereren. Sommige teams verwijderden het, andere niet.

FEIT — geverifieerd op 4 augustus 2026 De huidige stand van zaken bevestigt die lezing. developers.google.com/search/docs/llms.txt, developer.chrome.com/llms.txt, web.dev/llms.txt, cloud.google.com/llms.txt, ai.google.dev/llms.txt: overal 404. En firebase.google.com/docs/llms.txt: 200, 1,7 MB. Eén team is vergeten op te ruimen. De “llms.txt van Google” die overal als bewijs van adoptie wordt aangehaald, is het residu van een automatische uitrol.

FEIT En toch beweegt op datzelfde moment een ander deel van Google de andere kant op. Lighthouse 13.3, het in Chrome ingebouwde auditgereedschap, bevat een experimentele categorie “Agentic Browsing” met een llms.txt-controle (documentatie bijgewerkt op 5 mei 2026). Daar wordt het omschreven als “an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents”, en de controle merkt op dat agents zonder het bestand meer tijd kwijt zijn aan het doorzoeken van de site.

MIJN LEZING Dit is geen hypocrisie, en ik zal het ook niet zo brengen. Het is dat “Google” geen eenduidige entiteit is en dat de twee teams niet over dezelfde toepassing praten: Search heeft het over ranking en citatie in een antwoordmachine, Chrome over de efficiëntie van een navigerende agent. Beide standpunten zijn afzonderlijk verdedigbaar. Ze zijn simpelweg onverenigbaar voor de lezer die wil weten of “Google” het bestand aanraadt. En die verwarring neemt niemand weg. Search Engine Journal verwoordde het treffend: het advies van Google hangt af van welk product je het vraagt.

Waarom publiceert iedereen er dan een?

Dit is de hypothese die ik verdedig, en de bestanden zelf ondersteunen haar: llms.txt is nooit een SEO-bestand geweest. Het is een bestand voor ontwikkelaarsdocumentatie. De beoogde lezer is niet GPTBot die het web indexeert voor een antwoordmachine. Het is een ontwikkelaar met Cursor, Claude Code of Copilot open, wiens agent actuele API-documentatie moet laden in plaats van een verouderde versie op te dreunen die tijdens de training is geleerd.

FEIT De bestanden zeggen het ronduit. Dat van Cohere bevat een sectie “Instructions for AI Agents” die aanraadt .md aan elke URL toe te voegen voor schone Markdown, en een MCP-server te verbinden “for AI client integration (Claude Code, Cursor, etc.)”. Dat van Cloudflare vermeldt dat elk product zijn eigen llms.txt heeft, “the recommended way to explore a specific product's content”. Die zinnen richten zich niet tot een zoekmachine.

FEIT De logboeken van Buytaert wijzen dezelfde kant op: in IDE's ingebedde agents halen deze bronnen wél op, anders dan de crawlers van antwoordmachines.

Als die lezing klopt, dan berust het hele debat “verbetert llms.txt mijn AI-zichtbaarheid?” op een verkeerde rolverdeling. Een hulpmiddel voor technische documentatie wordt met SEO-maatstaven beoordeeld. Het faalt, uiteraard. Dat betekent niet dat het nutteloos is — het betekent dat het daar niet voor is.

Wat wél werkt, en wat niemand verkoopt: Markdown

FEIT Dit is het nuttigste gegeven van het hele onderzoek, en het is bijna onopgemerkt gebleven. Opnieuw uit de logboeken van Buytaert, wanneer een pagina als Markdown beschikbaar is op een voorspelbare URL:

Met andere woorden: de crawlers van OpenAI halen Markdown op wanneer het op een raadbare URL bestaat — meestal /mijn-pagina.md. Een derde van de ophaalacties, bij GPTBot. Dat is oneindig veel meer dan de 0,001 % van de llms.txt.

FEIT En het gevolg is hard: “No AI crawler uses content negotiation. Not one.” Geen enkele AI-bot gebruikt de Accept-header om Markdown te vragen. Contentnegotiatie — de nette, al dertig jaar gestandaardiseerde methode — wordt door iedereen genegeerd. Wat werkt, is het URL-achtervoegsel, de domste oplossing die er is.

Dat is precies het patroon dat Stripe, Cohere, Perplexity en Anthropic in hun bestanden gebruiken: elke regel wijst naar een .md-tweeling. De llms.txt is de gids; de Markdown-tweelingen zijn wat er werkelijk wordt geconsumeerd.

De casus Stripe: wanneer de index een bevel wordt

FEIT De llms.txt van Stripe begint niet met een beschrijving. Hij begint met gebiedende wijs gericht aan de machine die hem leest. Geverifieerd fragment, de eerste regels van het bestand:

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest
version rather than relying on memorized version numbers. Run `npm view stripe
version` [...] Never hardcode an old version number from training data — always
install with `@latest` or verify the current version first.

HYPOTHESE Dit oneigenlijk gebruik roept een veiligheidsvraag op die ik wel kan stellen maar niet kan beslechten: als een openbaar, niet-ondertekend bestand instructies kan bevatten, en een agent laadt het in zijn context zonder “beschrijving van de site” te onderscheiden van “uit te voeren opdracht”, dan zitten we in het domein van prompt injection. Ik heb geen enkel openbaar gedocumenteerd incident gevonden waarbij een llms.txt is misbruikt. Het risico is structureel, niet vastgesteld. Maar het formaat biedt vandaag geen enkele manier om beide te scheiden — en Stripe heeft, te goeder trouw, zojuist laten zien dat de deur openstaat.

Acht voorstellen om het formaat te repareren

Kritiek leveren is makkelijk. Dit is wat llms.txt naar mijn mening van geloofsartikel in bruikbaar gereedschap zou veranderen. Elk voorstel leunt op een mechanisme dat elders al bestaat.

1. Stop met met de hand schrijven. Genereer het.

Een met de hand geschreven llms.txt rot binnen drie maanden weg: de pagina's verschuiven, het bestand niet. Het hoort tijdens de build te worden aangemaakt, vanuit dezelfde bron als de sitemap of het CMS. De ironie: precies dat deed het interne systeem van Google — en het ongeluk van december 2025 ontstond doordat het genereren automatisch was en het besluit niet. Automatiseer het genereren, niet het besluit.

2. Serveer Markdown-tweelingen vóór de index.

Dit is het meest lonende voorstel, en het draait de gebruikelijke prioriteiten om. Omdat de crawlers van OpenAI ongeveer een derde van hun verzoeken in Markdown doen maar contentnegotiatie negeren: serveer /mijn-pagina.md naast /mijn-pagina, op een voorspelbare URL, en verklaar het in de HTML met <link rel="alternate" type="text/markdown" href="/mijn-pagina.md">. Het werkt vandaag, meetbaar, anders dan llms.txt. Als u uit dit artikel maar één ding meeneemt, neem dan dit mee.

3. Verhuizen naar /.well-known/.

RFC 8615 definieert sinds 2019 een standaardnaamruimte voor precies dit soort bestanden, met een IANA-register erachter. /.well-known/llms.txt zou de plaatsingsvraag in één klap oplossen — juist die vraag verklaart waarom alle bestanden in de tabel op documentatiesubdomeinen wonen in plaats van in de hoofdmap — en zou de enige geloofwaardige weg naar standaardisatie openen.

4. Verklaar het in robots.txt.

Eén regel, Llms: https://voorbeeld.nl/llms.txt, exact naar het model van de Sitemap:-richtlijn — die evenmin ooit is gestandaardiseerd en die elke zoekmachine toch respecteert. Nul kosten, gegarandeerde vindbaarheid, en een mechanisme waarvan twintig jaar praktijk de acceptatie bewijst.

5. Dateer elke regel.

Een index zonder versheid is onbruikbaar: tegenover een live gerenderde pagina heeft een model geen reden om een indexregel te verkiezen die twee jaar oud kan zijn. Een datum per regel — - [Pagina](url) (2026-07-12): beschrijving — plus een eerlijke Last-Modified op het bestand zelf geven eindelijk iets om mee af te wegen.

6. Scheid index en corpus, formeel.

Het formaat heeft een harde bovengrens nodig — zeg 50 KB — voor llms.txt, en moet al het overige doorschuiven naar een llms-full.txt die expliciet in de specificatie is gedefinieerd (wat nog altijd niet zo is). De 1,7 MB van Firebase en de 1,3 MB van xAI zijn geen misbruik: het zijn symptomen van een formaat dat nooit heeft gezegd waar het ophoudt.

7. Onderteken het, of erken dat het niets waard is.

Het bezwaar van John Mueller — “de site vult het zelf in, net als meta keywords” — is onweerlegbaar zolang er geen handtekening bestaat. Het gereedschap is er: HTTP Message Signatures (RFC 9421), een sleutel gepubliceerd in een DNS TXT-record. Een zelfverklaard, niet-ondertekend bestand zal altijd exact de bewijskracht hebben van een meta keywords uit 2003.

8. Verbied de gebiedende wijs — of zet er een hek omheen.

Zolang geen enkel mechanisme een beschrijving van een instructie onderscheidt, zou het formaat opdrachten moeten verbieden of een duidelijk afgebakende sectie ## Agent instructions moeten voorschrijven die agents als onbetrouwbare gegevens behandelen. De casus Stripe is geen op zichzelf staand misbruik: het is het eerste symptoom.

En tot slot: meet het.

Geen van deze voorstellen ontslaat u van de eenvoudigste handeling. Een toegang tot /llms.txt is een regel in uw serverlogboeken. Filter op de user-agents van AI-bots, vergelijk met uw HTML-pagina's, en binnen een week weet u of dat bestand bij u iets doet. Dat is het enige gegeven dat u werkelijk aangaat. Alle andere, de mijne inbegrepen, zijn het gemiddelde van iemand anders.

Oordeel: moet u er in 2026 een neerzetten?

Er is niet één antwoord. Er zijn er vier.

En één regel die voor iedereen geldt: betaal niemand om uw llms.txt te schrijven. Het is twintig minuten werk, of nul als u het genereert. Het enige wat budget verdient, is daarna controleren of de bots werkelijk langskomen — en dat vertellen uw logboeken, niet een leverancier.

Voor het overige is mijn standpunt niet verschoven sinds ons eerste artikel over het onderwerp: het bestand doet geen kwaad, kost bijna niets, en als het gebruik ooit aantrekt staat u klaar. Wat is veranderd, zijn de gegevens. We weten nu, met cijfers, dat het geen hefboom voor AI-zichtbaarheid is — en we beginnen te begrijpen wat het werkelijk is: gereedschap voor code-agents, verkeerd genoemd en verkeerd gecast.

Transparantienoot: Snorklee publiceert een eigen llms.txt, in de hoofdmap, met een voorbehoud erin geschreven. We doen dus precies wat we aanraden: neerzetten, er niet in geloven, en het meten.