Crawlbudget bij grote webshops: wanneer het speelt en wat je doet

Crawlbudget is het aantal URL's dat Googlebot op je site wil en kan crawlen in een bepaalde periode. Voor de meeste webshops met een paar duizend producten is het geen probleem. Het gaat spelen zodra filters, sorteringen en parameters een veelvoud aan URL's genereren, of zodra je server traag reageert, en dan zie je nieuwe producten en prijswijzigingen pas laat in Google terug.

Wat Google onder crawlbudget verstaat

Google beschrijft crawlbudget als de combinatie van twee dingen:

• Crawlcapaciteit. Hoeveel verzoeken Googlebot tegelijk en achter elkaar kan doen zonder je server te overbelasten. Reageert je server snel en foutloos, dan gaat de capaciteit omhoog. Komen er trage responses of 5xx-fouten, dan remt Googlebot af.
• Crawlvraag. Hoeveel Google je URL's wil crawlen. Dat hangt af van hoe populair pagina's zijn, hoe vaak ze veranderen en hoeveel URL's Google van je kent.

Het crawlbudget is wat er overblijft als je die twee combineert. Je kunt het niet instellen. Je kunt het wel verspillen.

Wanneer speelt het echt?

Google zegt zelf dat crawlbudget vooral relevant is voor:

• Zeer grote sites, in de orde van een miljoen of meer pagina's, met content die regelmatig verandert.
• Middelgrote sites, vanaf zo'n tienduizend pagina's, met content die dagelijks verandert.
• Sites met een groot deel van hun URL's in de status "Gevonden - momenteel niet geïndexeerd" in Search Console.

Die getallen gaan over URL's die Google kent, niet over je aantal producten. En daar zit de valkuil voor webshops. Een catalogus van 5.000 producten kan met layered navigation makkelijk honderdduizenden crawlbare URL's opleveren.

Een rekenvoorbeeld. Een categorie heeft vijf filters: merk (20 opties), kleur (12), maat (10), prijs (6 ranges) en materiaal (8). Combineer je die met elkaar, met drie sorteringen en een paar paginagroottes, dan loopt het aantal unieke URL's voor één categorie al snel in de tienduizenden. Vermenigvuldig dat met honderd categorieën.

De eerlijke versie: heb je een shop met 2.000 producten, een snelle server en filters die niet crawlbaar zijn, dan heb je geen crawlbudgetprobleem. Dan liggen je kansen elders, bijvoorbeeld in contentkwaliteit of interne links.

Symptomen van een crawlbudgetprobleem

Je herkent het aan een combinatie van deze signalen:

• Nieuwe producten worden traag geïndexeerd. Dagen tot weken na publicatie staan ze nog niet in Google.
• Prijs- of voorraadwijzigingen lopen achter in de zoekresultaten en in je rich results.
• "Gevonden - momenteel niet geïndexeerd" groeit in het Pagina's-rapport, vooral bij product-URL's.
• Crawlstatistieken tonen veel verzoeken naar parameter-URL's, terwijl belangrijke categorieën weinig bezoek krijgen.
• De gemiddelde reactietijd in Crawlstatistieken stijgt en het aantal crawlverzoeken daalt mee.

Een uitgebreide uitleg over die indexeringsstatus staat in Gevonden, maar niet geïndexeerd oplossen.

Meten: Crawlstatistieken en serverlogs

Crawlstatistieken in Search Console (onder Instellingen) geven een eerste beeld. Je ziet het aantal verzoeken per dag, de reactietijd, de verdeling per statuscode en voorbeeld-URL's. Het blijft een steekproef.

Voor een volledig beeld heb je je access logs nodig. Filter op verzoeken van Googlebot (en verifieer die via reverse DNS, want user agents zijn te vervalsen). Groepeer daarna per URL-patroon:

/products/*            → 18%
/collections/*         → 9%
/collections/*?filter* → 52%
/search?q=*            → 11%
overig                 → 10%

Dit zijn illustratieve getallen, geen benchmark. Het patroon is wel herkenbaar: als de helft van de crawlverzoeken naar filtercombinaties gaat die je niet geïndexeerd wilt hebben, weet je waar je moet ingrijpen. Hoe je zo'n analyse opzet, lees je in logfile-analyse voor webshops.

Wat je doet: de maatregelen op volgorde van impact

1. Houd onnodige URL's uit de crawl

Dit levert het meeste op. De belangrijkste bron van verspilling bij webshops is faceted navigation. Google adviseert zelf om filter-URL's die je niet geïndexeerd wilt hebben, via robots.txt te blokkeren.

Voorbeeld voor Magento 2, afhankelijk van welke filters je wél wilt laten indexeren:

User-agent: *
Disallow: /catalogsearch/
Disallow: /*?*product_list_order=
Disallow: /*?*product_list_limit=
Disallow: /*?*product_list_mode=
Disallow: /*?*price=
Disallow: /*?*color=
Disallow: /checkout/
Disallow: /customer/

Shopify blokkeert in de standaard robots.txt al een deel, zoals sorteringen, gecombineerde tags in collecties, de zoekpagina en checkout. Wil je meer blokkeren, zoals specifieke filterparameters, dan pas je dat aan via robots.txt.liquid.

Twee waarschuwingen:

• Blokkeer geen URL's die je wilt laten ranken. Heb je bewust een SEO-landingspagina voor "zwarte sneakers" als filtercombinatie, dan moet die crawlbaar blijven. Liever nog: maak er een echte categoriepagina van.
• Een URL geblokkeerd in robots.txt kan nog steeds geïndexeerd worden, zonder content, als er genoeg links naar wijzen. Dat is meestal geen ramp, maar houd het in de gaten.

Meer over het kiezen welke filters je indexeert en welke niet, op onze pagina over categoriepagina's en faceted navigation.

2. Laat je interne links niet naar ruis wijzen

Robots.txt is de rem. Beter is voorkomen dat Googlebot de URL's überhaupt vindt.

• Filters zonder crawlbare links. Bouw filteropties zo dat ze niet als gewone naar elke combinatie linken, of dat alleen geselecteerde filters dat doen. Let op: dit is een bewuste keuze. Wat Google niet via een link vindt, wordt ook niet gecrawld.
• Geen interne links naar redirects. Elke link naar een 301 kost een extra verzoek. Na een migratie of URL-wijziging moeten menu's, breadcrumbs en contentlinks naar de nieuwe URL wijzen.
• Geen links naar 404's. Verwijderde producten die nog in "gerelateerde producten" of oude blogposts staan.
• Sessie-ID's en trackingparameters horen niet in interne links.

Wat hosting en caching betekenen voor de snelheid van een Magento-shop lees je op Magento hosting.

4. Ruim duplicaten en dunne pagina's op

• Canonicals helpen Google de juiste versie te kiezen. Ze besparen weinig crawlbudget: Google moet de pagina eerst crawlen om de canonical te zien.
• Noindex werkt hetzelfde. Google moet de pagina crawlen om de noindex te lezen. Op termijn crawlt Google noindex-pagina's minder vaak, maar het is geen crawlbudgetmaatregel.
• Verwijderde producten zonder opvolger geef je een 404 of 410. Een 410 is iets explicieter. Een soft 404 (pagina met status 200 en "product niet gevonden") is het slechtste van twee werelden.

5. Gebruik sitemaps als prioriteitslijst

Een XML-sitemap garandeert geen crawl, maar helpt Google de URL's te vinden die jij belangrijk vindt.

• Alleen indexeerbare URL's met status 200. Geen redirects, geen noindex, geen canonicals naar andere URL's.
• Een correcte lastmod. Google gebruikt lastmod als het consistent en betrouwbaar is. Zet het niet bij elke cronjob op vandaag; dan leert Google het te negeren.
• Splits per type: producten, categorieën, content. Dan zie je in Search Console per groep hoeveel er geïndexeerd is.

Wat niet (meer) werkt

• De crawlsnelheid instellen in Search Console. Die instelling is begin 2024 verwijderd. Wil je Googlebot tijdelijk afremmen, bijvoorbeeld bij serverproblemen, dan kun je tijdelijk 503 of 429 teruggeven. Doe dat niet langer dan een paar dagen, anders kunnen URL's uit de index vallen.
• Noindex in robots.txt. Wordt sinds 2019 niet meer ondersteund.
• De priority- en changefreq-velden in sitemaps. Google negeert ze.
• Het URL-parameterhulpmiddel in Search Console. Ook verdwenen, sinds 2022. Parameterbeheer doe je nu via robots.txt, interne links en canonicals.

Specifiek voor Magento 2

Magento genereert standaard meer URL's dan nodig. De bekende bronnen:

• "Use Categories Path for Product URLs" aan betekent dat een product onder elke categorie een eigen URL krijgt. Met de canonical-instelling voor producten aan wijzen ze wel naar één versie, maar Google moet ze allemaal crawlen. Zet dit uit tenzij je een goede reden hebt.
• Layered navigation maakt filter-URL's met parameters. Bepaal per attribuut of het crawlbaar moet zijn.
• Toolbarparameters voor sortering, aantal per pagina en weergave (product_list_order, product_list_limit, product_list_mode) leveren geen unieke content op.
• De URL rewrites-tabel kan na jaren van importeren en hernoemen enorm groeien, met oude rewrites die nog intern gelinkt worden.

In onze Magento 2 SEO-instellingen checklist staan deze instellingen op een rij. Bredere context vind je op onze pagina over technische SEO voor webshops.

Veelgestelde vragen

Vanaf hoeveel producten moet ik me zorgen maken over crawlbudget?

Het gaat niet om producten maar om crawlbare URL's. Google noemt grote sites vanaf ongeveer een miljoen pagina's en middelgrote sites vanaf ongeveer tienduizend pagina's die dagelijks veranderen. Een webshop met veel filtercombinaties kan die grens bereiken met een bescheiden catalogus.

Bespaart een canonical tag crawlbudget?

Nauwelijks. Google moet een pagina eerst crawlen om de canonical te lezen. Een canonical helpt bij het kiezen van de juiste versie voor de index, niet bij het verminderen van crawlverzoeken. Daarvoor gebruik je robots.txt en schonere interne links.

Kan ik Google vragen sneller te crawlen?

Niet direct. Je vergroot de crawlcapaciteit met een snelle, stabiele server, en de crawlvraag met goede interne links, actuele sitemaps en pagina's die waarde hebben. Indexering aanvragen via URL-inspectie kan voor losse URL's.

Moet ik filter-URL's blokkeren in robots.txt of noindex geven?

Wil je ze niet in de index en wil je ook geen crawlbudget eraan kwijt, dan is robots.txt de aangewezen route. Noindex werkt alleen als Google de pagina kan crawlen. Combineer ze niet op dezelfde URL: een geblokkeerde URL kan Google niet lezen, dus de noindex ziet het nooit.

Telt crawlbudget ook voor AI-crawlers?

Elke crawler heeft zijn eigen gedrag. Voor Google Search en AI Overviews telt Googlebot. AI-crawlers zoals GPTBot of PerplexityBot belasten je server ook, maar vallen buiten het crawlbudget van Google. Die beheer je apart in robots.txt.