Wat de firewall voor je logs verbergt: de blinde vlek van blokkades aan de edge

Een sitebeheerder opent zijn logs, zoekt op GPTBot, ClaudeBot of PerplexityBot, vindt niets en concludeert dat de AI's geen belangstelling hebben voor zijn content. Die conclusie is vaak onjuist, en wel om een mechanische reden: wanneer een firewall of een CDN een verzoek weigert, strandt dat verzoek aan de rand van het netwerk, aan de edge, en bereikt het de origin server nooit. Het bestaat dus in geen enkele log van de origin. De stilte in de logs betekent niet dat de bots wegblijven; ze kan precies het tegendeel betekenen.

Hoe een verzoek kan verdwijnen

Op een site die achter een CDN als Cloudflare wordt geserveerd, passeert elk verzoek meerdere lagen voordat het bij de server aankomt. De application firewall, beschreven in de documentatie van de WAF van Cloudflare, evalueert regels en kan blokkeren, doorsturen of een challenge tonen. Een module voor botbeheer, uitgewerkt in de documentatie Bots, classificeert geautomatiseerd verkeer en past er een beleid op toe. Sinds 2024 bieden deze platforms aan om AI-bots met één klik te blokkeren, zoals Cloudflare aankondigde in zijn bericht over het blokkeren van AI-bots, en veel sites hebben die optie aangezet zonder na te gaan wat ze deed.

Elk verzoek dat op dat niveau wordt tegengehouden, krijgt een antwoord dat door het CDN is gemaakt, doorgaans een 403 of een challengepagina. De origin server ziet er niets van. De logs van Apache, nginx of de applicatie bevatten het niet, en een tool voor loganalyse die alleen de origin leest, kan het niet meetellen.

De drie denkfouten die daaruit voortkomen

1. "Er komt geen enkele AI bij ons langs." Dat is de meest voorkomende. De site wordt in werkelijkheid wel bezocht, maar elk bezoek wordt al aan de edge geweigerd. Een regel die uit voorzorg is aangezet, soms door een dienstverlener, soms door een vinkje in een interface, snijdt in stilte elke kans om geciteerd te worden af.
2. "Ons crawl-succespercentage is 100 %." Een dashboard dat de 200-antwoorden telt die de origin heeft geserveerd, toont een perfecte score, want alleen de geaccepteerde verzoeken komen daar aan. Het werkelijke percentage, blokkades meegerekend, kan heel laag liggen.
3. "De bot respecteert onze robots.txt niet." Als robots.txt zelf door de origin wordt geserveerd maar het eerste verzoek van de bot aan de edge wordt geblokkeerd, heeft hij het nooit gelezen. Je verwijt de bot dan gedrag waarvan de oorzaak bij jou ligt.

Hoe je nagaat wat er aan de edge gebeurt

De controles, van de eenvoudigste tot de meest volledige:

• De configuratie van het CDN herlezen. WAF-regels, modus voor botbeheer, opties om "AI-bots te blokkeren", lijsten met geweigerde user-agents. Je moet die lezen zoals ze is, niet zoals je denkt haar te hebben ingesteld: op een site die we deze zomer hebben doorgelicht, sneed een blokkeerregel die uit een eerdere configuratie was overgeërfd bots af waarvan niemand in het team dacht ze te blokkeren.
• Testen met de echte user-agents. Zelf een verzoek sturen naar een openbare pagina waarin je de user-agent van elke AI-bot opgeeft, van buiten het netwerk, en kijken naar de statuscode en naar wie hem afgeeft. Een 403 die door het CDN is ondertekend terwijl de origin 200 antwoordt, is het directe bewijs van een blokkade aan de edge.
• De logs van het CDN lezen, niet alleen die van de origin. De grote CDN's ontsluiten verkeersstatistieken die ook de geweigerde verzoeken bevatten, per regel en per user-agent, en soms per pad. Daar worden de bots zichtbaar die je afwezig waande. Bij Cloudflare zijn die gegevens bereikbaar via de interface en via de API met een token dat het leesrecht Zone Analytics heeft; op een gratis abonnement kun je de uitsplitsing per pad alleen via de API krijgen.

Een gemeten geval

Op een andere site, een industriële, die dezelfde zomer is doorgelicht, toonden de logs van de origin wekenlang geen enkel verzoek van een AI-bot, en het crawl-dashboard gaf een perfect succespercentage aan. De logs van het CDN vertelden iets anders: enkele honderden verzoeken van AI-bots die door een firewallregel met een 403 waren geweigerd, waarvan niemand een spoor had. De aanvankelijke conclusie, "de AI's komen niet", was het exacte tegendeel van de werkelijkheid: ze kwamen, geregeld, en vertrokken weer zonder iets te lezen. De site kwam in geen enkel gegenereerd antwoord voor, niet door gebrek aan belangstelling van de zoekmachines, maar door een beveiligingsinstelling. De diagnose kostte een uur; ze had ook nooit gesteld kunnen worden.

De valkuil van het IP-adres

Een tweede effect van het CDN bemoeilijkt het lezen van de logs van de origin: het IP-adres dat de server ziet, is dat van het CDN en niet dat van de bezoeker, tenzij de server is ingesteld om de header te lezen die het oorspronkelijke adres meedraagt. Ontbreekt die instelling, dan lijken alle bezoekers, mensen en bots, van een paar tientallen adressen van het CDN te komen. De echtheidscontroles die worden beschreven in ons artikel over reverse DNS en IP-ranges worden onmogelijk, en een echte bot kan voor een bedrieger worden aangezien, of omgekeerd. Een eigen header die het CDN toevoegt, overleeft doorgaans alle tussenliggende hops daar waar een generieke header overschreven kan worden. Bij Cloudflare is dat CF-Connecting-IP; de generieke header, X-Forwarded-For, kan door elke tussenschakel worden herschreven. Vraag uw hostingprovider de exacte naam van de header die hij toevoegt, en ga na of die daadwerkelijk tot in de log van de origin komt.

Welk beleid je aanhoudt

De onderliggende vraag is redactioneel: een medium dat door de AI's geciteerd wil worden, heeft geen enkele reden om hun zoek- en leesbots aan de edge te blokkeren. Training blokkeren is een legitieme beslissing, maar die neem je in robots.txt, user-agent voor user-agent, zoals we uitleggen in "robots.txt en AI", en niet met één schakelaar die alles weigert wat op een AI lijkt. Een blokkade aan de edge heeft alleen zin bij aangetoond misbruik van verkeer: abnormale volumes, spoofing, scrapers die robots.txt negeren.

Eén voorzorg blijft: blokkeer de spoofers evenmin met een brede regel op de user-agent. Een regel die elke "GPTBot" weigert die van een adres buiten de door OpenAI gepubliceerde ranges komt, oogt voorzichtig; in de praktijk weigert ze ook de legitieme verzoeken op de dag dat OpenAI een range toevoegt die de lokale lijst nog niet heeft. Het juiste antwoord op spoofing is meten en afremmen, niet blind weigeren.

Wat meten betekent zodra de blokkade is opgeheven

Zodra de edge doorlaat, worden de logs van de origin weer een betrouwbare bron, op voorwaarde dat ze het oorspronkelijke adres meedragen en de volledige user-agent bewaren. Je kunt dan per bot en per gebruik (training, zoeken, lezen op aanvraag) tellen wat de AI's werkelijk lezen: welke pagina's, hoe vaak, met welke statuscode. Het is die lezing, en niet een dashboard van de origin, waarmee je kunt stellen dat de generatieve zoekmachines je content bereiken. De methode werken we uit in "Een access log lezen in 30 minuten".

Het principe is dit: een log van de origin bewijst alleen wat tot de origin is gekomen. Alles wat daarvoor is geweigerd, laat er geen enkel spoor in na, en dat is precies wat je elders moet gaan zoeken voordat je ook maar iets over de AI's concludeert.