Logfile-analyse voor SEO: wat Googlebot en AI-crawlers doen

Logfile-analyse laat zien welke URL's Googlebot, Bingbot en AI-crawlers als GPTBot en PerplexityBot echt opvragen, hoe vaak, en welke statuscode ze terugkrijgen. Search Console geeft je een samenvatting; de accesslog van je webserver geeft je elke request. Voor een webshop met filters, parameters en duizenden producten is dat het verschil tussen gissen en weten waar je crawlcapaciteit naartoe gaat.

Een crawltool zoals Screaming Frog laat zien wat er te crawlen valt. Logs laten zien wat er gecrawld wordt. Die twee leggen we in een audit altijd naast elkaar.

Wat je uit logs haalt dat nergens anders staat

Search Console heeft onder Instellingen > Crawlstatistieken een nuttig rapport. Maar het is een steekproef, alleen voor Google, en zonder koppeling aan je eigen URL-structuur.

Uit je eigen logs haal je:

• Welke URL-groepen Googlebot bezoekt. Producten, categorieën, filters, zoekresultaten, assets.
• Hoeveel crawls naar waardeloze URL's gaan. Sorteringen, sessieparameters, oude URL's met 404.
• Hoe lang het duurt voordat een nieuw product gecrawld wordt.
• Welke statuscodes bots krijgen. 301-ketens, 404's, 5xx-pieken tijdens drukte.
• Wat AI-crawlers doen. Komen GPTBot, OAI-SearchBot en PerplexityBot langs? Op welke pagina's? Respecteren ze je robots.txt?
• Welke pagina's nooit bezocht worden. Een product dat Googlebot in 60 dagen niet heeft opgevraagd, staat waarschijnlijk niet of verouderd in de index.

Dat laatste is vaak de meest bruikbare uitkomst. Het verklaart een groot deel van de URL's in "Gevonden - momenteel niet geïndexeerd". Meer daarover in gevonden maar niet geïndexeerd oplossen.

Stap 1: zorg dat je log het juiste vastlegt

Het standaard combined-formaat van nginx is ingebouwd en ziet er zo uit:

# ingebouwd in nginx, niet zelf opnieuw definiëren
log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Dat is genoeg voor de basis: IP, tijdstip, URL, statuscode, user-agent. Voor SEO-analyse voeg je liefst een paar velden toe:

log_format seo '$remote_addr - $remote_user [$time_local] "$request" $status '
               '$body_bytes_sent "$http_referer" "$http_user_agent" '
               'rt=$request_time host=$host '
               'cache=$upstream_http_x_cache';

access_log /var/log/nginx/access.log seo;

De eerste velden staan in dezelfde volgorde als bij combined. Zo blijven de awk-commando's verderop werken (URL in veld 7, statuscode in veld 9).

• $request_time vertelt hoe lang de server erover deed. Trage antwoorden aan Googlebot remmen het crawltempo.
• $host is nodig als je meerdere domeinen of storeviews op één server draait.
• Een cache-header (de naam verschilt per setup, bij Varnish vaak X-Cache of X-Magento-Cache-Debug) laat zien of bots uit de cache bediend worden.

Let op bij een CDN of proxy

Zit er Cloudflare, Varnish of een load balancer voor nginx, dan is $remote_addr het IP van de proxy, niet van Googlebot. Dan heb je de echte client-IP nodig:

# Cloudflare voorbeeld
set_real_ip_from 173.245.48.0/20;   # vul aan met de actuele Cloudflare-ranges
real_ip_header CF-Connecting-IP;

Zonder echt IP kun je bots niet verifiëren. Dan analyseer je user-agents die iedereen kan vervalsen.

Bewaartermijn

Veel servers roteren logs na een week of twee. Voor SEO wil je minimaal 30 en liefst 90 dagen. Logs bevatten IP-adressen, dus spreek met je hostingpartij en je privacybeleid af hoe lang je ze bewaart. Een gangbare oplossing: alleen de botregels langer bewaren.

Stap 2: filter bots op user-agent

Begin simpel. Een eerste telling per bot:

grep -Ei "googlebot|bingbot|gptbot|oai-searchbot|chatgpt-user|perplexitybot|claudebot|applebot" access.log \
  | grep -oEi "googlebot|bingbot|gptbot|oai-searchbot|chatgpt-user|perplexitybot|claudebot|applebot" \
  | tr 'A-Z' 'a-z' | sort | uniq -c | sort -rn

De bots die voor een webshop het meest relevant zijn:

Google-Extended en Applebot-Extended zie je níét in je logs. Dat zijn alleen tokens in robots.txt waarmee je gebruik voor AI-training regelt. Er crawlt geen aparte bot met die naam. Hoe je deze bots in robots.txt behandelt, staat in AI-crawlers in robots.txt.

Stap 3: verifieer of Googlebot echt Googlebot is

Een user-agent is een tekststring. Scrapers en SEO-tools doen zich regelmatig voor als Googlebot. Wie die niet uitfiltert, trekt conclusies op basis van nep-verkeer.

Google beschrijft zelf hoe je verifieert: een reverse DNS-lookup, en daarna een forward lookup ter controle.

# 1. Reverse lookup op het IP uit je log
host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

# 2. Forward lookup op die hostnaam
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Klopt het?

• De hostnaam eindigt op googlebot.com, google.com of googleusercontent.com.
• De forward lookup geeft hetzelfde IP terug.

Dan is het echt. Anders niet.

Voor Bingbot werkt het op dezelfde manier: de hostnaam eindigt op search.msn.com.

Bij grote logs is DNS per regel traag. Google publiceert daarom ook de IP-ranges van zijn crawlers als JSON-bestanden in de Search Central-documentatie. OpenAI en Perplexity publiceren eveneens IP-lijsten voor hun crawlers. Download die lijsten en match IP's lokaal tegen de ranges. Dat is sneller en net zo betrouwbaar, zolang je de lijsten regelmatig ververst.

Een eenvoudig script voor unieke IP's per bot:

grep -i "googlebot" access.log | awk '{print $1}' | sort -u > googlebot-ips.txt
while read ip; do
  name=$(host "$ip" | awk '/pointer/ {print $5}')
  echo "$ip $name"
done < googlebot-ips.txt | grep -vE "googlebot\.com\.$|google\.com\.quot;

Alles wat dit script teruggeeft, is een IP dat zich als Googlebot presenteert maar het niet is.

Stap 4: groepeer URL's naar paginatype

Losse URL's analyseren schiet niet op. Groepeer op patroon. Voor een Magento-shop kan dat zo:

grep -i googlebot access.log | awk '{print $7}' | \
awk '
  /\/catalogsearch\//            {print "zoekresultaten"; next}
  /\?.*(sort|dir|order|limit)=/  {print "sortering"; next}
  /\?/                           {print "parameters/filters"; next}
  /\.(js|css|png|jpe?g|webp|svg|woff2?)$/ {print "assets"; next}
  /\.html$/                      {print "product of categorie"; next}
                                 {print "overig"}
' | sort | uniq -c | sort -rn

Pas de patronen aan op je eigen URL-structuur. Bij Shopify zijn de groepen voorspelbaarder: /products/, /collections/, /collections/*/products/, /pages/, /blogs/, /search.

De rekenstap: zet het aantal crawls per groep af tegen de waarde van die groep. Als 60% van de Googlebot-requests naar filtercombinaties gaat en 10% naar productpagina's, weet je waar je moet ingrijpen. Hoe je dat aanpakt bij grote catalogi lees je in crawlbudget voor grote webshops.

Stap 5: statuscodes en snelheid

Tel per bot de statuscodes:

grep -i googlebot access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Waar je op let:

• 301/302: veel redirects betekent dat interne links of de sitemap nog naar oude URL's wijzen. Elke redirect is een extra request.
• 404: welke URL's? Oude producten met inkomende links verdienen een redirect. Willekeurige rommel niet.
• 410: een bewust signaal dat iets weg is. Prima voor definitief verdwenen producten.
• 5xx: het belangrijkste getal. Serverfouten aan Googlebot zorgen dat Google zijn crawltempo verlaagt.
• 304: Googlebot ondersteunt conditional requests. Goede Last-Modified- of ETag-headers besparen crawlcapaciteit.

Kijk ook naar rt= (request time). Haal de mediaan en het 95e percentiel per paginatype op. Als productpagina's voor Googlebot ruim boven een seconde zitten, wordt er waarschijnlijk niet uit de cache geserveerd.

Stap 6: AI-crawlers apart bekijken

AI-crawlers gedragen zich anders dan Googlebot. Wat je in logs kunt zien:

• Of ze überhaupt komen. Als OAI-SearchBot nooit langskomt, is de kans klein dat je pagina's in ChatGPT-zoekresultaten opduiken.
• Of je ze per ongeluk blokkeert. Een WAF of botprotectie bij je CDN kan AI-crawlers een 403 geven, ook als je robots.txt ze toelaat.
• Welke pagina's ChatGPT-User ophaalt. Dat zijn requests op het moment dat iemand in ChatGPT een vraag stelt waarbij jouw pagina wordt opgehaald. Dat is het dichtst bij "AI-verkeer" dat je server-side kunt zien.
• Hoeveel load ze veroorzaken. Sommige crawlers kunnen bij grote catalogi flink wat requests doen. Dat is een reden om naar rate limiting te kijken, niet automatisch om te blokkeren.

grep -i "chatgpt-user" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Dit geeft de twintig pagina's die het vaakst op verzoek van ChatGPT-gebruikers zijn opgehaald. Dat zegt meer over je zichtbaarheid in AI-antwoorden dan welke "AI-visibility score" ook. Hoe dit past in een bredere aanpak staat op GEO voor webshops.

Tools: van command line tot dedicated software

Je hebt geen dure tooling nodig om te beginnen.

• grep, awk, sort, uniq. Genoeg voor 80% van de vragen. Werkt op elke Linux-server.
• GoAccess. Open source, draait in de terminal of genereert een HTML-rapport. Handig voor een snel overzicht per user-agent en statuscode.
• Screaming Frog Log File Analyser. Importeert logs, verifieert bots en combineert het met een crawl van je site. Goed voor het naast elkaar leggen van "wat bestaat" en "wat gecrawld wordt".
• Een eigen pipeline. Logs naar een database of tool als ClickHouse of Elasticsearch, met vaste dashboards. Zinvol voor grote shops die dit doorlopend willen monitoren.

Bij Shopify heb je geen toegang tot serverlogs. Shopify host alles en geeft die logs niet vrij. Daar ben je aangewezen op de Crawlstatistieken in Search Console en de gegevens in Bing Webmaster Tools. Dat is een echte beperking van het platform.

Wat je met de uitkomsten doet

Logs zijn geen doel. Ze leveren een takenlijst op. Typische acties na een analyse:

1. Robots.txt aanscherpen voor parameterpatronen die veel crawls opslokken en niets opleveren.
2. Interne links repareren die naar redirects of 404's wijzen.
3. Caching verbeteren voor paginatypes waar bots traag bediend worden.
4. Sitemap opschonen zodat er alleen indexeerbare URL's in staan.
5. Botprotectie afstellen zodat legitieme crawlers niet geblokkeerd worden.
6. Nieuwe producten beter linken vanuit categorieën en de homepage, als ze pas na weken gecrawld worden.

Herhaal de analyse daarna. Pas dan zie je of de verdeling verschuift naar de pagina's die omzet opleveren.

Logfile-analyse is een vast onderdeel van onze technische SEO-aanpak. We doen de analyse, en de mensen die je shop bouwen voeren de fixes direct door in nginx, Magento of de applicatie. Geen rapport dat in een la verdwijnt.

Veelgestelde vragen

Waar vind ik de logfiles van mijn webshop?

Bij nginx staan ze meestal in /var/log/nginx/access.log, bij Apache in /var/log/apache2/ of /var/log/httpd/. Bij managed hosting vraag je ze op bij je hostingpartij. Gebruik je een CDN, dan kunnen ook de CDN-logs nodig zijn.

Hoeveel dagen aan logs heb ik nodig?

Minimaal 30 dagen voor een bruikbaar beeld, liefst 90. Googlebot bezoekt niet elke pagina dagelijks. Met een paar dagen data mis je de URL's die maar eens per maand gecrawld worden.

Hoe weet ik of een bezoek echt van Googlebot komt?

Doe een reverse DNS-lookup op het IP. De hostnaam moet eindigen op googlebot.com, google.com of googleusercontent.com. Doe daarna een forward lookup op die hostnaam; die moet hetzelfde IP teruggeven. Alternatief: match tegen de IP-ranges die Google publiceert.

Kan ik logfile-analyse doen op Shopify?

Nee, Shopify geeft geen toegang tot serverlogs. Je gebruikt dan de Crawlstatistieken in Search Console en de crawlgegevens in Bing Webmaster Tools. Die geven een samenvatting, maar geen volledig beeld per URL.

Moet ik AI-crawlers blokkeren als ze veel requests doen?

Niet automatisch. OAI-SearchBot en PerplexityBot bepalen of je in die zoekmachines kunt verschijnen. Blokkeren van trainingscrawlers als GPTBot is een aparte afweging. Bij overmatige load is rate limiting meestal een betere eerste stap dan een volledige blokkade.