Met logfile analyse onderzoek je welke bots welke URL’s opvragen en welk antwoord je website geeft. Dat helpt bij serverfouten, eindeloze filtercombinaties en belangrijke pagina’s die nauwelijks bezoek krijgen. Begin bij de dekking van je logs en de identiteit van de bezoeker. Pas daarna kun je bepalen welke technische actie nodig is.
Welke vragen beantwoorden logs, en wat ontbreekt er?
Een access-log bevat geregistreerde verzoeken aan een server of tussenliggende dienst. Je kunt ermee onderzoeken welke URL een bot opvroeg, wanneer dat gebeurde en welke HTTP-status terugkwam. Afhankelijk van de logginginstellingen zie je ook verstuurde bytes, responstijd of cachegedrag. Een logregel bewijst op zichzelf geen indexering, hogere positie of vermelding in een AI-antwoord.
Loganalyse is nuttig wanneer je een concrete afwijking wilt verklaren. Denk aan nieuwe producten die moeilijk worden ontdekt, terugkerende serverfouten of een plotseling drukke server. Een kleine webshop kan zo’n probleem hebben; een grote website kan juist zonder acute crawlproblemen draaien. Er bestaat geen vaste URL-drempel waarboven deze analyse automatisch nodig wordt.
Controleer eerst waar de registratie plaatsvindt. Een CDN kan een pagina uit zijn cache leveren zonder de origin, de achterliggende webserver, te benaderen. Die aanvraag ontbreekt dan mogelijk in de originlogs. Andersom vertelt een CDN-export niet vanzelf alles over rechtstreeks verkeer naar de origin. Ook sampling, uitgesloten bestandstypen en ontbrekende hostnamen kunnen het beeld beperken.
Vraag de verantwoordelijke beheerder welke velden beschikbaar zijn, of cache-hits worden vastgelegd, welke hostnamen zijn inbegrepen, welke tijdzone geldt en welke periode bewaard is. Leg eventuele steekproeven en gaten vast. Kies vervolgens een meetperiode die past bij de vraag: een incident vraagt andere gegevens dan de ontdekking van een langzaam veranderend assortiment.
Deze afbakening hoort thuis in een SEO-audit. Zonder bekende logdekking kan ‘geen verzoek gevonden’ alleen betekenen dat je binnen deze registratie niets hebt waargenomen.
Lees de logvelden en controleer wie het verzoek verstuurde
Onderstaand fragment is volledig synthetisch. De IP-adressen komen uit documentatiereeksen en horen hier niet bij echte bots. Ook de user-agent is een zelf opgegeven label; het voorbeeld toont dus geen geverifieerd Googleverkeer.
192.0.2.24 - - [06/Oct/2026:09:12:00 +0200] "GET /producten/werkbank HTTP/1.1" 200 18420 "-" "Googlebot"
192.0.2.24 - - [06/Oct/2026:09:12:03 +0200] "GET /assortiment/werkbanken HTTP/1.1" 301 240 "-" "Googlebot"
198.51.100.18 - - [06/Oct/2026:09:12:07 +0200] "GET /handleidingen/werkbank.pdf HTTP/1.1" 503 620 "-" "VoorbeeldBot/1.0"- Tijdstip: datum, tijd en tijdzone van het geregistreerde verzoek.
- IP: het vastgelegde netwerkadres. Controleer of dit het oorspronkelijke clientadres of een tussenliggende proxy is.
- Methode: GET vraagt een bron op. Houd andere methoden apart wanneer hun betekenis voor je onderzoek verschilt.
- Pad: de aangevraagde route, inclusief eventuele queryparameters als die worden gelogd.
- Status: 200 is een geslaagde HTTP-respons, 301 een permanente verwijzing en 503 een melding dat de dienst niet beschikbaar is.
- Bytes: de geregistreerde omvang van de respons. De precieze definitie hangt af van het logformaat.
- User-agent: de opgegeven naam van de client. Dit veld kan worden vervalst.
Filter eerst op een botlabel om kandidaten te vinden. Voeg daarna een verificatiestatus toe. Voor Google doe je IP-verificatie met de officieel gepubliceerde IP-ranges, of met reverse-DNS gevolgd door forward-DNS. Bij die tweede route controleer je of de gevonden hostnaam aan de officiële voorwaarden voldoet en vervolgens weer naar het oorspronkelijke IP-adres verwijst. Alleen een geloofwaardig klinkende hostnaam is onvoldoende. De stappen staan in Googles documentatie over requestverificatie.
Maak vervolgens veldfilters: geverifieerde Googlebot-verzoeken met status 500 tot en met 599, of verzoeken waarvan het pad begint met /producten/. Voor filters kun je selecteren op aanwezige querysleutels, zoals kleur en maat. Bewaar de oorspronkelijke URL naast je indeling, zodat samenvoegen geen betekenisvolle verschillen verbergt.
De losse 301-regel bewijst geen redirectketen. Daarvoor moet je weten waar de verwijzing heen gaat en wat die bestemming vervolgens doet. Volg de redirects met een gerichte URL-test of crawl en noteer iedere tussenstap. Zelfs opeenvolgende verzoeken van hetzelfde IP vormen zonder verdere controle geen sluitend bewijs van één keten.
Bereken het requestaandeel per paginatype
Een verdeling maakt zichtbaar waar de waargenomen bezoeken terechtkomen. Onderstaande oefening gebruikt uitsluitend fictieve aantallen: 2.000 botverzoeken in één afgebakende export, waarvan 1.000 geverifieerde Googlebot-requests. Alleen die 1.000 vormen de noemer van deze tabel.
Geef ieder verzoek precies één paginatype. In dit voorbeeld gaat een filter-URL vóór paginering: /stoelen?page=2&kleur=blauw telt als filter. Een productpad telt als product; de resterende niet-geclassificeerde routes vallen onder overige URL’s. Documenteer zulke keuzes voordat je perioden vergelijkt.
| Paginatype | Requests | Requestaandeel | Beoordelingsvraag |
|---|---|---|---|
| Producten | 360 | 36% | Zijn actuele, verkoopbare producten bereikbaar? |
| Categorieën | 240 | 24% | Helpen deze pagina’s klanten en bots het assortiment vinden? |
| Filters | 180 | 18% | Biedt de selectie een nuttige bestemming of vooral duplicaten? |
| Content | 100 | 10% | Ondersteunt de uitleg een concrete aankoop- of gebruiksvraag? |
| Paginering | 80 | 8% | Is deze route nodig om verdere producten te bereiken? |
| Overige URL’s | 40 | 4% | Welke bestanden, hulpmiddelen of onbekende routes zitten hierin? |
| Totaal | 1.000 | 100% | Alle geverifieerde Googlebot-requests uit de oefening |
De rekensom voor filters is 180 / 1.000 × 100 = 18%. Dat percentage zegt nog niet dat 18% verspild wordt. Een filter voor een veelgevraagd productkenmerk kan een nuttige landingspagina zijn. Paginering kan noodzakelijk zijn om producten verderop in een categorie te ontdekken.
Beoordeel daarom commerciële functie én technische noodzaak. Combineer de tabel met ecommerce SEO en de opbouw van je assortiment. Google onderscheidt crawlcapaciteit en crawlvraag; het verwijderen van URL’s garandeert geen herverdeling van bezoeken naar jouw voorkeursproducten. De documentatie over crawlbudget geeft context voor grote of vaak bijgewerkte sites en substantiële ontdekkingsproblemen.
Vergelijk botgroepen zonder een ideale verdeling te verzinnen
Gebruik dezelfde export om bots naar rol en verificatiestatus te groeperen. Onderstaande fictieve botverdeling telt opnieuw op tot 2.000 requests. De eerste rij bevat exact de 1.000 Googlebot-verzoeken die hierboven over paginatypen zijn verdeeld.
| Groep | Requests | Aandeel van alle botrequests | Unieke URL’s binnen de groep |
|---|---|---|---|
| Geverifieerde Googlebot | 1.000 | 50% | 420 |
| Overige geverifieerde zoekmachinebots | 300 | 15% | 180 |
| Kandidaat-AI-bots, identiteit onbevestigd | 400 | 20% | 220 |
| Onbekende agents, doel onduidelijk | 220 | 11% | 150 |
| Na onderzoek als ongewenst aangemerkt verkeer | 80 | 4% | 60 |
| Totaal | 2.000 | 100% | Niet optellen: groepen kunnen dezelfde URL bezoeken |
Maak de groepen onderling uitsluitend. Een request dat na onderzoek als ongewenst is ingedeeld, tel je niet nogmaals bij onbekende agents. Een onbekende agent is bovendien niet automatisch schadelijk. Leg vast waarom je een verzoek in een groep plaatst.
Vergelijk naast aantallen en unieke URL’s ook verstuurde bytes, responstijden en cachegedrag, voor zover beschikbaar. Voor serverbelasting heb je vaak aanvullende metingen van de beheerder nodig. Honderd aanvragen voor zware, ongecachete pagina’s kunnen een andere belasting geven dan honderd cache-hits. Een access-log met alleen status en bytes geeft daar geen volledig antwoord op.
Splits AI-bots naar zoeken, ophalen en mogelijke training
De naam ‘AI-bot’ omvat verschillende taken. Volgens de OpenAI-botdocumentatie ondersteunt OAI-SearchBot zoeken in ChatGPT, verzamelt GPTBot mogelijk trainingsmateriaal en haalt ChatGPT-User informatie op na een gebruikersactie. Die laatste categorie is geen gewone automatische zoekcrawler; robots.txt hoeft bij zulke verzoeken niet van toepassing te zijn.
Perplexity onderscheidt eveneens een zoekbot, PerplexityBot, en gebruikersgestuurd ophalen via Perplexity-User. Die gebruikersverzoeken negeren doorgaans robots.txt. Anthropic onderscheidt ClaudeBot, Claude-SearchBot en Claude-User voor respectievelijk mogelijke trainingsverzameling, zoeken en gebruikersgestuurd ophalen. Controleer de identiteit met de officiële verificatiegegevens die de betreffende aanbieder beschikbaar stelt. Een user-agent blijft tot die controle een claim.
Google-Extended tel je niet als afzonderlijke logbot. Het is een product-control-token voor bepaalde toepassingen rond Gemini, zonder eigen HTTP-user-agent. Het regelt geen opname of ranking in Google Search. Zie hiervoor Googles overzicht van crawlers en controles.
Er bestaat geen algemeen ideale botmix. Een stijgend aantal AI-requests bewijst geen training of citatie. Houd toegangsmetingen en waargenomen antwoordvermeldingen gescheiden wanneer je AI en SEO beoordeelt.
Onderzoek vijf logpatronen voordat je iets wijzigt
Een patroon wordt pas een bruikbare diagnose als je het koppelt aan de bedoeling van de URL. De volgende controles helpen om fouten, bewuste keuzes en ontbrekende waarnemingen uit elkaar te houden.
1. Maak onderscheid tussen kapotte pagina’s en bewuste verwijderingen
Filter 4xx/5xx per URL en paginagroep. Controleer vervolgens of de pagina hoort te bestaan en of interne verwijzingen er nog naartoe wijzen. Een 404 voor een definitief verwijderd product kan passend zijn. Een 404 op een actuele categorie wijst op een ander probleem. Een 503 vraagt onderzoek naar beschikbaarheid, capaciteit of de achterliggende applicatie.
Herstel foutieve interne links naar de bedoelde bestemming. Gebruik een redirect alleen als er een passende vervanger is. Voor permanent verdwenen content kan 404 of 410 correct blijven. Controleer na herstel zowel de bronlink als de uiteindelijke respons; een algemene redirect naar de homepage lost de inhoudelijke mismatch niet op.
2. Test mogelijke redirectketens vanaf de oorspronkelijke URL
Veel 301- of 302-responses zijn een onderzoekssignaal. Verzamel de oorspronkelijke URL’s en volg hun bestemmingen. Als een oude categorie via twee tussenstappen bij de huidige categorie uitkomt, kun je beoordelen of een rechtstreekse verwijzing passend is.
Controleer vóór aanpassen of een tussenstap functioneel nodig is. Werk waar mogelijk ook interne links bij. De hertest begint opnieuw bij de oude URL en bevestigt de hele route, inclusief de eindstatus en juiste inhoud.
3. Zoek uit welke parametercombinaties nuttig zijn
Groepeer querysleutels en tel hoeveel verschillende combinaties ze opleveren. Bekijk voorbeelden: verandert een parameter het aanbod, alleen de sorteervolgorde of helemaal niets? Een oplopend aantal vrijwel identieke URL’s vraagt ander beheer dan een beperkte set bruikbare filters.
Onderzoek interne verwijzingen, canonicals en indexeerbaarheid voordat je de toegang beperkt. Noindex vereist nog steeds een request om de instructie te kunnen lezen. Blokkeren via robots.txt is geen vervanging voor het verwijderen van een URL uit de index. Controleer na een wijziging ook of noodzakelijke productontdekking blijft werken.
4. Onderzoek belangrijke pagina’s zonder waargenomen bezoek
Leg je lijst met belangrijke URL’s naast de logs. Controleer bij ontbrekende bezoeken eerst logdekking, publicatiedatum, status en crawlbaarheid. Vergelijk daarna de sitemap, interne links en beschikbare informatie in Search Console.
Een crawlbare pagina zonder waargenomen request is niet hetzelfde als een geblokkeerde pagina. Als de pagina alleen via een diep verstopt filter bereikbaar is, kan een relevante interne link helpen bij ontdekking. Controleer vervolgens opnieuw de bereikbaarheid en latere waarnemingen, zonder een bezoekmoment of indexering te beloven.
5. Koppel een crawlpiek aan tijdstip en servergedrag
Splits een plotselinge piek uit naar botidentiteit, pad, status en tijdvak. Vergelijk die met publicaties, releases, cachewijzigingen en servermetingen. Een crawlpiek na nieuwe content kan een andere verklaring hebben dan herhaalde verzoeken naar willekeurige niet-bestaande routes.
Laat de beheerder pas een toegangsmaatregel beoordelen als identiteit, noodzakelijke toegang en daadwerkelijke belasting zijn onderzocht. Test daarna of gewenst verkeer en vereiste bronnen toegankelijk blijven. Alleen een hoog requestaantal is onvoldoende reden voor een blokkade.
Werk van logexport naar een onderbouwde prioriteitenlijst
- Verzamelen: formuleer één onderzoeksvraag en vraag een beperkte, geautoriseerde logexport met de benodigde velden aan. Beschrijf CDN, origin, hostnamen, tijdzone, dekking en meetperiode.
- Valideren en filteren: controleer ontbrekende tijdvakken, dubbele registraties en het gebruikte client-IP. Verifieer botkandidaten en houd onbevestigde verzoeken herkenbaar apart. Tel CDN- en originregels niet zonder controle bij elkaar op.
- Groeperen: wijs ieder request toe aan een botgroep en paginatype. Bewaar ruwe paden naast de afgeleide groepen. Maak onbekende categorieën zichtbaar.
- Vergelijken: doe een crawlvergelijking en koppel de sitemap en Search Console aan dezelfde URL-lijst. Controleer eerst of je toegang hebt tot de juiste geverifieerde property. Logs tonen waargenomen aanvragen; een crawl test bereikbaarheid en Search Console geeft aanvullende informatie over crawling, indexering en zoekprestaties.
- Prioriteren: beoordeel impact en inspanning samen met bewijskracht en risico. Een reproduceerbare serverfout op een belangrijke categorie verdient doorgaans eerder aandacht dan een onverklaard percentage bij onbelangrijke routes.
Een spreadsheet past bij een beperkte export en enkele duidelijke groepen. Een loganalysetool kan helpen bij grotere bestanden en herhaalbare filters. Een datawarehouse wordt relevant als je omvangrijke gegevens uit meerdere bronnen structureel wilt koppelen. Laat volume, onderzoeksvraag en beheer bepalen wat nodig is; controleer vooraf of het gekozen hulpmiddel jouw velden en export werkelijk ondersteunt.
Beperk toegang tot ruwe gegevens en werk voor de beoordeling zoveel mogelijk met aggregaties. Leg de technische interpretatie naast je SEO-strategie: welke pagina’s moeten bezoekers kunnen vinden, en welke functie vervullen ze?
Werkblad: van logbewijs naar controletest en herstelcriterium
Kopieer onderstaande tabel naar je eigen werkblad. Alle requests zijn synthetische voorbeelden. Vervang ze door je eigen waarneming en noteer daarbij periode, logbron en verificatiestatus. Het werkblad ondersteunt drie uitkomsten: herstellen, eerst extra bewijs verzamelen of bewust blijven monitoren.
| Voorbeeldwaarneming | Wat dit bewijst | Wat nog ontbreekt | Volgende controletest | Herstelcriterium |
|---|---|---|---|---|
| GET /categorie/krukken → 503 | Deze geregistreerde aanvraag kreeg een foutrespons. | Oorzaak, duur en omvang. | Controleer applicatiefouten en herhaal de aanvraag. | De bedoelde categorie wordt correct geleverd; vergelijkbare aanvragen vertonen het onderzochte foutpatroon niet meer. |
| GET /oude-kruk → 301 | Deze aanvraag kreeg een verwijzing. | Bestemming en eventuele tussenstappen. | Volg de volledige redirectroute. | De afgesproken bestemming is via de bedoelde route bereikbaar. |
| GET /krukken?kleur=wit&sort=prijs → 200 | Deze combinatie leverde een geslaagde HTTP-respons. | Inhoudelijke waarde en aantal varianten. | Vergelijk inhoud, links en canonical met andere combinaties. | Overbodige varianten worden volgens het gekozen URL-beleid beheerd; nuttige selecties blijven bereikbaar. |
| Geen regel voor /krukken/verstelbaar | Geen waarneming in deze export. | Volledigheid, vindbaarheid en crawlbaarheid. | Controleer dekking, interne route, sitemap en Search Console. | Eventuele vindbaarheidsfouten zijn opgelost en resterende onzekerheid is vastgelegd. |
| Veel GET-verzoeken naar /zoeken in één tijdvak | Een concentratie van geregistreerde aanvragen. | Herkomst, aanleiding en belasting. | Verifieer identiteit en vergelijk met servermetingen. | De oorzaak is verklaard; een eventuele maatregel behoudt noodzakelijke toegang. |
Voeg aan iedere rij een eigenaar, uitgangsmeting, herstelactie, risico en hertest toe. Schrijf het risico concreet op, bijvoorbeeld ‘producten op vervolgpagina’s kunnen onbereikbaar worden’. Een ingevuld werkblad moet duidelijk maken welke beslissing verantwoord is en welke conclusie nog niet kan worden getrokken.
Scheid direct herstel, URL-beheer en monitoring
Direct herstel past bij bevestigde defecten, zoals een foutieve interne link of reproduceerbare serverfout. De eigenaar is degene die de oorzaak kan aanpassen: bijvoorbeeld de contentbeheerder, ontwikkelaar of hostingbeheerder. Leg vast welke URL vóór de wijziging welk probleem vertoonde.
Structureel URL-beheer betreft terugkerende patronen in filters, redirects en paginering. Dit vraagt afstemming tussen inhoud, techniek en assortiment. Test eerst een afgebakende wijziging en controleer bereikbaarheid, inhoud en indexeringsinstructies voordat je dezelfde aanpak breder toepast. Dit is onderdeel van technische SEO.
Monitoring past wanneer er geen bevestigd defect is of wanneer extra waarnemingen nodig zijn. Vergelijk dezelfde paginagroep over perioden met vergelijkbare dekking en omstandigheden. Noteer releases, assortimentwijzigingen en ontbrekende logdagen; die kunnen verschillen verklaren.
Een hertest controleert eerst de werking van de wijziging en daarna het waargenomen gedrag. Minder fouten bewijzen nog geen betere ranking. Meer bezoeken bewijzen nog geen extra omzet. Neem beide meetlagen afzonderlijk op in je SEO-rapportage, zonder vast hersteltempo of winstpercentage te beloven.
Onderzoek waarom een PDF minder bezoek krijgt dan de HTML-pagina
Stel dat een producthandleiding als HTML én PDF beschikbaar is, maar alleen de HTML-versie regelmatig in de logs verschijnt. Begin met een vergelijking van de twee concrete URL’s. Controleer status, toegang, interne vindbaarheid en of aanvragen naar het PDF-hostname in dezelfde registratie terechtkomen.
Bekijk daarna of een bezoeker de PDF via een gewone, relevante link kan vinden. Controleer een eventuele sitemapvermelding: is de URL bedoeld voor indexering en is dit de juiste versie? Een aparte sitemap kan bestanden overzichtelijk groeperen, maar is geen speciale route naar AI-citaties. Een sitemap helpt bij ontdekking en garandeert geen indexering. Gebruik betekenisvolle lastmod-waarden; Google negeert priority en changefreq, zoals toegelicht in de sitemapdocumentatie.
Kies vervolgens een actie op basis van het gevonden probleem. Herstel een kapotte downloadlink, verbeter een onduidelijke verwijzing of los een foutrespons op. Vergelijk daarna geverifieerde requests naar HTML en PDF over vergelijkbare perioden. Als er nog steeds weinig PDF-bezoek is, kan het verschil ook samenhangen met de vraag naar dat bestand of informatie die al in HTML beschikbaar is.
Registreer iedere citatiewaarneming apart met datum, platform, vraag en genoemde URL. Meer PDF-requests bewijzen geen gebruik in antwoorden. Voor Google AI Overviews en AI Mode gelden de gebruikelijke SEO-voorwaarden; er is geen speciaal AI-bestand vereist. Ondersteunende pagina’s moeten geïndexeerd zijn en een snippet kunnen tonen, maar verschijnen is niet gegarandeerd. Search Console verwerkt deze prestaties binnen Web en biedt daarmee geen zuiver los AI-overzicht. Zie Googles uitleg over AI-functies.
Veelgestelde vragen over logfile analyse en AI-bots
Bewijzen meer AI-botrequests dat mijn website vaker wordt genoemd?
Nee. Ze tonen alleen meer geregistreerde aanvragen binnen de dekking van je logs. Verifieer eerst de botidentiteit en registreer daadwerkelijke vermeldingen apart. Een request bewijst geen training, ranking of citatie.
Hoe lang moet mijn meetperiode zijn?
Dat hangt af van je onderzoeksvraag, beschikbare registratie en veranderingen op je website. Kies een periode waarin je het probleem kunt onderzoeken en vergelijkbare omstandigheden kunt beoordelen. Er is geen universele minimumperiode die iedere analyse betrouwbaar maakt.
Moet ik filters en paginering blokkeren?
Alleen nadat je hun functie en het probleem hebt vastgesteld. Nuttige filters kunnen een eigen bestemming zijn en paginering kan producten bereikbaar maken. Onderzoek duplicaten, interne links en indexeerbaarheid voordat je toegang beperkt.
Waarom zie ik Google-Extended niet als aparte bot?
Google-Extended is een product-control-token zonder afzonderlijke HTTP-user-agent. Je kunt het daarom niet als aparte geverifieerde crawler tellen. Het regelt bepaalde toepassingen rond Gemini, niet opname of ranking in Google Search.
Laat één concreet logpatroon beoordelen
Niblah helpt met SEO en websites op WordPress en Shopify. Wil je weten welke technische actie bij jouw botverkeer past? Beschrijf via het Niblah-contactformulier één probleem, de betrokken URL’s, de meetperiode en of je gegevens van CDN, origin of beide hebt. Vermeld ook welke controle je al hebt uitgevoerd. Daarmee begint het onderzoek bij een concrete vraag en een toetsbaar herstelcriterium.