TL;DR: Google Search Console vertelt je wat Google wil dat je ziet. Serverlogs vertellen je wat Googlebot daadwerkelijk heeft gedaan. Ik ontdekte dat Googlebot 73% van zijn crawl budget besteedde aan parameter-URL's waarvan we vergeten waren dat ze bestonden. GSC liet niets ongewoons zien. Hier lees je hoe je logbestandanalyse opzet, waar je op moet letten, en waarom dit de meest onderbenutte techniek in technische SEO is.
Google Search Console is een fantastische tool. Ik gebruik het dagelijks. Maar het heeft een fundamenteel probleem: het laat je alleen zien wat Google heeft besloten te rapporteren.
De crawlstatistieken van GSC geven je geaggregeerde cijfers — totaal aantal verzoeken, gemiddelde responstijd, enkele statuscodes. Wat het je niet vertelt is welke specifieke URL's Googlebot heeft bezocht, in welke volgorde, hoe lang elk verzoek duurde, of Googlebot terugkwam voor een tweede pass om JavaScript te renderen, of welke secties van je site het volledig negeert.
Dat is het gat. En het is enorm.
Serverlogs zijn de ongefilterde waarheid. Elk verzoek dat Googlebot aan je server doet wordt gelogd met een timestamp, de exacte URL, de statuscode, de responstijd en de user agent string. Geen samenvatting, geen sampling, geen Google dat bepaalt wat jij moet weten. Ruwe data.
Ik zal eerlijk zijn: ik heb logbestandanalyse de eerste twee jaar dat ik SEOJuice runde genegeerd. Het voelde als iets wat enterprise SEO's deden met zescijferige Botify-contracten. Ik had het mis. Op het moment dat ik onze eigen Nginx-logs begon te parsen, vond ik problemen die GSC maandenlang had verborgen. Crawl budget verspilling aan gefacetteerde URL's. 5xx-fouten die alleen optraden onder Googlebot's crawlpatronen. Nieuwe blogposts die Googlebot drie weken niet had bezocht.
Op basis van wat ik bij honderden sites heb gezien: in mijn ervaring heeft vrijwel elke site met meer dan 500 pagina's minstens één significant crawlprobleem dat alleen loganalyse kan onthullen.
Laat me dat ontleden:
| Veld | Waarde | Wat het betekent |
|---|---|---|
| IP-adres | 66.249.79.45 | Googlebot's IP (het 66.249.x.x-bereik is Google) |
| Timestamp | [15/Mar/2026:09:23:17 +0000] | Exact tijdstip van het verzoek |
| Verzoek | GET /blog/content-decay-guide/ HTTP/2.0 | Welke URL is gecrawld |
| Statuscode | 200 | Serverrespons (200 = OK) |
| Bytes verzonden | 34521 | Responsgrootte in bytes |
| Referer | - | Waar het verzoek vandaan kwam (meestal leeg bij bots) |
| User Agent | Googlebot/2.1 | Identificeert de crawler |
| Responstijd | 0.142 | 142ms om de pagina te serveren |
Verschillende webservers gebruiken licht afwijkende formaten. Apache's “Combined Log Format” is vrijwel identiek aan dat van Nginx. IIS gebruikt een W3C extended format met door spaties gescheiden velden en een headerregel die de kolommen definieert. De data is hetzelfde — de indeling verschilt.
De cruciale velden voor SEO zijn: user agent (om te filteren op bots), URL (om te zien wat gecrawld wordt), statuscode (om fouten te vinden) en responstijd (om performance-knelpunten te vinden).
Niet elk Googlebot-verzoek komt van dezelfde crawler. Google gebruikt verschillende user agents voor verschillende doeleinden, en het onderscheid is belangrijk.
| User Agent String | Wat het doet | Waarom het ertoe doet |
|---|---|---|
Googlebot/2.1 | Primaire webcrawler | Dit is de hoofdcrawl — je kernpagina's |
Googlebot-Image/1.0 | Afbeeldingscrawler | Crawlt afbeeldingen voor de Google Afbeeldingen-index |
Googlebot-Video/1.0 | Videocrawler | Ontdekt en indexeert videocontent |
Googlebot-News | Nieuwscrawler | Alleen relevant als je in Google News zit |
APIs-Google | AMP/API-fetcher | Haalt AMP-pagina's en speciale content op |
Chrome/W.X.Y.Z (met Googlebot) | Renderingbot | Dit is de belangrijkste. Wanneer je een Chrome UA samen met Googlebot ziet, is dat de Web Rendering Service — Google die je JavaScript uitvoert |
De renderingbot is bijzonder belangrijk. Wanneer Googlebot een pagina voor het eerst crawlt, krijgt het de ruwe HTML. Als de pagina JavaScript bevat, zet Google een tweede verzoek in de wachtrij via de Web Rendering Service (WRS), die een headless Chrome-browser gebruikt. Dat tweede verzoek verschijnt in je logs met een Chrome user agent string.
Als je de initiële Googlebot-hit ziet maar nooit de Chrome-renderingpass op een JS-zware pagina, ziet Google waarschijnlijk niet je volledige content. Dat is onzichtbaar in GSC. Alleen loganalyse onthult het.
De meeste standaard Nginx- en Apache-configuraties loggen genoeg data voor basisanalyse. Maar “basis” is niet goed genoeg. Je wilt responstijd, en de meeste standaardinstellingen bevatten dat niet.
Hier is het Nginx-logformaat dat ik gebruik. Voeg dit toe aan je http-blok in nginx.conf:
log_format seo_analysis '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time';
access_log /var/log/nginx/access.log seo_analysis;De twee toevoegingen die ertoe doen: $request_time (totale tijd van verzoek tot respons) en $upstream_response_time (hoe lang je applicatieserver erover deed, zonder Nginx-overhead). Het verschil tussen deze twee getallen vertelt je of het knelpunt bij je app of je proxylaag ligt.
Voor Apache, voeg %D (verzoektijd in microseconden) toe aan je LogFormat-directive:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" seo_combined
CustomLog /var/log/apache2/access.log seo_combinedHier wordt het vervelend. Als je achter Cloudflare, Bunny CDN, Fastly of een ander CDN zit, tonen je originserverlogs alleen verzoeken die langs de cache komen. Een perfect gecachte pagina kan 50 keer door Googlebot gecrawld worden, en je origin ziet nul van die verzoeken.
Je hebt CDN-level logs nodig:
Als je CDN geen bot-level logging biedt op jouw plan, kun je een regel instellen om de cache te bypassen voor bekende bot user agents. Dit dwingt botverzoeken om je origin te raken, waar je ze kunt loggen. De afweging is een iets hogere originbelasting tijdens crawls.
Ik weet niet zeker of dit de afweging waard is voor kleinere sites. Als je 200 Googlebot-verzoeken per dag krijgt, is de originbelasting van cache-bypass verwaarloosbaar. Als je er 200.000 krijgt, denk dan goed na over je infrastructuur voordat je die schakelaar omzet.
Logs worden snel groot. Een site met 10.000 dagelijkse bezoekers genereert ruwweg 2-5 MB aan access logs per dag. Over een jaar is dat 700 MB tot 1,8 GB ongecomprimeerd. Gezipt misschien 50-100 MB.
Voor SEO-analyse wil je minimaal 90 dagen aan logs. Idealiter 6 maanden, zodat je seizoensgebonden crawlpatronen kunt zien en correleren met algoritme-updates. Stel logrotate (Linux) in of een cron-job om logs wekelijks te comprimeren en archiveren. Verwijder alles ouder dan 6 maanden, tenzij je een specifieke reden hebt om het te bewaren.
Ik wil dit opdragen aan wijlen Hamlet Batista, die het gebruik van Python voor SEO-loganalyse en automatisering pionierde. Hamlet overleed in 2020, maar zijn werk — met name zijn schrijven over het gebruik van Python en Jupyter notebooks voor technische SEO — heeft fundamenteel veranderd hoe onze industrie dataproblemen benadert. Veel van wat volgt bouwt voort op patronen die hij de SEO-community heeft geleerd.
Hier is een basis Python-script dat Nginx-logs filtert op Googlebot-verzoeken en de metrics genereert die er daadwerkelijk toe doen voor SEO. Dit komt dicht bij wat ik op de logs van SEOJuice.com zelf heb gedraaid.
import re
import csv
from collections import Counter, defaultdict
from datetime import datetime
LOG_PATTERN = re.compile(
r'(?P<ip>\S+) \S+ \S+ '
r'\[(?P<timestamp>[^\]]+)\] '
r'"(?P<method>\S+) (?P<url>\S+) \S+" '
r'(?P<status>\d{3}) (?P<size>\d+) '
r'"[^"]*" "(?P<ua>[^"]*)" '
r'(?P<response_time>[\d.]+)?'
)
GOOGLEBOT_PATTERN = re.compile(r'Googlebot|Google-InspectionTool', re.IGNORECASE)
def parse_log(filepath):
"""Parse Nginx log, return only Googlebot requests."""
results = []
with open(filepath, 'r') as f:
for line in f:
match = LOG_PATTERN.match(line)
if not match:
continue
if not GOOGLEBOT_PATTERN.search(match.group('ua')):
continue
results.append({
'ip': match.group('ip'),
'timestamp': match.group('timestamp'),
'url': match.group('url'),
'status': int(match.group('status')),
'size': int(match.group('size')),
'ua': match.group('ua'),
'response_time': float(match.group('response_time') or 0),
})
return results
def analyze(requests):
"""Generate SEO-relevant metrics from Googlebot requests."""
url_counts = Counter(r['url'] for r in requests)
status_counts = Counter(r['status'] for r in requests)
slow_urls = [
(r['url'], r['response_time'])
for r in requests if r['response_time'] > 1.0
]
# Section-level crawl distribution
section_counts = Counter()
for r in requests:
parts = r['url'].strip('/').split('/')
section = parts[0] if parts and parts[0] else '(root)'
section_counts[section] += 1
print(f"Total Googlebot requests: {len(requests)}")
print(f"\n--- Status Code Distribution ---")
for code, count in status_counts.most_common():
pct = (count / len(requests)) * 100
print(f" {code}: {count} ({pct:.1f}%)")
print(f"\n--- Top 20 Most Crawled URLs ---")
for url, count in url_counts.most_common(20):
print(f" {count:>5}x {url}")
print(f"\n--- Crawl Distribution by Section ---")
total = len(requests)
for section, count in section_counts.most_common(10):
pct = (count / total) * 100
print(f" /{section}/: {count} ({pct:.1f}%)")
print(f"\n--- Slow Responses (>1s) ---")
for url, time in sorted(slow_urls, key=lambda x: -x[1])[:10]:
print(f" {time:.2f}s {url}")
if __name__ == '__main__':
requests = parse_log('/var/log/nginx/access.log')
analyze(requests)Dat zijn misschien 60 regels code. Het kostte me 20 minuten om te schrijven. En de output liet me direct zien dat Googlebot onze /tools/-sectie bombardeerde (73% van alle crawlverzoeken) terwijl nieuwe blogposts nauwelijks werden aangeraakt. Wat verklaarde waarom onze nieuwe content wekenlang niet werd geïndexeerd.
Voor grotere sites of doorlopende monitoring wil je iets robuusters. De ELK-stack (Elasticsearch, Logstash, Kibana) is de industriestandaard voor logaggregatie op schaal. Logstash neemt de logs op en parst ze, Elasticsearch indexeert ze voor snelle queries, en Kibana geeft je dashboards. Het is krachtig maar niet triviaal om op te zetten — reken op een dag of twee voor de initiële configuratie.
De /tools/-sectie had tientallen parametercombinaties (filters, sorteermogelijkheden, paginering) die duizenden crawlbare URL's genereerden. Googlebot crawlde ze allemaal plichtsgetrouw. Ondertussen kreeg onze blog — de sectie die daadwerkelijk organisch verkeer genereert — 11% van de crawlaandacht.
De oplossing was een combinatie van canonical tags, robots.txt-regels en noindex op parametervarianten. We hebben ook de interne linkbuilding geherstructureerd om onze content silo's beter te weerspiegelen. Binnen twee weken was de crawlfrequentie van de blog verdubbeld. Nieuwe posts werden binnen dagen geïndexeerd in plaats van weken.
Dit kun je niet zien in GSC. GSC geeft je het totaal aantal crawlverzoeken. Het splitst ze niet uit per sectie en laat het verdelingsprobleem niet zien.
Aggregeer je statuscodes over alle Googlebot-verzoeken. Zo ziet gezond eruit:
Ik zag ooit een site waar 22% van de Googlebot-verzoeken een 404 retourneerden. De vorige developer had een productcategorie verwijderd zonder redirect. Googlebot had die URL's in zijn crawlwachtrij en bleef ze opnieuw proberen. Tweeëntwintig procent van het crawl budget, verbrand op pagina's die niet bestonden. Acht maanden lang.
Google heeft herhaaldelijk gezegd dat paginasnelheid een rankingfactor is. Maar Core Web Vitals (die GSC rapporteert) meten client-side performance. Serverresponstijd — hoe lang je server erover doet om de HTML te genereren en te versturen — is iets anders, en dat verschijnt alleen in logs.
Waar je naar zoekt: elke URL waar de responstijd consistent boven de 500ms uitkomt. Boven 1 seconde is een probleem. Boven 2 seconden en Googlebot breekt het verzoek mogelijk helemaal af.
Sorteer je Googlebot-verzoeken op responstijd, aflopend. De traagste URL's vallen meestal in een paar categorieën: database-intensieve pagina's (productoverzichten met complexe filters), pagina's die externe API-calls maken tijdens het renderen, of pagina's die grote responses genereren (sitemaps, feeds).
Hoeveel klikken vanaf de homepage heeft Googlebot nodig om een pagina te bereiken? Dit staat niet direct in de logdata, maar je kunt het afleiden door naar timestamps en verwijzingspatronen te kijken.
Als Googlebot je homepage om 09:00 bezoekt, je hoofdcategoriepagina's om 09:01, en een diep geneste productpagina om 09:14 — dan suggereert die kloof van 14 minuten dat de pagina diep genest is. Pagina's die Googlebot laat in een crawlsessie ontdekt, krijgen minder aandacht.
Een eenvoudigere aanpak: vergelijk de set URL's die Googlebot heeft gecrawld met je volledige sitemap. Elke URL in de sitemap die Googlebot 30+ dagen niet heeft bezocht is effectief verweesd vanuit Google's perspectief, ongeacht wat je interne linkbuilding zegt.
Dit is zowel een beveiligings- en performancemetric als een SEO-metric. Filter je logs op user agent en bereken welk percentage van het totale verkeer van bots komt versus echte gebruikers.
Op de meeste sites zijn bots verantwoordelijk voor 30-50% van alle verzoeken. Als bots 80%+ uitmaken, word je waarschijnlijk gescrapet of getroffen door kwaadaardige bots die serverresources verspillen. Als Googlebot specifiek minder dan 5% van je botverkeer vertegenwoordigt, verbruikt iets anders je servercapaciteit en vertraagt het mogelijk Google's vermogen om je te crawlen.
Dit is misschien de meest waardevolle analyse die je kunt doen. Neem de lijst URL's in je sitemap of CMS. Vergelijk die met de lijst URL's die Googlebot de afgelopen 90 dagen heeft bezocht. Elke URL die Googlebot niet heeft aangeraakt is functioneel onzichtbaar.
Veelvoorkomende oorzaken: de pagina heeft geen interne links die ernaartoe wijzen (een echte verweesde pagina), de pagina zit te diep in de site-architectuur, of de pagina wordt geblokkeerd door een robots.txt-regel die je bent vergeten.
Ik snap oprecht niet waarom meer SEO's deze analyse niet standaard doen. Het kost 10 minuten met het bovenstaande Python-script en een lijst van je URL's. Elke keer dat ik het voor een klant heb gedraaid, vonden we pagina's die belangrijk hadden moeten zijn maar maandenlang niet waren gecrawld.
Theorie is leuk. Hier zijn de daadwerkelijke problemen die ik heb gevonden via loganalyse, op echte sites, die anders onontdekt waren gebleven.
Onze eigen ervaring heb ik al genoemd. Maar het is het benadrukken waard: gefacetteerde navigatie, zoekparameters, sorteervolgorden en paginering creëren een exponentieel aantal crawlbare URL's. Een productcatalogus met 500 producten, 8 filtercategorieën en 3 sorteeropties kan tienduizenden URL's genereren. Googlebot probeert ze allemaal te crawlen.
Volgens Botify's gepubliceerd crawl budget-onderzoek (2023) kan op grote e-commercesites tot 80% van Googlebot's crawl budget worden verbruikt door parameter-URL's die vrijwel identieke content leveren — hoewel het exacte cijfer sterk varieert per sitetype en architectuur. Hun CTO, Adrien Menard, heeft uitgebreid hierover geschreven: het crawl budget-probleem op grote sites gaat niet over Google meer laten crawlen — het gaat over Google stoppen met het verspillen van crawls aan URL's met lage waarde.
Een klant had intermitterende 503-fouten die alleen verschenen tijdens Googlebot's crawlpieken. Hun monitoring (Pingdom, UptimeRobot) liet 99,9% uptime zien omdat die tools eens per minuut vanaf één locatie controleren. Googlebot raakt 10-50 pagina's in snelle opeenvolging. Hun server kon de piek niet aan, gooide 503's voor ongeveer 15% van de Googlebot-verzoeken, en herstelde binnen seconden.
De crawlstatistieken van GSC lieten een licht verhoogd foutpercentage zien. De logs toonden het volledige beeld: elke dag tussen 02:00 en 03:00 UTC (wanneer Googlebot deze specifieke site het vaakst bezoekt), faalde de server onder belasting. Het oplossen vereiste het afstemmen van PHP-FPM worker-aantallen en database connection pooling. Totale kosten: twee uur DevOps-werk. De verbeteringen in rankings waren binnen drie weken zichtbaar.
We publiceerden een uitgebreide gids. Drie weken later was het nog steeds niet geïndexeerd. GSC toonde de URL als “Discovered — currently not indexed.” Nuttig.
De logs vertelden het echte verhaal: Googlebot had de URL nooit opgevraagd. Niet één keer. De pagina was gelinkt vanaf een tag-archiefpagina die zelf slechts twee keer in 60 dagen was gecrawld. Googlebot had simpelweg de link nog niet gevolgd.
De oplossing was het toevoegen van een interne link vanaf een veelgecrawlde pagina (onze homepage-sidebar). Googlebot bezocht de nieuwe pagina binnen 48 uur. Geïndexeerd binnen een week. Dit is precies het soort probleem dat een post-launch SEO-checklist moet opvangen voordat het een probleem wordt.
Een SaaS-klant had een marketingsite gebouwd in Next.js. SSR was ingeschakeld — goed. Maar de logs lieten iets vreemds zien: Googlebot's Chrome-renderingbot maakte een tweede pass op elke pagina, inclusief simpele statische pagina's zonder client-side dynamische content.
Het probleem was een client-side analytics-script dat de DOM aanpaste na het laden van de pagina. Googlebot zag de initiële HTML, kwam toen terug om JS te renderen en zag andere content (de door analytics geïnjecteerde elementen). Dus bleef het re-renderen om zeker te zijn dat het de definitieve versie had. Dit verbruikte rendering budget op pagina's die het niet nodig hadden.
De oplossing: verplaats het analytics-script zodat het laadt na het DOMContentLoaded-event met een defer-attribuut, en zorg ervoor dat het geen zichtbare DOM-elementen wijzigt. Renderingverzoeken daalden met 60%.
Botify — Enterprise-niveau. Neemt logs op grote schaal op, correleert ze met crawldata en Search Console, en bouwt automatisch dashboards. Als je een site met miljoenen pagina's beheert, is dit waarschijnlijk de investering waard. Voor sites onder de 100k pagina's is het overkill. De prijs lag in de honderden euro's per maand toen ik het laatst controleerde (medio 2025), al is hun exacte pricing ondoorzichtig en daar heb ik gemengde gevoelens over.
JetOctopus — Een sterke middenweg. Cloudgebaseerde loganalyse met goede visualisatie. Verwerkt grote logbestanden, integreert met GSC en kost aanzienlijk minder dan Botify. Ik heb dit aanbevolen aan bureaus die meerdere middelgrote sites beheren.
Custom Python + ELK — Als je technisch bent en volledige controle wilt, is het bovenstaande script een startpunt. Voor doorlopende monitoring stuur je je logs naar de ELK-stack (Elasticsearch, Logstash, Kibana). Logstash parst de logs met grok-patronen, Elasticsearch slaat ze op en indexeert ze, Kibana geeft je real-time dashboards. Setup kost een dag. Doorlopende kosten zijn alleen de server — misschien $20-$50/maand op een kleine VPS.
GoAccess — Een lichtgewicht, terminalgebaseerde log analyzer die HTML-rapporten genereert. Niet SEO-specifiek, maar verrassend handig voor een snel overzicht van botactiviteit en statuscodeverdeling. Gratis, snel, werkt op elke server. Goed voor het “ik wil even snel iets checken”-geval.
Transparantiemoment. Dit is wat ik vond toen ik eind 2025 voor het eerst een goede loganalyse op onze eigen site draaide.
Bevinding 1: Crawl budget verspilling op toolpagina's. Onze gratis SEO-tools (site audit, domain authority checker, keyword extractor, etc.) genereren unieke URL's per analyse. Elk toolresultaat had een unieke URL. Googlebot crawlde er duizenden. Dit waren voornamelijk dunne, kortstondige pagina's die niet in de index hoefden. We voegden noindex toe aan toolresultaatpagina's en zagen onze blog-crawlsnelheid binnen twee weken toenemen.
Bevinding 2: Trage API-afhankelijke pagina's. Onze pricingpagina maakte een real-time call naar de API van Paddle om actuele prijzen op te halen. Mediane responstijd: 1,8 seconden. Googlebot wachtte erop. We schakelden over naar caching van de pricingdata met een TTL van 1 uur. Responstijd daalde naar 90ms.
Bevinding 3: 301-redirectketens. Na een URL-herstructurering hadden we ketens als /old-url → /medium-url → /final-url. Twaalf procent van de Googlebot-verzoeken volgde redirects. Elke hop is een verspild verzoek. We hebben alle ketens teruggebracht tot single-hop redirects in onze Nginx-configuratie.
Bevinding 4: CSS- en JS-crawling. Dit verraste me. Ongeveer 30% van Googlebot's verzoeken was voor statische assets — CSS-bestanden, JavaScript-bundels, fonts. Deze zijn nodig voor rendering, maar het betekende dat slechts 70% van ons crawl budget naar daadwerkelijke contentpagina's ging. We konden dit niet elimineren (Google heeft deze bestanden nodig om pagina's te renderen), maar het zette ons totale crawl budget in een ander perspectief.
Nettoresultaat: na het aanpakken van bevindingen 1-3 werd onze blogcontent 3-4x sneller geïndexeerd. Nieuwe posts gingen van “ontdekt maar niet geïndexeerd voor 2-3 weken” naar “geïndexeerd binnen 3-5 dagen.” Allemaal dankzij inzichten uit loganalyse die GSC nooit had blootgelegd.
Ik heb de crawler analytics-functie in SEOJuice specifiek gebouwd omdat ik het zat was om ruwe logs te parsen. Het geeft je dezelfde inzichten zonder het commandoregelwerk.
SEOJuice's crawler analytics monitort Googlebot-activiteit op je site en laat zien:
Het vervangt niet in elk geval ruwe loganalyse. Als je een specifieke Nginx-configuratie moet debuggen of IP-level botgedrag moet onderzoeken, heb je nog steeds de ruwe logs nodig. Maar voor de 90% van de gevallen waarin je gewoon wilt weten “crawlt Googlebot de juiste dingen?” — is het een stuk sneller dan Python-scripts schrijven.
Probeer SEOJuice gratis en koppel je site om crawler analytics in actie te zien. Geen creditcard nodig.
Je hoeft niet elke dag naar logs te staren. Hier is de maandelijkse routine die ik volg:
Totale tijd: 30-45 minuten. De ROI is buitenproportioneel groot.
Ik heb dit niet uitputtend getest in elke niche, maar er is geen harde ondergrens — het rendement schaalt mee met de sitegrootte. Onder de 100 pagina's crawlt Googlebot sowieso alles, en je zult waarschijnlijk geen crawl budget-problemen hebben. Tussen 500-5.000 pagina's begint het waardevol te worden. Boven de 10.000 pagina's is het essentieel — crawl budget verspilling is vrijwel gegarandeerd op sites van die omvang. Dat gezegd hebbende, zelfs een site van 200 pagina's kan er baat bij hebben als je indexeringsvertragingen of mysterieuze rankingdalingen ziet.
Ja. Google publiceert zijn IP-bereiken, en je kunt een reverse DNS-lookup doen op het verzoekende IP. Legitieme Googlebot-IP's resolven naar *.googlebot.com of *.google.com. In Python: import socket; socket.gethostbyaddr('66.249.79.45'). Elk IP dat niet naar een Google-domein resolvet is een neppe Googlebot — waarschijnlijk een scraper die Googlebot's user agent string gebruikt. Google's officiële documentatie raadt deze verificatiemethode aan.
Dat varieert enorm. Een gezaghebbende nieuwssite kan duizenden Googlebot-verzoeken per uur zien. Een kleine bedrijfssite misschien 50-200 per dag. De frequentie hangt af van het waargenomen belang van je site, hoe vaak je content verandert, de responssnelheid van je server en de versheid van je XML-sitemap. Volgens JetOctopus' crawlfrequentie-analyse uit 2024 over hun klantenbestand ligt de mediane crawlfrequentie voor een site met 5.000 pagina's op ruwweg 300-800 Googlebot-verzoeken per dag.
Blokkeer kwaadaardige bots op serverniveau (Nginx deny-regels of fail2ban), niet alleen in robots.txt. Robots.txt is een suggestie — kwaadaardige bots negeren het. Maar wees voorzichtig: blokkeer niet per ongeluk legitieme crawlers. Ik heb sites gezien die alle bots met “bot” in de user agent string blokkeerden, waardoor ze ook Googlebot pakten. Whitelist altijd Google, Bing en andere zoekmachines die je belangrijk vindt voordat je brede botblokkeerregels implementeert.
Logbestandanalyse is hoe je crawl budget meet. Google definieert crawl budget als de combinatie van crawl rate limit (hoe snel Google kan crawlen zonder je server te overbelasten) en crawl demand (hoeveel Google wil crawlen op basis van waargenomen waarde). Je kunt geen van beide direct controleren, maar je kunt ze beïnvloeden: snellere responstijden verhogen het crawl rate limit, en het verwijderen van pagina's met lage waarde uit Google's crawlwachtrij vergroot het aandeel crawl budget dat aan pagina's wordt besteed die ertoe doen. Logs tonen je beide kanten van deze vergelijking.
Logbestandanalyse is niet glamoureus. Het is grep en regex en tekstbestanden door scripts pipen. Er zijn geen mooie dashboards (tenzij je ze zelf bouwt). Maar het is het dichtst dat je kunt komen bij het zien van je site door Google's ogen. GSC toont je een samengesteld overzicht. Logs tonen je de ruwe waarheid.
Als je een site beheert met meer dan een paar honderd pagina's en je hebt nooit naar je serverlogs gekeken, heb je crawlproblemen waar je niets van weet. Ik zou er geld op durven zetten.
Verder lezen in de Technical SEO-silo:
no credit card required
No related articles found.