Serverlogbestanden laten zien welke URL’s zoekmachinebots daadwerkelijk opvragen, hoe vaak ze dat doen en welk antwoord je website geeft. Je leert hoe je die gegevens leest, crawlproblemen opspoort en onderscheid maakt tussen nuttige bezoeken en verspilde crawlactiviteit.

Wat serverlogs over het crawlgedrag van zoekmachines vertellen

Een serverlog registreert verzoeken die bij een webserver binnenkomen. Voor SEO zijn vooral de regels interessant waarbij een zoekmachinebot een pagina, afbeelding, script of ander bestand opvraagt. Zo’n regel bevat doorgaans een tijdstip, het aangevraagde pad, een statuscode, de user-agent en vaak het IP-adres en de hoeveelheid verstuurde data. De precieze velden verschillen per server en configuratie.

Logs beantwoorden een andere vraag dan Google Search Console. Search Console rapporteert onder meer hoe Google de site verwerkt en welke pagina’s geïndexeerd zijn; logs tonen verzoeken die de server echt heeft ontvangen. Een URL die in een log voorkomt, is dus bezocht, maar daarmee nog niet geïndexeerd. Andersom bewijst het ontbreken van een recente aanvraag niet automatisch dat een pagina uit de index is verdwenen: Google kan die al eerder hebben opgehaald.

Die nuance maakt logs bruikbaar voor concrete diagnoses. Je kunt zien of belangrijke productpagina’s regelmatig worden bezocht, of bots blijven terugkomen op oude URL’s en of een migratie leidt tot onverwachte aanvragen. Logs geven geen volledig beeld van wat een zoekmachine intern met een pagina doet. Ze laten wél zien wat er aan de serverkant gebeurt, op welk moment en met welk resultaat. Dat maakt ze een waardevolle aanvulling op crawltools en rapportages.

De juiste logbestanden verzamelen en leesbaar maken

Begin bij de plek waar verzoeken worden vastgelegd: bijvoorbeeld de accesslogs van Apache of Nginx, een hostingplatform, een CDN of een load balancer. Bij websites achter een CDN kunnen de logs van de webserver alleen verzoeken tonen die de cache niet heeft afgehandeld. Vraag daarom na welke laag de bron is en of requests van bots daar volledig worden geregistreerd. Voor een representatief beeld zijn meerdere dagen nodig; neem bij webshops ook drukke en rustige dagen mee.

Controleer vervolgens welke velden aanwezig zijn. Een tijdstip met tijdzone, het volledige requestpad, de HTTP-statuscode en de user-agent zijn meestal essentieel. Bewaar queryparameters in de ruwe data, ook als je ze later apart analyseert: ze kunnen verklaren waarom een bot duizenden varianten bezoekt. Normaliseer tijdstempels en URL’s pas in een analysebestand, zodat je de oorspronkelijke regels kunt terugzoeken wanneer een telling verdacht lijkt.

Grote logbestanden zijn lastig handmatig te openen. Filter daarom eerst op periode en bekende bot-user-agents, of laad de data in een loganalyseplatform, spreadsheet of script. Let op rotatie en compressie: oude bestanden worden vaak opgesplitst of verwijderd. Leg vast welke servers en domeinen in de export zitten, zodat een ontbrekende host niet wordt aangezien voor afwezig crawlgedrag. Deel logs bovendien niet zomaar; IP-adressen, URL’s en parameters kunnen gevoelige gegevens bevatten.

Googlebot herkennen zonder crawlers verkeerd te tellen

Een user-agent zoals “Googlebot” is een aanwijzing, geen sluitend bewijs. Die tekst is door iedere bezoeker te vervalsen en kan ook voorkomen in verzoeken van SEO-tools of andere bots. Voor een betrouwbare telling moet je echte Google-crawlers verifiëren. Dat kan via de door Google beschreven controle met een reverse DNS-lookup, gevolgd door een forward lookup die terugwijst naar hetzelfde IP-adres. Gebruik daarvoor actuele, officiële instructies; vertrouw niet alleen op een lijst IP-adressen die ooit ergens is gekopieerd.

Maak onderscheid tussen typen crawlers. Googlebot Smartphone en Googlebot Desktop kunnen apart in de user-agent staan, terwijl Google ook andere bots gebruikt voor bijvoorbeeld afbeeldingen, video of advertenties. Andere zoekmachines hebben eveneens eigen crawlers. Houd die groepen gescheiden in je rapportage: anders kan een toename van een minder relevante bot ten onrechte lijken op meer Google-crawlactiviteit.

Bij twijfel is het verstandig om aanvragen in categorieën te plaatsen, zoals geverifieerde Googlebot, vermoedelijke bot en onbekende user-agent. Tel die groepen niet bij elkaar op alsof de zekerheid gelijk is. Controleer ook of interne monitoring, uptimechecks of externe crawlers herkenbare user-agents gebruiken; die kunnen anders in dezelfde grafiek belanden. Een zuivere botselectie kost wat voorbereiding, maar voorkomt dat je conclusies trekt op basis van vervalste of verkeerd geclassificeerde bezoeken.

Crawlfrequentie per URL en paginatype beoordelen

Tel niet alleen het totaal aantal requests, maar groepeer ze ook per URL en paginatype. Een overzicht van bezoeken per dag kan laten zien of categoriepagina’s, productpagina’s, artikelen en belangrijke landingspagina’s ongeveer de aandacht krijgen die je verwacht. Kijk naar patronen over tijd: een eenmalige piek kan door een publicatie of technische wijziging komen, terwijl een blijvend verschil eerder op een structureel probleem wijst.

De ruwe URL-lijst bevat vaak veel bijna-identieke adressen. Denk aan een URL met en zonder afsluitende slash, hoofdlettervarianten of dezelfde pagina met trackingparameters. Normaliseer zulke varianten voor een overzicht, maar bewaar daarnaast de oorspronkelijke URL. Als je alleen normaliseert, kun je juist het probleem missen dat de bot onnodig meerdere versies bezoekt. Maak ook onderscheid tussen HTML-pagina’s en bestanden zoals CSS, JavaScript en afbeeldingen; die verzoeken zeggen iets anders over crawlgedrag.

Een lage crawlfrequentie is niet automatisch slecht. Een stabiele brochurepagina hoeft niet dagelijks opnieuw te worden opgehaald, terwijl een voorraadgevoelige productpagina vaker kan veranderen. Vergelijk de loggegevens daarom met de verwachte actualiteit, interne links en het belang van een pagina. Let vooral op belangrijke URL’s die lang niet zijn aangevraagd, pagina’s die plots veel minder bezoeken krijgen en oude of onbelangrijke adressen die juist herhaaldelijk worden opgehaald. Dat zijn aanknopingspunten voor nader onderzoek, geen zelfstandig bewijs van een rankingprobleem.

Statuscodes gebruiken om crawlproblemen op te sporen

De statuscode in een logregel laat zien hoe de server op een verzoek reageerde. Veel 200-responses betekenen dat de server de aanvraag succesvol heeft afgehandeld, maar zeggen op zichzelf niets over de kwaliteit of indexeerbaarheid van de inhoud. Een 301 of 308 kan passend zijn bij een permanente verhuizing; controleer wel of de bot direct bij de eindbestemming uitkomt. Meerdere redirects achter elkaar kosten extra requests en maken migratieproblemen lastiger te ontdekken.

Een 404 is normaal voor een URL die niet meer bestaat, maar herhaalde 404-aanvragen op belangrijke pagina’s vragen om onderzoek. Controleer of interne links, een oude sitemap of externe links de bot naar het adres sturen. Een 410 kan duidelijk maken dat content definitief is verwijderd, maar vervang niet blind iedere 404 door een redirect: stuur alleen door naar inhoudelijk relevante alternatieven. Een 5xx-status wijst op een serverfout. Kijk bij pieken naar tijdstip, betrokken URL’s en hosting- of applicatielogs; incidentele fouten kunnen anders een structurele storing maskeren.

Ook een 403 of 429 verdient aandacht. De eerste kan betekenen dat beveiliging of toegangsregels een crawler blokkeren; de tweede kan ontstaan door rate limiting. Controleer of de beperking bewust is ingesteld en of geverifieerde zoekmachinebots erdoor worden geraakt. Zet statuscodes naast de URL, user-agent en tijd. Een losse foutregel vertelt weinig, maar een terugkerend patroon op een hele template kan wijzen op een configuratiefout die veel pagina’s tegelijk treft.

Onnodige crawlerbezoeken door parameters en filters herkennen

Webshops en sites met veel filters kunnen een groot aantal URL-varianten aanbieden. Sortering, kleur, maat, paginering, zoektermen en trackingparameters kunnen combinaties opleveren die inhoudelijk weinig van elkaar verschillen. In logs zie je dat bijvoorbeeld terug als een crawler veel verschillende querystrings opvraagt, terwijl de basispagina relatief weinig bezoek krijgt. Groepeer requests op pad en parameternaam om te ontdekken welke functies de meeste varianten veroorzaken.

Beoordeel daarna per parameter of die een eigen, waardevolle pagina oplevert. Een indexeerbare filtercombinatie kan nuttig zijn wanneer er zoekvraag en unieke inhoud is; duizenden dunne combinaties kunnen juist servercapaciteit en crawl aandacht opslokken. Mogelijke maatregelen zijn het beperken van filtercombinaties, interne links naar alleen gewenste varianten en consistente canonical-tags. Robots.txt kan crawlverzoeken beperken, maar voorkomt niet dat een geblokkeerde URL op basis van links wordt geïndexeerd. Gebruik een blokkade dus niet als vervanging voor een goed URL- en indexeringsbeleid.

Let ook op oneindige kalenderpagina’s, interne zoekresultaten en sessie-ID’s in URL’s. Een crawler kan daar eindeloos nieuwe adressen vinden. Pas niet meteen een brede blokkade toe: die kan nuttige pagina’s onbereikbaar maken of signalen verhullen. Test veranderingen op een beperkte groep URL’s en volg daarna in de logs of het aantal varianten afneemt en belangrijke pagina’s bereikbaar blijven. Een daling van het totale aantal requests is geen doel op zich; minder verspilling is alleen winst als relevante content nog steeds gevonden en opgehaald wordt.

Crawlbudget interpreteren zonder verkeerde conclusies

De term crawlbudget wordt vaak gebruikt alsof iedere website een vast aantal bezoeken krijgt. In werkelijkheid hangt de crawlactiviteit onder meer af van de capaciteit die een server aankan en hoe waardevol een zoekmachine het vindt om URL’s opnieuw te bezoeken. Vooral grote websites met veel veranderende pagina’s, technische varianten of serverproblemen hebben reden om dit nauwkeurig te onderzoeken. Bij een kleine site is een laag aantal requests op zichzelf zelden een probleem.

Gebruik logs om te vragen waar crawleraandacht naartoe gaat. Als bots veel oude redirects, filtercombinaties of foutpagina’s bezoeken, terwijl belangrijke nieuwe URL’s nauwelijks worden opgehaald, kan de verdeling aandacht verdienen. Controleer tegelijk of de belangrijke pagina’s intern goed gelinkt zijn, in een actuele sitemap staan en een bruikbare statuscode geven. Een sitemap is geen garantie op bezoek, maar kan samen met sterke interne links helpen gewenste URL’s vindbaar te maken.

Voorkom dat je een laag crawlaantal direct probeert op te lossen door overal links toe te voegen of robots.txt aan te passen. Een kunstmatige toename van aanvragen is niet automatisch nuttig en een blokkade kan zoekmachines juist verhinderen pagina’s of canonicals te zien. Vergelijk crawlactiviteit met wijzigingen, serverbelasting en indexeringssignalen. Pas vervolgens één belangrijke oorzaak tegelijk aan. Zo kun je achteraf beoordelen of minder onnodige requests samengaan met betere bereikbaarheid van de pagina’s die ertoe doen, zonder prestaties te verwarren met ruwe aantallen.

Loganalyses inrichten en privacy bewaken

Een bruikbare analyse is herhaalbaar. Kies een vaste meetperiode en definieer vooraf hoe je bots, URL’s, statuscodes en paginatypen groepeert. Rapporteer bijvoorbeeld per week het aantal geverifieerde botrequests, het aandeel 3xx-, 4xx- en 5xx-responses en de meest bezochte URL-patronen. Voeg een uitsplitsing naar host of server toe wanneer een website over meerdere omgevingen is verdeeld. Een wijziging in logging kan anders lijken op een plotselinge verandering in crawlgedrag.

Leg bij opvallende verschillen ook releases en incidenten vast. Een stijging na een migratie, nieuw filter of aanpassing van redirects kan dan worden gekoppeld aan een concrete gebeurtenis. Gebruik waar mogelijk een representatieve steekproef naast totalen; gemiddelden kunnen verbergen dat een klein aantal URL’s vrijwel alle fouten veroorzaakt. Houd dashboards eenvoudig genoeg om afwijkingen te zien, maar bewaar ruwe gegevens tijdelijk zodat je individuele gevallen kunt controleren.

Serverlogs kunnen IP-adressen, zoektermen in URL’s, accountnamen of andere persoonsgegevens bevatten. Beperk toegang tot medewerkers die de data nodig hebben, verwijder of maskeer gevoelige waarden waar mogelijk en stel een passende bewaartermijn in. Controleer ook of exports naar externe analysetools binnen het privacybeleid passen. Goede beveiliging is geen losstaand onderdeel van SEO: onzorgvuldig gedeelde logs kunnen informatie lekken, terwijl te agressieve anonimisering juist verhindert dat je echte crawlers betrouwbaar herkent. Zoek een werkwijze die beide belangen expliciet afweegt.