AI- en botverkeer
de reality check
Wat 10 miljard verzoeken, defecte crawlers en WordPress-infrastructuur laten zien over de nieuwe realiteit van botverkeer.
Ga naar een sectie
Je analytics liegen tegen je: een flink deel van het 'verkeer' op je website is niet menselijk.
De meeste adviezen die je tegenkomt, helpen weinig. Je hoort dat je alles moet blokkeren, of juist alles moet toelaten omdat AI de toekomst is. Geen van beide standpunten helpt je om een WordPress site écht te beheren.
Het afgelopen jaar is botverkeer veel meer geworden dan een veiligheids- of SEO-probleem. Inmiddels is het een uitdaging voor de hele infrastructuur. Crawlers bevragen dynamische endpoints, lopen vast in query string-loops, omzeilen de cache en veroorzaken verkeerspatronen die minder lijken op normale indexering en meer op kapotte automatisering, en dat allemaal op reusachtige schaal.
Een paar belangrijke bevindingen
Om te begrijpen wat er veranderd is, doken we in onderzoek uit de sector, spraken we met engineers en mensen uit de praktijk, en analyseerden we meer dan 10 miljard verzoeken op door Kinsta beheerde infrastructuur. De conclusie? Niet om alles maar te blokkerenof alles toe te laten, maar een pleidooi om beter erover na te denken.
Inzichten van
onze bijdragers
“Vanuit een infrastructuurperspectief bestaat er niet zoiets als 'gewoon botverkeer'. Achter elk verzoek zit een verhaal. Op grote schaal is inefficiënt crawlen niet langer een verkeersprobleem, maar een resourceprobleem.”
“Het meeste van wat we zien, is niet schadelijk of heeft slechte intenties. Het zijn bots die zich op grote schaal inefficiënt gedragen, en daar beginnen de echte problemen.”
“De misvatting is dat botverkeer een simpel 'blokkeren of toelaten'-probleem zou zijn. In werkelijkheid draait het om beleid, inzicht en economische controle.”
Meer bots zijn niet het probleem.
Wat veranderd is, is hoe ze zich gedragen.
Jarenlang ging het gesprek over botverkeer vooral over aantallen.
Teams hielden bij hoeveel verkeer geautomatiseerd was, filterden de duidelijke schadelijken eruit en gingen verder. Die aanpak werkte zolang de meeste bots zich voorspelbaar gedroegen: pagina's crawlen, content indexeren en weer vertrekken.
Dat model gaat niet meer op. De afgelopen twee jaar worden bots niet meer ontworpen om alleen content te indexeren voor zoekresultaten, maar om die op grote schaal te verwerken voor het trainen van modellen, retrieval-augmented generation en query's die door gebruikers worden gestart. Deze crawlers zijn gretiger, sneller en fundamenteel minder netjes in hun gedrag dan alles wat we eerder zagen.
Eind 2025 waren AI-crawlers goed voor 4,2% van de HTML-verzoeken op het netwerk van Cloudflare, en samen met het verkeer van crawlers als Googlebot liep dat cijfer op tot 8,5%. Tegelijkertijd zagen teams die websites draaiden en beheerden patronen ontstaan zoals herhaalde verzoeken, loops en grote aantallen hits op endpoints met weinig waarde, die helemaal niet meer op traditioneel crawlen leken.
Die 4,2% is een jaargemiddelde. Het werkelijke cijfer schommelde van 2,4% begin april naar 6,4% eind juni (bijna een verdrievoudiging binnen één jaar). GPTBot alleen al groeide 305% tussen mei 2024 en mei 2025. Van alle crawlactiviteit is 80% puur gericht op het trainen van modellen (niet op zoek- of gebruikersquery's). Het levert je site geen enkel verwijzend verkeer op.
Googlebot is in zijn eentje goed voor ~4,5% van het HTML-verkeer, meer dan alle niet-Google AI-bots samen. De crawler bezocht 11,6% van de unieke webpagina's, vergeleken met 3,6% voor GPTBot, en piekte eind april op 11% van alle HTML-verzoeken. Googlebot blokkeren om de serverbelasting te verlichten zou zo'n beetje de meest contraproductieve zet zijn die een site-eigenaar kan maken.
Cloudflare Radar 2025 Year in Review
Het grotere plaatje
De meeste bots vallen je niet aan.
Ze zitten gewoon vast.
De meeste AI-crawlers zijn ontworpen om elke link te volgen die ze tegenkomen en elk uniek adres vast te leggen. Die aanpak werkt prima op eenvoudige sites. Maar moderne websites, en zeker e-commercewinkels, genereren heel licht verschillende URL's voor in wezen dezelfde pagina.
Het team zag bijvoorbeeld dat meta-externalagent (de crawler van Facebook/Meta) op meerdere sites herhaaldelijk variaties van query strings doorliep. Voor een mens is een productlink met een kleurfilter, een winkelwagenpagina met een aantal en een agendapagina met een sorteervolgorde duidelijk dezelfde pagina. Voor een bot die URL's volgt, ziet elk daarvan er gloednieuw uit.
Dus de bot volgt de eerste link, die pagina genereert een nieuwe variatie, die de bot volgt. En nog een. En nog een. Hij heeft geen manier om te herkennen dat hij van het kastje naar de muur wordt gestuurd, en sommige van deze loops bleven dagenlang onopgemerkt voordat de infrastructuurregels ze opvingen.
Dit soort gedrag komt niet altijd voort uit zeer geavanceerde systemen.
Zoals David Belson van Cloudflare opmerkt, opereert niet elke bot met dezelfde mate van discipline: "Je hebt de persoon die gisteren niks kon, maar met vibecoding snel een bot in elkaar knutselt en heeft losgelaten - ze nemen niet eens de moeite om robots.txt te checken."
7,67 miljoen verzoeken naar add-to-cart-URL's in 24 uur
Zelfs de crawler van Google, degene die je absoluut niet kunt blokkeren, liep in dezelfde val.
Om de cijfers in perspectief te plaatsen: 3,75 miljoen verzoeken in 24 uur is ruwweg één verzoek elke 23 milliseconden, de klok rond, en elk daarvan wordt op de server behandeld als een nieuw verzoek in plaats van als iets dat uit de cache kan komen.
Op grote schaal is dit soort gedrag niet altijd bewust.
"Je kunt niet zomaar lukraak van alles afvuren," legt Belson uit. "Je moet je gedragen als een verantwoordelijke eindgebruiker. Je kunt een website niet platleggen met verzoeken."
Je server weet niet dat hij
met een bot praat
Het gedrag zelf is niet het probleem. Als elk verzoek goedkoop was, zouden loops en herhaalde bezoeken weinig uitmaken.
Op een eenvoudige statische pagina kunnen de meeste verzoeken uit de cache worden geleverd. De server geeft een gecachte versie van de pagina terug en de kosten per verzoek blijven laag.
Dat model loopt snel vast op echte WordPress sites, zeker die met WooCommerce, zoekfunctionaliteit, filters of veel plugins.
Een groot deel van het verkeer komt niet terecht op statische pagina's. Het komt terecht op endpoints zoals:
Deze zijn niet op dezelfde manier cachebaar. Ze vragen de server om elke keer echt werk te verrichten.
Elk verzoek veroorzaakt
Voor de volledige duur van elk verzoek wordt een PHP-thread (voorheen PHP-worker) aan het werk gezet. Bij aanhoudende botbelasting raken de threads uitgeput en moeten échte bezoekers wachten.
Dynamische pagina's bevragen je database bij elke laadbeurt. Geen enkele cachelaag kan dat op grote schaal opvangen.
Winkelwagen- en checkoutpagina's maken sessies aan of valideren ze, wat overhead oplevert, zelfs voor bots die nooit converteren.
De nadelen voor SEO
Is dit een aanval? Normaal botgedrag? Iets ertussenin? Juist die onduidelijkheid maakt het zo lastig op te lossen. Omdat dezelfde patronen zowel je prestaties als je vindbaarheid beïnvloeden, hangt de juiste reactie af van wat je probeert te beschermen.
Kies waarvoor je
optimaliseert
Als je hebt gezien hoe bots zich gedragen en welke impact ze kunnen hebben, is de natuurlijke reactie: blokkeren. Maar bots klakkeloos blokkeren is niet de oplossing, en de deur wagenwijd openzetten ook niet.
Zoals Belson het verwoordt: "Je moet de eerste stap zetten en een uitsmijter voor de deur neerzetten die bepaalt wie er binnenkomt en wie niet."
Niet alle bots zijn schadelijk, en niet al het verkeer hoort op dezelfde manier behandeld te worden. Sommige bots zorgen voor vindbaarheid, sommige verbruiken resources zonder iets toe te voegen, en weer andere zitten daar ergens tussenin.
Zelfs op netwerkniveau is het doel niet om alle bots uit te bannen. "Ik ben niet iemand die zou aanraden om alle bots te blokkeren," zegt Belson. "In een deel van dat verkeer zit echte waarde."
De uitdaging is nu niet meer of bots goed of slecht zijn. Het draait om begrijpen hoe verschillende keuzes je site beïnvloeden, en hoeveel van elke afweging je bereid bent te accepteren.
Cristian Lopez, Managing Editor van HostingAdvice, verwoordt het zo: "De misvatting is dat het simpelweg een 'blokkeren of toelaten'-kwestie zou zijn. In werkelijkheid is het inmiddels een vraagstuk van beleid, inzicht en economische controle."
Vindbaarheid en prestaties
Zoekcrawlers zijn essentieel om mensen je site te laten vinden, maar ze werken niet altijd efficiënt, en dat vraagt om balans. Ze te agressief blokkeren kan je zichtbaarheid in zoekresultaten beperken, terwijl onbeperkte toegang onnodige belasting met zich meebrengt, vooral wanneer ze dynamische pagina's gaan raken die echte verwerking vereisen in plaats van vanuit de cache te worden geserveerd.
Het doel is niet om voor het een of het ander te kiezen, maar om te sturen hoeveel je van elk toelaat, op basis van hoe je site zich daadwerkelijk gedraagt.
Toegang- en resourcekosten
Sommige bots leveren indirecte waarde. Denk aan AI-systemen die naar je content verwijzen, tools die je pagina's indexeren of diensten die data van het hele web aggregeren. Maar elk verzoek brengt kosten met zich mee in de vorm van CPU-gebruik, database-query's, geheugen en bandbreedte. Naarmate die activiteit toeneemt, worden de kosten merkbaar. Ze stapelen zich op en gaan impact hebben.
Niet alle toegang hoeft onbeperkt te zijn. De waarde die een bot biedt, moet je afwegen tegen de kosten die hij met zich meebrengt.
Controle en eenvoud
In eenvoudige gevallen kan automatisering botbeheer prima afhandelen, maar de juiste aanpak hangt uiteindelijk af van het type site dat je draait, het soort verkeer dat je ziet en wat voor jouw doelen het zwaarst weegt. Volledig leunen op automatisering kan dingen vereenvoudigen, maar het betekent ook dat je niet zelf vormgeeft hoe die beslissingen voor jouw specifieke site worden genomen.
De beste systemen dwingen je niet om te kiezen tussen gemak en controle. Ze laten je eenvoudig beginnen en bijsturen waar het ertoe doet.
Die overlap zorgt voor verwarring. Het verkeer piekt, de prestaties zakken, en het is niet altijd duidelijk of je moet blokkeren, toelaten of negeren, zelfs niet voor hetzelfde patroon op twee verschillende sites.
"Moet ik bots toelaten?"
"Welke bots, op welke delen van mijn site, onder welke voorwaarden?"
Die vraag beantwoorden vraagt om een andere manier van denken. Daar duiken we in het volgende onderdeel in.
Een betere manier om te bepalen wat je
toelaat, uitdaagt of blokkeert
Er bestaat geen universeel botbeleid dat voor elke site werkt. Een WooCommerce-winkel, een contentsite, een zakelijke website en een testomgeving hebben niet met dezelfde risico's te maken en vragen ook niet om dezelfde oplossingen.
De juiste aanpak hangt af van wat je site doet, wat voor verkeer hij ontvangt en waarop je probeert te optimaliseren. In de meeste setups wordt dit soort beslissingen afgehandeld door infrastructuurtools en niet handmatig per verzoek geconfigureerd, maar door de logica te begrijpen weet je wat er namens jou draait, en wanneer het zinvol is om bij te sturen.
Wat hier telt is niet alleen verkeer, maar het soort zichtbaarheid dat je wilt: zoekresultaten, vermeldingen in AI-antwoorden of directe bezoeken van gebruikers.
Je prestatieproblemen komen waarschijnlijk door bots die de add-to-cart- en checkout-endpoints van WooCommerce bevragen. Die omzeilen de paginacache volledig en forceren bij elk verzoek PHP-uitvoering en database-query's. De oplossing is niet om alles te blokkeren. Het doel is om gericht deze paden te beschermen.
/cart, /checkout en ?add-to-cart=-paden blokkeren via robots.txt/shop?add-to-cart= en /checkout in robots.txt./shop, /product/ en categoriepagina's om je winkel te kunnen ranken. Beperk de bot alleen op specifieke dynamische endpoints, niet op de hele site.De configuraties hierboven laten zien hoe het beheren van botverkeer eruitziet als je het handmatig doet. In de praktijk handelt Kinsta's Botbescherming het merendeel van deze patronen automatisch af. Schakel het door jou gewenste beschermingsniveau één keer in, en ons systeem regelt de rest (geen regels per pad of handmatige uitzonderingen nodig).
De meeste systemen waren niet ontworpen
voor dit niveau van controle
De meeste platforms beheren botverkeer ofwel automatisch door achter de schermen beslissingen te nemen, ofwel via instellingen die handmatige configuratie vereisen.
Automatische systemen vangen de duidelijke dreigingen af en laten bekende crawlers door, maar ze houden geen rekening met hoe verkeer zich op specifieke onderdelen van je site gedraagt, of wat het je kost. In sommige gevallen worden legitieme AI-crawlers aan de edge geblokkeerd, wat een blinde vlek op het gebied van vindbaarheid creëert waar de meeste teams nooit weet van hebben.
Handmatige controle biedt meer flexibiliteit. Maar dat vraagt vaak om een mate van precisie die de meeste site-eigenaren niet de tijd hebben om continu bij te houden. En zonder houvast zijn die instellingen makkelijk verkeerd te configureren.
Wat ontbreekt is niet zomaar controle, maar bruikbare controle.
De mogelijkheid om gedrag bij te sturen waar het ertoe doet, zonder essentieel verkeer te breken, en zonder je hele aanpak opnieuw op te bouwen telkens als er iets verandert.
De meeste sites hebben geen volledige automatisering of volledige controle nodig. Ze hebben de mogelijkheid nodig om gerichte beslissingen te nemen, zonder hun complete verkeersstrategie opnieuw te bouwen elke keer als de patronen veranderen.
Op dit punt is de uitdaging niet meer om botverkeer te identificeren. Het is om het te beheren op een manier die past bij hoe je site daadwerkelijk werkt.
Hoe de juiste reactie eruitziet
in verschillende situaties
Op dit punt is het patroon duidelijk: er is geen enkele regel die overal werkt. De juiste reactie hangt af van wat voor site je draait, wat voor verkeer je ziet en hoe urgent de situatie is.
Wat volgt is geen checklist. Het is een manier om na te denken over wat je nu moet doen, op basis van waar je op dit moment staat.
Begin met in kaart brengen, en neem dan één gerichte beslissing
Kijk eerst naar wat je verkeer daadwerkelijk is voordat je iets verandert. Je hoeft niet elke bot te identificeren. Je zoekt naar patronen: herhaalde verzoeken aan dezelfde soorten URL's, vooral URL's die voor een crawler niet relevant horen te zijn, zoals cart-endpoints of pagina's met veel parameters. De meeste analyticstools of serverlogs geven je genoeg inzicht om dit gedrag op te merken.
De meeste platforms filteren de duidelijkst kapotte patronen al weg, zoals overduidelijke loops of bekend misbruikverkeer. Zorg dat die standaardbescherming actief is en geef die de tijd om zijn werk te doen. Ze zijn meestal bewust voorzichtig ingesteld, wat betekent dat ze de ruis verminderen zonder legitieme bezoekers of zoekcrawlers te raken.
Als je een patroon ziet, acteer dan op dat patroon (niet op alles tegelijk). Raken bots herhaaldelijk dynamische endpoints? Beperk dan de toegang tot die paden. Scrapen specifieke crawlers content agressief? Bepaal dan of die toegang de kosten waard is. Het doel in deze fase is geen perfectie; het is overbodige belasting verminderen zonder nieuwe problemen te introduceren.
Pas dit proces toe op een paar verschillende klantsites. De patronen die je ziet op een e-commerce site, een contentsite en een dienstensite zijn verschillend, maar consistent genoeg om een herhaalbare aanpak op te bouwen voor klantgesprekken.
Botverkeer gaat niet weg.
Je strategie moet
Op dit punt is het patroon duidelijk. Botverkeer is niet langer iets dat je kunt behandelen als incidentele ruis of aan kunt negeren. Het is een constant, evoluerend onderdeel geworden van hoe websites worden benaderd en belast.
Wat het lastig maakt is niet alleen het volume, maar de overlap. Dezelfde systemen die mensen je site helpen vinden, kunnen ook resources opslokken, en patronen die op normaal crawlen lijken, kunnen zich op grote schaal gedragen als inefficiënte automatisering.
Er is dus geen enkele regel die overal werkt.
De juiste aanpak hangt af van je site, je verkeer en wat je probeert te beschermen. Het vereist dat je begrijpt hoe je site zich daadwerkelijk gedraagt en beslissingen neemt die die realiteit weerspiegelen.
Dit soort verschuiving is niet helemaal nieuw in de evolutie van het web. Jordan Sprogis, Contributing Expert bij HostingAdvice, verwoordt het zo: "Het verschilt niet veel van waar SSL ooit stond. SSL was lange tijd een betaalde add-on; inmiddels zitten SSL-certificaten bij vrijwel elk hostingpakket inbegrepen."
Meestal is het doel om onnodige belasting te verminderen, je zichtbaarheid te behouden waar die telt en een systeem te onderhouden waarop je kunt vertrouwen wanneer er dingen veranderen. Wat hierna komt, wordt lastiger te categoriseren. Agentic traffic, geautomatiseerde tools die zelf acties uitvoeren, duikt nu al op in infrastructuurdata. Google kondigde recent een speciale user-agent aan om vast te leggen wanneer zijn AI-agents met sites interacteren. De verantwoordelijke platforms zullen zich identificeren, crawl delays respecteren en endpoints met rust laten die geen doel dienen. Andere niet. De grens tussen een menselijke bezoeker en een agent zal verder vervagen.
En als geautomatiseerd verkeer je bezoekersaantallen opblaast, geven ruwe cijfers de realiteit niet meer weer. De signalen die er nu toe doen, zijn de gecorreleerde signalen: branded search volume, direct verkeer, engagementkwaliteit en omzet die gekoppeld is aan echt bezoekersgedrag. Bewegen die metrics ook? Dan weet je dat je zichtbaar bent waar het telt.
Bepaal hoe bots met je WordPress site omgaan, zonder je zichtbaarheid in zoekresultaten te breken
Met Kinsta's Botbescherming krijg je controle op omgevingsniveau met doordachte standaardinstellingen, zodat je kunt sturen hoe verschillende soorten verkeer met je site omgaan, zonder zoekmachines te blokkeren of je vindbaarheid in gevaar te brengen.
Dit rapport wordt je aangeboden door Kinsta.
Kinsta is een premium managed WordPress hostingplatform met meer dan 230.000+ klanten wereldwijd. #1 op G2 voor klanttevredenheid. 24/7 deskundige support in 10 talen.
Iemand in je team zou dit waarschijnlijk moeten zien.
Managed hosting voor WordPress