In 2025 waren bots goed voor 53% van al het webverkeer. Dat was de eerste keer dat geautomatiseerd verkeer in een kalenderjaar het menselijke verkeer voorbijstreefde. In juni 2026 schatte Cloudflare Radar dat cijfer op 57,5%: een omslag die volgens de CEO van Cloudflare jaren eerder kwam dan hij had verwacht.
Voor de meeste WordPress-beheerders is daar weinig van te merken. Hun dashboards ogen normaal. Het aantal bezoeken stijgt. Maar een steeds groter deel van wat die cijfers opdrijft komt niet van klanten, lezers of potentiële klanten, maar van een AI-crawler die content verzamelt om een taalmodel te voeden, op een schaal en snelheid die zoekmachinebots nooit hebben gehaald.
In dit artikel leg ik uit waarom dit anders uitpakt voor WordPress sites dan traditionele crawling, en hoe je het opspoort en er direct vanuit MyKinsta op reageert.
Wat is een AI-crawler?
AI-crawlers zijn geautomatiseerde bots die openbaar toegankelijke webpagina’s lezen en de inhoud verzamelen voor gebruik in AI-systemen. Op het eerste gezicht lijkt dat op een traditionele zoekmachinecrawler, maar het doel verschilt.
Een zoekcrawler als Googlebot leest een pagina om die te indexeren en te rangschikken, zodat bezoekers je kunnen vinden. Een AI-crawler leest dezelfde pagina om die in te voeren in een taal- of trainingsmodel. Dat gebeurt op een van deze manieren:
- Trainingscrawlers (zoals GPTBot en ClaudeBot) verzamelen tekst om grote taalmodellen te trainen.
- Ophaalcrawlers halen pagina’s in realtime op zodra iemand een AI-tool een vraag stelt waarvoor actuele informatie nodig is.
- Indexeringscrawlers bouwen een eigen zoekdatabase op voor een aanbieder, om minder afhankelijk te zijn van derden.
Wat ze gemeen hebben: geen van deze crawlers levert je een bezoeker op. De identificatie maakt het bovendien onvoorspelbaar. Sommige AI-crawlers gebruiken een herkenbare user agent en blijven binnen gepubliceerde IP-bereiken. Andere lenen de user agent van een legitieme browser, wisselen van bronadres, of identificeren zich helemaal niet betrouwbaar.
Kortom: het verkeer is lastiger toe te wijzen en groeit snel. Volgens de 2025 Radar Year in Review van Cloudflare waren AI-crawlers buiten Googlebot om goed voor gemiddeld 4,2% van de HTML-verzoeken, met uitschieters van 2,4% in april tot 6,4% in juni. Tel daar Googlebot bij op, die inmiddels zowel voor zoekindexering als voor AI-training crawlt, en het totale AI-gerelateerde crawlen kwam in 2025 uit op zo’n 8,7% van de HTML-verzoeken.
De crawlnormen waar zoekmachines zich aan houden
Om deze verandering te begrijpen, helpt het om te kijken naar wat de oude afspraak inhield. Zoekcrawling draaide op gezamelijke, voorspelbare regels en normen, waardoor site-eigenaren hun planning erop konden afstemmen. Het Robots Exclusion Protocol verscheen in 1994 en werd in 2022 officieel vastgelegd als internetstandaard. Daaromheen ontstonden vier gedragsregels die het mogelijk maakten om je infrastructuur op traditionele crawlers af te stemmen:
- Respect voor het
robots.txt-bestand. Een crawler las het bestand, zag welke paden waren uitgesloten en bleef daar weg. - Automatische beperking. De grote crawlers namen gas terug als een server het zwaar kreeg, zodat een overbelaste site minder verzoeken kreeg in plaats van meer.
- Consistente identificatie. Een stabiele user agent betekende dat je een crawler kon verifiëren en zelf kon bepalen hoe je ermee omging.
- Werken binnen een crawlbudget. Google definieert het crawlbudget van een site als de verzameling URL’s die Googlebot kan en wil crawlen. Daardoor wordt geen enkele site onbeperkt gecrawld.
Daaraan gekoppeld is de crawl delay: de tijd die een crawler wacht tussen twee paginaverzoeken. Dat is een onofficiële richtlijn, die Google nooit heeft ondersteund en buiten de standaard heeft gelaten. Googlebot past zijn crawlsnelheid in plaats daarvan dynamisch aan op basis van hoe snel je server reageert. De verwachting is dat een crawler de situatie inschat en zichzelf bijstuurt.
Die conventies zitten ingebakken in hoe hosting werkt. Cachinglagen bestaan bijvoorbeeld omdat nette crawlers dezelfde pagina’s voorspelbaar genoeg opvragen om ze vanuit de cache te serveren. Het hele model gaat ervan uit dat crawlers zich aan de regels houden.
Waar AI-crawlers die normen doorbreken
AI-crawlers spelen op drie punten volgens andere regels:
robots.txtwordt als optioneel beschouwd. Uit rapporten van TollBit blijkt dat het aantal bots dat de richtlijnen in robots.txt negeert flink is toegenomen. Diezelfde rapporten melden dat Cloudflare een grote AI-zoekmachine betrapte die content ophaalde op sites die dat expliciet hadden verboden.- Er wordt niet afgeremd. Veel AI-crawlers sturen verzoeken in een constant hoog tempo, ongeacht hoe je server reageert. Soms is dat niet eens opzet, omdat mensen “zomaar een bot in elkaar knutselen… en hem loslaten” zonder ooit
robots.txtte bekijken. - Crawlers lopen vast in loops. Dat is een kostbaar patroon dat eerder structureel is dan kwaadwillig. De meeste crawlers volgen elke link die ze tegenkomen en registreren elke unieke URL als een aparte pagina. AI-crawlers volgen één variant, die een volgende oplevert, die ze weer volgen, zonder door te hebben dat ze rondjes draaien.
Het vervelende is dat de meeste AI-crawling bedoeld is om modellen te trainen en niet om zoekopdrachten of gebruikersvragen te beantwoorden. Er komt dus geen verwijzingsverkeer naar je site terug.
Waarom dit je server als prestatieprobleem raakt
Het volume is hier niet het echte probleem. Een statische pagina uit de cache kost je vrijwel niets, dus duizend cache-hits merk je nauwelijks. De problemen beginnen zodra verkeer de cache omzeilt, en crawlers die in een loop zitten zijn goed in het vinden van precies die routes.
Op een WordPress site met WooCommerce zijn het vooral zoek- en filterverzoeken die dynamische endpoints raken in plaats van pagina’s. Denk hierbij aan winkelwagenacties, varianten van de ?add-to-cart=-parameter, gefilterde productpagina’s, zoekopdrachten en AJAX-gestuurde interacties die via admin-ajax.php lopen. Geen van die verzoeken is te cachen zoals een artikel, dus elk verzoek zet de server aan het werk:
- PHP-uitvoering. Voor de volledige duur van elk verzoek wordt een PHP-thread bezet gehouden. Bij aanhoudende botbelasting raken de threads op en komen echte bezoekers achter de bots in de wachtrij.
- Databasequery’s. Dynamische pagina’s doen bij elke laadbeurt een beroep op de database, omdat er geen cachelaag is die de query opvangt.
- Sessiebeheer. Winkelwagen- en afrekenpagina’s maken of valideren bij elk verzoek een sessie. Dat kost extra capaciteit, ook voor bots die nooit iets kopen.
Uit de infrastructuurgegevens van Kinsta blijkt dat één enkele bot in 24 uur 3,75 miljoen verzoeken naar add-to-cart-URL’s genereerde. Dat is ongeveer één verzoek per 23 milliseconden, de klok rond. De symptomen ogen als afwijkend gebruik: bandbreedte die overloopt, uitgeputte PHP-processen en tragere responstijden voor echte bezoekers. Het lijkt op gewone crawling in plaats van op een aanval, en daarom wordt het makkelijk over het hoofd gezien.
Hoe herken je AI-crawleractiviteit in MyKinsta
Voordat je instellingen aanpast, controleer je eerst of crawlers echt de oorzaak zijn. MyKinsta geeft je drie overzichten die samen van een vermoeden een diagnose maken.
Ga in MyKinsta eerst naar Sites > sitenaam > Botbescherming. De grafiek Breakdown verzoeken toont alle verzoeken die de afgelopen 24 uur naar je site zijn gestuurd en hoe Kinsta ze classificeert.
De categorie Agressieve AI-crawlers filtert de bots eruit die zoveel verzoeken genereren dat ze de prestaties in gevaar brengen. Valt een groot deel van de grafiek in die categorie, dan heb je te maken met crawlerverkeer en niet met een echte piek in bezoekers.
De grafiek Resultaten botbescherming laat zien wat er met dat verkeer is gebeurd, opgesplitst in verzoeken die zijn toegestaan, gechallenged of geblokkeerd. Zo zie je hoeveel geautomatiseerd verkeer je site nu bereikt en hoeveel er wordt weggefilterd voordat het zover komt. Leg je beide grafieken naast elkaar, dan zie je of de belasting al wordt opgevangen of rechtstreeks bij je server terechtkomt.
Om het verkeer te koppelen aan de vertraging, bekijk je de lijst van Top client IP’s in de Analytics van MyKinsta:
Hier zie je welke adressen de meeste verzoeken sturen, waarbij je via elk IP-adres doorklikt naar een opzoekdienst om de herkomst te controleren. Open tot slot het tabblad Prestatie en leg de pieken in responstijd naast de periodes met intensief crawlen. Stijgen en dalen het resourcegebruik en het botvolume samen, dan is de volgende stap het inkomende verkeer beheersen.
Hoe je AI-crawlers beheert met de botbescherming van Kinsta
Zodra je de bron hebt vastgesteld, geeft de Botbescherming van Kinsta je controle over elk type verkeer. Deze feature komt bovenop de platformbeveiliging die duidelijk kwaadaardig verkeer al wegfiltert, en zit bij alle pakketten inbegrepen.
Het paneel Beschermingsniveau op de pagina Botbescherming in MyKinsta biedt vier instellingen:
- Blokkeer kwaadaardig verkeer is de standaardinstelling. Deze zorgt voor DDoS-mitigatie en blokkeert IP-adressen en endpoints die gekoppeld zijn aan bekende aanvalsbronnen.
- Blokkeer automatiseringen voegt een laag toe die bevestigd geautomatiseerd verkeer tegenhoudt, terwijl geverifieerde bots en echte bezoekers wel worden doorgelaten.
- Daag bots uit voegt een verificatiestap toe voor vermoedelijke bots. Een bezoeker die daar doorheen komt, krijgt tien dagen lang geen nieuwe challenge op dezelfde browser en hetzelfde IP-adres.
- Geef iedereen een challenge is de strengste instelling en laat alleen geverifieerde bots door. Zet je dit in, doe dat dan kort en gericht tijdens een actieve piek.
Vanaf de instelling Daag bots uit of hoger krijgt elke tool die programmatisch verbinding maakt met je site en niet in de lijst met geverifieerde bots van Cloudflare staat een challenge, of wordt geblokkeerd. Controleer daarom of je bedrijfskritische tools op die lijst staan voordat je het niveau verhoogt.
Kinsta voegt eigen regels toe aan de lijst met geverifieerde bots van Cloudflare. Geverifieerde AI-bots die grote aantallen verzoeken genereren, belanden daardoor in de aparte categorie Agressieve AI-crawlers.
De logica hierachter: beoordeel een crawler op zijn gedrag in plaats van op zijn inloggegevens, zodat een geverifieerde bot die je site overspoelt wordt behandeld als het probleem dat hij geworden is. Zet je de bescherming op Daag bots uit of hoger, dan geef je legitieme diensten met veel volume de kans zich te bewijzen, terwijl crawlers die in een loop vastzitten eruit worden gefilterd.
Andere features van de botbescherming in MyKinsta
De schakelaar Blokkeer AI-crawlers staat los van het beschermingsniveau en richt zich specifiek op AI-crawlers, inclusief geverifieerde exemplaren als GPTBot. Googlebot en Bingbot blijven je site hoe dan ook indexeren, dus je haalt de belasting van AI-crawlers weg zonder je zichtbaarheid in zoekmachines aan te tasten.
Dat is netter dan handmatig robots.txt bewerken of regels per bot bijhouden, maar weeg de voor- en nadelen af voordat je de schakelaar omzet.
Als je AI-crawlers blokkeert, duikt je content minder vaak op in door AI gegenereerde antwoorden en samenvattingen. En omdat AI-tools voor sommige doelgroepen een steeds belangrijker ontdekkingskanaal worden, heeft volledig uitschakelen gevolgen die verder reiken dan alleen de serverbelasting.
Voor sites waar prestaties voorop staan, zoals WooCommerce-winkels, sites met veel verkeer of lidmaatschapsplatforms, zijn de kosten van AI-crawling hoog en het rendement laag. Loop je tegen problemen aan, dan is blokkeren waarschijnlijk de betere keuze. Voor sites waar content centraal staat en zichtbaarheid via AI een strategische prioriteit is, filteren Blokkeer automatiseringen of Daag bots uit het ergste gedrag eruit, terwijl je content indexeerbaar blijft voor AI-platforms.
Er is geen universeel juist antwoord. De schakelaar is er om jou die keuze te geven.
Strengere bescherming kan ook geautomatiseerd verkeer tegenhouden waar je juist op leunt, dus twee instellingen houden dat verkeer in beweging. In het gedeelte Altijd toestaan voeg je tot 50 uitzonderingen toe op basis van IP-adres, pad of user agent. Daar zet je neer wat nooit een challenge mag krijgen, zoals een monitoringdienst, een betalingswebhook of een vertrouwd IP-adres van je kantoor of je klant.
Het inschakelen van de optie Typische WordPress automatiseringen toestaan zet een beheerde lijst met toegestane WordPress-endpoints en -diensten aan, waaronder de REST API en achtergrondtaken. Zet die aan naast strengere bescherming wanneer je site afhankelijk is van plugins, integraties of geplande taken die geautomatiseerde verzoeken doen. Zo verstoort het aanscherpen van je beveiliging je workflow niet stilletjes.
De nieuwe regels voor webcrawling vragen om nauwkeuriger beheer van jouw kant
Het internetverkeer is veranderd, je hosting waarschijnlijk niet. AI-crawlers houden zich niet aan de regels die zoekmachines de afgelopen twee decennia hebben opgebouwd. robots.txt is optioneel, het crawlen gebeurt in een constant hoog tempo en je krijgt niets terug voor de resources die het kost. Dat levert een prestatie- en kostenprobleem op dat zich voordoet als een trage site in plaats van als crawleractiviteit.
De oplossing is een korte reeks stappen die je zelf uitvoert. Controleer eerst de oorzaak in de analytics van MyKinsta. Stel daarna het juiste beschermingsniveau in en zet Blokkeer AI-crawlers aan om de belasting van AI-crawlers te verlagen zonder je zichtbaarheid in zoekmachines te verliezen. Bescherm vervolgens wat je nodig hebt via Altijd toestaan, zodat strengere instellingen je vertrouwde integraties niet verstoren. Elke wijziging gaat live zonder downtime, dus je stuurt bij zodra de patronen veranderen.
Beheer je veel klantsites, dan combineert het Agency Partner Programma van Kinsta deze instellingen met persoonlijke ondersteuning. Ontdek de Managed WordPress Hosting van Kinsta en breng die controle in de praktijk.
