Het gevolg: je exploitatiekosten stijgen, terwijl de prestatieproblemen blijven. De Botbescherming tool van Kinsta<\/a> is precies voor dit soort situaties gemaakt. Je krijgt er controle mee over wat je server bereikt, in plaats van de capaciteit te vergroten die al dat verkeer moet opvangen.<\/p>\n Een menselijke bezoeker die een trage pagina tegenkomt, wacht misschien even, laadt opnieuw of haakt simpelweg af. Een bot blijft daarentegen hetzelfde aantal verzoeken sturen, ongeacht hoe je server reageert. Dat is de kern van het probleem: botverkeer reguleert zichzelf niet wanneer je resources toevoegt, dus het upgraden van je pakket geeft bots juist meer capaciteit om te verbruiken.<\/p>\n Het wordt nog ingewikkelder als je meeneemt hoe moderne WordPress sites verzoeken verwerken. Het meeste botverkeer komt niet terecht op statische pagina’s die je cache kan afvangen. In plaats daarvan raakt het juist eindpunten die de cache omzeilen en de server dwingen harder te werken. Op elke site met WooCommerce, zoekfuncties of filters komen bots daardoor terecht op allerlei elementen:<\/p>\n Geen van deze acties kun je op dezelfde manier cachen als een statische pagina. Bij elk verzoek dat op zo’n eindpunt binnenkomt, gebeurt er aan de serverkant een aantal dingen:<\/p>\n Uit onze eigen infrastructuurgegevens<\/a> blijkt dat \u00e9\u00e9n enkele bot in 24 uur tijd 3,75 miljoen verzoeken naar ’toevoegen aan winkelwagen’-URL’s genereerde. Dat komt neer op ongeveer \u00e9\u00e9n verzoek per 23 milliseconden, de klok rond. En \u00e9\u00e9n enkele regel voor loopdetectie filterde in 30 dagen tijd 550 miljoen verzoeken over het hele platform.<\/p>\n Dit zijn geen aanvalsvolumes in de traditionele zin. Het is het resultaat van bots die zijn gebouwd om elke URL te volgen die ze tegenkomen, inclusief variaties in query strings en paden met parameters.<\/p>\n “Vanuit infrastructuurperspectief bestaat er niet zoiets als ‘alleen maar botverkeer’. Elk verzoek is echt werk. Op grote schaal is ineffici\u00ebnt crawlen geen verkeersprobleem meer, maar een resourceprobleem.” \u2013 Daniel Pataki, CTO, Kinsta<\/em><\/p>\n Bij bureaus zie je vaak een vast patroon in een cyclus: zodra het resourcegebruik stijgt, upgraden klanten hun pakket, waarna het resourcegebruik opnieuw stijgt. Ondertussen verbeteren de prestaties niet, want het onderliggende verzoekvolume is niet veranderd.<\/p>\n Omdat Kinsta botverkeer bij de facturering niet meetelt<\/a> in je pakketgebruik, kun je snel vaststellen of bots een probleem vormen. Bekende bot-user-agents worden al gefilterd uit de pagina Bezoeken<\/strong> in de Analytics<\/strong> van MyKinsta. Zien die cijfers er normaal uit terwijl je server onder druk staat, dan is geautomatiseerd verkeer waarschijnlijk de oorzaak.<\/p>\n Het overzicht Bot- en geautomatiseerd verkeer<\/strong> in MyKinsta geeft een duidelijker beeld van het verkeer dat je site bereikt: geverifieerde bots, waarschijnlijk bots, AI-crawlers, agressieve AI crawlers, geautomatiseerd verkeer en waarschijnlijk mensen.<\/p>\n Zo zie je makkelijker wanneer geautomatiseerd verkeer je resources belast. Pieken in agressieve AI crawlers of geautomatiseerd verkeer wijzen bijvoorbeeld vaak op bots die herhaaldelijk niet-cachebare endpoints bevragen.<\/p>\n De grafiek Botbescherming resultaten laat ook zien hoe verzoeken na classificatie worden afgehandeld: toegestaan, uitgedaagd of geblokkeerd. Zo krijg je een duidelijker beeld van hoe je huidige instellingen het inkomende verkeer be\u00efnvloeden.<\/p>\n Het rapport Topverzoeken per weergave<\/strong> laat ook zien wat je server belast, en daarbij telt al het verkeer mee, niet alleen de bezoeken waarvoor je betaalt. Juist in het verschil tussen die twee cijfers lopen je kosten op zonder duidelijke reden.<\/p>\n Zo interpreteer je dat verschil:<\/p>\n Beheer je klantenportfolio’s, dan is elke site met door bots veroorzaakte belasting een kostenpost die lastig te verantwoorden is, zeker als de prestaties na een upgrade niet zijn verbeterd. Het verkeer van AI-bots is het afgelopen jaar met 300% gegroeid<\/a>, terwijl \u00e9\u00e9n op de 31 webbezoeken afkomstig is van een AI-bot<\/a>. Dit volume verdwijnt niet vanzelf.<\/p>\n De beveiliging op platformniveau van Kinsta blokkeert inkomend verkeer dat als schadelijk wordt aangemerkt, al voordat het je site bereikt. Denk hierbij aan DDoS-beveiliging<\/a> en aan verzoeken van IP-adressen die in verband worden gebracht met bekende aanvalsbronnen. Tussen dat verkeer en het verkeer dat je w\u00e9l wilt, zit een categorie niet-geverifieerde, omvangrijke en resource-intensieve geautomatiseerde verzoeken die je server t\u00f3ch bereiken. De botbeschermingsfuncties van Kinsta helpen dat volume terug te dringen.<\/p>\n De instellingen voor botbescherming in MyKinsta werken op infrastructuurniveau: het filteren gebeurt nog voordat WordPress eraan te pas komt. Je hoeft dus geen plugin te installeren of WordPress-instellingen aan te passen.<\/p>\n Kinsta classificeert elk verzoek met een combinatie van de eigen verkeersanalyse en het machine learning-systeem van Cloudflare<\/a>, dat elke bezoeker een botscore tussen 1 en 99 toekent. Een hoge score betekent dat het verzoek hoogstwaarschijnlijk van een mens komt; een lage score wijst op geautomatiseerde activiteit.<\/p>\n Het verkeer wordt ingedeeld in categorie\u00ebn als geverifieerde bots, waarschijnlijk bots, AI-crawlers, agressieve AI crawlers, geautomatiseerd verkeer en waarschijnlijk mensen. Het beschermingsniveau dat je kiest, bepaalt hoe elke categorie wordt behandeld.<\/p>\n Je beheert Botbescherming in MyKinsta onder Sites<\/strong> > sitenaam<\/strong> > Botbescherming<\/strong>.<\/p>\n Je kunt kiezen uit vier niveaus via de knop Wijzigen<\/strong> op de pagina Botbescherming<\/strong>:<\/p>\n Wil je het niveau wijzigen, ga dan naar Sites<\/strong> > Schakel je echter over naar Daag bots uit<\/strong> of hoger, dan wordt elke tool die programmatisch verbinding maakt met je site en niet in de geverifieerde bot-directory van Cloudflare<\/a> staat, geblokkeerd of uitgedaagd. Dit geldt voor custom integraties, deployscripts en zelfgehoste uptime-monitors. Gebruik je die, dan is het de moeite waard om v\u00f3\u00f3r het verhogen van het beschermingsniveau te controleren of ze op de lijst staan.<\/p>\n De schakelaar Blokkeer AI crawlers<\/strong> richt zich specifiek op AI-crawlers<\/a>: bots die content verzamelen voor het trainen van modellen, retrieval-augmented generation en door AI aangedreven zoekfuncties. Crawlers van zoekmachines raakt dit niet, maar speciale crawlers zoals GPTBot w\u00e9l. Googlebot en Bingbot blijven je site indexeren, of de schakelaar nu aan of uit staat.<\/p>\n Doorgaans is 80% van alle AI-crawlactiviteit bedoeld voor het trainen van modellen, niet voor door gebruikers gestarte zoekopdrachten. Het levert dus geen verwijzingsverkeer naar je site op, en daarom is het een goed idee om deze functie in te schakelen. Dat doe je via Sites<\/strong> > Het nadeel: je bent minder zichtbaar in door AI gegenereerde overzichten en samenvattingen. Is die zichtbaarheid belangrijk voor je contentstrategie, monitor dan eerst de impact voordat je de schakelaar permanent aan laat staan.<\/p>\n Ligt je prioriteit bij het beheersen van de serverbelasting, dan is dit een overzichtelijker optie dan het aanpassen van robots.txt<\/a> of het schrijven van regels per bot. Anders dan die aanpakken werkt deze functie op infrastructuurniveau, nog voordat een verzoek WordPress bereikt.<\/p>\n Verschillende sites hebben verschillende beschermingsniveaus nodig: een WooCommerce-winkel<\/a> met gefilterde productpagina’s is iets anders dan een contentplatform. Bovendien heeft elke site in een klantenportfolio een eigen verkeersprofiel, eigen integraties en een eigen tolerantie voor verificatiestappen. E\u00e9n beleid over het hele portfolio uitrollen beperkt sommige sites daardoor te veel, terwijl andere juist onvoldoende beschermd blijven.<\/p>\n Merk je signalen op dat botverkeer de kosten op een klantensite opdrijft, dan kun je deze praktische werkwijze volgen:<\/p>\n Voor bureaus die grote portfolio’s beheren via WordPress hosting<\/a> wordt dit een routineklus in plaats van een project. Sluiten de instellingen aan op het werkelijke verkeersprofiel van elke site, dan weerspiegelt het resourcegebruik de echte gebruikersactiviteit. De prestatiecijfers komen overeen met wat echte bezoekers ervaren:<\/p>\n “De misvatting is dat botverkeer een simpel ‘blokkeren of toestaan’-probleem is. In werkelijkheid gaat het om beleid, inzicht en economische controle.” – Cristian Lopez, hoofdredacteur, HostingAdvice<\/em><\/p>\n Wat je een klant over de kosten uitlegt, moet gaan over de keuzes die je voor hun verkeer hebt gemaakt, niet over capaciteit die je hebt toegevoegd als reactie op belasting die je niet kunt thuisbrengen.<\/p>\n Door je infrastructuur op te schalen vergroot je de belasting die je server aankan. Botbescherming verlaagt de belasting die je server bereikt. Dat zijn geen gelijkwaardige oplossingen voor hetzelfde probleem: de een voegt capaciteit toe, de ander neemt de druk weg waardoor meer capaciteit \u00fcberhaupt nodig leek.<\/p>\nWaarom bots zich niet gedragen als echt verkeer<\/h2>\n
\n
?add-to-cart=<\/code>.<\/li>\n\n
Hoe de kosten van botverkeer eruitzien<\/h2>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/kinsta-analytics.png\")
![\"Het](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/bot-results.png\")
\n
sitenaam<\/code> > Analytics <\/strong>> Pakketverbruik<\/strong>. Lijkt het aantal bezoeken normaal, dan heb je niet te maken met een echte piek in menselijk verkeer.<\/li>\nHoe de botbescherming van Kinsta werkt<\/h2>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/protection-level.png\")
Een beschermingsniveau kiezen<\/h3>\n
![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/change-level.png\")
\n
sitenaam<\/code> > Botbescherming<\/strong> en klik op Wijzigen<\/strong>. Via het Sites <\/strong>overzicht kun je meerdere sites selecteren en via Acties<\/strong> > Botbescherming wijzigen<\/strong> tegelijk aanpassen.<\/p>\nAI-crawlers blokkeren<\/h3>\n
sitenaam<\/code> > Botbescherming<\/strong>, met de schuifknop naast Blokkeer AI crawlers<\/strong>. Voor meerdere sites gebruik je Acties<\/strong> > Botbescherming wijzigen<\/strong> vanuit het Sites <\/strong>overzicht.<\/p>\n![\"De](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/05\/block-crawler.png\")
Beveiliging beheren binnen een klantenportfolio<\/h2>\n
\n
Stop met opschalen rond een probleem dat je zelf kunt beheersen<\/h2>\n