Als het resourcegebruik op een klantensite begint te stijgen zonder dat het aantal bezoeken echt toeneemt, lijkt een upgrade van je pakket de juiste stap. Dat is een logisch uitgangspunt zolang die groei voortkomt uit echt verkeer dat de belasting en de behoefte aan capaciteit vergroot.
Maar opschalen voegt weliswaar resources toe; het verlaagt niet het aantal verzoeken dat de server bereikt. Als botverkeer bijdraagt aan die verzoeken en aan de serverbelasting, geef je die bots met extra capaciteit alleen maar meer ruimte om hun gang te gaan.
Het gevolg: je exploitatiekosten stijgen, terwijl de prestatieproblemen blijven. De Botbescherming tool van Kinsta 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.
Waarom bots zich niet gedragen als echt verkeer
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.
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:
- Winkelwagenacties en varianten van de parameter
?add-to-cart=. - Gefilterde productpagina’s met verschillende combinaties van query strings.
- Zoekopdrachten.
- Afrekenstappen en acties op de verlanglijst.
- Interacties op basis van AJAX.
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:
- PHP-uitvoering. Er wordt een PHP-thread gereserveerd voor de volledige duur van het verzoek. Bij een aanhoudende botbelasting raken de threads op en moeten je bezoekers wachten.
- Databasequery’s. Dynamische pagina’s voeren bij elke laadbeurt een query uit op de database, omdat er geen cachelaag is om dit op te vangen.
- Sessiebeheer. Winkelwagen- en afrekenpagina’s maken of valideren bij elk verzoek een sessie, wat extra belasting oplevert, zelfs voor bots die nooit iets kopen.
Uit onze eigen infrastructuurgegevens blijkt dat één enkele bot in 24 uur tijd 3,75 miljoen verzoeken naar ’toevoegen aan winkelwagen’-URL’s genereerde. Dat komt neer op ongeveer één verzoek per 23 milliseconden, de klok rond. En één enkele regel voor loopdetectie filterde in 30 dagen tijd 550 miljoen verzoeken over het hele platform.
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.
“Vanuit infrastructuurperspectief bestaat er niet zoiets als ‘alleen maar botverkeer’. Elk verzoek is echt werk. Op grote schaal is inefficiënt crawlen geen verkeersprobleem meer, maar een resourceprobleem.” – Daniel Pataki, CTO, Kinsta
Hoe de kosten van botverkeer eruitzien
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.
Omdat Kinsta botverkeer bij de facturering niet meetelt in je pakketgebruik, kun je snel vaststellen of bots een probleem vormen. Bekende bot-user-agents worden al gefilterd uit de pagina Bezoeken in de Analytics van MyKinsta. Zien die cijfers er normaal uit terwijl je server onder druk staat, dan is geautomatiseerd verkeer waarschijnlijk de oorzaak.
Het overzicht Bot- en geautomatiseerd verkeer 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.
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.
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ïnvloeden.
Het rapport Topverzoeken per weergave 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.
Zo interpreteer je dat verschil:
- Kijk eerst bij Bezoeken onder Sites >
sitenaam> Analytics > Pakketverbruik. Lijkt het aantal bezoeken normaal, dan heb je niet te maken met een echte piek in menselijk verkeer. - Open Topverzoeken per weergave om al het verkeer te zien, inclusief bots. Een cluster van verzoeken met een hoog volume naar niet-cachebare paden (URL’s voor ’toevoegen aan winkelwagen’, variaties in query strings of afrekenstappen) bevestigt dat bots resources verbruiken waar je cache niet bij kan.
- Werp ook een blik op het prestatierapport. Verhoogde PHP-responstijden of threadlimieten die worden bereikt, wijzen op door bots veroorzaakte belasting die je server onder druk zet.
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, terwijl één op de 31 webbezoeken afkomstig is van een AI-bot. Dit volume verdwijnt niet vanzelf.
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 en aan verzoeken van IP-adressen die in verband worden gebracht met bekende aanvalsbronnen. Tussen dat verkeer en het verkeer dat je wél wilt, zit een categorie niet-geverifieerde, omvangrijke en resource-intensieve geautomatiseerde verzoeken die je server tóch bereiken. De botbeschermingsfuncties van Kinsta helpen dat volume terug te dringen.
Hoe de botbescherming van Kinsta werkt
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.
Kinsta classificeert elk verzoek met een combinatie van de eigen verkeersanalyse en het machine learning-systeem van Cloudflare, 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.
Het verkeer wordt ingedeeld in categorieën 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.
Je beheert Botbescherming in MyKinsta onder Sites > sitenaam > Botbescherming.
Een beschermingsniveau kiezen
Je kunt kiezen uit vier niveaus via de knop Wijzigen op de pagina Botbescherming:
- Blokkeer kwaadaardig verkeer is de standaardinstelling. Die zorgt voor DDoS-beveiliging en blokkeert verkeer van IP-adressen en eindpunten die in verband staan met bekende aanvalsbronnen.
- Blokkeer automatiseringen bouwt voort op de standaardinstelling en blokkeert ook bevestigd geautomatiseerd verkeer, terwijl geverifieerde bots en echte bezoekers worden doorgelaten.
- Daag bots uit blokkeert geautomatiseerd en kwaadaardig verkeer en voegt een verificatiestap toe voor waarschijnlijk bots. Bezoekers die de verificatie doorstaan, worden tien dagen lang niet opnieuw uitgedaagd op dezelfde browser en hetzelfde IP-adres.
- Geef iedereen een challenge past die controle ook toe op bezoekers die waarschijnlijk mensen zijn. Dit niveau is geschikt voor kortstondig gebruik tijdens verkeerspieken of actieve aanvallen.
Wil je het niveau wijzigen, ga dan naar Sites > sitenaam > Botbescherming en klik op Wijzigen. Via het Sites overzicht kun je meerdere sites selecteren en via Acties > Botbescherming wijzigen tegelijk aanpassen.
Schakel je echter over naar Daag bots uit of hoger, dan wordt elke tool die programmatisch verbinding maakt met je site en niet in de geverifieerde bot-directory van Cloudflare 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óór het verhogen van het beschermingsniveau te controleren of ze op de lijst staan.
AI-crawlers blokkeren
De schakelaar Blokkeer AI crawlers richt zich specifiek op AI-crawlers: 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él. Googlebot en Bingbot blijven je site indexeren, of de schakelaar nu aan of uit staat.
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 > sitenaam > Botbescherming, met de schuifknop naast Blokkeer AI crawlers. Voor meerdere sites gebruik je Acties > Botbescherming wijzigen vanuit het Sites overzicht.
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.
Ligt je prioriteit bij het beheersen van de serverbelasting, dan is dit een overzichtelijker optie dan het aanpassen van robots.txt of het schrijven van regels per bot. Anders dan die aanpakken werkt deze functie op infrastructuurniveau, nog voordat een verzoek WordPress bereikt.
Beveiliging beheren binnen een klantenportfolio
Verschillende sites hebben verschillende beschermingsniveaus nodig: een WooCommerce-winkel 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én beleid over het hele portfolio uitrollen beperkt sommige sites daardoor te veel, terwijl andere juist onvoldoende beschermd blijven.
Merk je signalen op dat botverkeer de kosten op een klantensite opdrijft, dan kun je deze praktische werkwijze volgen:
- Begin in het overzicht Bot- en geautomatiseerd verkeer binnen MyKinsta. Blijft het menselijke verkeer stabiel terwijl het geautomatiseerde verkeer, agressieve AI crawlers of AI-crawleractiviteit toeneemt, dan is botverkeer waarschijnlijk de oorzaak.
- Open vervolgens Topverzoeken per weergave onder Analytics en zoek naar hoge verzoekvolumes op niet-cachebare paden. Een cluster van activiteit rond ’toevoegen aan winkelwagen’-URL’s, gefilterde productpagina’s, afrekenstappen, zoekopdrachten of variaties in query strings is een sterke aanwijzing voor door bots veroorzaakt resourcegebruik.
- Het prestatierapport helpt je de impact te bevestigen. Stijgende PHP-responstijden, een hogere doorvoer of het bereiken van threadlimieten zijn signalen dat geautomatiseerd verkeer je server belast.
- Pas daarna het juiste beschermingsniveau toe voor de site. Blokkeer automatiseringen is meestal het juiste startpunt, terwijl Daag bots uit een extra verificatielaag toevoegt voor verkeer dat waarschijnlijk van bots komt en de origin-server blijft bereiken.
- Voor sites die gebruikmaken van integraties, API’s of geautomatiseerde WordPress-functionaliteit helpen de instellingen Sta typische WordPress automatiseringen toe en Altijd toestaan het risico te verkleinen dat legitieme diensten worden geblokkeerd.
- Wijzigingen worden zonder downtime doorgevoerd, en je kunt ze meteen ongedaan maken als een instelling restrictiever blijkt dan de integraties van een site aankunnen. Omdat de instellingen buiten WordPress om zitten, loop je geen risico voor de site zelf terwijl je de situatie evalueert.
Voor bureaus die grote portfolio’s beheren via WordPress hosting 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:
“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
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.
Stop met opschalen rond een probleem dat je zelf kunt beheersen
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 überhaupt nodig leek.
Met de analytics van MyKinsta stel je vast wanneer geautomatiseerd verkeer bijdraagt aan een stijgend resourcegebruik, zelfs als het menselijke verkeer stabiel blijft. Vervolgens geeft Botbescherming je de mogelijkheid om ongewenst verkeer te classificeren, uit te dagen en te blokkeren voordat het WordPress, PHP of de database bereikt.
Voor sites met overmatige crawleractiviteit vermindert de schakelaar Blokkeer AI crawlers bovendien het AI-gedreven verkeer, zonder dat dit invloed heeft op traditionele zoekmachinecrawlers als Googlebot of Bingbot.
Wil je meer controle over hoe geautomatiseerd verkeer je infrastructuur bereikt, dan geeft de Botbescherming van Kinsta je het inzicht en de filtertools om onnodige belasting direct vanuit MyKinsta terug te dringen.
