Wat Googlebot en AI-crawlers echt op je site doen

Google Search Console geeft je een nette samenvatting: zoveel pagina's gecrawld, zoveel geïndexeerd, een grafiekje crawlverzoeken per dag. Sinds 31 augustus 2026 staat daar voor alle sites ook een prestatierapport over generatieve AI bij, met het aantal keren dat je site in AI Overviews en AI Mode opduikt. Dat is winst, maar het rapport toont alleen vertoningen, geen kliks en geen zoekopdrachten, en het gaat uitsluitend over Googles eigen AI-oppervlakken. Over ChatGPT, Claude en Perplexity staat er niets, en over welke pagina's hun crawlers bij jou ophalen al helemaal niet.

Je serverlogbestanden vullen dat gat. Ze leggen elk verzoek vast dat binnenkomt: elk IP-adres, elke opgevraagde URL, elke statuscode, elke user-agent. Het is de enige bron die registreert wat een crawler op je site doet, zonder steekproef en zonder vertraging. Wie wil weten of zijn investering in content en backlinks daadwerkelijk wordt opgepikt, leest geen dashboard maar zijn eigen logs.

Wat legt een serverlog precies vast?

Een serverlog is een tekstbestand waarin je webserver elke binnenkomende aanvraag op een aparte regel wegschrijft. Apache en Nginx gebruiken standaard het zogenoemde combined log format. Eén regel ziet er ongeveer zo uit:

66.249.66.1 - - [28/May/2026:09:14:02 +0200] "GET /diensten/linkbuilding/ HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

In die ene regel staat alles wat je nodig hebt. Van links naar rechts: het IP-adres van de bezoeker, de datum en tijd, de opgevraagde URL met methode, de HTTP-statuscode (hier een 200), het aantal verzonden bytes, de verwijzende pagina, en helemaal achteraan de user-agent die verraadt wie er aanklopt. Vermenigvuldig dat met honderdduizenden regels per maand en je hebt een compleet bewegingsregister van iedere bot en bezoeker.

Het verschil met Search Console zit in de ruwheid. Search Console aggregeert, bemonstert en vertraagt: je ziet totalen en trends, geen losse verzoeken. Ook het nieuwe AI-rapport kent die grenzen, want het valt onder dezelfde limiet van duizend rijen per weergave. Op sites met meer dan vijftigduizend URL's wordt dat een probleem, want dan toont het rapport alleen nog een fractie van wat er werkelijk gebeurt.

Logs kennen die limiet niet. Ze tonen elke individuele hit, inclusief de pagina's waarvan je niet eens wist dat ze bestonden.

Je vindt de bestanden op je server meestal in /var/log/nginx/ of /var/log/apache2/, op CentOS-systemen in /var/log/httpd/. Werk je met een controlepaneel als DirectAdmin of cPanel, dan staan de zogeheten raw access logs vaak achter een knop in je dashboard. Belangrijk om te weten: veel hosters bewaren logs maar enkele dagen. Wie patronen wil zien, moet ze structureel wegschrijven naar bijvoorbeeld externe opslag, anders is de data verdwenen voordat je iets nuttigs kunt concluderen.

Waarom is logfile-analyse juist nu belangrijk?

Logfile-analyse is nu belangrijk omdat er een categorie bezoekers is bijgekomen waarvoor nog bijna geen dashboard bestaat, en omdat het dit jaar over geld gaat. AI-crawlers halen massaal content op om taalmodellen te trainen en om antwoorden in ChatGPT, Claude en Perplexity van bronnen te voorzien. Of jouw pagina's daarin meedoen, zie je buiten Googles eigen AI-rapport nergens terug, behalve in je logs. Zoals Search Engine Land het stelt: logbestanden zijn voorlopig de enige manier om te zien hoe AI-systemen je site werkelijk benaderen.

Dat die verhouding scheef ligt, is inmiddels algemeen bekend. AI-bots halen veel pagina's op en sturen weinig bezoekers terug, en de verhouding tussen die twee heet de crawl-to-refer ratio. Wees voorzichtig met de cijfers die daarover rondgaan, want ze schommelen hard.

Metingen over het eerste kwartaal van 2026 kwamen voor ClaudeBot uit op tienduizenden opgehaalde pagina's per doorverwezen bezoeker, terwijl metingen over juli van datzelfde jaar op een paar duizend uitkwamen en GPTBot op enkele honderden. Googlebot zit in vrijwel elke meting rond de vijf. De richting is stabiel, het getal niet, en dat is precies waarom je je eigen ratio wilt berekenen in plaats van die van een onderzoeksbureau te citeren.

Interessanter dan het exacte getal is wat die crawlers ophalen. Cloudflare meldde bij zijn aankondiging van 1 juli 2026 dat meer dan de helft van het AI-crawlverkeer bestaat uit het opnieuw ophalen van pagina's die sinds het vorige bezoek niet zijn veranderd, en dat bots dit jaar het menselijke verkeer op het web hebben ingehaald. Dat is geen abstracte statistiek. Het is bandbreedte en servercapaciteit die jij betaalt voor hetzelfde bestand dat de bot vorige week al had, en je ziet het terug als identieke 200-regels op dezelfde URL in je eigen logbestand.

Daar komt een commerciële laag bij. Cloudflare begon in 2025 met Pay Per Crawl, waarbij een bot een 402-foutmelding kreeg tenzij hij per opgevraagde pagina betaalde. Op 1 juli 2026 kondigde het bedrijf aan dat model te vervangen door Pay Per Use, waarin een uitgever niet wordt betaald voor het ophalen van een pagina maar voor het gebruik ervan in een antwoord, aldus TechCrunch. Of jij open of dicht staat voor die bots, en of ze daadwerkelijk binnenkomen, controleer je het betrouwbaarst in je logs. Ontbreekt GPTBot volledig in je logs, dan word je niet meegenomen.

Welke crawlers moet je in je logs herkennen?

Je moet drie soorten bots herkennen: trainingscrawlers, zoekcrawlers en ophaalcrawlers. Trainingscrawlers verzamelen content voor toekomstige modellen en komen onregelmatig en in golven langs. Zoekcrawlers bouwen een index waaruit een AI-antwoord zijn bronnen haalt. Ophaalcrawlers, ook agents genoemd, reageren op een concrete vraag van een gebruiker en bezoeken gericht enkele URL's. Dezelfde driedeling gebruikt Cloudflare inmiddels in zijn instellingen: Search, Training en Agent.

Je herkent ze aan het stukje tekst in de user-agent. Een actuele lijst houdt Search Engine Journal bij, maar dit zijn de namen die je nu in vrijwel elk logbestand tegenkomt:

• Googlebot (Googlebot/2.1) - de klassieke zoekmachinecrawler, en tegelijk de bron voor AI Overviews en AI Mode.
• GPTBot (GPTBot/1.1) - haalt content op die OpenAI gebruikt om modellen te trainen.
• OAI-SearchBot (OAI-SearchBot/1.0) - indexeert pagina's voor de zoekfunctie binnen ChatGPT, los van training.
• ChatGPT-User (ChatGPT-User/1.0) - bezoekt een pagina alleen wanneer een gebruiker ChatGPT vraagt die specifieke link te openen.
• ClaudeBot - de trainingscrawler van Anthropic, berucht om zijn hoge crawlvolume.
• Claude-SearchBot - bouwt de zoekindex achter de antwoorden van Claude.
• Claude-User - haalt een pagina op wanneer de vraag van een Claude-gebruiker dat vereist.
• PerplexityBot en Perplexity-User - respectievelijk de index en de losse paginabezoeken van Perplexity.
• MistralAI-User - de on-demand crawler van Mistral, die een pagina ophaalt wanneer een gebruikersvraag erom vraagt.
• Google-Agent - de agent die namens een gebruiker pagina's ophaalt, en die je sinds dit jaar in je logs ziet.
• Google-GeminiNotebook - de huidige Gemini Notebook-agent, die het oude Google-NotebookLM opvolgt (dat tot augustus 2026 werd ondersteund).

Eén naam die je in deze lijst nooit zult aantreffen, is Google-Extended, en dat is een wijdverbreid misverstand. Google-Extended is geen crawler maar een besturingstoken zonder eigen user-agent: je gebruikt het in robots.txt om te bepalen of je content voor het trainen van Gemini mag worden gebruikt, maar er klopt nooit iets met die naam bij je server aan. Zoek je het in je logs, dan vind je niets, en dat zegt niets over je instelling.

Let verder op het verschil tussen de drie categorieën, want dat is geen detail. Zie je wel GPTBot maar nooit OAI-SearchBot, dan word je misschien wel gebruikt voor training, maar verschijn je niet in de live zoekresultaten van ChatGPT. Komt ChatGPT-User of Claude-User regelmatig langs, dan vragen echte gebruikers actief om jouw pagina's. Houd daarbij in gedachten dat Google zelf schrijft dat zijn door gebruikers aangestuurde fetchers robots.txt over het algemeen negeren, juist omdat er een mens achter zit. Door per user-agent te filteren, zet je het gedrag van alle bots naast elkaar en zie je precies welke content waar terechtkomt. En wil je weten wat dat op het blog doet waar je een plaatsing koopt, dan is dat in de robots.txt van die site vaak anders geregeld dan je verwacht.

Waarom je logs leeg kunnen zijn terwijl de bot wel kwam

Een ontbrekende regel betekent sinds dit jaar niet meer automatisch dat de bot niet langskwam. Zit er een CDN of een beveiligingslaag voor je site, dan kan die het verzoek afhandelen of blokkeren voordat het je eigen server bereikt. Je origin-log blijft dan stil terwijl er in werkelijkheid honderden verzoeken zijn geweest. Op elke site achter Cloudflare, Fastly of een vergelijkbare dienst lees je je logs dus naast het dashboard van die dienst, niet in plaats daarvan.

Dat is geen theoretisch risico meer, want de standaardinstellingen zijn veranderd. Cloudflare blokkeert sinds 15 september 2026 Training- en Agent-crawlers standaard op pagina's met advertenties, bij nieuwe domeinen en bij bestaande gratis accounts. Tegelijk kwam er een instelling Disallow AI Training, waarmee je training weigert terwijl zogenoemde accountable crawlers wel voor zoeken blijven komen. De harde variant Block is riskanter dan hij lijkt: volgens Search Engine Journal sluit die ook Googlebot, Applebot en Bingbot volledig buiten, inclusief voor gewoon zoeken.

Je logs zijn de plek waar je dat merkt voordat je rankings het merken. Drie signalen moeten een alarmbel doen afgaan: Googlebot die 403's krijgt op pagina's die eerder 200 gaven, een crawler die van de ene op de andere dag volledig uit je log verdwijnt, en een plotselinge piek aan 429's. Controleer dat direct na elke wijziging aan je bot- of firewallinstellingen, en zeker als iemand anders dan jij aan dat dashboard zit.

Hoe weet je of het echt Googlebot is?

Dat weet je pas zeker na een dubbele DNS-controle op het IP-adres uit je logregel. Vertrouw nooit blind op de user-agent, want die tekst is triviaal te vervalsen. Iedere scraper of spamtool kan zich "Googlebot" noemen om je vriendelijker te laten reageren. Onderzoek laat zien dat tussen de twaalf en achttien procent van het verkeer dat zich als Googlebot voordoet, in werkelijkheid nep is. Wie zijn logs serieus neemt, controleert de identiteit.

Google beschrijft daar zelf de officiële methode voor in de documentatie over het verifiëren van Googlebot. Je neemt het IP-adres uit je log en doet er een reverse DNS-lookup op met het host-commando. Het resultaat moet eindigen op googlebot.com, google.com of googleusercontent.com. Vervolgens doe je een forward lookup op die hostnaam en controleer je of die weer uitkomt op exact hetzelfde IP-adres. Klopt die heen-en-terugcontrole, dan is het echt. Een vervalser kan namelijk wel de user-agent namaken, maar niet beide kanten van Googles DNS.

Voor de AI-crawlers is dat inmiddels eenvoudiger geworden, want de aanbieders publiceren hun IP-ranges nu zelf als JSON-bestand dat je dagelijks kunt ophalen. Google doet dat voor zijn crawlers, OpenAI heeft aparte lijsten op openai.com/gptbot.json, openai.com/searchbot.json en openai.com/chatgpt-user.json, Anthropic publiceert claude.com/crawling/bots.json en Perplexity perplexity.ai/perplexitybot.json. Die bestanden worden regelmatig vernieuwd, dus haal ze op in plaats van de ranges over te typen. Logtools als Screaming Frog en de Semrush Log File Analyzer doen de verificatie standaard en markeren vervalste verzoeken automatisch. Werk je met ongeverifieerde data, dan baseer je beslissingen op verkeer dat misschien helemaal niet van Google komt.

Hoe ziet verspild crawlbudget eruit in je logs?

Verspild crawlbudget herken je aan bots die hun tijd verdoen aan pagina's die er commercieel niet toe doen. In de praktijk blijkt dertig tot veertig procent van alle crawlverzoeken naar URL's te gaan die een bedrijf nooit bewust zou prioriteren. Denk aan eindeloze filtercombinaties in een webshop, URL's met sessieparameters, printvriendelijke varianten, interne zoekresultaten en oude redirectketens. Elke keer dat Googlebot zo'n waardeloze URL ophaalt, is dat een verzoek dat niet naar je belangrijke pagina's gaat.

Crawlbudget is het aantal pagina's dat Google binnen een bepaalde periode op je site wil ophalen, en op grotere sites is dat eindig. Google legt in zijn handleiding over crawlbudget uit dat het wordt bepaald door de capaciteit van je server en de interesse van Google in je content. Je logs laten zien waar dat budget heen lekt. Sorteer je crawlverzoeken op URL, dan zie je meteen welke nutteloze patronen de meeste hits opslokken. Dat is ook de reden dat een nieuwe backlink pas na weken effect heeft: tussen de link en je ranking zit een crawl die eerst moet plaatsvinden.

Let daarbij vooral op de statuscodes. Een berg 404's die bots blijven opvragen, verspilt budget aan pagina's die niet meer bestaan. Lange ketens van 301-redirects vertragen elke crawl. Duiken er 403- of 429-codes op bij AI-crawlers, dan blokkeer of beperk je ze mogelijk zonder het te weten. En ontbreekt een belangrijke nieuwe pagina dagen of weken in je logs, dan is dat een hard signaal dat je interne links die pagina niet goed doorgeven.

Wat je logs ook over je AI-bezoekers vertellen

Je logs registreren niet alleen de bots, maar ook de mensen die via een AI-antwoord bij je uitkomen, en daar schuilt een meetprobleem dat de ruwe data oplost. Verkeer uit een AI-app komt in Google Analytics vaak binnen als direct verkeer, omdat de verwijzende pagina in de webview verloren gaat. Search Engine Journal meldde begin oktober 2026 dat Google ongedocumenteerd UTM-parameters is gaan toevoegen aan de links in Gemini-antwoorden. Een UTM in de URL staat wel in je ruwe logregel, ook wanneer de referrer onderweg is weggevallen. Houd er rekening mee dat Google de implementatie niet heeft gedocumenteerd en dat de details nog kunnen schuiven.

Praktisch betekent dat twee greps naast elkaar. Tel over dezelfde periode hoeveel crawlverzoeken een aanbieder deed, en hoeveel echte bezoekers er vanuit diezelfde aanbieder binnenkwamen. De verhouding daartussen is je eigen crawl-to-refer ratio, en die is bruikbaarder dan elk marktgemiddelde, omdat hij over jouw pagina's en jouw niche gaat. Meet hem maandelijks, want bij deze bots is één week veel te kort om iets te zien.

Een eerste logfile-analyse in vijf stappen

Je hebt geen duur platform nodig om te beginnen. Met een logbestand en de commandregel kom je al ver. Werk deze volgorde af:

1. Haal je logs op. Download het toegangslogbestand van de afgelopen weken via je hoster of kopieer het van de server. Hoe langer de periode, hoe betrouwbaarder het beeld, zeker bij grillige AI-crawlers.
2. Filter op één crawler. Tel hoe vaak een bot langskwam met een simpele regel, bijvoorbeeld grep "GPTBot" access.log | wc -l. Herhaal dat voor Googlebot, ClaudeBot, Claude-User en de rest om de verhoudingen te zien.
3. Zoek de probleemcodes. Filter op foutcodes met iets als grep "Googlebot" access.log | grep ' 403 ' en breng in kaart welke pagina's bots niet binnenkomen. Herhaal dat voor 404 en 429.
4. Rangschik op opgevraagde URL. Tel per pagina hoeveel crawlhits er binnenkomen en zet ze van hoog naar laag. Bovenaan hoor je je commercieel belangrijkste pagina's te zien, niet je interne zoekresultaten.
5. Verifieer en verdiep. Controleer verdachte bots met de DNS-methode of de gepubliceerde IP-lijsten, en laad het bestand desgewenst in een tool als de Screaming Frog Log File Analyser voor sorteerbare overzichten van crawlfrequentie, statuscodes en responstijden.

Na deze ronde weet je drie dingen die geen enkel ander rapport je geeft: welke bots je site echt bezoeken, welke pagina's hun aandacht krijgen, en waar ze tegen muren oplopen.

Wat je deze week met je logs kunt doen

Logfile-analyse klinkt als technisch monnikenwerk, maar de eerste winst pak je in een uur. Begin klein en concreet:

• Controleer of AI-crawlers binnenkomen. Grep je logs op GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot en PerplexityBot. Staan ze er niet, dan mis je structureel zichtbaarheid in AI-antwoorden en is dat je eerste werkpunt.
• Controleer je botinstellingen bij je CDN. Zit je achter Cloudflare, kijk dan of je op Block staat in plaats van op Disallow AI Training, en of Googlebot nog gewoon 200's krijgt. Deze instelling is in september 2026 voor veel domeinen automatisch gewijzigd.
• Stop de grootste lekken. Identificeer de nutteloze URL-patronen die het meeste crawlbudget opslokken en sluit ze af met robots.txt, canonicals of nette redirects.
• Bewaar je logs langer. Zet automatisch wegschrijven aan, zodat je over een paar maanden patronen kunt zien in plaats van losse momentopnames.

De diepere les is simpel. Je kunt nog zo veel investeren in sterke content en gezaghebbende backlinks, maar het rendeert pas als crawlers die pagina's daadwerkelijk ophalen en indexeren. Een backlink naar een pagina die Googlebot nauwelijks bezoekt, geeft zijn waarde maar traag door. En of een bot langskwam, bepaalt sinds dit jaar steeds vaker een instelling bij je CDN in plaats van je robots.txt. Je logs zijn de enige plek waar je dat hele proces kunt controleren in plaats van erop te hopen. Begin met lezen, en je site verandert van een zwarte doos in een open boek.