Logfile analyse

Door middel van SEO logfile analyses krijg je waardevolle inzichten over hoe elke zoekmachine jouw website crawlt (uitleest). Deze informatie wordt soms onderschat, maar kan een goudmijn zijn voor jouw SEO prestaties. In deze blog leg ik uit waarom logfile analyse belangrijk is, welke inzichten je uit je logs kan krijgen en hoe je dit eventueel kan oplossen voor een maximaal SEO succes.

Waarom logfile analyse?

Serverlogs registreren elk verzoek dat aan je website infrastructuur wordt gedaan. Wanneer Googlebot een URL ophaalt (fetched), verschijnt dat verzoek in je logs. Dit komt samen met de exacte tijdstempel, de geretourneerde statuscode, de responstijd en het aantal overgedragen bytes.

Jouw eigen logfiles zijn het waardevolst omdat: Search Console levert data op basis van steekproeven en met vertraging in de rapportage. Crawltools van derden laten zien wat hun crawler ziet, niet wat Googlebot daadwerkelijk doet.

Voor sites waar crawl budget een serieuze beperkende factor is, meestal sites met honderdduizenden of miljoenen pagina’s, is loganalyse het belangrijkste diagnostische middel. Het geeft antwoord op vragen die geen enkele andere databron kan beantwoorden. Denk aan:

• Inzicht krijgen in welke pagina’s van je website wel en niet uitgelezen worden. 
• Inzicht krijgen in de responscodes die de zoekmachines te zien krijgen.
• Inzicht krijgen in welke pagina’s vaker gecrawld worden en dus prioriteit van Google krijgen
• Hoe lang duurt de response tijd?
• Fetched het de bronnen die nodig zijn om javascript te kunnen renderen

Crawlbudget niet voor iedereen relevant

Crawl budget is niet voor elke website relevant. Voornamelijk voor grote websites, zo deelde John Muller, een medewerker van Google recent:

Maar Google vertelt op zijn blog wel duidelijk:

“Crawl health: if the site responds really quickly for a while, the limit goes up, meaning more connections can be used to crawl. If the site slows down or responds with server errors, the limit goes down and Googlebot crawls less”

Zelf aan de slag met logfile analyse

Voordat je aan de slag kan gaan met logfile analyses, heb je twee zaken nodig: een webserver logfile en een logfile analyse tool. Je kan gebruik maken van Excel, BigQuery, Python om je logs uit te pluizen. Echter zijn er veel (niet al te dure tools) op de markt die je een hoop tijd besparen. Zoals:

• Screaming Frog Log File Analyser: Werkt met een grafische interface (GUI), verwerkt grote bestanden en heeft ingebouwde bot-verificatie.
• Botify / JetOctopus / Lumar / OnCrawl: Cloud-gebaseerde loganalyse met Search Console-integratie.

Wat is een webserver logfile?

Een webserver logfile is een overzicht van alle vragen (hits) die een webserver ontvang. De data die bewaard wordt, is anoniem en bevat zaken zoals:

• Server IP
• Tijdstempel (dag/tijd)
• Url request (de pagina die bezocht wordt)
• Http status code (is je pagina bereikbaar (2xx) of niet (404 pagina)
• De user agent (Bijvoorbeeld: Googlebot)
• Bytes
• Referrer (de verwijzende bron)

Naast het gedrag van de zoekmachines, staat er nog meer in een logfile, bijvoorbeeld een collega die op een CMS is ingelogd etc. Voor het analyseren van je SEO prestaties heb je deze log-gegevens niet nodig.

Tip: Geef bij je webdevelopers aan dat je alleen het gedrag van zoekmachines en LLM’s wilt analyseren. De rest mag verwijderd worden uit de logs. Vraag niet alleen om de logfiles van je webserver, maar ook om de logs van een CDN of een loadbalancer (mits die aanwezig zijn).

Crawlbudget, zet het optimaal in

Google heeft niet de tijd om het volledige web dagelijks uit te lezen. Daarvoor heeft het een zo genoemde: crawlbudget. Crawl budget betekent: hoe vaak kan en wil een zoekmachine jouw website uitlezen. Jij als SEO specialist, wilt dat hier optimaal gebruik van gemaakt wordt. Dus probeer je o.b.v. je logfile analyse fouten op te sporen en op te lossen. Denk aan:

Crawl frequency per website sectie

Deze verdeling zou grofweg overeen moeten komen met je contentprioriteiten. Als je blog aanzienlijk organisch verkeer genereert, maar slechts 10% van de crawlaandacht krijgt terwijl een sectie met weinig waarde domineert, onderzoek dan waarom dat zo is.

Website sectie	Requests/dag	% van crawl
/product/	12,450	62%
/categorie/	4,200	21%
/blog/	2,100	10%
/pagina/	890	4%
overig	560	3%

Statuscode per onderdeel van je website

Een verhoogd aantal redirects suggereert dat er intern gelinkt wordt naar niet-canonieke URL’s. Hoge 404-percentages kunnen wijzen op verwijderde content waarnaar nog steeds intern of extern wordt verwezen. Alle 5xx-fouten die Googlebot tegenkomt, tasten de crawlefficiëntie aan en moeten dringend worden opgelost.

Status	Aantal	%	Intrepetatie
200	18,450	87%	Succesvolle responses
301	1,240	6%	Redirects (onderzoeken als het aantal hoog is)
304	890	4%	Niet gewijzigd (caching werkt)
404	420	2%	Pagina niet gevonden (zie je spikes? onderzoek het gedrag)
500	200	1%	Server errors (direct onderzoeken)

Response tijd analyse

Als je logs de responstijd bevatten (vaak genoteerd als %D in Apache of $request_time in Nginx), analyseer dan de patronen in latency (vertraging):

• Per URL-patroon: Zijn bepaalde paginatypes structureel traag?
• Op tijdstip: Verslechteren de prestaties tijdens piekuren?
• Per crawler: Krijgt Googlebot tragere reacties dan gewone gebruikers?

Google verlaagt de crawlsnelheid (crawl rate) als servers traag reageren. Responstijden voor Googlebot die structureel boven de 200ms liggen, vereisen een onderzoek naar de prestaties.

Belangrijke bronnen geraadpleegd?

Controleer voor JavaScript-gerenderde sites of Googlebot de resources opvraagt die nodig zijn voor het renderen:

• JavaScript-bundels (/static/js/*.js)
• CSS-bestanden (/static/css/*.css)
• API-endpoints die worden aangeroepen tijdens het renderen (/api/*)
• Webfonts en afbeeldingen waarnaar in de CSS wordt verwezen

Als deze resources niet in de verzoeken van Googlebot verschijnen, controleer dan je robots.txt op onbedoelde blokkades of verifieer of de URL’s van de resources daadwerkelijk toegankelijk zijn.

Intern gelinkt maar niet gecrawld

Vergelijk URL’s die interne links ontvangen met URL’s die Googlebot heeft opgevraagd:

• URL’s met 10+ interne links: 45.000
• URL’s met 10+ interne links EN een verzoek van Googlebot (90 dagen): 38.000
• Kloof: 7.000 URL’s die gelinkt worden, maar niet gecrawld zijn

Dit verschil suggereert mogelijk:

• Problemen met JavaScript-rendering: Links bestaan in de gerenderde DOM, maar niet in de HTML die door de server wordt verzonden.
• Nofollow op grote schaal: Interne links bevatten mogelijk onverwacht rel="nofollow".
• Crawlprioritering: Google kiest ervoor deze links niet te volgen, ondanks dat ze worden gezien.
• Fouten in linkdetectie: Links bevinden zich op locaties die Googlebot niet parset (JavaScript event handlers, niet-standaard attributen).

Onderzoek handmatig een steekproef. Gebruik Google’s URL-inspectietool om te zien of Google via andere detectiepaden van deze pagina’s op de hoogte is.

URL’s in XML sitemap niet gecrawld

Leg je XML-sitemaps naast je crawllogs:

• URL’s in sitemap: 125.000
• Sitemap-URL’s gecrawld (90 dagen): 98.000
• Nooit opgehaald: 27.000

Mogelijke oorzaken:

• Sitemap niet verwerkt: Controleer of de sitemap in Search Console verschijnt met het juiste aantal URL’s.
• Signalen van lage prioriteit: Google kan URL’s minder prioriteit geven op basis van historische kwaliteit of updatepatronen.
• Uitputting van crawlbudget: Google wijst beperkte crawlmiddelen toe; URL’s met een lagere prioriteit kunnen voor onbepaalde tijd worden uitgesteld.
• Problemen met URL-patronen: variaties in parameters of inconsistenties met de trailing slash (afsluitende slash) tussen de sitemap en canonieke URL’s.

De sitemap is een verzoek om te crawlen, geen garantie. De sitemap-documentatie van Google vermeldt expliciet dat het indienen geen garantie biedt voor crawlen of indexeren.

Canonical doelpagina, zonder bot hits

Als je een rel="canonical" instelt van pagina A naar pagina B, maar Googlebot pagina B nooit rechtstreeks opvraagt, kan dit wijzen op:

• Google is het niet eens met je canonical: Het heeft mogelijk een andere canonical geselecteerd op basis van eigen signalen.
• Het canonical-doel is niet toegankelijk: De URL wordt mogelijk geblokkeerd, geredirect of geeft een foutmelding.
• Signaalverwarring: Er zijn tegenstrijdige canonical-signalen op de site.

Controleer via de URL-inspectietool wat Google’s geselecteerde canonical is in vergelijking met jouw opgegeven canonical.

Crawl budget waste

Identificeer URL-patronen die onevenredig veel crawlaandacht krijgen in verhouding tot hun waarde:

Url patroon	Requests/day	Index waarde
/search?q=*	8,200	Niet (interne zoekopdrachten)
/product/*?soort=*	5,100	Laag (Productvarianten)
/product/*?kleur=*	4,800	Laag (productvarianten)
/product/* (canonical)	3,200	Hoog (productpagina’s)

Wanneer variaties met parameters meer crawlaandacht krijgen dan je canonieke productpagina’s, verspil je crawlbudget. Oplossingen zijn onder meer:

• Blokkades via robots.txt voor patronen met weinig waarde
• URL-parameterinstellingen in Search Console
• Canonical-tags die van parametervarianten naar schone URL’s verwijzen

Redirect chains ontdekken

Identificeer URL’s waarop Googlebot herhaaldelijk 301/302-responses ontvangt:

• /oude-pagina → 301 (komt 45 keer voor in 30 dagen)
• /slug/product → 301 (komt 120 keer voor in 30 dagen)

Herhaalde redirect-reacties wijzen op:

• Interne links naar redirect-bronnen: Werk interne links bij zodat ze direct naar de eindbestemming verwijzen.
• Externe links die je niet beheert: De redirects zijn hier noodzakelijk, maar er kunnen ketens (chains) bestaan.
• Redirect-loops of ketens: Volg de redirect-bestemmingen om te controleren of ze daadwerkelijk op een werkende pagina uitkomen.

Elke redirect kost één crawlverzoek. Een pagina die drie ‘hops’ vereist (A → B → C → D) verbruikt dus vier verzoeken om de bestemming te bereiken.

Logfiles + Google search console indexering status

Ontdekt i.s.m. Google search console of Google overal bijkomt, of er kwaliteits of canonical issues zijn.

status	Indexering status	Intrepetatie
Frequent gecrawld	geïndexeerd	Werkt zoals verwacht
Frequent gecrawld	Niet geindexeerd	Kwaliteit of canonical issues
Niet gecrawld	Niet geindexeerd	Crawler komt niet bij je bestanden
Nooit gecrawld	Geindexeerd	Ontdekt via je XML sitemap of interne links

Logfiles + XML sitemap

Vergelijk de signalen van actualiteit (freshness) in je sitemap met de daadwerkelijke crawlpatronen:

• URL’s met een recente <lastmod> maar zonder recente crawls: De signalen van actualiteit worden mogelijk niet vertrouwd (Google negeert de datum omdat deze in het verleden onnauwkeurig bleek).
• URL’s zonder <lastmod> die toch vaak worden gecrawld: Google beschikt over andere signalen om de actualiteit van deze pagina’s te bepalen.
• Nieuwe URL’s in de sitemap die nooit zijn gecrawld: Ontdekking via de sitemap is niet gegarandeerd.

Logfiles + backlink data

Onderzoek URL’s met backlinks van hoge autoriteit die geen verzoeken van Googlebot ontvangen:

• Is de URL toegankelijk? (Controleer op blokkades of foutmeldingen).
• Wordt de backlink daadwerkelijk gevolgd? (Controleer op nofollow of JavaScript-links).
• Heeft Google de linkende bron in waarde verlaagd?

Externe links lokken doorgaans een crawl uit. Doelpagina’s die ondanks kwalitatieve backlinks ongecrawld blijven, wijzen op toegangsproblemen.

Logfiles + Analytics data

Vergelijk gecrawlde pagina’s met pagina’s die organisch verkeer ontvangen:

• Gecrawld, geen verkeer: Geïndexeerd, maar rankt niet, of is helemaal niet geïndexeerd.
• Wel verkeer, zelden gecrawld: stabiele posities; Google ziet geen noodzaak om frequent opnieuw te crawlen.
• Veel verkeer, veel gecrawld: belangrijke pagina’s die passende aandacht krijgen.

Afwijkingen in deze correlatie (intensief gecrawlde pagina’s met nul verkeer) kunnen wijzen op verspild budget of indexeringsproblemen.

Niet wenselijke IP adressen indentificeren

Zie je onbekende IP-adressen langskomen die bijvoorbeeld niet van Google of bing afkomstig zijn, dan is het een overweging om dit IP-adres te blokkeren. Zo bespaar je de server ruimte die je beschikbaar kan stellen aan partijen bij wie je dat wilt. Let wel op dat je niet verkeerde IP adressen uitsluit, bijvoorbeeld die van van Google en Bing

Logfiles en gedrag van LLM’s

Jouw logfiles kunnen ook waardevolle inzichten geven m.b.t. het gedrag van LLM’s zoals: chatGPT, Gemini en Perplexity. Dat zit zo:

• Wanneer je een vraag stelt in een LLM, verwerkt het systeem niet alleen jou vraag, maar stelt het zichzelf meer vragen (Query fan out).
• LLM’s hebben beperkte kennis m.b.t. trainingsdata die ze gebruiken om het model te verbeteren. Het gaat bijvoorbeeld niet verder dan 1 oktober 2024
• Als je dus de vraag stelt over iets recents, bijvoorbeeld: is Luke Littler wereldkampioen in 2025. Dan zoekt het actuele informatie op het internet op.
• Het proces waarbij het model actuele informatie ophaalt, wordt RAG genoemd (retrieval augmented Generation) of grounding.

En precies in die laatste stap, laat een LLM kruimelsporen achter die jij met je logfiles kunt analyseren. Pieter Serraris (presentatie) en Jérôme Salomon (presentatie), deelden tijdens BrightonSEO in oktober een hoop waardevolle inzichten die je hier als SEO-specialist uit kunt halen.

Hou rekening met het gedrag van LLM’s in je logfiles

Voordat jij in je logfiles duikt om LLM’s beter te begrijpen, hou rekening met de volgende punten:

• AI-bots bezoeken meer dan 1 webpagina per prompt
• Niet bij elke prompt, wordt het RAG systeem aangesproken. Volgens het actueelste onderzoek van Semrush: 46% (zie afbeelding hieronder)
• AI-bots crawlen het web niet alleen voor het RAG-systeem. Als voorbeeld: de useragent GPTBot wordt gebruikt voor trainingsdoeleinden, de agent: ChatGPT-User voor het RAG-systeem.
• GPT lijkt steeds meer de focus te leggen op intelligentie i.p.v. het zelf in bezit hebben van kennis. En kiest dus steeds vaker: search boven eigen kennis.
• Een crawl voor het RAG systeem betekent niet per se in het antwoord komen van een LLM. Denk aan: client-side-JS wat het niet kan verwerken, een paywall of een verkeerde http statuscode.
• ChatGPT gebruikt een cachingsysteem, wat betekent dat het niet elke keer de URL ophaalt (crawlen).
• ChatGPT volgt redirects. Wat betekent dat twee URL’s, soms één geciteerd antwoord kan betekenen (filter dit er dus uit in je resultaten).

Inzichten die je uit logfiles over LLM”s kunt halen

1. Hoeveel bezoek je krijgt van AI bots & unieke pagina’s die gecrawld zijn

2. De progressie over tijd

3. Hoe vaak een pagina X geraadpleegd wordt & jij dus een onderdeel van het antwoord bent:

4. Hoeveel pagina’s een LLM van jouw website gebruikt/kent.

5. De CTR berekenen als je GA4 data combineert met je logfiles

6. Citations misgelopen i.v.m. verkeerde HTTP statuscode

7. Pagina’s die niet door AI bots worden gecrawld, maar wel kliks uit Google krijgen.

8. Welke taalvariant van je website het vaakst door AI-bots wordt gebruikt

En vast nog veel meer. Deel gerust jouw inzichten per email, dan voeg ik het graag toe aan aan dit artikel.

FAQ