Logbestanden zijn de enige bron waarin je exact ziet waar zoekmachines hun tijd verspillen. Bij grote sites gaat tot 30% van de crawl-activiteit naar pagina’s zonder rankingpotentieel. Vaak vind je binnen een uur turen al de grootste lekken: verspilde crawls op parameter-URL’s, redirectketens die niemand meer nodig heeft, of pagina’s die Google honderden keren bezoekt terwijl ze nooit indexeren.
Kort samengevat:
- Bij grote websites verspil tot 30% van het crawlbudget aan pagina’s zonder indexeringspotentie, zoals parameter-URL’s en redirectketens.
- Logbestanden bieden onversneden data over crawlactiviteit, inclusief statuscodes en responstijden, waardoor problemen vaak sneller zichtbaar worden dan via Search Console.
- Voor sites met meer dan 10.000 URL’s, complexe filters of JavaScript-frameworks is loganalyse essentieel om inefficiënties in crawlpatronen te identificeren en te verbeteren.
- Verzamel minimaal 30 dagen logs, filter op bots met verificatie, en koppelen aan crawldata en Search Console om grote lekken en blokkades op te sporen.
- Gebruik commandline tools voor snelle checks of schaal naar BigQuery en ELK-stack voor langdurige monitoring van uitgebreide websites.
Inhoudsopgave
- Wat is logfile-analyse en waarom is het essentieel voor SEO?
- Praktische checklist van benodigde logvelden en metrieken
- Welke tools gebruik je: CLI, Screaming Frog of BigQuery?
- Zo verzamel, filter en koppel je logs aan crawldata
- Welke patronen in logs vreten je crawlbudget op?
- Hoe prioriteer je fixes en meet je het resultaat?
- Ramons aanpak: praktische voorbeelden uit de praktijk
- Wanneer is logfile-analyse níet je eerstvolgende stap?
- Hoe wij kunnen helpen bij logfile-analyse
- Bronnen
- Veelgestelde vragen
Wat is logfile-analyse en waarom is het essentieel voor SEO?
Logfile-analyse is het uitpluizen van de serverlogboeken van je website: elk verzoek dat een bot of bezoeker ooit deed, staat erin. Geen sample, geen interpretatie. Gewoon de kraan, wagenwijd open, met alles wat erdoorheen stroomde.
Dat is het grote verschil met Google Search Console. GSC toont je een steekproef, gefilterd en vertraagd. Serverlogs bevatten vaak jaren aan data, inclusief statuscodes en timestamps die operationele problemen soms weken eerder blootleggen dan GSC ooit zou rapporteren. Je dweilt niet met de kraan open, je zet de kraan gewoon dicht voordat het water de kamer bereikt.
Voor wie is dit onmisbaar?
- Sites met meer dan 10.000 URL’s, waar crawlbudget een echte beperking wordt.
- E-commerce met facet-navigatie en duizenden filter-URL’s.
- Elke site die net gemigreerd is of een JavaScript-framework gebruikt.
- Publishers met dagelijkse nieuwe content die snel geïndexeerd moet worden.
Een sprekend voorbeeld: bij een migratie zag een team in de logs binnen 48 uur dat Googlebot massaal 404’s raapte op oude URL-patronen, terwijl GSC dat probleem pas na twee weken begon te tonen. Wie op GSC had gewacht, had twee weken lang linkwaarde laten weglekken.
Praktische checklist van benodigde logvelden en metrieken
Je hebt geen twintig kolommen nodig om te beginnen. Je hebt de juiste zeven nodig.
- Timestamp: wanneer vond het verzoek plaats, cruciaal voor patronen per dagdeel of na een release.
- Volledige URL: inclusief parameters, anders mis je precies de pagina’s die budget opslokken.
- Statuscode: 200, 301, 404, 500, allemaal signalen van een andere aard.
- User-agent: identificeert welke bot langskwam, al is dit veld op zichzelf onvoldoende.
- IP-adres: nodig om de user-agent te verifiëren, want die is te vervalsen.
- Responstijd (TTFB): hoe traag je server antwoordt, direct van invloed op hoe diep een bot durft te crawlen.
- Response size: kleine groottes op contentpagina’s wijzen vaak op een lege JavaScript-schil.
Extra velden die het verschil maken bij grotere sites: cache-status, CDN edge-locatie en upstream-timing. Die laten zien of een trage pagina aan je origin-server ligt of aan een CDN-laag ertussen.
Pro-tip: Responstijd is geen decoratief cijfer: het verschil tussen 300 milliseconden en 3 seconden bepaalt hoe diep een crawler durft te gaan. Trage servers krijgen letterlijk minder crawlbudget toegewezen.
Welke tools gebruik je: CLI, Screaming Frog of BigQuery?
De keuze tussen tools hangt af van schaal, niet van voorkeur. Een kleine oorlog vraagt om een ander wapen dan een langdurig beleg.
Voor een snelle check op een enkele dag logs volstaan grep en awk op de commandline, of GoAccess voor een direct leesbaar dashboard met bot-hits, statuscodes en response-tijden op een tijdlijn. Dit is je eerste verkenning, binnen een paar minuten operationeel.
Wil je logs koppelen aan een crawl om te zien welke URL’s Googlebot bezoekt maar jij zelf niet meer linkt? Dan is de Screaming Frog Log File Analyser de praktische tussenstap. De gratis versie verwerkt een beperkt aantal events, de betaalde licentie schaalt door naar grotere imports.
Voor structurele monitoring, met maanden aan historie en herhaalbare dashboards, verschuif je naar BigQuery of een ELK-stack. Dat is geen luxe voor kleine sites, maar bittere noodzaak zodra je site over de miljoen URL’s groeit.
- CLI + GoAccess: snelle diagnose, geen setup, ideaal voor een eerste indruk.
- Screaming Frog Log File Analyser: koppeling met crawldata, zichtbare orphan pages en niet-gecrawlde URL’s.
- BigQuery/ELK: schaalbare pijplijn met dashboards voor teams die maandelijks vergelijken.
Zo verzamel, filter en koppel je logs aan crawldata
De uitvoering volgt een vaste volgorde. Sla geen stap over, ook niet als je haast hebt.
- Verzamel minimaal 30 dagen aan logs, bij voorkeur 90. Kortere periodes tonen ruis, geen patroon.
- Filter op bot-traffic met user-agent strings, maar vertrouw die nooit blind.
- Verifieer elke bot met reverse DNS en een forward-confirmatie: los rDNS-adres opnieuw op naar een IP en check of dat matcht. User-agent alleen is onbetrouwbaar, spoofing is triviaal.
- Koppel de gefilterde logs aan een verse Screaming Frog-crawl om te zien welke URL’s gecrawld worden maar niet meer intern gelinkt zijn.
- Cross-referentie met Search Console: als Googlebot een URL veertig keer bezoekt en die staat niet geïndexeerd, dan is er ergens een blokkade of kwaliteitsprobleem.
Pro-tip: Gzip je rotated logs en verwerk ze met zcat, filter met grep op bekende bot-strings, en zet het resultaat als NDJSON in BigQuery. Dan bouw je pivot-tabellen per bot, per URI en per statuscode zonder ooit een spreadsheet te openen.
Welke patronen in logs vreten je crawlbudget op?
Elk patroon hieronder is een lek. Sommige druppelen, andere gieren.
- Parameter- en filter-URL’s: een facetnavigatie met kleurfilters kan duizenden vrijwel identieke URL’s genereren die de crawler evenveel aandacht geeft als je belangrijkste productpagina’s.
- Redirectketens en loops: elke extra sprong kost een apart verzoek. Een keten van vier redirects is vier keer crawlbudget voor één eindbestemming.
- Soft 404’s met verdacht kleine response sizes: een pagina die 200 teruggeeft maar nauwelijks bytes bevat, is vaak een lege JavaScript-schil. AI-crawlers zoals GPTBot en ClaudeBot voeren geen JavaScript uit en zien dan letterlijk niets.
- Orphan pages: URL’s die wél gecrawld worden maar in geen enkele sitemap of interne link meer voorkomen. Die oorlog winnen we niet met een paar interne links, dat vraagt structurele opruiming.
- Mismatch tussen sitemap en werkelijke crawlactiviteit: staan er URL’s in je sitemap die de bot straal negeert, of omgekeerd, URL’s die veel bezoek krijgen maar buiten de sitemap vallen?
Grote sites verspillen tot 30% van hun crawlbudget aan precies dit soort pagina’s. Dat is geen afrondingsverlies, dat is een derde van je beschikbare crawlcapaciteit die naar niets gaat.
Hoe prioriteer je fixes en meet je het resultaat?
Niet elk lek repareer je als eerste. Reken het uit voordat je begint.
Prioriteer op een simpele formule: aantal hits × indexatiestatus × business-waarde van de URL. Een pagina die duizend keer gecrawld wordt maar niet geïndexeerd staat en geen omzet oplevert, staat bovenaan. Een pagina die twintig keer gecrawld wordt en al topconversies draait, laat je met rust.
- Noindex of 410 voor pagina’s zonder waarde die toch blijven opduiken.
- Redirect-collapse: verkort ketens van vier stappen naar één directe sprong.
- Interne link-herstel voor orphan pages die het waard zijn om te behouden.
- Infrastructuurtuning: cache-instellingen en serverrespons versnellen als TTFB structureel boven de seconde uitkomt.
| Actie | Vóór | Na |
|---|---|---|
| Redirect-collapse | 4 sprongen per URL | 1 sprong per URL |
| Noindex verspilde parameters | duizenden crawls op filters | crawls verschoven naar kernpagina’s |
| TTFB-optimalisatie | > 1.000 ms | < 300 ms |
| Orphan pages herlinkt | 0 interne links | opgenomen in navigatie |
Meet dit altijd met een log-vergelijking vóór en na de fix, aangevuld met indexatiecijfers uit Search Console. Zichtbaarheid in de zoekresultaten is de uiteindelijke lakmoesproef, maar die volgt altijd een paar weken later dan het crawlgedrag.
Ramons aanpak: praktische voorbeelden uit de praktijk
Na 19 jaar in technische SEO is één les blijven hangen: logs liegen niet, dashboards soms wel. Bij een migratiecontrole vergelijk ik altijd de historische logs van vóór de livegang met de eerste twee weken erna, exact volgens de stappen uit mijn migratie-aanpak. Zo zie je binnen dagen of Googlebot je nieuwe structuur accepteert of blijft hangen op oude URL’s.
Een quick scan van één uur is vaak genoeg om de grootste interne link-lekken bloot te leggen: sorteer op top-hits, en de grootste boosdoeners springen er meteen uit. Combineer dat met de checks uit een volledige technische audit en je hebt binnen een dag een prioriteitenlijst die klopt.
— Ramon
Wanneer is logfile-analyse níet je eerstvolgende stap?
Bij een site onder de 1.000 URL’s is crawlbudget zelden de beperkende factor. Dan zit je probleem in content of links, niet in crawlefficiëntie.
Heb je minder dan twee weken logretentie? Regel eerst logshipping naar opslag, anders analyseer je ruis. En als je servers vaker plat gaan dan dat Googlebot langskomt, is infrastructuur je eerste zorg. Wortel eruit, altijd, maar wel de juiste wortel.
Hoe wij kunnen helpen bij logfile-analyse
Sommige teams draaien de commandline-checks zelf en komen een eind. Maar zodra je site groeit richting honderdduizenden URL’s, of je zit midden in een migratie zonder interne capaciteit om logs uit te pluizen, kost dweilen met de kraan open je meer tijd dan het je oplevert.
Bij ons combineert men technische scans met logfile-analyse, filtert men op verifieerde bot-traffic en levert men geen rapport vol grafieken maar een lijst met uitvoerbare tickets voor developers. Dat is de kern van hoe we werken: strategisch advies dat meteen wordt doorgevoerd, niet blijft liggen in een PDF. Twijfel je of jouw site aan de beurt is voor een technische scan of een volledige technische audit? Vraag een vrijblijvend gesprek aan via Nebber en we kijken binnen een week met je mee in de logs.
Veelgestelde vragen
Wat is logfile-analyse in SEO precies?
Logfile-analyse is het onderzoeken van serverlogboeken om te zien welke pagina’s zoekmachinebots daadwerkelijk bezoeken, hoe vaak en met welk resultaat. Het toont ongefilterde data, in tegenstelling tot de steekproeven die Google Search Console rapporteert.
Hoeveel bezoekers en bots staan er in mijn logbestanden?
Elk verzoek aan je server staat in de logs, van menselijke bezoekers tot elke bot die langskomt. Filter altijd op user-agent én rDNS-verificatie, want alleen zo onderscheid je een echte Googlebot van een vervalste crawler.
Welke tool moet ik als eerste gebruiken voor logfile-analyse?
Begin met GoAccess voor een snel overzicht, gebruik Screaming Frog Log File Analyser om logs aan een crawl te koppelen, en schaal naar BigQuery zodra je structureel maandelijks wilt monitoren.
Hoe lang moet ik logbestanden bewaren voor SEO-analyse?
Minimaal 30 dagen, bij voorkeur 90 dagen. Kortere periodes laten geen betrouwbaar patroon zien in crawlgedrag na wijzigingen of migraties.
Kan Nebber logfile-analyse voor mijn website uitvoeren?
Ja, Nebber combineert logfile-analyse met een technische scan of audit en levert concrete, uitvoerbare tickets in plaats van alleen een rapport. Prijzen voor een technische scan of audit vind je op de site.