Tegen 2025 is het digitale landschap veranderd: CAPTCHA is niet langer de betrouwbare poortwachter die het ooit was. Terwijl AI-gestuurde bots CAPTCHA-puzzels oplossen met bijna perfecte nauwkeurigheid, raken echte gebruikers gefrustreerd en verlaten vaak sites wanneer ze worden uitgedaagd. Recente studies tonen aan dat bots nu voor 96-100% door beeld- en tekst-CAPTCHAs komen—ver ver boven de succespercentages van mensen en het aantal formulierconversies met wel 20% doen dalen. Maar het probleem gaat veel dieper dan een verouderde puzzel.
Vandaag de dag domineert geautomatiseerd verkeer het web. Dit realiseer ik me persoonlijk. In 2024 werd geschat dat bijna de helft van alle online activiteit werd gegenereerd door bots, met tot 37% geclassificeerd als ronduit kwaadaardig. Zelfs sites met actieve mitigatie rapporteren nog steeds 10-20% aanhoudende botactiviteit. De realiteit is schokkend: traditionele oplossingen zoals CAPTCHA en IP-blacklists zijn vrijwel machteloos geworden in het aangezicht van gecoördineerde, snel evoluerende botnets die echte gebruikers kunnen nabootsen, door verse IP's kunnen wisselen, en zelfs mobiele apparaten kunnen misbruiken voor grootschalige aanvallen.
Voor website-eigenaren en online bedrijven is de impact verwoestend. Botstromen kunnen serverbronnen verlammen, pagina's traag maken en de gebruikerservaring verpesten. Maar de effecten gaan verder—Google-rankings dalen terwijl de pagina-prestaties kelderen, advertentie-inkomsten verdampen doordat de verkeerskwaliteit afneemt, en relaties met advertentiepartners verzuren wanneer nepbezoeken hun analyses overspoelen.
Ik heb deze crisis uit de eerste hand ervaren. Het begon allemaal met een beschuldiging van een reclamebureau: ze stelden dat 90% van het verkeer op mijn site nep was. Hun trackingcode, ingebed voor advertentiedistributie, onthulde botvolumes die niet alleen hun filters, maar ook mijn server overweldigden. We hebben het over meer dan een miljoen botbezoeken per dag—verkeer dat onzichtbaar was voor Google Analytics maar catastrofaal achter de schermen. Wat ik aanvankelijk dacht dat echte gebruikers waren, waren in werkelijkheid onderdeel van een meedogenloze golf van geautomatiseerde hits, die mijn infrastructuur overspoelden en de levensvatbaarheid van mijn hele project bedreigden.
Dit is niet alleen een verhaal over slechte actoren die zwakheden uitbuiten—het gaat over hoe de architectuur van het moderne web onder vuur ligt. Code-optimalisaties en serverupgrades waren niet genoeg. De uitdaging werd een wapenwedloop, waarbij mijn site gevangen zat in de vuurlinie. Hier is hoe de botvloed zich ontvouwde, bijna alles wat ik had opgebouwd vernietigde—en de stappen die ik nam om terug te vechten.
Mijn verhaal over botverkeer: van 3 miljoen naar een half miljoen websitebezoeken
Het begon allemaal met een reclamebureau dat me beschuldigde van 90% nepverkeer, ik heb het al eerder gezegd maar: ze hadden een trackingcode op mijn site geplaatst om advertenties te leveren, en het botvolume was ook voor hen een probleem—het overweldigde hun filters en verhoogde de serverbelasting. We hebben het over meer dan een miljoen botbezoeken per dag.
In het begin was ik verontwaardigd. In Google Analytics zag ik 100.000 pure dagelijkse bezoeken. Echte gebruikers, dacht ik. Maar hun zorg ging over verkeer buiten Analytics. Die onzichtbare laag van hits richtte ravage aan op de serverbelasting. Destijds draaide mijn project op Laravel 5.3 gehost op gedeelde hosting, en ik dacht dat de prestatieknelpunten de oude codebasis waren. Ik herschreef alles in Laravel 10 met uitstekende optimalisatie, inclusief dagelijkse analyse van miljoenen databaserecords.
Toch bleef het traag. Mijn gedeelde hosting kon het niet aan. Pagina's laadden traag, en het echte verkeer daalde—maand na maand verloor ik ongeveer 150.000 bezoeken. Van 3 miljoen maandelijkse bezoeken verloor ik uiteindelijk meer dan de helft.
Ik was overgestapt naar een krachtige VPS met 16 CPU-kernen en 32GB RAM, in de verwachting dat dit alles zou oplossen. Maar zelfs met de verbeterde infrastructuur en hercodeerde Laravel 10 backend, bleef het probleem bestaan. Sterker nog, het werd erger—de bots werden agressiever, verhoogden hun aanvalvolume en frequentie. Het werd duidelijk dat geen enkele hoeveelheid codeoptimalisatie of hardware-uitbreiding een probleem kon oplossen dat fundamenteel ging over ongecontroleerd, kwaadaardig botverkeer.
Maar dat was nog niet alles. Bij nader inzien realiseerde ik me dat de schaal zelfs groter was: meer dan 2 miljoen websitecrawls per dag, los van ongeveer 1,5 miljoen dagelijkse botbezoeken. En toch bracht het te gelde te maken, te volgen deel van de site (het deel waar bureaus om gaven) slechts 100.000 impressies per dag binnen. Daar escaleerde het probleem. Ik werkte samen met een reclamebureau dat afhankelijk was van schoon, menselijk verkeer. Ze moesten snel manieren vinden om de bots eruit te filteren, anders zouden hun analysesystemen en advertentieplatformen overweldigd raken. De beschuldigingen, de overbelasting van de infrastructuur en de discrepanties in opbrengst—ze waren allemaal verbonden met deze onzichtbare, onophoudelijke stroom van bots.
Mijn eerste stap was het maken van een aangepaste CAPTCHA, met als doel bots een lege pagina te tonen terwijl echte gebruikers doorgelaten werden. Helaas werkte dat averechts. Kwaadaardige bots vertraagden niet—ze namen toe. De CAPTCHA werd een uitdaging die ze agressief probeerden te overwinnen, wat de belasting verdubbelde.
Vervolgens kwam massablokkering via .htaccess. Het werkte—voor een paar dagen. Toen pasten de botnetwerken zich aan, verschenen nieuwe IP's en werd .htaccess log en traag. Mijn hostingprovider kwam tussenbeide en hielp tijdelijk hele subnetten te blokkeren, maar het probleem keerde wekelijks terug.
Uiteindelijk wendde ik me tot Cloudflare. Dit was de meest invloedrijke verandering. Hoewel niet perfect, stelde het me in staat om meer dan 1,5 miljoen botverzoeken binnen 24 uur te filteren. Ik uploadde netwerkblokkades direct in hun firewall. Het resultaat? Van 1,5 miljoen bot hits, werden er dagelijks slechts 20 CAPTCHA-uitdagingen geactiveerd—het bewijs dat Cloudflare's randdetectie beter werkte dan alles wat ik eerder probeerde.
Om voor te blijven op de bots, bouwde ik mijn eigen interne loggingsysteem. Het registreert elke aanvraag op IP-adres en User-Agent-string, en slaat deze op in een database. Achter de schermen draait elke minuut een geplande taak om de gegevens samen te voegen. Wanneer het verdachte activiteit detecteert—zoals een groot aantal aanvragen van een enkel netwerk of IP-bereik—wordt er automatisch een e-mailmelding verzonden. Die e-mail bevat een lijst met IP's en subnetten die klaarstaan om aan Cloudflare te worden toegevoegd voor blokkering.
Ik ben nog steeds op Cloudflare's gratis plan, maar zelfs dat biedt voldoende controle om handmatige firewallregels te implementeren. Deze proactieve benadering stelt me in staat om botstromen te detecteren en erop te reageren voordat ze het systeem overweldigen. Op Apache-niveau probeerde ik aanvankelijk .htaccess te gebruiken om verkeer direct te blokkeren, maar deze methode had afnemende opbrengsten. Naarmate meer regels zich opstapelden, degradeerde de siteprestaties, wat duidelijk maakte dat serverniveau-blokkering niet houdbaar was zonder een CDN of randlaagondersteuning.
Hoe maak je een inlogsysteem + CloudFlare-bescherming?
Waarom geen rate limiting of geo-blokkering? Omdat ze in mijn geval niet werken. De meeste van deze bots maken slechts één verzoek per IP—maar ze doen het met honderden of zelfs duizenden IP's binnen hetzelfde netwerk. Dat betekent dat rate limiting per IP niet veel helpt; het volume is verspreid, niet geconcentreerd. Wat betreft detectie door User-Agent? Zinloos. Sommige bots zijn slim genoeg om Googlebot of andere legitieme crawlers na te bootsen, dus je kunt headers alleen niet vertrouwen. Wat dacht je van geo-locatie filtering? Ook niet effectief. Mijn site is meertalig en ontvangt verkeer uit veel landen bij ontwerp. Deze flood-netwerken weten dat en roteren IP's van over de hele wereld. Misschien scrapen ze mij omdat mijn site waardevolle inhoud heeft—maar ik kan het niet zomaar achter een registratie muur verbergen. Dat zou de gebruikerservaring verpesten. Dus ik had iets slimmers nodig dan de gebruikelijke oplossingen.
