Hoe je een robots.txt schrijft die AI-scrapers echt blokkeert

De ongemakkelijke waarheid over robots.txt

Een robots.txt-bestand is geen slot. Het is een bordje op de deur.

Dat onderscheid is belangrijk wanneer teams vragen of ze “AI-scrapers kunnen blokkeren” met één klein tekstbestand. Voor betrouwbare crawlers die het Robots Exclusion Protocol volgen, is het antwoord ja: een correct geschreven robots.txt kan ze vertellen je pagina’s niet te crawlen. Voor onbekende scrapers, imitators, browserautomatisering en bots die het eenvoudigweg niets kan schelen, doet het op zichzelf niets.

Het praktische doel is dus niet: “scraping onmogelijk maken.” Het is:

• Conforme AI-crawlers vertellen dat ze je site niet moeten gebruiken.
• Voorkomen dat je per ongeluk zoekmachines of nuttige diensten blokkeert.
• Sterkere server-side controles toevoegen tegen misbruik.
• Het beleid onderhoudbaar houden wanneer crawlernamen veranderen.

Dat is de saaie versie. Het is ook de versie die werkt.

Wat robots.txt wel en niet kan doen

Een robots.txt-bestand staat in de root van een site:

https://example.com/robots.txt

Crawlers vragen het op voordat ze crawlen. Het bestand bevat groepen regels. Elke groep begint met een of meer User-agent-regels, gevolgd door Allow- of Disallow-directives.

Een eenvoudige blokkade voor de hele site ziet er zo uit:

User-agent: GPTBot
Disallow: /

Dat betekent: als je GPTBot bent, crawl dan niets op deze site.

Maar robots.txt heeft harde grenzen:

1. Het is vrijwillig. Kwaadwillenden kunnen het negeren.
2. Het voorkomt niet dat een URL wordt opgevraagd door een normale browser of script.
3. Het verwijdert geen content die al elders is verzameld.
4. Het definieert op zichzelf geen auteursrecht, licenties of trainingsrechten.
5. Het kan verkeerd worden geconfigureerd, waardoor de verkeerde bots worden geblokkeerd.

Als je echte toegangscontrole nodig hebt, gebruik dan authenticatie, autorisatie, rate limiting, IP-gebaseerde controles, botmanagement of juridische middelen. Robots.txt is nog steeds nuttig, maar hoort thuis in een bredere strategie voor contentbescherming.

Dit lijkt op andere governanceproblemen op het web: de zichtbare controle is zelden de volledige controle. Als je organisatie intern al onbeheerd AI-gebruik heeft, geldt hetzelfde principe; een snelle shadow AI-audit is vaak nuttiger dan doen alsof één beleidsdocument het probleem oplost.

Begin met je beleidskeuze

Bepaal voordat je het bestand bewerkt wat je eigenlijk probeert te blokkeren.

Er zijn minstens vier verschillende dingen die mensen bedoelen met “AI-scraper”:

• Crawlers die worden gebruikt om trainingsdata te verzamelen.
• Crawlers voor AI-zoekmachines of antwoordmachines.
• Door gebruikers geactiveerde fetchers, bijvoorbeeld wanneer iemand een AI-product vraagt een URL samen te vatten.
• Algemene scrapers die zich voordoen als gewone browsers.

Misschien wil je ze allemaal blokkeren. Of misschien wil je vindbaarheid in zoekmachines behouden, terwijl je niet wilt meedoen aan modeltraining. Dat is niet hetzelfde beleid.

OpenAI documenteert bijvoorbeeld afzonderlijke user agents voor verschillende doelen, waaronder GPTBot, ChatGPT-User en OAI-SearchBot. Google gebruikt Google-Extended als controletoken voor sommige Gemini- en Vertex AI-toepassingen, terwijl normaal crawlen voor Google Search wordt afgehandeld door andere Googlebot-user agents.

Die scheiding is belangrijk. Als je brede user agents onzorgvuldig blokkeert, kun je gewone zoekzichtbaarheid schaden terwijl je AI-training probeert te blokkeren.

Een redelijk robots.txt-sjabloon om AI te blokkeren

Hier is een conservatief startpunt om meerdere vaak gedocumenteerde AI-gerelateerde crawlers te blokkeren, terwijl algemene zoekcrawlers met rust worden gelaten:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Dit is geen magische universele lijst. Het is een onderhoudbaar patroon.

Een paar opmerkingen:

• Disallow: / betekent “crawl geen enkel pad.”
• User-agent: * geldt voor crawlers die niet matchen met een specifiekere groep.
• Allow: / is niet strikt vereist voor de standaardgroep, maar maakt je bedoeling duidelijk.
• Houd commentaar kort. Sommige parsers zijn vergevingsgezind, maar robots.txt moet saai blijven.
• Neem geen privé-URL’s op in robots.txt. Het bestand is openbaar, en het vermelden van gevoelige paden kan ze juist onder de aandacht brengen.

Dat laatste punt verdient herhaling. Robots.txt is geen geheimhoudingsmechanisme. Als /client-contracts/ niet openbaar mag zijn, bescherm het dan met authenticatie. Sta niet slechts crawling ervan niet toe.

Wees voorzichtig met Google-Extended

Google-Extended wordt vaak verkeerd begrepen. Het is niet hetzelfde als Google Search blokkeren.

Volgens de documentatie van Google is Google-Extended een zelfstandig producttoken waarmee uitgevers kunnen beheren of sitecontent mag helpen bij het verbeteren van bepaalde Gemini- en Vertex AI-mogelijkheden. Het blokkeren ervan zou op zichzelf Googlebot niet moeten blokkeren bij het crawlen voor Search.

Vervang dat gezegd hebbende niet alle Google-directives door een brede blokkade zoals deze, tenzij je dat echt bedoelt:

User-agent: Googlebot
Disallow: /

Dat zou de belangrijkste crawler van Google Search vertellen je site niet te crawlen. Voor de meeste openbare websites is dat niet wat je wilt.

Hetzelfde onderscheid geldt elders. Sommige leveranciers scheiden trainingscrawlers van door gebruikers geactiveerd browsen of AI-zoekcrawlers. Andere doen dat niet. Je moet de documentatie lezen voor de bots waar je om geeft en je robots.txt behandelen als een levend bestand, niet als een eenmalig vinkje.

Test het bestand als productiecode

Robots.txt lijkt eenvoudig, en juist daarom gaat het gemakkelijk stuk.

Veelvoorkomende fouten zijn:

• Het uploaden naar de verkeerde plaats, zoals /assets/robots.txt in plaats van /robots.txt.
• Het gebruiken van slimme aanhalingstekens die uit een documenteditor zijn gekopieerd.
• Per ongeluk alle crawlers blokkeren met User-agent: * en Disallow: /.
• Aannemen dat het bestand van één domein ook geldt voor een ander subdomein.
• Vergeten dat http://, https://, www en niet-www-hosts anders kunnen worden afgehandeld, afhankelijk van je setup.

Controleer bij sites met meerdere domeinen elke canonieke host. Een robots-bestand op https://www.example.com/robots.txt beheert niet automatisch https://app.example.com/robots.txt.

Inspecteer bij het debuggen de daadwerkelijke HTTP-respons, niet alleen wat de preview van je CMS toont. Je wilt een 200 OK-respons, indien mogelijk het contenttype text/plain, en exact het bestand dat je verwacht. Als redirects, caching of CDN-regels meespelen, helpt ruwe headerinspectie. De workflow in redirects en HTTP-headers debuggen in productie is hier direct van toepassing.

Voeg server-side controles toe voor bots die de regels negeren

Als de crawler conform is, is robots.txt het netste signaal. Als de crawler misbruik maakt, heb je handhaving nodig.

Praktische controles zijn onder meer:

Rate limiting

Stel drempels in voor ongebruikelijke requestpatronen: te veel pagina’s per minuut, diep door paginering heen gaan, herhaalde 404’s of een hoog requestvolume vanaf een kleine set IP-adressen. Rate limits moeten ruim genoeg zijn om echte gebruikers niet te straffen en streng genoeg om bulkextractie duur te maken.

User-agent-filtering

Je kunt gedocumenteerde AI-crawler-user agents blokkeren op de webserver, reverse proxy, CDN of applicatielaag. Dit is sterker dan robots.txt, omdat het een daadwerkelijke weigering teruggeeft.

Nginx kan bijvoorbeeld een user-agent-patroon blokkeren, al moeten productieregels zorgvuldig worden getest:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

Dit is niet waterdicht. User-agent-strings zijn gemakkelijk te vervalsen. Maar het stopt eerlijk of lui verkeer en vermindert de belasting.

IP- en ASN-controles

Sommige operators publiceren IP-reeksen, maar veel scraper-ecosystemen doen dat niet. IP-gebaseerd blokkeren kan werken bij duidelijk misbruik, vooral vanaf cloudhostingreeksen zonder normaal gebruikersverkeer, maar het kan ook false positives veroorzaken. Gebruik logs voordat je regels maakt.

Authenticatie en paywalls

Als content niet op schaal gekopieerd mag worden, zet de volledige content dan niet op een openbare URL. Robots.txt is ongeschikt voor vertrouwelijk materiaal, gelicentieerde databases, besloten communities of betaalde archieven.

Contentminimalisatie

Soms is de beste bescherming architecturaal. Stel geen onnodige API’s, grote JSON-payloads, verborgen metadata, draft-endpoints of volledige archieven bloot als de openbare pagina slechts een kleine subset nodig heeft. Sites met veel afbeeldingen moeten ook nadenken over welke metadata ze publiceren; de privacylogica in EXIF-metadata verwijderen voordat je foto’s online deelt geldt ook voor contentoperaties.

Gebruik robots-metatags voor regels op paginaniveau

Robots.txt regelt crawlen. Robots-metatags en X-Robots-Tag-headers regelen indexering en snippetgedrag voor conforme zoekmachines en crawlers.

Bijvoorbeeld:

<meta name="robots" content="noindex, noarchive">

Of als HTTP-header:

X-Robots-Tag: noindex, noarchive

Dit zijn geen AI-specifieke schilden. Ze zijn nuttig wanneer je wilt dat een pagina toegankelijk is, maar niet wordt geïndexeerd. Als je een crawler echter in robots.txt blokkeert om een pagina op te halen, ziet die mogelijk nooit de metatag op paginaniveau. Vertrouw niet op een noindex-tag op een URL die de crawler niet mag crawlen.

De ruwe regel:

• Gebruik robots.txt om crawling te verminderen of te voorkomen.
• Gebruik meta robots of X-Robots-Tag om indexeringsgedrag te sturen.
• Gebruik server-side controles om toegang af te dwingen.

Monitor logs na publicatie

Het bestand publiceren is pas stap één. Controleer daarna je logs.

Let op:

• Requests naar /robots.txt van de user agents die je hebt genoemd.
• Voortgezet crawlen nadat disallow-regels zijn aangeboden.
• Verdachte user agents met hoog volume.
• Browserachtige user agents die duizenden pagina’s achter elkaar opvragen.
• Herhaalde toegang tot feeds, sitemaps, zoekpagina’s en paginering.

Als een bot robots.txt opvraagt, een volledige disallow ziet en daarna stopt, heeft robots.txt zijn werk gedaan. Als hij doorgaat, verplaats die bot dan naar handhaving: rate limits, blokkades of authenticatie.

Bekijk ook je sitemap-blootstelling. Sitemaps zijn nuttig voor zoekmachines, maar het zijn ook handige kaarten voor scrapers. Dat betekent niet dat je ze van gewone sites moet verwijderen. Het betekent wel dat je geen URL’s moet opnemen waarvan je niet wilt dat openbare systemen ze ontdekken.

Houd het bestand klein en gecontroleerd

Robots.txt heeft de neiging te verouderen. Een marketingteam voegt een campagne-microsite toe. Een developer voegt een staging-pad toe. Een leverancier verandert de naam van zijn crawler. Twee jaar later weet niemand nog waarom de helft van de regels bestaat.

Behandel het als configuratie:

• Sla het waar mogelijk op in version control.
• Voeg een korte comment toe voor elke AI-crawlergroep.
• Review het elk kwartaal.
• Controleer leveranciersdocumentatie voordat je brede regels toevoegt.
• Test na wijzigingen aan CDN, CMS of hosting.

Als je site AI-ondersteunde content publiceert, houd crawlerbeleid dan ook gescheiden van redactionele transparantie. AI-scrapers blokkeren gaat over toegang en hergebruik. Disclosure gaat over vertrouwen van lezers. Ze overlappen ethisch, maar zijn niet dezelfde controle. Een praktische disclosure-aanpak wordt behandeld in hoe eerlijke AI-disclosure eruitziet op een kleine website.

<!-- tool-cta:start -->

💡 Probeer dit: Nadat je regels voor AI-crawlers hebt toegevoegd, controleer je de syntaxis met Robots.txt Tester zodat je niet per ongeluk ook legitieme bots blokkeert.

<!-- tool-cta:end -->

De kern

Een goed robots.txt-bestand blokkeert conforme AI-crawlers. Het stopt geen vastberaden scraping, gekopieerde user-agent-strings, gecompromitteerde browsers of mensen die je content handmatig in AI-systemen plakken.

Dat maakt het niet nutteloos. Het maakt het één laag.

Schrijf expliciete regels voor gedocumenteerde AI-crawlers. Vermijd brede blokkades die zoekzichtbaarheid schaden. Test het geserveerde bestand, niet de conceptversie. Houd logs in de gaten. Dwing af met server-side controles waar gedrag verschuift van ongewenst naar misbruik.

Het web heeft altijd gedraaid op een mix van protocol, normen en handhaving. Robots.txt is de normenlaag. Gebruik het, maar verwar het niet met een muur.