Join our community of websites already using SEOJuice to automate the boring SEO work.
See what our customers say and learn about sustainable SEO that drives long-term growth.
Explore the blog →TL;DR. Googlebot is niet één bot maar een hele familie van crawlers, en Googlebot Smartphone doet sinds mobile-first indexing in 2023 vrijwel al het werk. De job verloopt in drie fasen (crawl, render, index) die uren of zelfs dagen uit elkaar kunnen liggen; de meeste klachten “Googlebot ziet mijn pagina niet” blijken in de renderfase te zitten. In de support-tickets die we bij SEOJuice tussen medio 2024 en begin 2026 behandelden, was circa 6 op de 10 escalaties rond indexering een renderprobleem; slechts 2 op de 10 hadden echt met de crawl-fase te maken (de rest kwam door noindex-tags of robots.txt-fouten). Deze gids bespreekt de bot-familie, de drie-fase-pipeline, hoe je een echte Googlebot-hit verifieert, de robots- en crawl-budget-vragen die iedereen stelt, en hoe Googlebot zich in 2026 verhoudt tot Bingbot, GPTBot, PerplexityBot en ClaudeBot.
Bijgewerkt mei 2026. Vernieuwd met proprietaire SEOJuice-ticketdata, een anekdote over een Cloudflare-bot-fight-outage en een verwijzing in de AI-crawler-sectie naar de eerder behandelde JS-renderfouten.
Ik schreef dit artikel omdat ik wekelijks drie of vier keer dezelfde uitleg in Intercom plak. De klant zegt: “Googlebot wordt geblokkeerd op mijn site.” We openen Search Console. De crawl-fase is prima. De render-fase klapte een week geleden om toen een ontwikkelaar een tab-panel-refactor pushte en niet merkte dat de artikeltekst pas na een klik wordt geladen. Ik wilde één URL die ik in het ticket kan plakken in plaats van telkens hetzelfde stuk te typen. Dit is die URL.
Googlebot is het programma waarmee Google webpagina’s ophaalt om ze in de Google-index te plaatsen. Publiceer je een nieuwe blogpost die later in de zoekresultaten verschijnt, dan begint die reis met Googlebot die de URL opvraagt, de HTML downloadt, de JavaScript uitvoert en het resultaat doorstuurt naar het indexeringssysteem van Google. Zonder Googlebot bestaan je pagina’s voor Google Search simpelweg niet.
Twee verduidelijkingen vooraf. “Googlebot” wordt soms losjes gebruikt voor “elke Google-crawler”. Strikt genomen is Googlebot de crawler die pagina’s voor de hoofdindex van Google Search ophaalt. Er zijn andere Google-crawlers (AdsBot voor landingspagina-kwaliteit, Storebot voor Shopping-listings, Google-Extended voor AI-opt-outs) met eigen regels en schema’s. Wees specifiek over welke je bedoelt als je debugt.
Googlebot is ook iets anders dan een scraper. Hij leest vóór elke crawl je robots.txt, respecteert noindex-metatags, tempert zichzelf als je server traag wordt en identificeert zich in de request-headers zodat je kunt verifiëren dat het echt Google is. Zie je in je logs een “Googlebot” die je origin bestookt zonder af te remmen, dan is het vrijwel zeker geen echte Googlebot. Verifieer voordat je gaat rate-limiten.
De bot waar je het meest rekening mee moet houden is Googlebot Smartphone, die sinds Google mobile-first indexing in 2023 afrondde standaard de mobiele versie van je site crawlt. Desktopcrawls gebeuren nog, maar zijn nu secundair. Dit is de familiestamboom met de exacte user-agentstrings die Google publiceert:
| Crawler | User-agent-string (uittreksel) | Functie |
|---|---|---|
| Googlebot Smartphone | Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X...) ... Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) | Primaire crawler voor de mobiele versie van je site. Stuurt de meeste indexering aan. |
| Googlebot Desktop | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36 | Crawlt desktopvarianten. Kleinere share van de totale crawltraffic sinds mobile-first. |
| Googlebot Image | Googlebot-Image/1.0 | Haalt afbeeldingen op voor Google Images. Andere bot, andere regels. |
| Googlebot Video | Googlebot-Video/1.0 | Haalt videobestanden op voor Google Videos. |
| Googlebot News | Geen aparte UA — gebruikt diverse Googlebot-strings | Crawlt voor Google News. Identificatie vereist IP-check i.p.v. UA. |
| Google-InspectionTool | Mozilla/5.0 (compatible; Google-InspectionTool/1.0;) | Wordt getriggerd wanneer je de URL-inspectie in Search Console gebruikt. Omzeilt deels caching. |
De placeholder W.X.Y.Z in de Smartphone- en Desktop-UA’s is niet letterlijk. Google vult de actuele Chromium-versie in en houdt die bij de stabiele Chrome-release. Op dit moment ligt de rendering-engine van Googlebot hooguit een paar weken achter op publieke Chrome. (Jarenlang zei ik tegen klanten dat Googlebot renderde alsof het Chrome 41 was; dat klopte tot de evergreen-update van 2019. Tot ver in 2021 gaf ik die verouderde tip, tot een talk van Martin Splitt me dwong de huidige docs te lezen.) Gebruikt je site een JS-feature die Chrome 130+ vereist, dan ondersteunt Googlebot die waarschijnlijk. Iets dat nog niet in Chrome zit, ondersteunt Googlebot niet.
Googlebot werkt in drie aparte fasen. Ze gebeuren niet tegelijk en een vertraging of fout in één fase kan je pagina uit de zoekresultaten houden. Google’s eigen documentatie vat het helder samen: “Google verwerkt JavaScript-webapps in drie hoofdfasen: 1. Crawlen 2. Renderen 3. Indexeren.” Kun je niet benoemen in welke fase een probleem zit, dan gok je naar de oplossing. Dat is precies de cruciale scheiding waarvoor dit artikel bestaat.
Googlebot pakt een URL uit de queue, stuurt een HTTP-request en ontvangt de ruwe HTML-response. That’s it. Er draait nog geen JavaScript. De crawler leest de statuscode, headers (waaronder cache-headers en X-Robots-Tag) en de ruwe body. URLs komen uit XML-sitemaps, interne links van al geïndexeerde pagina’s, externe links en rechtstreekse submit via de URL-inspectie.
Bevat je ruwe HTML al alle content die geïndexeerd moet worden (klassieke SSR), dan kan Googlebot door. Staat je HTML bijna leeg en vult JS de content later in, dan gaat de pagina naar de renderfase. Hier leest Googlebot ook robots.txt. Is een URL disallowed, dan wordt hij niet eens opgehaald.
Moet er JavaScript draaien om content te tonen, dan geeft Googlebot de URL aan de Web Rendering Service (WRS). De WRS is een headless Chromium die de pagina laadt, scripts uitvoert en de uiteindelijke HTML oplevert. Google zegt letterlijk: “Zodra Google-resources het toelaten, rendert een headless Chromium de pagina en voert de JavaScript uit.”
Die woorden “zodra Google-resources het toelaten” doen veel werk. Renderen is duur, dus Google batcht het in een queue. Een pagina kan seconden, uren of in het slechtste geval dagen in de wachtrij staan. (Ik heb een screenshot uit 2024 met 96 uur tussen crawl en render op een Next.js-shop. Die pin ik in Slack om elke paar maanden dezelfde discussie te winnen.) De officiële richtlijn blijft vaag: “De pagina kan enkele seconden in deze wachtrij staan, maar het kan langer duren.” Hoe de queue prioriteert blijft onduidelijk; near-identieke sites krijgen soms render na 5 minuten versus 36 uur.
Die renderdelay is het terugkerende probleem bij JS-sites. Je blogpost wordt binnen minuten gecrawld maar pas 24 uur later gerenderd, dus verschijnt hij een dag later in Search. Puur server-side gerenderde pagina’s slaan deze queue over.
Heeft Googlebot de definitieve HTML (direct of via WRS), dan parseert het indexeringssysteem het document, extraheert tekst, classificeert de content, beoordeelt rankingsignalen en slaat alles op in de index. Vanaf hier kan de pagina ranken. Ook indexeren is niet instant, maar Googlebot is klaar; de ranking-algoritmen nemen het over.
Hier gaat het stuk. Crawlen lukt bijna altijd; de pagina rendert alleen niet zoals verwacht. De zes faalmodi hieronder zie ik het vaakst bij SEOJuice-klanten, grofweg in afnemende frequentie — nummer 1 en 2 zijn meer dan de helft van alle render-escalaties, volgens de ticket-sample uit de TL;DR.
Moet je op een “Show More”-knop klikken om een sectie te tonen, dan ziet Googlebot die content niet. WRS klikt niet en scrolt niet. Alles wat belangrijk is hoort bij load in de DOM te staan, desnoods verborgen met CSS. Dit is de nummer-één-renderfout, vooral bij componentbibliotheken die tabpanel-, accordion- of “load more”-feeds lazy-mounten.
Lazy-loaded afbeeldingen en blokken hebben native loading="lazy" of een Intersection Observer nodig die WRS kan resolven. Bibliotheken die wachten op scroll-events falen vaak omdat WRS niet scrolt. Gebruik loading="lazy" voor afbeeldingen; render componenten server-side of met een framework dat goede SSR/hydration biedt.
Gooi je een uncaught exception, dan stopt de rest van de scripts en blijft de pagina leeg. WRS ziet wat vóór de fout gerenderd is. Gebruik de URL-inspectie (“Geteste pagina weergeven”) om precies te zien wat Googlebot zag, inclusief HTML en screenshot.
CAPTCHAs, een te agressieve Cloudflare Bot Fight Mode en naïeve geo-blocking geven Googlebot 403 of een challenge. (Cloudflare’s standaard Bot Fight Mode heeft meer sites gebeten dan welke setting dan ook — een B2B-SaaS verloor tweederde van z’n geïndexeerde pagina’s in één weekend eind 2024 toen een stagiair ’m aanzette. Herstel kostte drie weken.) Whitelist altijd de officiële Google-IP-ranges (googlebot.json) voor je bots blokkeert. Verifieer elke WAF-wijziging met de URL-inspectie.
Blokkeer je /static/ of /assets/, dan kan WRS JS- en CSS-bundles niet ophalen en rendert je pagina zonder styles of met kapotte JS. Sta Googlebot toe om statische assets te crawlen.
Googlebot logt niet in, accepteert cookies nauwelijks en heeft geen sessie. Alles achter een login wordt niet geïndexeerd. Gebruik de Indexing API of structured data voor betaalmuren en maak duidelijk wat afgeschermd is.
De SEO-community discussieerde 2017–2020 of Googlebot ooit modern Chrome zou inhalen. Die discussie is klaar — sinds de evergreen-switch van 2019 loopt hij mee — maar veel adviezen dateren van vóór die switch, waardoor punt 1 en 2 blijven opduiken.
De user-agent is makkelijk te spoofen. Echte Googlebot-requests komen uit Google-IP-ranges. De betrouwbare methode is reverse DNS gevolgd door forward DNS. In het kort:
.googlebot.com of .google.com.Op de command-line: host 66.249.66.1 en daarna host crawl-66-249-66-1.googlebot.com. Automatiseer dit in je logpipeline; vaak blijkt een “Googlebot-spike” gewoon een scraper met die UA. Ahrefs heeft een goede walkthrough met curl-voorbeelden.
Google noemt dit het crawl-budget. Onder ~10.000 URL’s is het zelden een beperking. Pas bij miljoenen URL’s, gefacetteerde zoek-e-commerce of veel duplicaten speelt het. Google publiceert twee factoren: crawl-rate (hoe snel je server 200’s geeft) en crawl-demand (populariteit en update-frequentie). Semrush’ Googlebot-uitleg heeft een goede breakdown.
Ja, als ze het crawl-budget van een grote site opeten. Blokkeer faceted search-URL’s, interne zoekresultaten, paginatie na pagina 5, sessie-ID-varianten en admin-endpoints. Gebruik robots.txt om crawling te blokkeren en noindex voor index-blokkade. Robots voorkomt de crawl; noindex laat crawlen maar voorkomt indexatie.
Submit via URL-inspectie in Search Console. Dit triggert een out-of-band crawl (Google-InspectionTool) en is sneller dan wachten. Link ook vanaf een al geïndexeerde high-authority pagina.
Omdat er ergens een publieke link naar staging of dev is gelekt. Blokkeer het hele domein in robots.txt met Disallow: / en zet basic auth aan als het gevoelig is.
Systematisch debuggen bestaat uit vier checks op volgorde, tot er één een duidelijk antwoord geeft.
Check 1, URL-inspectie in Search Console. Plak de URL. Je ziet of Google heeft gecrawld en geïndexeerd, wanneer voor ’t laatst, en “Geteste pagina weergeven”. Mist de content in de gerenderde HTML, dan zit het probleem in de renderfase. Bij een non-200 status in de crawl-fase. Deze check lost twee derde van onze tickets op.
Check 2, curl met Googlebot-UA. curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://jouwsite.com/pad. Geeft je server andere content aan Googlebot dan aan een browser? Dan zie je het hier. Cloaking (expres of per ongeluk) is een klassieke oorzaak.
Check 3, robots.txt en metatag-audit. Ga naar https://jouwsite.com/robots.txt. Controleer of de URL niet geblokkeerd is. Bekijk de pagesource en zoek noindex. Verbazingwekkend vaak is dit de boosdoener.
Check 4, serverlogs. Filter op geverifieerde Googlebot-hits van de laatste 30 dagen. Verschijnt de URL nooit, dan is het een discoverability-probleem. Voeg hem toe aan je sitemap en link er naartoe. Verschijnt hij wel maar geeft hij 4xx/5xx, los dat op. SEOJuice draait deze loganalyse standaard en alarmeert zodra een key-URL niet meer in echte Googlebot-traffic opduikt.
Googlebot was ooit de enige crawler waar men aan dacht; dat is veranderd. Zo vergelijken de grote crawlers zich in 2026:
| Crawler | Operator | Render JS? | Doel |
|---|---|---|---|
| Googlebot | Ja (recente Chromium) | Google Search index | |
| Bingbot | Microsoft | Ja (Edge / Chromium) | Bing Search, Copilot grounding |
| GPTBot | OpenAI | Beperkt / geen SPA | ChatGPT-training |
| OAI-SearchBot | OpenAI | Beperkt | ChatGPT-search retrieval |
| PerplexityBot | Perplexity | Beperkt | Perplexity-answers |
| ClaudeBot | Anthropic | Beperkt | Claude-training & retrieval |
| Google-Extended | N.v.t. (read-only-signaal) | Opt-out-vlag voor Gemini-training |
Let op: faalmodi 1, 2 en 5 uit de JS-renderlijst — user-interaction-gating, lazy-load-signalen en geblokkeerde assets — raken AI-crawlers harder dan Googlebot doordat hun renderers zwakker zijn. Dezelfde checklist werkt voor een Perplexity-probleem; de inzet is alleen lager in AI-search dan in Google Search. (Ik ging er te lang vanuit dat PerplexityBot zich gedroeg als Googlebot. Pas toen een klant met SSR-site 4× beter scoorde dan een CSR-concurrent in Perplexity-citations ben ik het gaan testen.)
Twee praktische conclusies. AI-crawlers renderen JavaScript zwakker dan Googlebot. Is je content client-side gerenderd, dan kun je prima ranken in Google maar onzichtbaar zijn voor ChatGPT, Perplexity en Claude. De fix is dezelfde: server-side render of pre-render je cruciale content. Onze gratis AI-visibility-checker laat in een minuut zien of de grote AI-engines je content wel zien. Verder heeft elke AI-crawler eigen robots.txt-regels. User-agent: GPTBot blokkeert OpenAI, User-agent: Google-Extended blokkeert Gemini-training. User-agent: Googlebot regelt nog steeds de zoekcrawler. Wil je wel in Google Search maar niet in AI-training, stel de regels apart in.
“Wat men vaak mist aan Googlebot is dat crawlen en renderen niet dezelfde stap zijn. Een URL kan gecrawld zijn maar pas uren later gerenderd.” — Martin Splitt, Google Search Relations, parafrase uit Search Off the Record.
Googlebot is de webcrawler waarmee Google pagina’s ontdekt en downloadt om ze te indexeren en te tonen in zoekresultaten. Het is eigenlijk een familie (Smartphone, Desktop, Image, Video, News) met verschillende user-agents, maar meestal bedoelt men Googlebot Smartphone, de primaire crawler sinds mobile-first indexing in 2023.
Ja. De Web Rendering Service is een headless Chromium die JS draait op pagina’s die dat nodig hebben. De Chromium-versie volgt stabiele Chrome, dus moderne JS werkt doorgaans. De catch is de renderqueue: die kan seconden tot dagen duren. Server-side gerenderde pagina’s slaan die wachtrij over.
Reverse DNS op het IP: hostnaam moet eindigen op .googlebot.com of .google.com. Daarna forward DNS terug naar hetzelfde IP. Faalt één stap, dan is het spoof. De user-agent alleen bewijst niets.
Ja. Zet User-agent: Googlebot gevolgd door Disallow: / in robots.txt. Dit blokkeert crawlen en dus indexatie. Wil je fijner afzetten, gebruik noindex-meta’s of specifieker robots-pad. Blokkeer CSS/JS-bundles niet; die heeft de renderer nodig.
Nee. Ze worden door andere bedrijven beheerd voor andere doelen. Googlebot indexeert voor Google Search. GPTBot verzamelt trainingsdata voor ChatGPT. PerplexityBot haalt content voor Perplexity. Ze hebben elk hun eigen user-agent en robots.txt-regels. Je kunt Googlebot toestaan en GPTBot blokkeren of andersom.
Meest voorkomend: de pagina is niet gelinkt vanaf een geïndexeerde URL, geeft geen 200-status, heeft een noindex, is geblokkeerd in robots.txt of hangt af van JS dat nog niet gerenderd is. Gebruik URL-inspectie; “Geteste pagina weergeven” toont exact wat Googlebot zag. Nieuwe pagina’s worden meestal binnen uren tot dagen geïndexeerd; langer bij lage crawl-frequentie.
De praktijk, als stelling: als je content JS-afhankelijk is en je health-check enkel “rankt het in Google Search?” luidt, optimaliseer je voor de sterkste renderer en negeer je de rest. AI-crawlers zijn zwakker en hun aandeel in referrals groeit elk kwartaal. Server-side rendering is geen Google-optimalisatie meer maar een AI-visibility-vereiste. Dat is de belangrijkste takeaway.
Wil je snel weten welke crawlers je site echt zien, onze gratis AI-visibility-checker rendert je URL onder dezelfde beperkingen als Googlebot, GPTBot, PerplexityBot en ClaudeBot en toont welke crawler een lege pagina leest. Bij de meeste sites blijkt minstens één cruciaal template (vaak product of blog) leeg voor Perplexity maar oké voor Google.
Wat ik nog probeer te ontrafelen: de logica achter de renderqueue-prioriteit. De docs zeggen resource-afhankelijk, maar de variatie tussen bijna identieke sites doet vermoeden dat er meer meespeelt. Heb je een clean before/after-dataset, laat het weten.
Gerelateerd:
no credit card required
No related articles found.