Alle pagina’s van een website verkennen vereist het kiezen van de juiste methode uit een tiental beschikbare benaderingen. Sitemap XML, zoekoperatoren, SEO-crawlers, loganalyse: elke techniek dekt een ander bereik en laat verschillende blinde vlekken achter. Het gaat er niet om ze allemaal te kennen, maar om te begrijpen welke wat detecteert, en vooral wat ze mist.
JavaScript-rendering en crawl: wat elke robot daadwerkelijk ziet
De capaciteit van een tool om de pagina’s van een site te verkennen, hangt rechtstreeks af van de manier waarop deze omgaat met JavaScript. Googlebot rendert JavaScript sinds 2019 en heeft dus toegang tot de client-side gegenereerde inhoud. Daarentegen rendert generatieve AI-crawlers (GPTBot, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider) geen JavaScript: ze downloaden de JS-bestanden zonder ze uit te voeren.
Voor een site die is gebouwd als SPA (single-page application) of sterk afhankelijk is van client-side rendering, verandert dit alles. Dynamisch gegenereerde interne links blijven onzichtbaar voor deze robots. Een crawl met een tool die de JS niet rendert, zal dus een onvolledige lijst van URL’s opleveren, soms op significante wijze.
Een project voor volledige verkenning moet ook rekening houden met de HTML-grootte limiet van Googlebot, vastgesteld op 2 MB per URL. Boven deze limiet worden links onderaan de pagina simpelweg niet gelezen. Derde partijen die de pipeline van Googlebot nabootsen, erven deze beperking.
Voor degenen die op zoek zijn naar een concrete toegangspunt, is het mogelijk om de pagina’s van de Marcelllin-site te verkennen via zijn sitemap, wat goed illustreert hoe een gestructureerde XML-index werkt.
Vergelijking van methoden om alle pagina’s van een site te vinden
Elke methode voor het ontdekken van URL’s dekt een specifiek bereik. De onderstaande tabel vat de werkelijke capaciteiten van zes gangbare benaderingen samen.
| Methode | Geïndexeerde pagina’s | Geblokkeerde pagina’s (robots.txt) | JS-rendering | |
|---|---|---|---|---|
| Operator site: Google | Ja | Nee | Nee | Ja (via Google) |
| Sitemap XML | Ja (indien verklaard) | Nee | Mogelijk | Niet relevant |
| SEO-crawler (Screaming Frog, enz.) | Ja | Deels | Configureerbaar | Optioneel |
| Google Search Console | Ja | Nee | Nee | Ja |
| Serverloganalyse | Ja | Ja | Ja | Niet relevant |
| AI-crawlers (GPTBot, ClaudeBot) | Deels | Nee | Nee | Nee |
De conclusie die naar voren komt: geen enkele geïsoleerde methode dekt alle URL’s van een site. De operator site: van Google toont alleen de geïndexeerde pagina’s, en Google garandeert niet dat alle bekende URL’s worden weergegeven. De sitemap vermeldt alleen de URL’s die vrijwillig door de webmaster zijn verklaard. Alleen de serverloganalyse detecteert weespagina’s, omdat deze elke ontvangen HTTP-aanroep registreert, inclusief die van bots of oude externe links.
Sitemap XML en robots.txt-bestand: twee complementaire lezingen
Het robots.txt-bestand geeft robots aan wat ze niet moeten verkennen. Het raadplegen voordat je een crawl uitvoert, maakt het mogelijk om opzettelijk uitgesloten mappen te identificeren (beheerderspagina’s, staging-omgevingen, filter-URL’s). De sitemap XML biedt daarentegen de lijst van URL’s die de site geïndexeerd wil zien.
De combinatie van beide onthult vaak frequente inconsistenties: URL’s die in de sitemap staan maar door het robots.txt-bestand zijn geblokkeerd, of omgekeerd. Deze afwijkingen wijzen vaak op configuratiefouten die de SEO schaden.
SEO-crawler met JavaScript-rendering: het breedste bereik
Een SEO-crawler zoals Screaming Frog of Sitebulb, geconfigureerd met ingeschakelde JavaScript-rendering, biedt de meest uitgebreide dekking onder de tools die toegankelijk zijn zonder servertoegang. Het volgt interne links, voert de JS uit en kan de sitemap integreren als bron van start-URL’s.
- De crawl configureren zodat deze de sitemap XML als lijst van seed-URL’s opneemt, maakt het mogelijk om verklaarde maar niet intern gelinkte pagina’s te detecteren
- JavaScript-rendering inschakelen garandeert de ontdekking van dynamisch gegenereerde links, iets wat noch de sitemap, noch de operator site: doet
- De lijst van gecrawlde URL’s exporteren en vergelijken met de serverlogs over een bepaalde periode onthult weespagina’s die alleen door bots of via externe links zijn bezocht
Deze combinatie (JS-crawler + sitemap + logs) vormt het meest betrouwbare protocol voor het opstellen van een volledige inventaris van de URL’s van een site.
Weespagina’s en doodlopende pagina’s: de blinde vlekken van de interne linkstructuur
Een weespagina heeft geen interne links die naar haar verwijzen. Ze bestaat op de server, kan worden geïndexeerd als er een externe link naartoe leidt, maar blijft onzichtbaar voor een crawler die vanaf de homepage vertrekt. Serverlogs zijn de enige manier om deze te detecteren zonder de URL vooraf te kennen.
Doodlopende pagina’s vormen een symmetrisch probleem: ze bestaan in de structuur maar bevatten geen uitgaande links naar andere pagina’s van de site. Een bezoeker die daar terechtkomt, kan alleen de site verlaten. Voor zoekmachines verdunnen deze pagina’s het crawlbudget zonder autoriteit via interne links te herverdelen.
- Identificeer weespagina’s door logs/crawl te kruisen en verbind ze vervolgens met de interne linkstructuur of verwijder ze
- Herken doodlopende pagina’s door het ontbreken van uitgaande links in de export van de crawler
- Controleer of elke strategische pagina toegankelijk is in maximaal drie klikken vanaf de homepage
Een site met duizenden pagina’s accumuleert van nature deze anomalieën in de loop van herontwerpen en inhouds toevoegingen. Een kwartaal audit van de interne linkstructuur beperkt de technische schuld.
Structuur van de site en crawlbudget: wat zoekmachines prioriteren
Zoekmachines wijzen een beperkt aantal verzoeken per crawl-sessie toe aan elke site. Dit crawlbudget hangt af van de grootte van de site, de responstijd en de frequentie van updates. Een platte structuur, waarbij elke pagina toegankelijk is in enkele niveaus van diepte, vergemakkelijkt de snelle ontdekking van alle URL’s.
Geparametriseerde URL’s (filters, sorteringen, pagineringen) verbruiken crawlbudget zonder unieke inhoud te bieden. Deze blokkeren in het robots.txt-bestand of beheren via canonical-tags vermindert verspilling. Het robots.txt-bestand controleert de crawl, de canonical-tag controleert de indexering: beide werken op verschillende niveaus en vullen elkaar aan.
De architectuur van een site bepaalt ook de maximale diepte die crawlers kunnen bereiken. Boven de vijf niveaus van diepte neemt de kans dat een pagina tijdens een sessie wordt gecrawld sterk af. Het verminderen van de gemiddelde diepte blijft de meest directe structurele hefboom om de crawldekking te verbeteren.