De AI-crawlertax: wie betaalt als bots 57% van je verkeer zijn?

Bots zijn de mens voorbij op het web, en AI-crawlers groeien het hardst. De bandbreedte en compute komen bij jou terecht, vaak als betaalde 'visits'. Alles blokkeren is de verkeerde reflex: het kost je ook je zichtbaarheid in AI-zoekresultaten. Zo rate-limit je gericht.

Blokkeer AI-crawlers niet massaal. Dat is de reflex zodra je bandbreedtegrafiek piekt, maar je snijdt jezelf er ook mee af van de zoekresultaten van ChatGPT en Perplexity, en de crawler die robots.txt toch negeert raak je er niet mee. De bots zijn niet echt het probleem. Het facturatiemodel dat hun verkeer stilletjes in jouw factuur verandert, dat is het probleem.

Op 3 juni 2026 meldde Cloudflare-CEO Matthew Prince dat bots voor het eerst de mens voorbij waren als aandeel van het webverkeer: zo'n 57% van de HTTP-verzoeken naar HTML-pagina's, tegenover 43% van mensen. Dat getal klopt. Wat het meet wordt breed verkeerd gelezen, en juist die misvatting leidt naar de verkeerde oplossing.

TL;DR

  • Het cijfer van ~57% bots (Cloudflare, juni 2026) is al het geautomatiseerde verkeer. AI-crawlers waren in december 2025 maar zo'n 4,2% van de HTML-verzoeken, maar wel het snelst groeiende en duurste deel.
  • De kosten komen bij jou terecht als bandbreedte en CPU, en steeds vaker als betaalde "visits". Read the Docs slikte een bandbreedtefactuur van ruim $5.000 in één maand door één crawler.
  • Hosts gaan heel verschillend om met bot-facturatie. WP Engine sluit bekende én verdachte bots uit; Kinsta sluit alleen uit wat het zeker kan herkennen, dus nieuwe AI-crawlers kunnen alsnog meetellen.
  • Alles blokkeren is de verkeerde reflex. Trainingscrawlers en zoekcrawlers zijn aparte, gedocumenteerde bots. Blokkeer je GPTBot, dan sta je nog steeds in ChatGPT-zoekresultaten; blokkeer je OAI-SearchBot, dan niet.
  • robots.txt is een beleefd verzoek, geen hek. Afdwingen doe je op de server of aan de edge: rate limits, IP-range-regels en een WAF.

Inhoudsopgave

De 57%-kop klopt, maar meet iets anders dan je denkt

Het omslagpunt kwam sneller dan Cloudflare verwachtte: Prince had het rond 2027 ingeschat. Maar die ~57% is élk geautomatiseerd verzoek, en wat het over de helft duwde zijn niet de crawlers die pagina's indexeren. Het is agentic verkeer: AI-agents die namens een gebruiker taken over meerdere pagina's uitvoeren en daarbij veel meer pagina's bezoeken dan een mens ooit zou doen.

AI-crawlers zelf zijn een kleiner stukje. In Cloudflares 2025 Year in Review waren AI-bots zo'n 4,2% van de HTML-verzoeken, net onder de 4,5% van Googlebot. Klein, maar het groeit hard en het zwaartepunt ligt bij één taak: trainingscrawls zijn goed voor ruwweg 80% van het crawlen door AI-bots.

De scheefheid bepaalt elke keuze die hierna komt. Cloudflare heeft gemeten hoe vaak elk bedrijf je site crawlt voor elke bezoeker die het terugstuurt. In augustus 2025 zat ClaudeBot van Anthropic op bijna 50.000:1. GPTBot van OpenAI op 887:1, Perplexity op 118:1. Trainingscrawlers nemen alles en geven bijna niets terug. Ik moraliseer daar niet over; het is een kostenstructuur, en het vertelt je welke bots hun plek verdienen.

De echte kosten zijn compute en bandbreedte, geen pageviews

Een crawler kost je geen "visit". Hij kost je de bytes die hij ophaalt en de PHP-workers die hij bezet om ongecachte pagina's te genereren. Voor iedereen die WordPress draait is dat tweede de echte sloper: een agressieve crawler die ongecachte, geparametriseerde URL's afgaat jaagt de PHP- en databasebelasting flink hoger op dan je op grond van het aantal verzoeken zou verwachten.

De cijfers van mensen die het hebben gemeten zijn keihard. Read the Docs zag één crawler 73 TB aan gezipte HTML in één maand ophalen, bijna 10 TB op één dag, voor een bandbreedtefactuur van ruim $5.000. Na het blokkeren van AI-crawlers zakte hun verkeer met 75%. De Wikimedia Foundation meldde dat de bandbreedte voor multimedia met 50% was gestegen sinds januari 2024, waarbij 65% van het duurste verkeer van bots kwam die maar zo'n 35% van de pageviews uitmaken. Op zijn Diaspora-server zag Dennis Schubert 70% van twee maanden verkeer van LLM-bots komen die elke zes uur terugkwamen, robots.txt of niet.

Het wordt erger zodra crawlers zich niet meer kenbaar maken. Drew DeVault schreef dat LLM-scrapers zo'n 20 tot 100% van zijn week opslokten, binnenkomend vanaf tienduizenden residentiële IP's met user-agents die overlappen met echte browsers, met tot gevolg tientallen korte storingen. De GitLab van GNOME raakte zo overspoeld dat van de 81.000 verzoeken in één tijdvak maar 3,2% van een mens kwam. Of die belasting opduikt als een bandbreedte-overschrijding, een schorsing wegens CPU-limieten of gewoon een trage site, hangt volledig af van hoe je host je factureert.

Wie betaalt er echt: de facturatiemodellen

Hier wordt de "tax" geheven, en hosts lopen sterk uiteen. De adder zit in de afgerekende "visit", meestal gedefinieerd als één uniek IP per 24 uur. Of een crawler als visit meetelt is een beleidskeuze, en de meeste providers maken die stilletjes.

WP Engine sluit het duidelijkst uit. Een visit is één uniek IP per UTC-dag, en bekende bot-user-agents tellen niet mee. Sinds september 2025 sluiten ze ook verdachte bots uit: user-agents die niet op de bekende lijst staan maar zich ook niet als mens gedragen. Verzoeken die 403 teruggeven en statische assets tellen evenmin mee. Dat is de sterkste gedocumenteerde bescherming die ik heb gevonden.

Kinsta is zachter dan zijn reputatie doet vermoeden. Het sluit "de meeste bekende" bots uit van de visit-telling, maar de eigen docs zijn er helder over: bot-verkeer kost nog steeds RAM, CPU en bandbreedte, "as such, some bots might be included in your total visits count". Onder de bot-beschermingsfunctie wordt alleen verkeer dat het mét zekerheid als geautomatiseerd herkent uitgesloten; alles wat slechts "likely automated" is, precies waar een nieuwe AI-crawler valt voordat hij op iemands lijst staat, kan alsnog meetellen. Kinsta's overstap naar bandbreedtegebaseerde prijzen in november 2025 belooft "lower risk" op bot-overschrijdingen, maar dat is iets anders dan bot-bandbreedte van de factuur halen.

Pressable en Flywheel sluiten "bekende bots" uit zonder te benoemen of specifieke AI-crawlers op die lijsten staan. SiteGround kiest een heel andere route en blokkeert trainings-AI-crawlers op infrastructuurniveau, terwijl het de crawlers die in live chatsessies worden gebruikt wel toelaat, zodat veel van dat verkeer je origin nooit bereikt. En klassieke cPanel-shared hosting, het "unlimited bandwidth"-niveau, verstopt de kosten in CPU- en proceslimieten: een gulzige crawler knalt geen bandbreedteplafond stuk, hij loopt tegen resource-limieten aan en krijgt je account afgeknepen of geschorst wegens "excessive resource use". Voorspelbare kosten zijn een van de sterkere argumenten voor managed hosting boven een goedkoop shared pakket.

Waarom alles blokkeren de verkeerde reflex is

De reflex zodra je de factuur ziet is één regel in robots.txt: Disallow: / voor alles wat AI is. Dat is een vergissing, want "AI-bot" is niet één ding. Elke grote aanbieder draait aparte, gedocumenteerde crawlers voor aparte taken, en ze kosten en betalen je heel verschillend terug.

OpenAI draait er drie: GPTBot voor training, OAI-SearchBot voor de zoekindex en ChatGPT-User voor realtime ophaalacties die een gebruiker zelf start. De eigen docs zijn duidelijk: blokkeer je OAI-SearchBot, dan wordt je site "will not be shown in ChatGPT search answers", terwijl het blokkeren van GPTBot alleen het verzamelen voor training stopt. Anthropic doet hetzelfde met ClaudeBot (training), Claude-User en Claude-SearchBot. Perplexity splitst PerplexityBot (zoeken, respecteert robots.txt) en Perplexity-User. Google stopt alle controle over AI-training in het Google-Extended-token, waarvan het stelt dat het de Search-ranking niet beïnvloedt en dat geen aparte user-agent heeft die je überhaupt in je logs ziet.

Combineer dat nu met de crawl-tot-referral-verhoudingen. Een trainingscrawler op 50.000:1 blokkeren kost je vrijwel nul referralverkeer, want hij stuurde er toch al geen. Een zoekcrawler blokkeren kost je iets concreets, want dát is degene die je voor gebruikers zet. En de bezoekers die hij stuurt zijn ongewoon waardevol: Ahrefs vond dat AI-zoeken maar 0,5% van zijn bezoekers was, maar 12,1% van zijn aanmeldingen, met een conversie van 23 keer die van klassieke organische zoekresultaten. Alles blokkeren gooit dat weg om verkeer te stoppen dat toch al goedkoop te serveren was. Als AI-zoekzichtbaarheid voor je telt, verdient die afweging meer dan een reflex, en dat sluit direct aan op waarom GEO nog steeds vooral SEO is.

robots.txt is een beleefd verzoek, geen hek

Ook als je de keuze goed maakt, stopt robots.txt alleen de bots die zich eraan willen houden. Het is een bordje in de tuin, geen hek. De net gedragen crawlers respecteren het. De crawlers die je het meest kosten, vaak niet.

Cloudflare beschuldigde Perplexity er in augustus 2025 van stiekeme, niet-aangemelde crawlers in te zetten om no-crawl-regels te omzeilen: 3 tot 6 miljoen verzoeken per dag vanaf een generieke Chrome-user-agent en IP's buiten de gepubliceerde reeksen, tot op honeypot-domeinen die het expliciet verboden. Cloudflare schrapte Perplexity uit zijn programma voor geverifieerde bots; Perplexity bestreed de analyse. Het was niet het eerste zulke bericht: WIRED ontdekte in 2024 dat een niet-aangemeld, aan Perplexity gelinkt IP sites van Condé Nast bleef bezoeken die het had geblokkeerd. TollBit zag het aandeel bots dat robots.txt negeert in één kwartaal stijgen van 3,3% naar 12,9%.

Twee verwante regelaars zijn nog zwakker. Crawl-delay is adviserend, en Google heeft het nooit ondersteund; Bing en Yandex wel, maar een crawler die het negeert ondervindt geen enkel gevolg. En llms.txt, het voorgestelde bestand om modellen op inferentiemoment te sturen, is in de praktijk voorlopig fictie: een audit over 1.000 domeinen in augustus 2025 registreerde nul bezoeken aan llms.txt van GPTBot, ClaudeBot of PerplexityBot, en Googles John Mueller zei botweg dat geen enkel AI-systeem het al gebruikt. Zie het als een gok op de toekomst, niet als een regelaar van vandaag.

Een gelaagde aanpak die wel standhoudt

Je hebt dus lagen nodig, elk doend wat het kan. Het principe: gebruik robots.txt om je bedoeling kenbaar te maken aan eerlijke bots, en dwing de rest af waar bots niet kunnen tegensputteren.

Begin met de bedoeling. Verbied in robots.txt de trainingscrawlers die je geen modellen wilt laten voeden (GPTBot, ClaudeBot, Google-Extended, CCBot) en sta de zoekcrawlers die hun plek verdienen expliciet toe (OAI-SearchBot, Claude-SearchBot, PerplexityBot). Dat ene onderscheid doet het meeste werk.

Dwing daarna af. Rate-limit op de webserver per user-agent, zodat zelfs een crawler die zich misdraagt je workers niet kan verzadigen:

# Koppel AI-crawler-user-agents aan een vlag
map $http_user_agent $ai_crawler {
    default        0;
    ~*GPTBot       1;
    ~*ClaudeBot    1;
    ~*Bytespider   1;
}

# Beperk gevlagde crawlers tot een paar verzoeken per minuut per IP
limit_req_zone $binary_remote_addr zone=ai_zone:10m rate=6r/m;

server {
    location / {
        if ($ai_crawler) {
            limit_req zone=ai_zone burst=4 nodelay;
        }
    }
}

Matchen op user-agent pakt de eerlijke bots; de spoofers pakt het niet. Voor die laatste blokkeer je op gepubliceerde IP-range (OpenAI, Anthropic en Perplexity publiceren allemaal de hunne) en leun je op een WAF die het zware werk doet. Cloudflare biedt sinds juli 2024 op elk pakket, ook gratis, een AI-bot-blokkade met één klik, plus controle per aanbieder en, sinds juli 2025, een pay-per-crawl-model dat HTTP 402 teruggeeft aan crawlers die niet willen betalen. Tegen december 2025 had het 416 miljard AI-bot-verzoeken geblokkeerd. Afdwingen aan de edge telt omdat het verzoek wordt gestopt voordat het ooit je origin bereikt, en dat is het enige punt waarop blokkeren je compute echt bespaart.

Wanneer alles blokkeren juist de juiste keuze is

De selectieve aanpak klopt voor de meeste content-gedreven sites, maar niet voor alle. Draai je een brochuresite, een portfolio of iets wat niets verdient aan vindbaarheid via zoeken en dat ook nooit zal doen, dan kantelt de rekensom: er valt geen referralwinst te beschermen, dus is alles dichtzetten simpeler en goedkoper. Blokkeer de hele zwik aan de edge en klaar.

Hetzelfde geldt voor private of interne applicaties, staging-omgevingen en alles achter een login. Geen enkele crawler, training of zoek, heeft daar iets te zoeken, en de AI-zoekafweging bestaat er niet. Daar is Disallow: / plus een edge-blokkade precies goed, en de enige fout zou zijn dezelfde botte regel toe te passen op een publieke site die je juist gevonden wilt hebben.

Voor alles daartussenin is de vraag niet "bots of geen bots". Het is welke bots hun rekening betalen. Een trainingscrawler die 50.000 pagina's per referral pakt is een kostenpost zonder opbrengst. Een zoekcrawler die op 23 keer organisch converteert is het serveren waard, ook op schaal. De tax zit niet in de crawlers. Hij zit in het betalen voor de verkeerde, op een pakket dat je daar ook nog voor laat dokken.

Belangrijkste punten

  • Het cijfer van ~57% bot-meerderheid klopt, maar het is al het geautomatiseerde verkeer; AI-crawlers waren eind 2025 ~4,2% van de HTML-verzoeken, groeien hard en leunen voor ~80% op training.
  • Crawlerkosten zijn bandbreedte en CPU, geen pageviews. Ongecachte, geparametriseerde URL's maken WordPress extra kwetsbaar. Read the Docs kreeg een maandfactuur van $5.000 door één crawler.
  • Hosts verschillen flink: WP Engine sluit bekende en verdachte bots uit; Kinsta sluit alleen wat het zeker herkent uit, dus nieuwe AI-crawlers kunnen meetellen; shared cPanel verstopt de kosten in CPU-limieten.
  • Trainings- en zoekcrawlers zijn aparte, gedocumenteerde bots. Blokkeer training (50.000:1, geen referral) en houd zoeken (converteert op 23x organisch). Blokkeer ze niet allebei uit reflex.
  • robots.txt, Crawl-delay en llms.txt zijn verzoeken, geen afdwinging. Rate-limit per user-agent, blokkeer per IP-range en zet aan de edge een WAF in voor de rest.

WordPress onderhoud zonder omkijken?

Ik regel updates, backups en beveiliging, en houd performance strak—zodat storingen en traagheid niet terugkomen.

WordPress onderhoud uitbesteden

Doorzoek deze site

Begin met typen om te zoeken, of blader door de kennisbank en blog.