Kinsta heeft binnen zijn hostinginfrastructuur meer dan 10 miljard HTTP-verzoeken geanalyseerd en ontdekte dat bots in één periode van 24 uur maar liefst 7,67 miljoen keer ‘toevoegen aan winkelwagen’-URL’s aanriepen op WordPress sites. Eén crawler genereerde in zijn eentje 550 miljoen verzoeken in 30 dagen, tot een regel hem tegenhield.
Geen van die verzoeken leidde tot een conversie. Geen enkel verzoek bracht een bezoeker terug naar de site. Ze bleven simpelweg binnenstromen: winkelwagenpagina’s, gefilterde product-URL’s, zoekopdrachten en AJAX-endpoints. Elk verzoek dwong de server om PHP uit te voeren, een databasequery te draaien en een sessie af te handelen, voor verkeer dat nooit een klant zou worden.
De sites die deze belasting opvingen, gingen niet down. Pagina’s laadden. Afrekenen werkte. Volgens alle gangbare maatstaven zag alles er prima uit. En dat is precies het probleem waar dit artikel over gaat.
Botverkeer is niet langer alleen maar achtergrondruis
In 2025 waren bots goed voor 53% van al het webverkeer. Voor het eerst overtrof geautomatiseerd verkeer in een kalenderjaar het menselijke verkeer. In juni 2026 schatte Cloudflare Radar dat cijfer op 57,5%, een omslagpunt dat volgens de CEO van Cloudflare zelf jaren eerder kwam dan hij had verwacht.
Voor WordPress-beheerders is de praktische verandering concreter dan een percentage. Botverkeer bestaat allang niet meer uit alleen zoekcrawlers die hun werk doen. Denk ook aan crawlers voor AI-training, scrapingtools, SEO-auditbots, uptime-monitors, nep-user-agents en agentische AI-tools die links veel agressiever volgen dan traditionele crawlers ooit deden.
Sommige indexeren content, andere scrapen die. Weer andere testen endpoints. En sommige behandelen elke combinatie van URL-parameters als een aparte pagina en crawlen ze stuk voor stuk.
Dat laatste gedrag is bijzonder kostbaar voor WordPress. Een productpagina met filters voor kleur, maat, sortering, paginering en voorraad is voor een menselijke bezoeker één pagina. Een bot ziet honderden unieke URL’s en crawlt ze allemaal.
AI-gedreven botverkeer steeg in één jaar met 300%. Eind 2025 waren AI-bots goed voor 1 op de 31 webbezoeken op het netwerk van TollBit, tegenover 1 op de 200 aan het begin van dat jaar. De richting is duidelijk. Wat nog steeds onderschat wordt, is wat dat verkeer daadwerkelijk kost.
Bandbreedte is de voor de hand liggende kostenpost
Bandbreedte is de data die je site verstuurt zodra iemand een pagina, afbeelding, script of ander bestand opvraagt. Menselijke bezoekers gebruiken die. Bots ook, alleen kopen die daarna niets.
Een crawler die één keer een artikel bezoekt, is geen probleem. Maar een bot die herhaaldelijk archieven, tagpagina’s, afbeeldingen, feeds, scripts en gefilterde URL’s doorspit, verbruikt echte bandbreedte zonder enige zakelijke waarde op te leveren.
Volgens Cloudflare-gegevens uit 2025, aangehaald in het AI- en Botverkeer Rapport van Kinsta, is 80% van de AI-crawlingactiviteit bedoeld voor het trainen van modellen in plaats van voor zoekopdrachten of door gebruikers geactiveerde verzoeken. Verwijzingsverkeer levert dat niet op. Voor WordPress sites met veel content verandert die dynamiek waardevolle pagina’s in een kostenpost.
Het verraderlijke is dat bandbreedteverspilling zich opstapelt zonder zichtbaar prestatieprobleem. De site laadt nog steeds. De server reageert nog steeds. Maar het verbruik blijft stijgen, omdat geautomatiseerd verkeer steeds weer pagina’s en bestanden opvraagt die geen enkele bezoeker nodig heeft.
Tegen de tijd dat de bandbreedtekosten opvallen, heeft de site misschien al dagen of weken verkeer verwerkt waar het bedrijf niets aan had.
De belasting van de backend is moeilijker te zien
Niet elk verzoek kost evenveel om te verwerken. Een gecachet artikel is relatief goedkoop: de server stuurt een opgeslagen versie terug en gaat verder. Dynamische verzoeken werken anders.
Roept een bot een WooCommerce-winkelwagenactie, een gefilterde productpagina, een zoek-URL, een inlogpagina of een AJAX-endpoint aan, dan valt er niets uit de cache te halen. De server moet het elke keer opnieuw doen:
- PHP-uitvoering: er wordt een thread gereserveerd voor de volledige duur van het verzoek
- Databasequery’s: de pagina raadpleegt de database bij elke laadbeurt, zonder dat de cache dat opvangt
- Sessiebeheer: winkelwagen- en afrekenpagina’s maken of valideren een sessie per verzoek, ook voor bots die nooit iets afrekenen
- Pluginlogica: elke plugin die op deze verzoeken is aangesloten, voert bij elke aanroep zijn code uit
- Cache-bypass: het verzoek belandt nooit in de cache, dus identieke verzoeken kosten later precies hetzelfde
Hier wordt botverkeer duurder dan het lijkt. Het gaat niet alleen om hoeveel data een bot downloadt, maar om hoeveel werk je infrastructuur verzet voordat die data teruggaat.
De infrastructuurgegevens van Kinsta maken de omvang concreet: bots raakten ‘toevoegen aan winkelwagen’-URL’s 7,67 miljoen keer in één periode van 24 uur, waarvan 3,75 miljoen verzoeken van ClaudeBot alleen. Elk verzoek gold aan de serverkant als een nieuw verzoek. Elk verzoek betekende PHP code uitvoeren en een databasequery draaien. Geen enkel verzoek was bedoeld voor een klant.
Zoals Kinsta’s CTO Daniel Pataki het bij de lancering verwoordde: “Het meeste advies over botbeheer komt neer op ‘blokkeer alles’ of ‘laat het met rust’. Geen van beide werkt op grote schaal.”
Waarom ‘we geen downtime hebben gehad’ de plank misslaat
Uptime betekent dat de site online blijft. Niet dat de site efficiënt werkt.
Een WordPress site kan een flinke hoeveelheid onnodig verkeer opvangen voordat bezoekers iets merken. Pagina’s laden nog steeds. Afrekenen werkt nog steeds. Beheerpagina’s reageren nog steeds. Maar de infrastructuur verwerkt intussen elk botverzoek dat een dynamisch endpoint raakt, en die verwerking kost echt geld, ook als de site stabiel oogt.
Die kosten laten zich subtieler zien dan een storing:
- Hoger bandbreedteverbruik dat langzaam de limieten van je pakket nadert
- Meer druk op PHP-workers en databaseverbindingen
- Minder ruimte wanneer echte verkeerspieken diezelfde resources opeisen
- Vertekende statistieken waarin botsessies zich mengen met menselijke interactie
- A/B-testresultaten en conversiepercentages die scheeflopen door verkeer dat nooit zou converteren
- Infrastructuurbeslissingen op basis van cijfers die het gedrag van je publiek niet weerspiegelen
- Lastiger troubleshooten, omdat de ruis van botactiviteit het signaal van echte prestatieproblemen overstemt
Daarom geeft ‘geen downtime’ teams al snel een vals gevoel van veiligheid. De site oogt stabiel omdat de infrastructuur het extra werk opvangt. Maar verspilling opvangen kost nog steeds geld, het valt alleen niet op.
Waarom bureaus dit moeten aanpakken voordat klanten het merken
Bureaus horen meestal pas over botverkeer als het al zichtbaar misgaat. Een klant ziet zijn hostingverbruik oplopen, tragere beheerpagina’s, vertraging bij het afrekenen, vreemde verkeerspatronen of statistieken die niet meer stroken met de bedrijfsresultaten. Op dat moment is het gesprek al reactief: je moet uitleggen wat er is gebeurd, waarom het uitmaakt en wat er moet veranderen.
Botverkeer biedt bureaus juist de kans op een proactief gesprek.
Alarmerend hoeft het niet te klinken. Praktisch is genoeg:
- “Je site presteert misschien prima, maar een deel van dat verkeer komt waarschijnlijk niet van echte bezoekers.”
- “Sommige botactiviteit is nuttig, zoals zoekcrawlers en monitoringtools. Andere activiteit verbruikt alleen resources.”
- “We kunnen verspilling terugdringen zonder het verkeer te raken dat er echt toe doet.”
- “Pak je dit goed aan, dan houd je prestatieruimte over en blijft het verbruik voorspelbaar.”
Zo koppel je botbeheer aan wat klanten al begrijpen: kosten, efficiëntie en betrouwbaarheid. En het verschuift de rol van het bureau van reactieve probleemoplosser naar proactieve infrastructuuradviseur, wat een duurzamere relatie oplevert.
Het doel is niet om elke bot te blokkeren
Niet al het botverkeer is slecht. Zoekcrawlers zorgen dat pagina’s in de zoekresultaten verschijnen. Monitoringtools bewaken de uptime. SEO-platforms voeren pagina-audits uit. Ook betalingsproviders, integraties, API’s en WordPress-automatiseringen hebben soms toegang tot de site nodig om hun werk te doen.
AI-crawlers liggen ingewikkelder. De ene site-eigenaar wil zichtbaarheid in AI-gedreven ervaringen. De andere vindt dat AI-crawling meer kost dan het oplevert, zeker als het grote contentbibliotheken afspeurt zonder noemenswaardig verwijzingsverkeer terug te sturen.
Alles blokkeren is dus niet het doel. Te veel blokkeren levert SEO-problemen op, verstoort integraties, onderbreekt monitoring of zit normale WordPress-workflows in de weg.
Selectieve controle werkt beter:
- Laat nuttig verkeer toe
- Blokkeer automatisering die niets oplevert
- Geef verdacht verkeer een challenge
- Bescherm kostbare paden
- Houd de resultaten in de gaten
Zo krijgen teams meer grip zonder elke bot over één kam te scheren. Je beperkt de verspilling en houdt tegelijk het verkeer, de tools en de workflows overeind die het bedrijf wél ondersteunen.
Hoe Kinsta’s Botbescherming dit in de praktijk aanpakt
Zodra botverkeer een infrastructuurprobleem wordt, moet de reactie aansluiten op de situatie van de site.
Botbescherming in MyKinsta is precies op die variatie gebouwd. Het zit zonder extra kosten bij elk pakket, werkt op omgevingsniveau en is meteen actief zodra je de instellingen wijzigt.
Beschermingsniveaus
Ga naar Sites > sitenaam > Botbescherming > Wijzigen en kies uit vier vooraf ingestelde niveaus. Je stelt ze per omgeving apart in, zodat je testomgeving, ontwikkelomgeving en productieomgeving verschillende instellingen kunnen gebruiken.
- Blokkeer kwaadaardig verkeer: de standaardinstelling op elke site. Zorgt voor DDoS-beperking en blokkeert IP-adressen en endpoints die gekoppeld zijn aan bekende aanvalspatronen. Dit staat al aan op elke Kinsta-site.
- Blokkeer automatiseringen: het aanbevolen startpunt voor de meeste sites met botverkeer. Blokkeert bevestigd geautomatiseerd en kwaadaardig verkeer en laat geverifieerde bots en echte bezoekers door. Effectief voor sites die herhaalde hits op dynamische URL’s zien en tegelijk geen echte bezoekers willen tegenhouden.
- Daag bots uit: voegt een verificatiestap toe voor vermoedelijke bots en niet-geclassificeerd verkeer. Wie de challenge doorstaat, krijgt tien dagen lang geen nieuwe challenge op dezelfde browser en hetzelfde IP-adres. Handig bij verkeerspieken, uitverkoopacties of periodes waarin veel gescraped wordt, wanneer de balans tussen blokkeren en wrijving meer precisie vraagt.
- Geef iedereen een challenge: de zwaarste instelling, bedoeld voor kort gebruik tijdens een actieve aanval of aanhoudend misbruik. Al het niet-geverifieerde verkeer krijgt een challenge, ook bezoekers die waarschijnlijk echt zijn. Dit is geen permanente configuratie.
Zet je het niveau hoger dan Blokkeer kwaadaardig verkeer, controleer dan eerst of je bedrijfskritische integraties in de lijst met geverifieerde bots van Cloudflare staan. Vanaf Daag bots uit en hoger krijgt elke niet-geverifieerde tool die programmatisch verbinding maakt met je site een challenge, of wordt die geblokkeerd.
AI-crawlers blokkeren
De schakelaar AI-crawlers blokkeren staat los van het beschermingsniveau. Die richt zich specifiek op AI-crawlers, inclusief geverifieerde zoals GPTBot, terwijl Googlebot en Bingbot er geen last van hebben. Je zoekindexering loopt gewoon door.
Voor contentrijke sites, uitgevers, documentatiebibliotheken en hubs met premium content, waar AI-crawlers herhaaldelijk en massaal artikelpagina’s, archiefpagina’s en niet-gecachete bestanden opvragen, haalt deze schakelaar die belasting weg zonder je zichtbaarheid in zoekresultaten te raken.
Het nadeel is reëel en het vermelden waard: blokkeer je AI-crawlers, dan duikt je content minder vaak op in door AI gegenereerde antwoorden en samenvattingen. Is zichtbaarheid in AI een strategische prioriteit, blijf dan bij Blokkeer automatiseringen of Daag bots uit. Die filteren het ergste gedrag eruit en houden je site indexeerbaar. Wegen de kosten van resources en je pakketgebruik zwaarder dan zichtbaarheid in AI, dan is blokkeren de duidelijkere keuze.
Typische WordPress-automatiseringen toestaan
Zet je het beschermingsniveau boven de standaardinstelling, schakel dan meteen Typische WordPress-automatiseringen toestaan in.
Daarmee activeer je een beheerde allowlist voor veelvoorkomende WordPress-paden en -services: REST API-calls, WooCommerce-routes, achtergrondtaken, geplande taken en plugin-integraties. Zo verstoort strengere botfiltering niet stilletjes de workflows waar de site op draait.
Schakel dit in zodra je overstapt op Blokkeer automatiseringen of hoger. Het doel is onnodig verkeer terugdringen, niet legitieme activiteit onderbreken.
Altijd toestaan
Sommige diensten mag je nooit tegenhouden, ongeacht het beschermingsniveau. In Altijd toestaan voeg je tot 50 custom uitzonderingen toe op basis van IP-adres, URL-pad of user-agent.
Gebruik dit voor:
- Webhooks van betalingsproviders (Stripe, PayPal)
- Betrouwbare monitoringdiensten (UptimeRobot, Pingdom)
- Bekende partnerintegraties of API-gebruikers
- IP-ranges van ontwikkelaars of kantoren
- Specifieke WordPress-paden zoals /wp-json/* of /wp-admin/admin-ajax.php, als die nog niet onder de allowlist voor WordPress-automatiseringen vallen
Inzicht in verzoeken en resultaten van botbescherming
Botverkeer valt lastig te optimaliseren als teams niet zien hoe verzoeken worden geclassificeerd en afgehandeld.
Controleer eerst de pagina Botbescherming voordat je instellingen aanpast. De grafiek Breakdown verzoeken toont elk verzoek dat je site de afgelopen 24 uur heeft ontvangen, verdeeld over zeven categorieën: Waarschijnlijk mensen, Geverifieerde bots, Waarschijnlijk bots, AI-crawlers, AI-crawlers met te hoge frequentie, Niet-geclassificeerd verkeer en Geautomatiseerd verkeer.
De vraag is veranderd
Hosting werd altijd beoordeeld op een korte lijst zichtbare resultaten: is de site online? Laadt hij snel? Kunnen bezoekers doen waarvoor ze komen?
Die vragen doen er nog steeds toe. Alleen geven ze niet meer het volledige beeld.
Een site kan online blijven terwijl er bandbreedte weglekt. Hij kan snel laden terwijl bots de PHP-threads en databaseverbindingen opsouperen die echte bezoekers nodig hebben. Hij kan op dinsdagmiddag een snelheidstest doorstaan en donderdag alsnog moeite hebben met de belasting van een campagnelancering, omdat de reserve die klaar had moeten staan al opging aan verkeer dat het bedrijf niets opleverde.
De vraag is niet langer alleen: “Kan de site de belasting aan?” Maar: “Hoeveel van die belasting zou de site überhaupt moeten verwerken?”
Botverkeer hoeft een site niet offline te halen om geld te kosten. Het hoeft alleen de paden te blijven raken die echte verwerking vragen, in een volume dat er in elk dashboard uitziet als normale activiteit.
Zicht op dat verkeer, plus de mogelijkheid om te handelen naar wat je ziet, maakt het verschil. Je kunt niet beheren wat je niet ziet, en je kunt niets zinnigs doen met wat je wél ziet als je enige opties alles blokkeren of niets doen zijn.
Beheer je contentrijke sites, WooCommerce-winkels of een grote klantenportfolio? Met de Managed WordPress Hosting van Kinsta vind je die knoppen in MyKinsta, zonder extra kosten en per omgeving aanpasbaar, zonder supportticket. Begin met het AI & Botverkeer Rapport voor een volledig beeld van wat je WordPress-infrastructuur belast en wat dat kost.
