Wat is crawlen in SEO? Hoe zoekbots uw site lezen

TL;DR: Een SEO-crawl is de ontdekkings- en downloadstap. Googlebot vindt een URL, haalt de content op en kan daarbij ook de JavaScript renderen. Crawlen garandeert echter geen indexering of rankings, dus bepaal eerst of de fout is ontstaan bij crawling, rendering, indexering of ranking voordat je je site aanpast.

De meeste crawl-problemen worden gediagnosticeerd vanaf de verkeerde kant. Een pagina ontbreekt in de zoekresultaten, iemand concludeert dat Google hem niet heeft gecrawld, en robots.txt wordt aangepast. Maar Google heeft de pagina mogelijk al opgehaald en besloten die niet te indexeren, een andere canonical gekozen, of geen reden gezien om hem te ranken voor de zoekopdracht die je controleert.

Crawl, render, index en rank zijn aparte “poorten”. Google plaatst rendering officieel binnen de crawlfase, maar door ze bij troubleshooting uit elkaar te houden, worden technische problemen veel makkelijker te lokaliseren.

Wat crawling in SEO in de praktijk betekent

Google Search Central definieert crawling nuchter:

“Crawling: Google downloadt tekst, afbeeldingen en video’s van pagina’s die het op internet heeft gevonden via geautomatiseerde programma’s, crawlers.”

Concreet betekent crawling: ontdekking plus ophalen (fetchen). Google leert dat een URL bestaat en vraagt de content op, zodat de pagina later verwerkt kan worden.

Het programma dat dit werk doet is Googlebot. Google beschrijft het als “ook bekend als een crawler, robot, bot of spider”. Die namen verwijzen naar hetzelfde algemene type software: een geautomatiseerd programma dat pagina’s opvraagt en links volgt om meer URL’s te ontdekken.

Googlebot “inspecteert” je site niet door visueel rond te klikken zoals een mens. Het vraagt HTML en ondersteunende resources op. Tijdens de crawlfase kan Google de pagina ook renderen met een recente versie van Chrome en het JavaScript uitvoeren. Dit is belangrijk als je relevante tekst, navigatie of interne links pas bestaan nadat scripts zijn gedraaid.

Een extra detail dat makkelijk wordt gemist: Googlebot is vooral mobiel. Google zegt: “Voor de meeste sites indexeert Google Search primair de mobiele versie van de content. Daardoor worden het merendeel van de Googlebot-crawlverzoeken gedaan met de mobile crawler en een minderheid met de desktop crawler.” Als belangrijke content op desktop wel aanwezig is maar op mobiel ontbreekt, kan geslaagde desktop-testing je een vals gevoel van zekerheid geven.

Ik ben eerder tijd kwijtgeraakt aan het oplossen van de verkeerde poort. Een URL die ontbreekt in de zoekresultaten bewijst niet dat de ontdekking is mislukt, en een extra crawlverzoek repareert geen duplicate of onhelpful content (een frustrerend vaak voorkomende categorie-mistake).

Crawl, render, index en rank zijn verschillende taken

1. Crawl: ontdekken en downloaden

Googlebot moet eerst weten dat een URL bestaat. Zodra een URL is ontdekt, probeert Google de rauwe HTML van de pagina en de benodigde resources op te halen. Een robots.txt-beperking, DNS- of netwerkfout, timeout of een servererror kan het proces hier al stoppen.

Een succesvolle fetch krijgt de URL door de eerste poort. Meer niet.

2. Render: de pagina uitvoeren

Google neemt rendering officieel op binnen crawling, maar het is de moeite waard om het apart te testen (niet als een vierde officiële fase, om precies te zijn). Google zegt dat Google tijdens het crawlen pagina’s rendert en JavaScript uitvoert met een recente versie van Chrome, vergelijkbaar met een normale browser.

Voor JavaScript-applicaties beschrijft Google de werkvolgorde als crawling, rendering en indexing. Pagina’s die een succesvolle response teruggeven kunnen in een renderqueue terechtkomen, waar headless Chromium hun JavaScript uitvoert. Google Search gebruikt een evergreen-versie van Chromium in plaats van een permanent bevroren browserversie.

Dat maakt een belangrijke diagnostische splitsing. Googlebot kan een HTTP 200-pagina fetchen, terwijl het nog steeds niet lukt om de uiteindelijke content te zien. Geblokkeerde resources, script errors, vertraagde client-side content of links die alleen verschijnen na interactie van de gebruiker kunnen ervoor zorgen dat het gerenderde resultaat onvolledig blijft.

3. Index: analyseren en opslaan

Google definieert indexering als het analyseren van de tekst, afbeeldingen en video’s van een pagina en het opslaan van informatie in de Google-index. Tijdens dit proces beoordeelt Google ook duplicaten en kiest het welke URL het als canonical beschouwt.

Een gecrawlde pagina wordt niet automatisch geïndexeerd. Een noindex-richtlijn kan uitsluiting afdwingen. Google kan daarnaast dunne of sterk gedupliceerde content weigeren te indexeren, of het kan de pagina samenvoegen onder een andere canonical-URL. Onze handleiding over hoe Google indexing werkt gaat hier dieper op in.

4. Rank en serve: antwoord geven op een zoekopdracht

Geïndexeerd betekent “in aanmerking komen om te verschijnen”. Het betekent niet dat je voor elke zoekopdracht zichtbaar bent of dat je gegarandeerd een bepaalde positie krijgt. Google moet nog steeds bepalen of de pagina bij de zoekopdracht past en waar die hoort tussen andere in aanmerking komende resultaten.

• Een URL kan ontdekt worden maar niet succesvol worden opgehaald.
• De URL kan worden opgehaald maar onjuist worden gerenderd.
• De URL kan worden gerenderd maar worden uitgesloten van de index.
• De URL kan worden geïndexeerd maar alsnog niet ranken voor de zoekopdracht die je controleert.

Google geeft site-eigenaren een nuttige reality check: “Google garandeert niet dat het je pagina zal crawlen, indexeren of serveren, zelfs niet als je pagina voldoet aan de Google Search Essentials.” Technische toegankelijkheid is noodzakelijk. Het is geen garantie op inclusie of zichtbaarheid.

Hoe Google pagina’s ontdekt

Google begint niet met een compleet overzicht van elke URL op het web. In de documentatie worden drie hoofd-routes voor ontdekking genoemd:

1. Bekende URL’s opnieuw bezoeken. Google gaat terug naar pagina’s die het eerder al heeft opgehaald.
2. Links volgen. Google haalt een link uit een bekende pagina en ontdekt waar die naartoe gaat.
3. Sitemaps lezen. Google verwerkt lijsten met URL’s die site-eigenaren indienen.

Daarom is interne linking infrastructuur en geen decoratie. Een pagina zonder interne links die naar die pagina verwijzen, is een orphan. Hij kan wel bestaan in het CMS en in de XML-sitemap staan, maar dan nog steeds losstaan van de routes die Googlebot normaal volgt.

De studie van Cyrus Shepard naar ongeveer 23 miljoen interne links over circa 1.800 sites vond een richtinggevende relatie tussen interne links en Google clicks: “URL’s met 0-4 interne links kregen gemiddeld 2 clicks vanuit Google Search, terwijl URL’s met 40-44 interne links er 4 keer zoveel kregen.” Dit was correlatief, geen bewijs dat links toevoegen het verkeer mechanisch vermenigvuldigt.

De studie vond ook dat het effect omkeert na ongeveer 45 tot 50 interne links. Meer is niet altijd beter. De bruikbare conclusie is dat belangrijke pagina’s meerdere relevante crawl-routes nodig hebben, niet dat elke pagina tientallen willekeurige links moet krijgen.

Wat we bij SEOJuice over sites heen zien, is dat orphan pages en zwakke interne routes veel vaker voorkomen dan echte crawl-capacity-problemen. De fix is meestal: verbind de pagina met relevante, al geïndexeerde content en houd die pagina in de sitemap. Een samenhangende structuur zoals content silos voor SEO geeft crawlers herhaalbare routes tussen gerelateerde pagina’s.

Ik behandelde sitemap-inclusie vroeger als sterker bewijs dan het in werkelijkheid is. Het bewijst dat een URL aan Google is aangeboden, niet dat Google hem heeft gecrawld of geïndexeerd (ik las het signaal te zwaar uit). Een sitemap helpt met ontdekking; het vervangt geen interne links en het dwingt geen uitkomst af.

Voor één nieuwe of geüpdatete URL biedt URL Inspection in Google Search Console ook een actie Request Indexing. Dat voegt een verzoek toe aan Google’s verwerkingsqueue. Het is een duwtje in de rug, geen opdracht.

robots.txt, noindex en nofollow doen verschillende dingen

robots.txt stuurt op fetchen

Een robots.txt-bestand vertelt toegankelijke crawlers welke URL-pad(en) ze mogen benaderen. Google zegt dat het vooral wordt gebruikt om te voorkomen dat crawlverzoeken een site overbelasten.

Het is geen betrouwbaar verwijderinstrument. Google’s robots.txt-documentatie stelt dat “Een pagina die is geblokkeerd in robots.txt alsnog geïndexeerd kan worden als er vanuit andere sites naar wordt gelinkt” en noemt het bestand expliciet “geen mechanisme om een webpagina buiten Google te houden.” Google kan weten dat een geblokkeerde URL bestaat zonder toestemming om de content op te halen.

Controleer elke brede regel voordat je publiceert. Een production Disallow: / bevat maar heel weinig tekst en kan de toegang van Googlebot tot de hele site blokkeren. De robots.txt generator kan helpen om een bestand op te stellen, maar de output moet nog steeds worden getest tegen je belangrijkste paden.

noindex stuurt op indexeringsgeschiktheid

Gebruik noindex wanneer Google een pagina wel kan crawlen maar niet mag bewaren in zoekresultaten. Blokkeer die URL niet ook in robots.txt. Google moet de pagina ophalen om de noindex-richtlijn te kunnen lezen.

Beide toepassen kan leiden tot het tegenovergestelde van de gewenste zekerheid. De crawlbeperking verhindert dat Google de index-instructie ziet, waardoor de geblokkeerde URL mogelijk toch bekend blijft via externe of interne links.

nofollow is een hint op linkniveau

Het nofollow-attribuut is geen pagina-brede crawlverbod. Google behandelt het als een hint, niet als een gegarandeerde blokkade. Het mag niet worden gebruikt om een URL te verbergen, om private content te beschermen of om uitsluiting uit de index zeker te stellen.

Faceted navigation is waar deze nette definities minder comfortabel worden. Er is geen universeel veilig robots.txt-patroon voor elke catalogus. Sommige gefilterde URL’s voldoen aan verschillende zoekopdrachten; andere maken in feite een oneindige combinatie. Eerst blokkeren en later de waarde in kaart brengen is riskant (en ja, dit is één van de plekken waar ik wantrouwig ben over “fixes” van één regel).

Waarschijnlijk heb je geen crawl-budgetprobleem

Crawl budget is de set URL’s die Google kan en wil crawlen. Google beschrijft twee onderdelen: de crawl capacity-limiet, waarbij parallelle verbindingen, responstijd en servergezondheid worden meegenomen; en crawl demand, die factoren zoals sitesize, updatefrequentie, kwaliteit, populariteit en veroudering weerspiegelt.

De term klinkt belangrijk genoeg om elke website-eigenaar zorgen te geven. Google’s drempels zeggen iets anders.

“Als je site niet een groot aantal pagina’s heeft die snel wijzigen, of als je pagina’s lijken te worden gecrawld op dezelfde dag dat ze worden gepubliceerd, dan hoef je deze handleiding niet te lezen.”

Google richt zijn crawl-budgetadvies vooral op sites met meer dan een miljoen unieke pagina’s die ongeveer wekelijks wijzigen, of op sites met meer dan 10.000 unieke pagina’s die dagelijks wijzigen. Voor de meeste kleinere sites is het onderhouden van de sitemap en het controleren van de indexeringsdekking voldoende.

Als je een bescheiden aantal URL’s publiceert en Google nieuwe pagina’s snel ophaalt, stop dan met proberen crawl budget te optimaliseren. Repareer gebroken ontdekking-routes, onbedoelde richtlijnen, renderingproblemen, servererrors of contentkwaliteit. Voor echt grote of sterk dynamische sites behandelt onze crawl budget optimalisatiehandleiding de lastigere gevallen.

Hoe je ziet wat Google crawlt

Begin met URL Inspection

Bij één ontbrekende pagina is URL Inspection in Google Search Console het snelste startpunt. Het kan de laatste crawldatum tonen, of crawling was toegestaan, de indexeringsstatus en de canonical die Google heeft gekozen.

Lees die velden als een volgorde. Als crawling was geblokkeerd: herstel de toegang. Als Google de URL wel heeft gecrawld maar heeft uitgesloten van de index, is een extra crawlverzoek meestal niet genoeg om het onderliggende probleem op te lossen.

Gebruik Crawl Stats voor patronen op siteschaal

Het rapport Crawl Stats laat Google’s crawlgeschiedenis zien, inclusief aantal verzoeken, totale downloadgrootte, gemiddelde responstijd, serverresponses, beschikbaarheidsproblemen, bestandstypen, crawldoel en type Googlebot.

Google noemt dit een geavanceerd rapport en zegt dat sites met minder dan 1.000 pagina’s het doorgaans niet nodig hebben. Dat is logisch. Ik bekijk het nog steeds na migraties of abrupte veranderingen op siteniveau, maar het is geen nuttig dagelijks scorebord (meer crawlen is niet automatisch beter).

Gebruik serverlogs voor exacte requests

Server access logs registreren requests die daadwerkelijk je infrastructuur hebben bereikt. Ze kunnen laten zien welke URL’s Googlebot ophaalt, hoe vaak het elk gedeelte bezoekt, en of parameters of “rommel”-URL’s aandacht krijgen terwijl waardevolle pagina’s zelden worden bezocht.

De user-agent strings van Googlebot bevatten Googlebot/2.1, maar de user-agent-tekst kan worden nagebootst. Voor betrouwbare identificatie kun je verdachte Googlebot-requests verifiëren via reverse en forward DNS, in plaats van alleen op de string te vertrouwen.

Voor de meeste sites is echte Googlebot-activiteit redelijk mild. Google zegt: “Voor de meeste sites zou Googlebot je site niet vaker dan gemiddeld eens per paar seconden moeten benaderen.”

Vijf SEO-crawl-fouten die je echt wilt oplossen

1. Orphan en near-orphan pagina’s

Een orphan heeft geen interne linkroute vanuit de rest van de site. Een near-orphan heeft mogelijk één obscure link vanuit een archief- of pagineringspagina die Google zelden opnieuw bezoekt. Voeg contextuele links toe vanuit relevante, al geïndexeerde pagina’s in plaats van te leunen op alleen een sitemap.

Dit is meestal het eerste structurele probleem dat ik controleer. De URL bestaat, dus het team gaat ervan uit dat de site hem goed ontsluit. Dat zijn niet dezelfde dingen.

2. Geblokkeerde JavaScript of CSS

Google rendert pagina’s met Chromium. Als robots.txt resources blokkeert die nodig zijn om content of navigatie zichtbaar te maken, kan de HTML-request wel slagen, terwijl de gerenderde pagina onvolledig blijft.

Vergelijk Google’s gerenderde output met wat gebruikers zien, vooral bij client-rendered applicaties waarbij de initiële HTML weinig inhoud bevat die echt iets voorstelt.

3. Oneindige crawl traps

Filters, sorteersparameters, agenda’s, zoekpagina’s en sessie-ID’s kunnen enorme aantallen combinaties opleveren met weinig waarde. Dit wordt een serieus crawl-probleem op grote sites.

Veelvoorkomende remedies zijn: duplicaten consolideren met canonicals, het beperken van crawlbare parametercombinaties en het blokkeren van passende patronen. Breng in kaart welke combinaties geïndexeerd verdienen voordat je ze beperkt; een algemene regel kan waardevolle categoriepagina’s ook blokkeren samen met de rommel.

4. Trage of onbetrouwbare servers

Google past crawl capacity aan op basis van servergezondheid. Aanhoudende timeouts, trage responses en 5xx-errors kunnen ervoor zorgen dat Google de crawl verlaagt. Crawl Stats kan geaggregeerde veranderingen in responstijd blootleggen, terwijl logs de templates en URL’s aanwijzen die het veroorzaken.

5. Onbedoelde blocks in productie

Controleer of er staging robots.txt-regels zijn uitgerold naar productie, sitebrede noindex-richtlijnen, geblokkeerde assets en CMS-instellingen die bedoeld waren om zoekmachines te ontmoedigen. Het zijn alledaagse fouten met gevolgen voor de hele site.

Tijdens onze migratie van seojuice.io naar seojuice.com in januari 2026 behandelden we discovery, fetching, canonical selection en indexering als losse checks. Een URL op de oude host die opnieuw gecrawld werd, bewees niet dat de vervanging op de nieuwe host was geïndexeerd, en een correcte redirect bewees niet dat Google zijn canonical al had omgezet. Door die scheiding bleven we de migratie niet reduceren tot een misleidende “Google ziet het”-checkbox.

We zijn met z’n tweeën, Lida en ik, dus de volgorde van diagnosticeren doet ertoe. We kunnen geen dagen besteden aan het polijsten van crawl-budget-theorieën terwijl een orphan page of een production noindex de daadwerkelijke schade aanricht.

Als die terugkerende issues lastig handmatig te monitoren zijn, SEOJuice heeft een gratis plan zonder dat je een creditcard nodig hebt. De automatisering kan relevante interne links toevoegen en de site-audit markeert robots.txt-blokkades, noindex-tags en geblokkeerde resources. Het kan specifieke on-site problemen oplossen of zichtbaar maken; het kan Google niet dwingen om sneller te crawlen, een pagina te indexeren of rankings toe te kennen.

Veelgestelde vragen

Wat is crawling in SEO?

Crawling in SEO is het proces waarmee bots van zoekmachines pagina’s ontdekken en downloaden. Googlebot vindt URL’s door bekende pagina’s opnieuw te bezoeken, links te volgen en sitemaps te lezen. Geslaagde crawling garandeert niet dat een pagina wordt geïndexeerd of gerankt.

Wat is het verschil tussen crawling en indexing?

Crawling betekent dat Google een pagina ophaalt. Indexing betekent dat Google de pagina analyseert, de canonical beoordeelt en mogelijk informatie over die pagina opslaat in de Google-index. Een pagina kan wel gecrawld maar niet geïndexeerd worden door noindex, duplicatie, contentkwaliteit of een canonical-keuze.

Wat is een web crawler, spider of bot?

Een web crawler is een geautomatiseerd programma dat URL’s bezoekt, content downloadt en links volgt om andere pagina’s te vinden. De crawler van Google is Googlebot. Crawler, spider, robot en bot zijn verschillende namen voor hetzelfde algemene type software.

Hoe vindt en crawlt Google mijn website?

Google bezoekt URL’s opnieuw die het al kent, volgt links vanuit bekende pagina’s naar nieuwe bestemmingen en leest ingediende XML-sitemaps. Interne links bieden directe ontdekking-routes, terwijl de sitemap een handige lijst met URL’s aanlevert die Google kan overwegen om te crawlen.

Stoppen robots.txt Google met crawlen of indexeren?

robots.txt beperkt crawling, niet indexing. Een geblokkeerde URL kan alsnog in Google verschijnen als hij wordt ontdekt via links. Om een crawlbare pagina buiten de index te houden, gebruik je noindex en voorkom je dat je tegelijkertijd Google verhindert de directive op te halen.

Hoe kan ik zien wat Google crawlt?

Gebruik URL Inspection voor de status van één URL, Crawl Stats voor patronen in requests en server voor de hele site, en server access logs voor de exacte URL’s die Googlebot heeft aangevraagd. Samen helpen die bronnen om een echte crawl-fout te onderscheiden van een later rendering- of indexeringsprobleem.