Tijdens ons live-evenement ‘Botverkeer Reality Check’ stelden twee mensen dezelfde vraag, en daar zijn we live niet aan toegekomen: zorgt een llms.txt bestand er echt voor dat AI je site niet langer overspoelt?
We hebben lang over die vraag nagedacht, want het eerlijke antwoord is geen simpel ja of nee. llms.txt is namelijk nooit bedoeld geweest om te doen wat mensen hoopten dat het deed, en veel van wat er dit jaar over is geschreven, heeft stilletjes de indruk gewekt dat het dat wél doet.
Die verwarring staat niet op zichzelf. In alle vragen die we kregen, kwamen robots.txt, llms.txt, “AI-crawlers” en botbescherming steeds terug alsof het vier standen op dezelfde draaiknop zijn, en alsof het niet uitmaakt aan welke je draait. Dat is niet zo. Ze zitten op compleet verschillende punten in het verzoekspad, ze worden afgedwongen door compleet verschillende mechanismen (of, in één geval, helemaal niet), en juist door ze door elkaar te halen doe je als site-eigenaar alles ‘goed’ en word je alsnog keihard geraakt.
En dit is geen theorie. Uit ons AI & Botverkeer Rapport bleek dat AI-botverkeer op sites die bij Kinsta draaien is gestegen van 1 op de 200 webbezoeken een jaar geleden naar 1 op de 31 nu. Een bordje op de deur helpt weinig als er zoveel mensen aan de klink trekken.
TL;DR
- robots.txt is een verzoek, geen slot. De serieuze AI-crawlers van OpenAI, Anthropic, Google en Perplexity lezen het en houden zich er meestal aan. Sommige doen dat niet, zoals Bytespider van ByteDance in het verleden.
- llms.txt regelt de toegang niet. Het is een contentindex voor AI-tools die ervoor kiezen het te lezen, geen bestand dat rechten toekent. Zo’n 9 tot 10% van de sites gebruikt het, en de grote AI-crawlers halen het meestal niet eens op.
- Botbescherming is de enige laag die echt iets afdwingt. robots.txt en llms.txt werken door het vriendelijk te vragen. Kinsta Botbescherming en AI Crawl Control van Cloudflare zijn de tools die een crawler die je voorkeuren negeert daadwerkelijk blokkeren, challengen of afremmen.
Vier lagen, vier taken, één punt van verwarring
| Laag | Wat het daadwerkelijk doet | Houdt het kwaadwillenden tegen? |
| robots.txt | Geeft je voorkeur door aan elke crawler die de moeite neemt het te lezen | Nee |
| llms.txt | Geeft AI-tools een overzichtelijke index van je content | Nee |
| AI-crawlers | De bots die de verzoeken doen | N.v.t. (dit is wat je beheert, geen maatregel) |
| Botbescherming (Kinsta / Cloudflare) | Detecteert en classificeert verzoeken op infrastructuurniveau en grijpt in | Ja |
Zodra je het zo op een rijtje hebt, beantwoorden de meeste vragen van de deelnemers zichzelf. We lopen ze daarom laag voor laag door, te beginnen bij de laag die iedereen al een beetje kent.
robots.txt
robots.txt, vastgelegd in RFC 9309, vertelt crawlers welke delen van je site ze beter kunnen overslaan. Er zit geen technische handhaving achter: het werkt puur omdat de crawlers die het lezen zelf hebben besloten zich eraan te houden.
Het geruststellende is dat de crawlers waar je waarschijnlijk het meest mee zit, die van OpenAI, Anthropic, Google en Perplexity, allemaal gedocumenteerde user-agents publiceren en zich aan de standaardrichtlijnen houden.
Waar het vaak misgaat: mensen gaan ervan uit dat elk bedrijf maar één “AI-bot” draait. Dat is niet zo. De meeste bedrijven houden training en zoeken tegenwoordig gescheiden, en die scheiding is de sterkste hefboom uit dit hele artikel:
- GPTBot (OpenAI): traint de basismodellen. Blokkeer je deze, dan wordt je content niet meer meegenomen in toekomstige trainingsrondes.
- OAI-SearchBot (OpenAI): indexeert pagina’s voor verwijzingen in de zoekfunctie van ChatGPT. Blokkeer je deze, dan verlies je die verwijzingen, maar op de training heeft het geen effect.
- ClaudeBot (Anthropic): training.
- Claude-SearchBot (Anthropic): zoekindexering voor Claude.
- Google-Extended: gaat specifiek over gebruik voor AI-training en AI Overviews. Blokkeer je deze, dan heeft dat geen invloed op de normale indexering door Googlebot of op je gewone zoekresultaten.
- PerplexityBot: de crawler achter de antwoordengine van Perplexity.
De echte keuze was dus nooit “AI toelaten of weren”. De vraag is: wil je dat je content een model traint, dat het geciteerd wordt in een AI-antwoord, allebei, of geen van beide? Met robots.txt kun je die vraag al vrij precies beantwoorden. De meeste site-eigenaren hebben hem alleen nog nooit zo gesteld.
In een robots.txt-bestand ziet die precisie er zo uit. Stel dat je niet wilt dat je content wordt gebruikt voor training, maar wel wilt opduiken als iemand ChatGPT of Claude iets vraagt wat jouw content zou kunnen beantwoorden:
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /Wil je liever één specifiek gedeelte volledig buiten schot houden, zowel voor training als voor zoekresultaten, dan beperk je de disallow tot een pad in plaats van de hele site:
User-agent: GPTBot
Disallow: /premium-reports/
User-agent: ClaudeBot
Disallow: /premium-reports/Het addertje onder het gras is dat naleving een kwestie van beleefdheid is, geen verplichting. Van een handvol crawlers is bekend dat ze disallow-regels gewoon negeren. Daar komt een nieuwere complicatie bij: als iemand ChatGPT of een vergelijkbare assistent vraagt om nu meteen één specifieke pagina te lezen, gedraagt die ene opvraging zich niet altijd als een crawl, en daar is de logica van robots.txt niet op gebouwd.
llms.txt
In veel artikelen uit 2026 wordt llms.txt beschreven als een tool voor toegangscontrole of als SEO-truc. Het eerlijke antwoord is simpeler en minder nuttig dan die artikelen doen vermoeden.
llms.txt is een gewoon Markdown bestand in je rootmap dat fungeert als inhoudsopgave voor AI-tools. Het wijst ze naar je belangrijkste pagina’s, zodat een model niet een volledig gerenderde pagina hoeft te parsen om te begrijpen wat je doet. Dat is de hele specificatie. Er staat niets in over wat een crawler wel of niet mag.
Zo ziet zo’n bestand er ongeveer uit:
# Acme Analytics
> Acme Analytics is a WordPress plugin for tracking site performance and uptime.
## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation
## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparisonLet op: geen Allow, geen Disallow, geen user-agent-targeting, niets dat een crawler vertelt wat wel en niet mag.
Dit laten de huidige cijfers zien:
- Het gebruik blijft laag. Zo’n 9 tot 10% van de sites heeft er een, ook onder de grootste domeinen van het web, terwijl mensen elkaar al ruim een jaar vertellen dat ze het moeten toevoegen.
- De bots die er echt toe doen, lezen het meestal niet. Uit verkeersanalyses van honderden miljoenen AI-verzoeken blijkt dat GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot en Google-Extended het bestand massaal overslaan en direct doorgaan met het crawlen van HTML.
- Google heeft officieel nee gezegd. De zoekspecialisten van Google hebben klip en klaar gesteld dat llms.txt geen signaal is voor ranking of crawling, en vergeleken het weinig vleiend met de allang verdwenen keywords-metatag.
- Geen enkel groot AI-lab heeft toegezegd het als toegangssignaal te gebruiken, niet voor training en niet voor zoeken.
Waar het wél nuttig is: als routekaart voor coding agents en developertools zoals Claude Code of Cursor, die baat hebben bij een overzichtelijke, gestructureerde index van een documentatiesite.
llms.txt voorkomt dus niet dat je site keer op keer wordt gescraped. Het is een tool voor vindbaarheid, geen snelheidsbegrenzer en geen poort.
AI-crawlers
De term “AI-crawler” is een verzamelnaam voor minstens drie soorten gedrag, en juist het door elkaar halen daarvan is waar veel verkeerde beslissingen beginnen:
- Trainingscrawlers die regelmatig content verzamelen voor de trainingsset van een model: GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot.
- Zoek- en antwoordcrawlers die de index opbouwen waaruit een AI-antwoordengine daadwerkelijk put: OAI-SearchBot, Claude-SearchBot, PerplexityBot.
- Realtime opvragingen door agents, waarbij iemand een assistent vraagt om nu meteen één specifieke pagina te lezen, en die dat ter plekke doet.
De eerste twee gedragen zich als klassieke crawlers en identificeren zich meestal met een gedocumenteerde user-agent. Precies daarom is sturing via robots.txt überhaupt mogelijk. De derde lijkt veel meer op iemand die op een link klikt dan op een crawl. Dat verklaart deels waarom sommige AI-browsertools nu in serverlogs opduiken zonder onderscheid met gewone bezoekers, en deels waarom keihard blokkeren van bots af en toe ook legitiem, door mensen aangestuurd verkeer in hetzelfde net meeneemt.
Dit is ook wat Daniel Pataki tijdens het webinar bedoelde: het meeste AI-crawlerverkeer is tegenwoordig niet kwaadaardig, maar gewoon meedogenloos. Het volgt elke link die het tegenkomt, inclusief elke overbodige URL-variant die een dynamische WordPress- of WooCommerce-pagina kan genereren, en loopt uiteindelijk vast in een loop die eruitziet als een aanval, maar in werkelijkheid gewoon een bot is die niet doorheeft dat hij deze pagina al negenduizend keer heeft gezien.
We gaan dieper in op waarom dat juist WooCommerce-infrastructuur zo hard raakt, en waarom WooCommerce-sites extra kwetsbaar zijn voor botverkeer.
De laag die echt effect heeft: botbescherming
Zodra je accepteert dat robots.txt vrijwillig is en llms.txt helemaal geen controle biedt, blijft er maar één laag over die iets kan doen tegen een crawler die weigert mee te werken: botbescherming, of dat nu Kinsta Botbescherming is, de tools van Cloudflare of iets heel anders.
Cloudflare speelde hier snel op in, maar bij Kinsta kiezen we voor een gerichtere, WordPress-specifieke aanpak van hetzelfde probleem: een aparte schakelaar Blokkeer AI-crawlers die AI-crawlers tegenhoudt, ook geverifieerde, zonder Googlebot of Bing te raken. Daarnaast is er een classificatie voor AI-crawlers met een buitensporige frequentie, die bots opspoort die technisch geverifieerd zijn maar je site veel zwaarder belasten dan een normale crawl ooit zou doen.
Laszlo Farkas, onze Director of Engineering, vatte de onderliggende afweging zo samen toen we hem vroegen een beheerde tool te vergelijken met zelf regels opstellen:
Heb je de expertise en de tijd om dit zelf te finetunen, dan is dat waarschijnlijk de betere keuze. Heb je die niet, dan kun je beter die van Kinsta gebruiken: die is beheerd, speciaal afgestemd op WordPress en we onderhouden hem voor je.
Wil je een uitgebreidere vergelijking van waar de tool van Kinsta en die van Cloudflare het beste tot hun recht komen? Bekijk dan onze gids over Kinsta Botbescherming versus Cloudflare.
De vragen die we kregen, direct beantwoord
“We willen LLM-crawlers toelaten, maar misbruik voorkomen. Is er een betrouwbare manier om dit te doen?” Ja, en het draait om die bewuste scheiding tussen training en zoeken. Laat de zoek- en antwoordcrawlers toe als je vindbaar wilt zijn en geciteerd wilt worden. Sluit trainingscrawlers uit via robots.txt als dat het deel is waar je bezwaar tegen hebt. Laat botbescherming vervolgens het misbruik op volume opvangen, van alles wat harder crawlt dan zou moeten, geverifieerd of niet.
“We willen het verkeer niet blokkeren, omdat we willen dat AI ons bedrijf onder de aandacht brengt. Wat moeten we dan eigenlijk doen?” Hetzelfde antwoord, andere invalshoek. Vindbaar zijn in AI-antwoorden en de belasting van je resources beheersen bijten elkaar niet, omdat verschillende bots elk hun eigen taak hebben. Geef de trainingscrawlers en de crawlers met hoog volume een challenge of blokkeer ze als dat je zorg is, en zet de zoek- en antwoordcrawlers expliciet open.
“Houden content-paywalls AI-bots tegen om die content te scrapen?” Gedeeltelijk, en alleen tegen crawlers die zich als crawler gedragen. Een inlogscherm houdt een bot tegen die de normale paginastructuur respecteert en geen geldige inloggegevens heeft, net zoals het elke anonieme bezoeker tegenhoudt. Tegen AI-tools die eerder browsen als een uitgelogde gebruiker helpt het niets, net zomin als tegen tools die dezelfde content bereiken via een cachekopie, een RSS-feed of een andere achterdeur waar de paywall-logica helemaal niet aan te pas komt. Nuttig als aanvulling, maar geen vervanging van botbescherming.
“Kunnen we voorkomen dat AI-crawlers eindeloos door de filters van onze WooCommerce-winkel lopen?” Dit is eigenlijk een caching- en URL-structuurprobleem dat zich voordoet als een botbeschermingsprobleem. Crawlers volgen elke link die ze tegenkomen, en dynamische filter- en sorteerparameters genereren bijna oneindig veel URL-varianten voor wat voor een mens dezelfde pagina is. Die parameterpatronen blokkeren in robots.txt is een verstandige eerste stap:
User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=Maar als een crawler dit toch negeert, en sommige doen dat, zijn het de frequentieregels in botbescherming die de loop daadwerkelijk doorbreken.
Waar dit je brengt
Zie deze vier niet als concurrerende opties, maar als een stack die je in volgorde toepast:
- robots.txt geeft je intentie door, waarbij je trainingscrawlers scheidt van zoek- en antwoordcrawlers op basis van wat je van elk wilt.
- llms.txt is, als je de moeite neemt, een service aan de tools die het lezen, geen middel om je crawlvolume te verlagen of te sturen.
- “AI-crawlers” is een verzamelnaam voor trainingsbots, zoekbots en realtime opvragingen door agents, en elk daarvan verdient mogelijk een ander antwoord.
- Botbescherming is waar de handhaving echt plaatsvindt, want het is de enige laag die kan ingrijpen bij een verzoek dat alles negeert wat je hebt gevraagd.
Is je vraag niet zozeer “hoe regel ik dit”, maar eerder “hoe word ik hierdoor gevonden”, dan sluiten onze gidsen over AEO voor WordPress en GEO vs. AEO vs. SEO naadloos aan op dit artikel. Wil je de instellingen uit dit artikel bekijken, ga dan naar Kinsta Botbescherming.
