AI-crawlers blazen je verkeerscijfers op, en de gebruikelijke kortere weg — het controleren van de User-Agent-header — vangt dit niet op.

Een recente log-scan van acht dagen onthulde 468 echte artikel-fetches, maar 991 verzoeken die zich voordeden als AI-bots terwijl ze in werkelijkheid op zoek waren naar bestanden zoals .env of .git. De schuldige? Iedereen kan een zelfverklaarde User-Agent-string zoals GPTBot of ChatGPT-User in een HTTP-verzoek invoegen.

Waarom deze metriek ertoe doet

Websites zien een piek in "AI-verkeer" als een teken van relevantie. Ze gebruiken de cijfers om advertentietarieven te rechtvaardigen, serverbronnen toe te wijzen en te pronken bij investeerders. Wanneer de helft van de gerapporteerde AI-hits slechts ruis is, raken budgetten ontspoord en worden dashboards misleidend.

De twee filters die claim van realiteit scheiden

  1. Cloudflare's verifiedBotCategory – Cloudflare vult dit veld pas in nadat het IP-adres van het verzoek via reverse DNS is gekoppeld aan een bekend bot-domein. Als de header "GPTBot" zegt, maar het IP-adres de lookup niet doorstaat, belandt het verzoek in de categorie "niet-geverifieerd".
  2. Sitemap-controle – Een bot leest je inhoud pas echt als de gevraagde URL in je XML-sitemap staat. Verzoeken naar paden die niet in de sitemap staan, zijn waarschijnlijk op zoek naar kwetsbaarheden in plaats van artikelen te indexeren.

Het toepassen van beide filters op dezelfde steekproef van acht dagen leverde schokkende cijfers op:

  • ChatGPT-User – 39 % van de verzoeken is geverifieerd.
  • GPTBot – 13 % geverifieerd.
  • PerplexityBot – 0 % geverifieerd.
  • Google-Extended – 0 % geverifieerd; de string komt niet overeen met een officiële Google-crawler.

Zelfs onder de geverifieerde aanroepen haalden veel bots alleen robots.txt of de sitemap zelf op, en niet de artikelpagina's die er voor jou toe doen.

Wat ontwikkelaars vandaag nog kunnen doen

  • Schakel Cloudflare-botverificatie in in je analytics-pipeline. Het veld verifiedBotCategory verschijnt in de request headers en kan worden opgeslagen naast je eigen logs.
  • Houd een actuele sitemap bij en automatiseer een controle of het pad van elk inkomend verzoek daar aanwezig is voordat je het als een weergave van content telt.
  • Filter niet-GET-methoden uit en verzoeken die zich richten op typische ontwikkelingsbestanden (.env, .git, .bak). Dit zijn bijna altijd kwaadaardige scans.

Het tegenargument

Sommigen beweren dat reverse DNS-controles kunnen worden vervalst (spoofed) en dat het legitieme doel van een bot kan zijn om nieuwe URL's te ontdekken die nog niet in de sitemap staan. Die zorgen zijn terecht: een vastberaden aanvaller zou een DNS-record kunnen compromitteren, en nieuwe content zal van nature afwezig zijn in de huidige sitemap tot de volgende generatiecyclus.

De pragmatische reactie is om verificatie te behandelen als een betrouwbaarheidsscore in plaats van een harde grens. Combineer DNS-verificatie, de aanwezigheid in de sitemap en controles van de request-methode om de lat hoger te leggen voor wat je als "echt AI-verkeer" telt. Als een verzoek twee van de drie controles doorstaat, markeer het dan voor handmatige controle in plaats van het direct te verwerpen.

Waar je op moet letten

  • Wijzigingen in de verificatie-API van Cloudflare – elke wijziging in de verifiedBotCategory-logica kan de verificatiepercentages beïnvloeden.
  • Opkomst van nieuwe zelf-geïdentificeerde bots – houd de User-Agent-strings in je logs in de gaten; een plotselinge piek kan wijzen op een nieuwe scanner die zich voordoet als een AI-crawler.
  • Frequentie van sitemap-generatie – langere intervallen vergroten de kans dat legitieme crawlers verkeerd worden geclassificeerd.

De belangrijkste les is simpel: stop met het behandelen van een User-Agent-string als bewijs. Voeg DNS-verificatie en sitemap-validatie toe, en je krijgt een duidelijker beeld van wie je inhoud daadwerkelijk leest.

Source: https://dev.to/aulvem/ai-crawler-user-agents-are-self-reported-468-real-fetches-991-fake-ones-bgo