Google heeft de handleiding over crawl budget volledig herschreven. Negen van de tien wijzigingen zijn gewoon strakker geformuleerde zinnen — maar er staan nu een paar dingen zwart op wit die er eerst niet stonden. En één daarvan verklaart waarom nieuwe sites zo traag op gang komen in Google.
Eerst: waarom zou dit je boeien?
Crawl budget is de hoeveelheid tijd en verbindingen die Google aan het crawlen van jouw site besteedt. Google zegt zelf in de handleiding: heb je geen site met honderdduizenden pagina’s die dagelijks veranderen, dan hoef je hier niet wakker van te liggen. Klopt. Maar de principes erachter verklaren wél waarom sommige sites snel geïndexeerd worden en andere maandenlang genegeerd worden. Daarom lees je hem toch.
Dit staat er nu letterlijk in (en eerst niet)
1. Elke site begint met dezelfde lage limiet
“Every site starts with the same default, conservative crawl capacity limit.” Google begint dus bij iedereen voorzichtig, en verhoogt de limiet pas als er vraag is naar meer crawlen én je server het aankan. Dit is het eerlijkste antwoord dat Google ooit gaf op de vraag waarom een verse site zo langzaam geïndexeerd wordt: je moet je budget verdienen. Een nieuwe site met duizend pagina’s live zetten en verwachten dat Google ze deze week allemaal pakt — zo werkt het dus niet.
2. Waar de vraag van Googlebot van afhangt
Google noemt nu expliciet de vier factoren: de grootte van je site, hoe vaak hij verandert, de kwaliteit van je pagina’s en je relevantie vergeleken met andere sites. Die laatste is interessant: crawl budget is relatief. Google verdeelt beperkte machines over het hele web, dus jouw site concurreert om crawltijd met alle andere sites in jouw niche.
3. Crawlers eten van hetzelfde bord
“The crawl capacity limit is shared across all crawlers.” Googlebot, AdsBot en Google Shopping delen samen één limiet per site. Draai je veel dynamische advertenties of een grote merchant-feed, dan snoept AdsBot dus crawlcapaciteit weg die Googlebot ook had kunnen gebruiken. Stond er nooit zo helder in.
4. Snelheid en HTTP-caching zijn nu officieel advies
Nieuw in het lijstje best practices: maak je server sneller, en ondersteun 304-statuscodes. Die tweede is onderschat. Als een pagina niet veranderd is sinds Google’s vorige bezoek, zegt een 304 (Not Modified) tegen Google: gebruik je opgeslagen versie maar. Kost jouw server niets, en Google kan die tijd besteden aan pagina’s die wél veranderd zijn.
Wat wij er vandaag mee deden
Toevallig hebben we vandaag bij onze eigen site precies dit principe toegepast. Er stonden hier 998 artikelen, waarvan het merendeel oude, generieke content die in een half jaar welgeteld niets aan bezoekers opleverde. Google bleef die pagina’s wel gewoon crawlen — verspilde crawltijd die niet naar de pagina’s ging die ertoe doen. Dus: 895 artikelen eruit, nette 301’s erop, en de 103 pagina’s die wél iets doen krijgen nu alle aandacht. Dat is crawl budget-optimalisatie in de praktijk: niet meer laten crawlen, maar minder rommel aanbieden.
Moet jij nu iets doen?
Voor de meeste sites: nee, geen paniek. Wel drie dingen die altijd verstandig zijn:
- Ruim op wat niets doet. Pagina’s zonder bezoekers, dunne tags-pagina’s, oude testpagina’s: weg ermee (met een 301 of 410, niet via robots.txt — geblokkeerde URL’s blijven in de wachtrij hangen).
- Houd je sitemap vers en gebruik het lastmod-veld, zodat Google weet wat er echt veranderd is.
- Maak je server snel en check of je 304’s teruggeeft voor onveranderde pagina’s. Bij de meeste hosting en caching-plugins is dat een instelling, geen project.
De volledige herschreven handleiding staat bij Google zelf, inclusief changelog. Vragen over hoe dit voor jouw site zit? We kijken graag even mee in je Search Console.