Google heeft recent meer helderheid gegeven over hoe Googlebot omgaat met grote bestanden. Dat is niet academische ruzie tussen ingenieurs: het bepaalt of belangrijke pagina’s en documenten worden opgepakt, of dat ze vroegtijdig worden afgebroken. Hieronder leg ik uit wat er is gezegd, waarom die limieten bestaan en welke praktische stappen je als ondernemer of marketeer moet nemen.
De harde grens? Niet zo hard als je denkt
Google’s infrastructuur heeft een standaardlimiet van 15 megabyte per fetch. Dat klinkt als een regel die voor iedereen geldt, maar Gary Illyes maakte duidelijk dat het een infrastructuurniveau‑instelling is die teams binnen Google kunnen overschrijven. Sterker: voor Google Search zelf staat die limiet vaak op twee megabyte. Met andere woorden: wat in de documentatie staat is een uitgangspunt, geen onveranderlijke wet.
Waarom zulke limits bestaan
De limieten zijn er niet om willekeurig te dwarsbomen, maar om de eigen infrastructuur te beschermen. Grote bestanden kosten tijd en rekenkracht om binnen te halen, te ontleden en te indexeren. Als Google zonder beperking hele gigabytes tegelijk zou binnenhalen, zou dat onnodig veel resources opslokken en vertragingen veroorzaken in de verwerkings‑ en indexeringspijplijn. Illyes benoemt dit als een bescherming voor zowel Google als de rest van het systeem.
Grote bestanden: PDFs en lange HTML‑bestanden
Voor bepaalde bestandstypen gelden andere, hogere limieten. PDFs kunnen bijvoorbeeld een veel hogere grens hebben — Illyes noemde voorbeelden rond de 64 tot 96 megabyte — omdat veel documenten simpelweg groter zijn. Omgekeerd is het onzinnig om een enorme enkele HTML‑file van 14 megabyte volledig te crawlen: moderne standaarden bevatten vaak onderdelen die als losse pagina’s beschikbaar zijn, waardoor Google nuttiger en efficiënter kan werken door die kleinere onderdelen te halen in plaats van één monoliet.
Googlebot is geen monoliet — het is meer een dienst
Martin Splitt benadrukte dat de crawl‑infrastructuur niet één vaste entiteit is. Zie het eerder als een service met parameters: verschillende clients (zoals websearch, afbeeldingen, PDF‑verwerking) roepen die service aan met verschillende instellingen. Die instellingen kunnen per request verschillen, en zelfs binnen Googlebot kunnen instellingen variëren afhankelijk van het doel van de fetch. Dat verklaart waarom in de praktijk voorkomen dat limieten worden aangepast op projectniveau.
Wat dit praktisch betekent voor jouw site
1) Meet echte fetch‑groottes. Controleer de on‑the‑wire grootte van je belangrijkste pagina’s en documenten, niet alleen de gecomprimeerde bestandsgrootte in je CMS. 2) Verplaats cruciale content naar de beginning‑of‑file: crawlers stoppen vaak nadat een limiet is bereikt, dus zorg dat de kerninformatie vroeg komt. 3) Splits monolieten. Als je één enkele, grote HTML‑pagina gebruikt voor veel content, overweeg segmentatie of paginering zodat elke fetch betekenisvolle, compacte inhoud oplevert. 4) Voor grote PDFs: maak een korte HTML‑samenvatting met de belangrijkste punten en metadata, zodat Google iets bruikbaars heeft als de PDF zelf niet volledig wordt binnengehaald. 5) Let op afbeeldingen en assets: grote, onnodige resources kun je lazy‑loaden of in meerdere kleinere bronnen aanbieden.
Wanneer kun je rekenen op een hogere limiet?
Binnen Google bestaan er situaties waarin teams de standaardlimiet verhogen — Illyes zegt expliciet dat dat gebeurt. Maar dat is geen garantie voor jouw site. Het gebeurt vooral bij toepassingen waarbij de inhoud een speciale verwerking nodig heeft en het voordeel opweegt tegen de extra kosten voor Google. Voor de meeste commerciële sites is het praktischer om de site zo te ontwerpen dat hij netjes binnen gangbare limieten valt.
Checklist: concrete stappen deze week
1) Scan je top‑100 pagina’s op fetch‑grootte en laadtijd. 2) Zorg dat belangrijkste tekst en structured data vroeg in de HTML staan. 3) Maak van grote documenten korte HTML‑samenvattingen en voeg duidelijke metadata toe. 4) Test of pagina’s die je belangrijk vindt daadwerkelijk indexeerbaar zijn met Google's URL Inspection in Search Console. 5) Documenteer uitzonderlijke gevallen (grote catalogi, datasets) zodat je bij een gesprek met een technisch contact of SEO‑specialist exact kunt aantonen waarom een uitzondering zinvol zou zijn.
Een nuchtere conclusie
De kern is praktisch: Google beschermt zijn infrastructuur met standaardlimieten, maar die grenzen zijn flexibel binnen hun organisatie en per use‑case. Voor jou betekent het dat techniek en informatiearchitectuur het verschil maken. Kleine aanpassingen — content vroeg in de file, splitsen van grote pagina’s, HTML‑samenvattingen voor zware documenten — leveren vaak meer effect dan proberen een uitzondering bij Google af te dwingen. Als je wilt, kijk ik graag met je mee naar de grootste pagina’s en documenten; soms is een uur werk aan structuur genoeg om indexatie en zichtbaarheid aanzienlijk te verbeteren.