Logbestandanalyse voor SEO: lees je serverlogs en verhelp crawlverspilling

Korte quiz

Is SEO iets voor jou, en hoe begin je?

Vraag 1 van 425%

Zoeken mensen in Google naar wat je verkoopt?

Ja, ik denk het welNee, het is nieuw of heel nicheWeet ik niet

Wat een serverlog registreert, en waarom het je andere data overtreft

Telkens wanneer iets een bestand van je server opvraagt, schrijft de server één regel in zijn toegangslog. De meeste servers gebruiken een formaat dat lijkt op het Apache-"combined"-formaat. Een Googlebot-verzoek ziet er zo uit:

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Lees het van links naar rechts: het IP-adres, de tijdstempel, de HTTP-methode en URL, de statuscode (hier 200), het aantal verzonden bytes, de referrer en de user agent. Elk verzoek staat erin, ook de verzoeken die nooit als paginaweergave in je analysetool verschijnen: afbeeldingen, CSS-bestanden, redirects en 404-fouten.

Je andere gegevensbronnen zien elk maar een deel daarvan. Het Crawlstatistieken-rapport in Search Console is geaggregeerd en dekt alleen de crawlers van Google. Analysetools registreren alleen bezoekers wier browser je JavaScript uitvoert. Een site-crawler zoals Screaming Frog toont wat hij kan bereiken door je links te volgen, wat niet hetzelfde is als wat Google heeft gekozen om op te vragen. Alleen het serverlog legt vast wat er echt is gebeurd.

Waarom logbestandanalyse belangrijk is: crawlbudget in gewone taal

Crawlbudget is de verzameling URL's die Google op je site kan en wil crawlen. Google beschrijft het met twee factoren. De eerste is de crawlcapaciteitslimiet: hoeveel verbindingen de crawlers van Google tegelijk open kunnen houden met je server zonder die te overbelasten. Die limiet stijgt wanneer je site gezond blijft en daalt wanneer reacties vertragen of 5xx- of 429-fouten geven. De tweede is de crawlvraag, die afhangt van de omvang van je site, hoe vaak de inhoud verandert, de kwaliteit en de populariteit van je pagina's.

Google presenteert het onderwerp als een gevorderde gids voor grote sites. De indicatieve drempels zijn sites met 1 miljoen of meer unieke pagina's waarvan de inhoud ongeveer één keer per week verandert, en sites met 10000 of meer unieke pagina's waarvan de inhoud elke dag verandert. Sites waarbij veel URL's de status "Gevonden, momenteel niet geïndexeerd" hebben, vallen ook binnen het bereik. Kleinere sites kunnen meestal vertrouwen op een actuele sitemap en regelmatige controles van het rapport Pagina-indexering. Dat maakt logs voor hen niet nutteloos. Wanneer er iets misgaat met het crawlen, is het log de snelste manier om precies te zien waar.

Als je site in dat bereik valt, is de vraag niet meer of je logs moet lezen, maar hoe vaak. Een eenmalige audit laat de verspilling van vandaag zien. Een maandelijkse export laat zien of je correcties hebben veranderd waar Googlebot zijn tijd aan besteedt. Voor de basisbegrippen behandelt het glossarium-item over crawlbudget de grondbeginselen, en de gids over Gevonden, momenteel niet geïndexeerd legt de status uit die dit soort onderzoek meestal in gang zet.

De methode, stap voor stap

De onderstaande werkwijze werkt met elke server en elk hulpmiddel. De latere secties leggen elke stap uitgebreid uit en geven de commando's die je vandaag op een ruw logbestand kunt uitvoeren.

Haal de logs uit de juiste laag

Vraag je ontwikkelaar of hostingprovider om de ruwe toegangslogs van de webserver (Apache, Nginx of IIS). Controleer drie dingen voordat je begint: het logformaat, de tijdzone en de bewaartermijn. Afhankelijk van je opzet kunnen oude logs na een paar dagen of weken worden weggeroteerd, dus vraag de export nu aan en niet later.

De laag is belangrijker dan mensen verwachten. Als een CDN een verzoek uit zijn cache beantwoordt, ziet je oorspronkelijke server het nooit. Googlebot kan een URL crawlen die nooit in het oorspronkelijke log verschijnt, dus een export van alleen de oorspronkelijke server onderschat de crawlactiviteit op gecachte inhoud. Exporteer ook de CDN-logs en vergelijk de twee bronnen bij een paar URL's voordat je een van beide totalen vertrouwt.

Filter en tel Googlebot met een paar commando's

In een log in combined-formaat is de statuscode het 9e veld en het URL-pad het 7e. Die twee kolommen beantwoorden de meeste eerste vragen. Dit commando telt de Googlebot-verzoeken per statuscode:

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

Dit geeft de 20 paden die Googlebot het vaakst opvraagt, zonder querystring, zodat filtervarianten samen worden gegroepeerd:

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

Het eerste commando leest de tekst van de user agent, die iedereen kan vervalsen. Behandel de uitvoer als een lijst met kandidaten totdat je de volgende sectie hebt doorlopen. Als je log een eigen formaat gebruikt, veranderen de veldnummers bovendien, dus controleer één regel met je eigen ogen voordat je de kolommen vertrouwt.

Verifieer Googlebot zoals Google dat beschrijft

De eigen methode van Google om te bevestigen dat een bezoeker Googlebot is, werkt met DNS. Voer een reverse DNS-lookup uit op het IP-adres uit je log, controleer dat de hostnaam eindigt op googlebot.com, google.com of googleusercontent.com, en voer daarna een forward-lookup uit op die hostnaam die het oorspronkelijke IP moet teruggeven. De documentatie van Google gebruikt dit voorbeeld, waarbij 66.249.66.1 resolvet naar crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

De forward-controle is het tweede commando, en die moet hetzelfde IP teruggeven:

host crawl-66-249-66-1.googlebot.com

Als je miljoenen regels verwerkt, worden DNS-lookups traag. Google publiceert ook JSON-bestanden met de IP-bereiken van zijn crawlers, waaronder common-crawlers.json voor Googlebot. Matchen tegen die bereiken is sneller, en de officiële verificatiegids beschrijft beide methoden in de gids van Google over het verifiëren van Googlebot.

Groepeer, meet en lees de resultaten

Ruwe tellingen per URL zijn lastig om op te handelen. Groepeer de URL's eerst per template, omdat een oplossing meestal op een template van toepassing is en niet op één pagina. Meet daarna vier dingen per groep. Hoeveel Googlebot-hits de groep krijgt in verhouding tot het belang voor je bedrijf. De verdeling van de statuscodes. Hoe snel nieuwe pagina's na publicatie hun eerste hit krijgen. En of de hits zich concentreren op de pagina's die je wilt laten ranken.

Lees de resultaten als een patroon, niet als één getal. Als de meeste Googlebot-hits op filter-URL's landen en slechts enkele op productpagina's, lekt je crawlbudget, en het probleem zit waarschijnlijk in de interne links of de parameterafhandeling, niet in de productpagina's. De volgende sectie somt de signalen op waar je op moet letten.

De zeven signalen verborgen in de logs

Zodra de Googlebot-regels zijn geverifieerd en gegroepeerd, verklaren zeven signalen de meeste crawlproblemen. De tabel geeft het patroon aan waarop je moet letten en de gebruikelijke oplossing. Elke oplossing is een wijziging aan de site, dus bevestig die in de volgende export.

Signaal	Wat de logs laten zien	Wat te doen
Crawlverspilling	Googlebot-hits op filters, sorteervolgorden, interne zoekfunctie en sessie-URL's	Consolideren met canonicals, interne links naar die URL's verwijderen en onnodige varianten die niet kunnen worden geconsolideerd blokkeren in robots.txt
Redirects	Hits op 301- of 302-antwoorden en ketens van twee of meer hops	Link direct naar de uiteindelijke URL. De gids over 301 vs 302 helpt je het juiste redirecttype kiezen
Fouten	Herhaalde 404- of 410-hits en pieken van 5xx-antwoorden	Pagina's die er nog toe doen herstellen of redirecten, en serverfouten oplossen, omdat 5xx-antwoorden verminderen hoeveel Google crawlt
Ontbrekende crawls	Belangrijke URL's zonder enkele Googlebot-hit in het tijdvak	Interne links, sitemapvermeldingen en robots.txt-regels controleren die crawlers zouden kunnen tegenhouden
Duplicaten	Dezelfde inhoud onder meerdere URL's, met afsluitende slashes, hoofdletters of parameters	Kies één canonieke URL en link er overal naar
Tijd tot eerste crawl	Tijd tussen publicatie en de eerste Googlebot-hit op een nieuwe pagina	Nieuwe pagina's linken vanaf pagina's die al vaak gecrawld worden, en je sitemap schoon houden
Responstijd	Trage reacties op de templates die Googlebot het vaakst raakt	Eerst die templates versnellen, want Google zegt dat trage reacties ertoe leiden dat het minder crawlt

De rij "ontbrekende crawls" is de rij die mensen overslaan, en het is vaak de duurste. Een pagina die je nooit in het log ziet, kan niets opleveren in rankings, zelfs als de inhoud uitstekend is. Als een URL in je sitemap staat maar nooit in de logs verschijnt, is de pagina waarschijnlijk alleen bereikbaar via een pad dat crawlers niet volgen. De gids over Gecrawld, momenteel niet geïndexeerd behandelt de andere kant van die situatie, wanneer Googlebot wel langskomt maar nog steeds niet indexeert.

Drie manieren om de analyse uit te voeren, vergeleken

Je kunt logbestandanalyse uitvoeren met scripts, met een desktopapplicatie of met een platform. Elk past bij een ander volume en een ander team. De keuze hangt minder af van de omvang van je site dan van hoe vaak je het antwoord nodig hebt en wie het gaat lezen.

Commandoregel: grep, awk en Python

Principe: je ontleedt de ruwe bestanden met scripts en schrijft de resultaten naar een bestand of spreadsheet. Wanneer gebruiken: eenmalige controles, kleine sites of een ontwikkelaar die volledige controle wil. Voordelen: het is gratis, je ziet elke regel en je kunt het automatiseren met een geplande taak. Beperkingen: het kost tijd om te schrijven en te onderhouden, het draait zo snel als je machine, het heeft geen grafieken, en je moet de bots zelf verifiëren.

Voorbeeld: de commando's uit de methodesectie, eenmaal per maand op dezelfde export gedraaid, geven je de verdeling van de statuscodes en de topmappen van Googlebot. Een kort Python-script kan hetzelfde en voegt de DNS-controle toe, die trager maar nauwkeuriger is.

Desktoptool: Screaming Frog Log File Analyser

Principe: je importeert de ruwe logs in een desktopproject, de tool groepeert de bots, controleert hun identiteit en tekent de grafieken. Wanneer gebruiken: een consultant of interne analist die werkt aan een site met tienduizenden URL's. Voordelen: het leest Apache-, IIS- en Nginx-logs in het W3C Extended-formaat, verifieert zoekmachinebots en markeert grote of trage pagina's. Beperkingen: de gratis versie is beperkt, en de hoeveelheid data die je kunt laden hangt af van je harde schijf.

Lees de productpagina van Screaming Frog Log File Analyser voordat je koopt. Voor een volledige uitleg van de crawler die bij deze analyser past, zie onze gids over Screaming Frog SEO Spider. De logbestandanalyser doet iets wat de crawler niet kan: hij laat zien wat bots in de praktijk hebben opgevraagd, en niet wat je links suggereren.

Platform: continue logmonitoring

Principe: het platform ontvangt je logs volgens een schema, vaak van het CDN of de server, en koppelt ze aan een crawl van je site en aan indexeringsdata. Wanneer gebruiken: grote e-commerce-sites of enterpriseteams die de crawl elke week over meerdere markten monitoren. Voordelen: het schaalt naar zeer grote logs, bewaart de geschiedenis en laat meerdere teams dashboards delen. Beperkingen: het kost meer, het vergt tijd om in te richten, en de afhankelijkheid van de leverancier is reëel, dus controleer hoe je je data kunt exporteren voordat je je vastlegt. Leveranciers in deze categorie zijn onder meer Oncrawl en Botify, en het is de moeite waard aan elk te vragen hoe ze bots verifiëren.

Criterium	Commandoregel	Desktoptool	Platform
Kosten	Gratis	Gratis tot 1000 logevents, £99 per jaar voor de volledige licentie	Abonnement, prijs afhankelijk van het volume
Opzet	Je schrijft en onderhoudt de scripts	Installeren, importeren, starten	Connectors en onboarding
Volume	Beperkt door je machine	Beperkt door je harde schijf en licentie	Gebouwd voor zeer grote logs
Botverificatie	Handmatig, met DNS- of IP-bereikcontrole	Ingebouwd	Vraag het de leverancier
Het best voor	Eenmalige controles en kleine sites	Consultants en middelgrote sites	Enterprise- en e-commerceteams met wekelijkse monitoring

Het Crawlstatistieken-rapport van Google: nuttig, maar niet genoeg

Voordat je ook maar één log exporteert, open je het Crawlstatistieken-rapport in Search Console. Het toont het totale aantal crawlverzoeken, de totale downloadomvang, de gemiddelde responstijd, de antwoorden gegroepeerd per type, de bestandstypen, het crawldoel en het Googlebot-type dat elk verzoek deed. Voor een trendcontrole is het de snelste weergave die je hebt, en de Google Search Console-tutorial legt uit waar je het vindt.

De beperkingen laten zien waarom logs nog steeds belangrijk zijn. Het rapport is alleen beschikbaar voor domeineigenschappen en URL-prefixeigenschappen op rootniveau. Het dekt alleen de crawlers van Google, dus GPTBot, ClaudeBot en de andere ontbreken. Het groepeert gegevens in plaats van elke URL te tonen, dus het kan je vertellen dat de crawlverzoeken zijn gedaald, maar niet welke templates ze hebben verloren. Gebruik het om te zien dat er iets is veranderd, en de logs om uit te zoeken wat.

De Google-hulppagina over Crawlstatistieken beschrijft elke groepering. Wanneer de grafiek en je logexport niet overeenkomen, vertrouw dan geen van beide totdat je het tijdvak en de verificatiestap hebt gecontroleerd. De meeste afwijkingen komen voort uit een ander tijdvak, een CDN dat vanuit de cache antwoordt, of een botteltelling die niet-geverifieerde verzoeken bevat.

Crawlverspilling oplossen zodra je die ziet

De oplossingen volgen uit de signalen. De meeste komen neer op drie bewegingen: crawlers stoppen met sturen naar pagina's die er niet toe doen, ze rechtstreeks naar de uiteindelijke URL sturen wanneer een pagina is verplaatst, en de pagina's die er wel toe doen sneller maken.

Gefacetteerde navigatie. Filters en sorteervolgorden maken veel URL's met bijna dezelfde inhoud. Consolideer ze met canonicals waar het kan, en verwijder de interne links naar varianten zonder zoekwaarde. Wanneer een variant niet kan worden geconsolideerd en buiten de crawl moet blijven, blokkeer je hem in robots.txt. De richtlijn van Google is hier duidelijk: gebruik daarvoor geen noindex, want Google moet de pagina toch opvragen voordat het de tag kan zien. Dit is het soort regel dat je moet testen:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Houd de robots.txt-wijziging in verhouding. Google zegt dat het blokkeren van URL's geen crawlbudget vrijmaakt voor je andere pagina's, tenzij de site al tegen zijn capaciteitslimiet aanloopt. Blokkeren is bedoeld voor URL's zonder waarde, niet als manier om budget naar je beste pagina's te duwen. Ons robots.txt-glossariumitem legt uit hoe het bestand wordt gelezen.

Redirectketens. Wanneer een pagina twee keer is verplaatst, doorloopt de crawler elke keer beide redirects. Werk de interne links bij zodat ze naar de uiteindelijke URL wijzen, en behoud de oude redirects voor externe links. De keuze tussen een permanente en een tijdelijke redirect telt om dezelfde reden, en de gids over 301 vs 302 behandelt dat in detail.

Verdwenen pagina's. Geef een 404 of 410 terug voor pagina's die permanent zijn verwijderd. Google zegt dat soft 404's blijven worden gecrawld en crawlbudget verspillen, dus een "pagina niet gevonden"-melding met status 200 is slechter dan een echte 404.

Responstijd en caching. Google zegt dat trage of falende reacties ertoe leiden dat het minder crawlt. Ondersteun 304-antwoorden (Not Modified), zodat ongewijzigde pagina's uit de cache kunnen worden geleverd. Kijk daarna naar de templates die de meeste Googlebot-hits krijgen en maak die reacties eerst sneller.

De fouten die het meest kosten, en hoe je ze vermijdt

De meeste logbestandanalyses die misgaan, maken een van een kleine set fouten. Elk van de onderstaande heeft een symptoom dat je in de data kunt zien en een oplossing die je dezelfde week kunt toepassen.

Vertrouwen op de user agent-string

Wat het is: elk verzoek dat zegt "Googlebot" te zijn, tellen als de crawl van Google. Hoe je het herkent: Googlebot-hits van IP-adressen die niet terugresolveren naar de hostnamen van Google, of een plotselinge piek vanaf één adres. Hoe je het oplost: voer de verificatie uit de methodesectie uit voordat je iets telt, en houd de niet-geverifieerde hits in een aparte groep, zodat je de scraperactiviteit nog steeds ziet.

Alleen de 200-antwoorden lezen

Wat het is: je richten op pagina's die 200 geven en de rest negeren. Hoe je het herkent: je rapport heeft geen sectie voor 3xx, 4xx of 5xx, of de verdeling van de statuscodes wordt nooit besproken. Hoe je het oplost: begin altijd met de verdeling van de statuscodes. Een stijging van 404-hits kan een kapotte interne link aan het licht brengen, en een stijging van 5xx-hits kan een serverprobleem aan het licht brengen dat de hele crawl vertraagt.

Een pagina blokkeren die je wilt deïndexeren

Wat het is: een robots.txt-regel toevoegen aan een pagina die ook een noindex-tag heeft. Hoe je het herkent: de pagina blijft in de index, en het log toont geen Googlebot-hits, omdat de crawler wordt geblokkeerd om de pagina op te vragen. Hoe je het oplost: verwijder de blokkering zodat Google de noindex-tag kan lezen, wacht tot de pagina uit de index verdwijnt en herstel daarna de blokkering als je die nog nodig hebt. De gids over Geblokkeerd door robots.txt legt de status van Search Console uit die in dit geval verschijnt.

Vensters van verschillende lengte vergelijken

Wat het is: een export van 3 dagen vóór een correctie vergelijken met een export van 30 dagen erna. Hoe je het herkent: de totalen bewegen sterk, maar het aandeel per template niet. Hoe je het oplost: vergelijk hetzelfde aantal dagen, bij voorkeur in dezelfde periode van het jaar, en vergelijk aandelen in plaats van ruwe totalen wanneer het volume verandert.

Hits meten in plaats van waarde

Wat het is: juichen over een stijging van Googlebot-hits zonder te controleren of die hits geïndexeerde pagina's bereiken. Hoe je het herkent: de hits concentreren zich op URL's die niet geïndexeerd zijn of nooit verkeer opleveren. Hoe je het oplost: koppel je loggroepen aan de indexeringsstatus uit de URL-inspectietool van Search Console, en tel een oplossing alleen als een succes wanneer de crawl naar de pagina's die ertoe doen verschuift.

Waar AI-bots in dezelfde logs passen

Dezelfde logs laten zien wat AI-crawlers op je site doen, en de methode is hetzelfde: groepeer ze, verifieer ze waar de leverancier een manier biedt om dat te doen, en lees de statuscodes. Onze gids over AI-crawler-logs behandelt welke bots je moet zoeken en hoe ze verschillen van Googlebot. Dit artikel gaat diep in op de Googlebot-methode, en de AI-sectie hieronder laat zien hoe je beide in één rapport samenvoegt.

Bottype	Voorbeelden	Wat je in de logs moet controleren	Waar je meer leest
Zoekcrawler	Googlebot	Hits per template, verdeling van statuscodes, tijd tot eerste crawl van nieuwe pagina's	De bovenstaande secties van dit artikel
Trainingscrawler	GPTBot, ClaudeBot, CCBot	Of ze je inhoud opvragen en of ze je robots.txt respecteren	Robots.txt voor AI-crawlers
Ophaalcrawler	ChatGPT-User, PerplexityBot	Korte pieken van bezoeken gekoppeld aan vragen van gebruikers, en de pagina's die ze bereiken	AI-crawler-logs

Het onderscheid tussen training en ophalen komt voort uit de manier waarop AI-crawlers worden gedocumenteerd. Trainingscrawlers verzamelen inhoud voor modellen, en ophaalcrawlers halen pagina's op wanneer een gebruiker een vraag stelt. Je rapport moet die twee gescheiden houden, want een beleidsbeslissing voor de ene geldt niet automatisch voor de andere.

Als je Google-verkeer en AI-verkeer naast elkaar wilt zien terwijl je deze correcties doorvoert, toont het GEO / SEO-dashboard van Sorank beide in één weergave. Gebruik het om te controleren of de wijzigingen die je uit de logs maakt het verkeer bewegen, en niet alleen de crawltellingen.