Googlebot ontrafeld: hoe crawling, fetching en bytelimieten uw SEO beïnvloeden
Google heeft in een uitgebreide blogpost de interne werking van Googlebot toegelicht, met bijzondere aandacht voor de bytelimieten die bepalen hoeveel van uw pagina daadwerkelijk wordt opgehaald en geïndexeerd. De officiële limiet van 2MB per URL voor HTML-pagina's heeft directe gevolgen voor de indexering van content die verder in het document staat. Dit artikel biedt concrete handvatten voor marketeers en SEO-professionals om hun technische optimalisaties daarop af te stemmen.
Kernpunten
- Googlebot is geen enkel, afzonderlijk programma maar eerder een gebruiker van een gecentraliseerd crawlingplatform dat ook door tientallen andere Google-diensten zoals Shopping en AdSense wordt gebruikt.
- Voor HTML-pagina's geldt een fetchlimiet van 2MB per URL, inclusief de HTTP-headers, wat betekent dat alles na die grens volledig wordt genegeerd door de crawler en de indexeringssystemen.
- PDF-bestanden hebben een aparte, veel hogere limiet van 64MB, terwijl crawlers die geen specifieke limiet instellen standaard op 15MB worden ingesteld, ongeacht het contenttype.
- Alle externe resources die in een HTML-pagina worden gerefereerd, zoals JavaScript- en CSS-bestanden, worden apart opgehaald door de Web Rendering Service en hebben elk hun eigen, afzonderlijke bytenteller van 2MB.
- De Web Rendering Service (WRS) verwerkt JavaScript en client-side code op een manier vergelijkbaar met een moderne browser, maar opereert stateloos, wat betekent dat lokale opslag en sessiedata tussen verzoeken worden gewist.
- Google raadt aan om de meest kritieke HTML-elementen, zoals metatags, title-elementen, canonical-links en gestructureerde data, zo vroeg mogelijk in het HTML-document te plaatsen om te garanderen dat ze binnen de 2MB-grens vallen.
Analyse
Een van de meest opvallende onthullingen in dit blogbericht is dat Googlebot al lang geen enkelvoudig programma meer is, ondanks de historische naam die dateert uit de begindagen van Google. De crawler fungeert als een gemeenschappelijke infrastructuur die door talrijke Google-producten wordt gedeeld. Dit is relevant voor webmasters die in hun serverlogboeken verschillende user agents zien van Google en willen begrijpen welk systeem precies verantwoordelijk is voor bepaalde crawlactiviteit.
De 2MB-limiet is technisch gezien geen harde blokkade die ervoor zorgt dat een pagina wordt geweigerd, maar een zachte afkapgrens waarbij de crawler simpelweg stopt met downloaden. Het gedeelte dat is opgehaald, wordt vervolgens aan de indexeringssystemen doorgegeven alsof het het volledige bestand betreft. Dit klinkt minder ingrijpend dan het is, maar voor pagina's met veel inline CSS, inline base64-afbeeldingen of uitgebreide navigatiemenu's bovenaan het document, kan dit betekenen dat de eigenlijke pagina-inhoud nooit wordt bereikt door de crawler.
De samenwerking tussen de crawler en de Web Rendering Service verdient extra aandacht. Nadat Googlebot de bytes heeft opgehaald, neemt WRS het over om JavaScript uit te voeren en de uiteindelijke staat van de pagina te begrijpen. Echter, WRS kan alleen werken met de bytes die de crawler daadwerkelijk heeft opgehaald. Als een JavaScript-bestand zelf groter is dan 2MB, wordt ook dat bestand afgekapt, met mogelijke gevolgen voor de juiste weergave van dynamisch geladen content.
Het stateloze karakter van de Web Rendering Service heeft ook implicaties voor websites die zwaar leunen op JavaScript-frameworks die gebruikmaken van lokale opslag of sessiedata voor het tonen van content. Omdat WRS deze gegevens tussen verzoeken wist, zal elke pagina van nul af aan worden geïnterpreteerd, zonder de context die een terugkerende menselijke bezoeker zou meenemen. Dit kan leiden tot onvolledige weergave van gepersonaliseerde of sessie-afhankelijke content in de zoekindex.
Hoewel de 2MB-limiet voor de meeste websites geen dagelijks probleem vormt, aangezien een HTML-payload van 2MB uitzonderlijk groot is, zijn er specifieke scenario's waarbij dit wel degelijk relevant wordt. Denk aan e-commerceplatformen met uitgebreide productpagina's die grote hoeveelheden inline data bevatten, of websites die gestructureerde data laat in het document plaatsen. Voor deze gevallen is een proactieve technische audit noodzakelijk.
Wat te doen
- Verplaats zware CSS- en JavaScript-code naar externe bestanden in plaats van ze inline in het HTML-document op te nemen, zodat de 2MB van het HTML-document wordt benut voor daadwerkelijke inhoud en kritieke metadata.
- Controleer uw HTML-bronbestanden op de aanwezigheid van inline base64-afbeeldingen of grote datastructuren die vroeg in het document staan en onnodig bytes verbruiken vóór de eigenlijke paginacontent.
- Zorg ervoor dat essentiële SEO-elementen zoals de title-tag, canonicaltag, metatags en schema.org-gestructureerde data zo hoog mogelijk in de HTML-broncode staan, bij voorkeur in de head-sectie van het document.
- Monitor uw serverlogboeken regelmatig op response-tijden en crawlfrequentie. Als uw server te langzaam reageert, zal Googlebot automatisch minder frequent crawlen, wat een negatief effect heeft op de indexering van nieuwe of gewijzigde content.
- Voer periodiek een technische audit uit op de bestandsgrootte van uw HTML-pagina's en externe resources, en stel drempelwaarden in voor paginagewicht om te voorkomen dat pagina's de 2MB-grens naderen.
- Test pagina's die zwaar afhankelijk zijn van JavaScript-rendering op hun gedrag in een stateloze omgeving, en overweeg server-side rendering of statische generatie als alternatief voor content die absoluut correct geïndexeerd moet worden.
Als kritieke content zoals gestructureerde data, canonicaltags of essentiële tekstinhoud pas na de eerste 2MB van het HTML-document verschijnt, zal Googlebot deze simpelweg nooit zien en dus ook niet indexeren. Dit kan leiden tot ernstige indexeringsproblemen en verlies van zichtbaarheid in de zoekresultaten, zelfs voor pagina's die technisch gezien correct zijn opgebouwd.