“Vanuit infrastructuurperspectief bestaat er niet zoiets als ‘alleen maar botverkeer'”, aldus Daniel Pataki, CTO van Kinsta. “Elk verzoek is echt werk. Op grote schaal is ineffici\u00ebnt crawlen geen verkeersprobleem meer, maar een probleem met de beschikbare resources.”<\/p>\n
In dit artikel leggen we uit waarom die verschuiving heeft plaatsgevonden, wat het WordPress-site-eigenaren daadwerkelijk kost en hoe het verhaal moet veranderen.<\/p>\n
Het oude model werkt niet meer<\/h2>\n
Traditioneel botbeheer was gebaseerd op een simpel uitgangspunt: blokkeer de slechte en laat de goede door. Jarenlang was dat genoeg. Googlebot crawlde je pagina’s, indexeerde je content en ging weer verder. Kwaadaardige bots probeerden in te breken op je inlogpagina. Twee heel verschillende problemen, twee heel verschillende oplossingen.<\/p>\n
Waar geen van beide modellen rekening mee hield, was een derde categorie: geautomatiseerd verkeer dat niet kwaadaardig is en niet wordt geblokkeerd, maar op grote schaal meetbare schade toebrengt aan de prestaties van je site.<\/p>\n
AI-crawlers<\/a> – bots die niet alleen zijn ontworpen om pagina’s te indexeren voor zoekresultaten, maar ook om content te verzamelen voor het trainen van modellen, retrieval-augmented generation en realtime zoekopdrachten van gebruikers – opereren op een fundamenteel andere schaal dan alles wat er eerder was. GPTBot alleen al groeide met 305% tussen mei 2024 en mei 2025. Begin 2025 was ongeveer \u00e9\u00e9n op de 200 webbezoeken afkomstig van een AI-bot. Tegen het einde van het jaar was die verhouding gestegen naar \u00e9\u00e9n op de 31.<\/p>\n Eind 2025 waren AI-crawlers goed voor 4,2% van alle HTML-verzoeken op het netwerk van Cloudflare, een cijfer dat schommelde van 2,4% begin april tot 6,4% eind juni \u2013 bijna een verdrievoudiging binnen een jaar.<\/p>\n Deze crawlers zijn hardnekkig en komen vaak langs, en ze gedragen zich niet zoals traditionele zoekmachinebots. Veel ervan genereren grote hoeveelheden verzoeken naar niet-gecachete, dynamische endpoints, wat je server ‘echt werk’ bezorgt.<\/p>\n Hier wordt het infrastructuurprobleem duidelijk, en dat is een aspect dat in de meeste analyses van botverkeer over het hoofd wordt gezien.<\/p>\n Als een bezoeker een in de cache opgeslagen pagina op een WordPress-site laadt, hoeft je server bijna niets te doen. Hij stuurt een vooraf opgebouwd HTML-bestand<\/a> terug, net zoals hij een afbeelding of een CSS-bestand<\/a> zou serveren. De oorspronkelijke server merkt er nauwelijks iets van. Dat is juist het hele punt van caching.<\/p>\n Maar een aanzienlijk deel van de verzoeken op een echte WordPress-site, en met name op WooCommerce-winkels, kan niet vanuit de cache worden verwerkt. Deze verzoeken omvatten:<\/p>\n Als een bot deze endpoints bezoekt, gebeurt er het volgende op je server:<\/p>\n Dit is het mechanisme waardoor botverkeer een infrastructuurprobleem wordt. Het is geen theorie. Het is de specifieke reeks gebeurtenissen die plaatsvindt wanneer geautomatiseerde verzoeken dynamische endpoints op een live WordPress-site overspoelen.<\/p>\n Het abstracte wordt concreet als je kijkt naar echte gegevens van de infrastructuur die we op grote schaal beheren.<\/p>\n Een gegeven dat ons bijzonder opviel, is dat \u00e9\u00e9n enkele bot (ClaudeBot) binnen 24 uur 3,75 miljoen ’toevoegen aan winkelwagen’-verzoeken genereerde.<\/strong> Dat is ongeveer \u00e9\u00e9n verzoek per 23 milliseconden (de hele dag, de hele nacht), die allemaal door de server als een nieuw verzoek worden behandeld omdat winkelwagen-endpoints van nature dynamisch zijn.<\/p>\n Om dat even in perspectief te zetten: verzoeken om iets aan de winkelwagen toe te voegen behoren tot de duurste endpoints die een WooCommerce-winkel heeft. Ze maken sessies aan, voeren query’s uit en werken de status van de winkelwagen bij. Elk verzoek kost echt werk. De 3,75 miljoen verzoeken die we op \u00e9\u00e9n dag vanuit \u00e9\u00e9n bron zagen, is het soort verkeerspatroon dat een site offline kan halen.<\/p>\n Een tweede voorbeeld laat zien hoe hardnekkig deze patronen kunnen zijn: \u00e9\u00e9n foutief werkende loop genereerde 550 miljoen verzoeken in 30 dagen<\/strong>, genoeg verkeer om een eigen, speciale afschermingsregel in onze infrastructuur te rechtvaardigen. Dit is geen DDoS-aanval of een malwarecampagne, maar een bot die vastzit in een crawlingloop en herhaaldelijk URL’s opvraagt die hij al heeft gezien.<\/p>\n Dit zijn geen uitzonderlijke gevallen. Het zijn patronen die we overal op ons platform zien.<\/p>\n Een van de meest onderschatte aspecten van het huidige botverkeerprobleem is dat het grootste deel van wat schade aan de infrastructuur veroorzaakt helemaal niet kwaadaardig is. Het is ineffici\u00ebnte automatisering op grote schaal.<\/p>\n Moderne websites, vooral e-commercewinkels, genereren net iets andere URL’s voor in wezen dezelfde pagina:<\/p>\n Voor een mens zijn dit allemaal “dezelfde pagina”. Voor een bot die URL’s volgt, lijkt elke URL een gloednieuwe pagina die gecrawld moet worden.<\/p>\n Dus de bot volgt de eerste link. Die pagina genereert weer een andere URL-variant, die de bot volgt. En dan nog een. En nog een. Hij heeft geen mechanisme om te herkennen dat hij in cirkels ronddraait, en sommige van deze loops bleven dagenlang onopgemerkt op de managed infrastructuur voordat de beveiligingsregels ze opmerkten.<\/p>\n In het rapport over AI- en botverkeer dat we onlangs publiceerden, zei David Belson<\/a>, voormalig hoofd Data Insights bij Cloudflare: \u201eEr is iemand die gisteren geen idee had waar hij mee bezig was, maar vandaag zomaar even een bot in elkaar heeft geknutseld en losgelaten. Die neemt niet eens de moeite om Dit gedrag komt niet altijd van kwaadwillende actoren. Het komt van AI-crawlersystemen die niet zijn ontworpen met kennis van gefacetteerde navigatie, wildgroei aan URL-parameters of door sessies gegenereerde URL’s, wat standaardfuncties zijn op moderne WordPress-sites.<\/p>\n Google zelf noemt gefacetteerde navigatie<\/a> en op parameters gebaseerde URL’s expliciet als een bron van ineffici\u00ebntie bij het crawlen, en merkt op dat bots bijna oneindig veel variaties van dezelfde pagina kunnen verkennen.<\/p>\n Tot voor kort waren veel hostingpakketten afgestemd op het aantal bezoeken, wat redelijk goed werkte als maatstaf voor echt menselijk gebruik. De aanname was dat het aantal bezoeken grofweg overeenkwam met het aantal mensen dat actief met je site bezig was.<\/p>\n Die aanname gaat niet meer op.<\/p>\n Geautomatiseerd verkeer heeft de bezoekersaantallen opgeblazen op een manier die weinig te maken heeft met daadwerkelijke bedrijfsactiviteit. Botverzoeken kunnen bezoekersaantallen genereren zonder dat dit leidt tot bijbehorende betrokkenheid, conversies of omzet. Site-eigenaren kregen overschrijdingsmeldingen bij op bezoekersaantallen gebaseerde pakketten, veroorzaakt door botactiviteit waar ze geen controle over hadden en waar ze niet om hadden gevraagd.<\/p>\n Dit was zo duidelijk een systematisch patroon dat Kinsta hostingpakketten op basis van bandbreedte introduceerde<\/a>, als directe reactie op een categorie sites waarvan de bezoekcijfers aanzienlijk begonnen af te wijken van hun daadwerkelijke verbruik van resources. Als het aantal bezoeken aan een site groeide maar de bandbreedte geen gelijke tred hield, was dat bijna altijd een teken van bots. Door over te stappen op een bandbreedtemodel werd de facturering effectief losgekoppeld van een statistiek die bots hadden leren opblazen.<\/p>\n Het factureringsprobleem is meetbaar en oplosbaar. Het lastigere probleem is dat de meeste site-eigenaren zich hier helemaal niet van bewust zijn, omdat hun dashboards niet het volledige plaatje laten zien.<\/p>\n Een gevolg van botverkeer op deze schaal is dat standaardanalyses geen betrouwbare weergave meer zijn van de werkelijke prestaties van je site.<\/p>\n Als je bezoekersaantallen stijgen, maar je omzet, de tijd op de pagina en het bounce-gedrag niet evenredig meegroeien, spelen bots waarschijnlijk een rol. Als je server prestatieverlies vertoont dat niet overeenkomt met de verkeerspieken die je zou verwachten van content of marketingactiviteiten, is het de moeite waard om botverkeer naar niet-gecachete endpoints te onderzoeken.<\/p>\n Kinsta filtert automatisch bekende bot-user-agents uit de statistieken en berekeningen van je abonnementsgebruik. Maar geautomatiseerd verkeer dat sterk op menselijk gedrag lijkt, kan nog steeds in je statistieken opduiken.<\/p>\n De patronen waar je op moet letten:<\/p>\n Geen van deze factoren is op zichzelf doorslaggevend, maar elke combinatie is reden voor nader onderzoek voordat je de cijfers toeschrijft aan bedrijfsgroei.<\/p>\n De meest voorkomende reactie bij het zien van botverkeersgegevens is om alles te blokkeren. Anderen laten misschien alles toe, omdat \u201eAI de toekomst is”.<\/p>\n Geen van beide werkt!<\/p>\n Zomaar alles blokkeren betekent dat je ook geverifieerde crawlers blokkeert, waaronder Googlebot, waarvan de crawl-dekking bepaalt of je content \u00fcberhaupt in de zoekresultaten verschijnt. Het betekent dat je AI-ontdekkingsbots blokkeert die je content misschien naar voren halen in conversatiegerichte zoekresultaten, AI-aangedreven aanbevelingen of antwoordengines. Voor een WooCommerce-winkel<\/a> of een contentuitgever zijn dat aanzienlijke distributiekosten.<\/p>\n Alles doorlaten betekent dat je infrastructuurkosten accepteert die geen enkel rendement opleveren. En voor de dynamische endpoints die bots het vaakst raken, zijn die kosten niet marginaal. Ze stapelen zich op en worden steeds groter, vooral bij aanhoudende geautomatiseerde belasting.<\/p>\n Het echte antwoord ligt ergens tussenin, en daarvoor moet je de verschillen tussen verkeerscategorie\u00ebn begrijpen in plaats van alle bots als \u00e9\u00e9n groep te behandelen.<\/p>\n Zoals Cristian Lopez, hoofdredacteur bij HostingAdvice, in het rapport<\/a> zei: \u201eDe misvatting is dat je denkt dat botverkeer een simpel ‘blokkeren of toestaan’-probleem is. In werkelijkheid gaat het om beleid, zichtbaarheid en economische controle.”<\/p>\n Geverifieerde bots, zoals Googlebot, Bing en legitieme monitoringtools, moeten over het algemeen worden toegestaan, met eventueel padbeperkingen voor endpoints die geen crawlwaarde hebben (je afrekenpagina draagt bijvoorbeeld niets bij aan je zoekresultaten). Niet-geverifieerde bots zonder identificatiegegevens of duidelijk doel verdienen meer aandacht. AI-trainingscrawlers die grote hoeveelheden verzoeken naar dynamische endpoints genereren, vormen een specifieke categorie die mogelijk geblokkeerd of aan een snelheidsbeperking onderworpen moet worden, afhankelijk van je type website en prioriteiten.<\/p>\n In ons rapport over AI- en botverkeer<\/a> hebben we een interactief besluitvormingskader opgesteld dat de juiste aanpak voor verschillende soorten websites uitlegt. Het onderstaande voorbeeld toont de aanbevolen configuratie voor een WooCommerce-winkel die zich richt op siteprestaties en stabiliteit:<\/p>\n Dat soort genuanceerde, categoriegerichte controle is precies wat de meeste bestaande tools je niet bieden.<\/p>\n De botbescherming van Kinsta<\/a> is speciaal ontworpen voor de infrastructuuruitdagingen die we hierboven beschreven.<\/p>\n Het systeem deelt het verkeer in<\/a> in categorie\u00ebn, zoals geverifieerde bots, waarschijnlijk mensen, waarschijnlijk bots, geautomatiseerd verkeer en kwaadaardig verkeer, en laat je beschermingsniveaus instellen die aansluiten bij de daadwerkelijke behoeften van je site.<\/p>\n De niveaus zijn niet zwart-wit. ‘Blokkeer automatiseringen’ richt zich op bevestigd geautomatiseerd verkeer, terwijl geverifieerde bots met rust worden gelaten. ‘Daag bots uit’ voegt een verificatiestap toe voor niet-geverifieerde automatisering zonder legitieme bezoekers te hinderen. ‘Daag iedereen uit’ is beschikbaar voor periodes van acute verkeersdruk, maar brengt de te verwachten nadelen met zich mee.<\/p>\n Cruciaal is dat de tool is gebaseerd op Cloudflare’s bot-scoring op zakelijk niveau, een realtime classificatie via machine learning die elke bezoeker een score van 1 tot 99 toekent op basis van gedragssignalen, niet alleen op basis van user-agent-strings. Dit is belangrijk omdat het matchen van user-agents alleen steeds minder effectief is: 12,9% van de AI-bots negeert nu Er is ook een ‘Altijd toestaan’<\/a>-uitzonderingssysteem voor vertrouwde integraties, monitoringdiensten en bedrijfskritische automatiseringen die niet door de beveiligingsregels mogen worden tegengehouden, want te veel blokkeren kost ook echt geld, vooral voor WooCommerce-winkels die afhankelijk zijn van geautomatiseerde ordersynchronisatie, betalingsgateway-integraties of uptime-monitors.<\/p>\n De schakelaar voor het blokkeren van AI-crawlers<\/a> richt zich specifiek op AI-trainingsbots, zonder dat dit invloed heeft op crawlers van zoekmachines zoals Googlebot of Bingbot. Voor sites die last hebben van de impact van AI-crawleractiviteit op de prestaties, is dit een eenvoudige oplossing in \u00e9\u00e9n stap, waarvoor je geen individuele regels hoeft in te stellen.<\/p>\n Weten dat de tool bestaat, is \u00e9\u00e9n ding. Weten wanneer en hoe je hem moet gebruiken, is iets anders.<\/p>\n Als je de hierboven beschreven patronen ziet, is dit een praktisch startpunt, gerangschikt op impact:<\/p>\n Ten eerste: controleer de bron.<\/strong> Gebruik de grafiek met verzoekuitsplitsing<\/a> in het botbeschermingsoverzicht van MyKinsta om te begrijpen hoe het verkeer naar je site wordt ingedeeld.<\/p>\n Als een aanzienlijk deel geautomatiseerd of niet-geverifieerd is, is dat voor jou het teken om in actie te komen. Sla deze stap niet over, want beschermingswijzigingen doorvoeren zonder te weten waartegen je je beschermt, leidt tot verkeerde configuraties.<\/p>\n Ten tweede: stem het beveiligingsniveau af op het type site.<\/strong> Een WooCommerce-winkel heeft andere prioriteiten dan een contentwebsite, die weer andere prioriteiten heeft dan een testomgeving. Het blokkeren van geautomatiseerd verkeer en het controleren van vermoedelijke bots is logisch voor een winkel met dynamische endpoints. Een contentwebsite zou er bijvoorbeeld voor kunnen kiezen om AI-ontdekkingsbots toe te laten, terwijl AI-trainingscrawlers worden geblokkeerd. Een testomgeving moet sowieso volledig worden afgesloten.<\/p>\n Ten derde: bescherm eerst de kostbare paden.<\/strong> Voordat je brede beveiligingsregels toepast, moet je nagaan of je duurste endpoints, zoals de winkelwagen, de kassa en AJAX-handlers, toegankelijk zijn voor crawlers die daar niets te zoeken hebben. Het blokkeren van bekende bot-user-agents van Ten vierde: blijf monitoren en pas aan.<\/strong> De patronen van botverkeer veranderen sneller dan de meeste site-eigenaren beseffen. Het aandeel van GPTBot in het verkeer verdrievoudigde binnen \u00e9\u00e9n jaar. Beschermingsregels \u00e9\u00e9n keer instellen en ze daarna negeren is geen strategie. De grafiek met botbeschermingsresultaten<\/a> in MyKinsta houdt bij wat er in de loop van de tijd wordt geblokkeerd, gecontroleerd en toegestaan.<\/p>\n Deze gegevens moeten je helpen bij het afstemmen van je instellingen.<\/p>\n Als bots zorgen voor overschrijdingen van het aantal bezoeken bij een op bezoeken gebaseerd pakket, kan het de moeite waard zijn om tegelijkertijd de op bandbreedte gebaseerde hostingpakketten<\/a> van Kinsta te bekijken. Overstappen naar een pakket op basis van bandbreedte lost het onderliggende botprobleem niet op, maar het geeft wel een beter beeld van de werkelijke infrastructuurkosten van je verkeersmix, die vaak aanzienlijk lager zijn dan het aantal bezoeken doet vermoeden.<\/p>\n Er verschijnt al ‘agentic’-verkeer in infrastructuurlogs. Google heeft een speciale user agent<\/a> aangekondigd voor wanneer zijn AI-agenten met websites communiceren. Dit zijn geautomatiseerde systemen die op links klikken, formulieren invullen en verzoeken doen die steeds meer op menselijk sessiegedrag lijken.<\/p>\n De signalen die nu werken voor het classificeren van bots, zoals user-agent-strings, de frequentie van verzoeken en gedragsscores, worden steeds moeilijker duidelijk toe te passen naarmate de grens tussen geautomatiseerde en menselijke interactie steeds vager wordt.<\/p>\nWat ‘echt werk’ betekent voor een WordPress-site<\/h2>\n
\n
?add-to-cart=<\/code>, \/cart<\/code>, \/checkout<\/code>)<\/li>\n\n
![\"Hoe](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/how-bot-talk-to-server.png\")
Wat de infrastructuurgegevens van Kinsta daadwerkelijk laten zien<\/h2>\n
![\"7,67](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bots-hit-add-to-cart-url.png\")
Het loopprobleem: bots vallen niet aan, ze zitten vast<\/h2>\n
\n
![\"Bots](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-causing-loop-problem.png\")
robots.txt<\/code> te checken.”<\/p>\nJe serverfactuur is nu een botbeheerprobleem<\/h2>\n
![\"Kinsta-hostingpakketten](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/kinsta-bandwidth-hosting-plans.png\")
Wat je analytics je wel (en niet) vertellen<\/h2>\n
\n
Waarom dit een moeilijker probleem is dan het lijkt<\/h2>\n
![\"Interactief](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/ai-bot-traffic-report-decision-framework.png\")
De aanpak van Kinsta voor botbescherming<\/h2>\n
![\"MyKinsta-botbeschermingsniveaus.\"](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-levels-mykinsta.png\")
robots.txt<\/code>-richtlijnen, een stijging ten opzichte van 3,3% slechts \u00e9\u00e9n kwartaal eerder. Gedragsclassificatie vangt op wat op user-agents gebaseerde regels missen.<\/p>\n![\"Altijd](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/always-allow-exception-bot-protection-mykinsta.png\")
![\"Blokkeer](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/mykinsta-bot-protection-ai-crawlers.png\")
Wat te doen als botverkeer je probleem is<\/h2>\n
![\"Grafiek](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-request-breakdown-mykinsta.png\")
\/cart<\/code> en ?add-to-cart=<\/code> via robots.txt<\/code> is een begin; door dit op WAF-niveau af te dwingen (en niet alleen te signaleren) voorkom je daadwerkelijk de belasting.<\/p>\n![\"Grafiek](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-protection-results.png\")
Het grotere plaatje: dit probleem wordt alleen maar lastiger<\/h2>\n