Googlebot en de 2 MB-limiet: wat betekent dit voor SEO?

Googlebot verwerkt voor Google Search alleen de eerste 2 MB van ondersteunde bestandstypen per individuele URL. Is je HTML-response groter, dan kan Googlebot de fetch afkappen. Dat is geen automatische rankingstraf, maar content, links en technische signalen die pas na die grens staan, kunnen buiten beeld blijven. Vooral grote HTML-pagina's met veel inline code, base64-data of complexe page builders verdienen daarom een controle.

Wat is de Googlebot-responslimiet van 2 MB?

De limiet geldt voor de hoeveelheid ongecomprimeerde data die Googlebot voor Google Search verwerkt bij ondersteunde bestandstypen. Een server mag een response dus gecomprimeerd versturen, bijvoorbeeld met gzip of Brotli, maar voor deze limiet is de uitgepakte omvang relevant.

Belangrijk: dit is een limiet per URL of resource, niet voor je hele website. Googlebot haalt HTML, CSS, JavaScript, afbeeldingen en andere bestanden afzonderlijk op. Een grote afbeelding maakt je HTML dus niet vanzelf groter, tenzij je die afbeelding als base64-data ín de HTML opneemt.

Wat gebeurt er als HTML groter is dan 2 MB?

Googlebot wijst de URL niet automatisch af. Het verwerkt de response tot de limiet en kapt de fetch daarna af. Staat een belangrijke tekstsectie, interne link, canonical-verwijzing of structured data pas laat in de HTML, dan bestaat het risico dat Googlebot dat onderdeel niet bereikt.

De praktische vraag is daarom niet alleen: “Is deze pagina groter dan 2 MB?” Vraag ook: “Staat alles wat Google moet kunnen zien ruim vóór de cutoff?”

Wat telt wel en niet mee?

• Wel relevant: de ongecomprimeerde omvang van een individuele ondersteunde response, zoals een HTML-document.
• Afzonderlijk opgehaald: externe CSS-, JavaScript- en afbeeldingsbestanden. Die tellen niet op bij de HTML-response, maar kunnen zelf wel een eigen fetchlimiet hebben.
• Extra risico: inline CSS en JavaScript, grote JSON-blokken, uitgebreide navigaties, HTML die door een page builder wordt gegenereerd en base64-afbeeldingen in de broncode.
• PDF's: Google documenteert hiervoor een andere limiet, namelijk 64 MB.

2 MB-limiet, crawlbudget en paginasnelheid: drie verschillende zaken

Onderwerp	Waar gaat het over?	Praktische actie
Googlebot 2 MB-limiet	Hoeveel ongecomprimeerde data Googlebot per ondersteunde URL verwerkt.	Meet grote HTML-responses en plaats essentiële inhoud vroeg in de broncode.
Crawlbudget	Hoe Google crawlcapaciteit over veel URL's op een site verdeelt.	Beperk onnodige URL-varianten, fouten en crawl traps.
Paginasnelheid	Hoe snel een pagina voor gebruikers laadt en reageert.	Optimaliseer renderen, afbeeldingen, scripts en serverprestaties.
404- en soft-404-fouten	URL's die ontbreken of voor Google onvoldoende bruikbare inhoud bieden.	Herstel, redirect of laat onbruikbare URL's correct verdwijnen.

Een HTML-response van meer dan 2 MB is dus geen synoniem voor een crawlbudgetprobleem of een Core Web Vitals-probleem. Wel kunnen dezelfde technische keuzes meerdere problemen veroorzaken. Een site met eindeloze filterpagina's heeft bijvoorbeeld een ander probleem dan één belangrijke landingspagina met extreem veel inline code.

Voor foutstatussen en pagina's die Google als onvoldoende waardevol kan zien, lees ook de gids over 404- en soft-404-fouten.

Welke websites lopen het meeste risico?

• Websites met page builders die veel geneste HTML en inline styling produceren.
• Pagina's waarop scripts, configuraties of grote datasets rechtstreeks in de HTML staan.
• Landingspagina's met zeer uitgebreide menu's, footerlinks of herhaalde componenten.
• Sites die afbeeldingen of bestanden als base64-data in de HTML opnemen.
• Websites met client-side rendering waarbij belangrijke inhoud laat in het document verschijnt.

Voor de meeste mkb-websites is de limiet geen dagelijks probleem. Juist daarom is gericht controleren beter dan zomaar HTML verwijderen. Begin met belangrijke pagina's: homepage, dienstenpagina's, categoriepagina's en pagina's die organisch verkeer of aanvragen moeten opleveren.

Zo controleer je de responsegrootte van een URL

1. Kies prioriteitspagina's. Start met pagina's die commercieel belangrijk zijn of opvallend omvangrijk aanvoelen in je CMS.
2. Vraag de HTML-response op. Gebruik browser-devtools, een HTTP-client of een technische crawltool en controleer de omvang van het HTML-document. Controleer daarbij de ongecomprimeerde response, niet alleen de overgedragen grootte na compressie.
3. Vergelijk met de 2 MB-grens. Zit de HTML ruim onder de grens, dan is deze limiet waarschijnlijk geen prioriteit. Zit je erboven of er dicht tegenaan, onderzoek dan de opbouw.
4. Zoek de grootste blokken. Controleer broncode op lange inline scripts, CSS, JSON-data, base64-strings, herhaalde markup en onnodig zware componenten.
5. Controleer de volgorde. Zorg dat de titel, hoofdinhoud, belangrijke interne links, canonieke verwijzingen en relevante structured data vroeg beschikbaar zijn.
6. Pas gericht aan en meet opnieuw. Verplaats code naar externe bestanden, verwijder overbodige markup en vergelijk de nieuwe ongecomprimeerde HTML-response.

Praktische verbeteringen voor WordPress en page builders

Werk niet vanuit de aanname dat een page builder altijd de oorzaak is. Meet eerst. Blijkt de HTML groot, dan zijn dit logische verbeteringen:

• Verplaats inline CSS en JavaScript waar mogelijk naar externe bestanden.
• Gebruik geen base64-afbeeldingen in HTML als een normaal afbeeldingsbestand geschikt is.
• Verwijder ongebruikte secties, verborgen varianten en overmatig geneste containers.
• Beperk grote data-objecten in de pagina-output als die niet nodig zijn voor de bezoeker of functionaliteit.
• Laat essentiële content server-side of vroeg in de HTML beschikbaar zijn.
• Controleer plug-ins en themafuncties die op elke pagina omvangrijke markup of scripts toevoegen.

Bij technische SEO gaat het uiteindelijk niet alleen om minder bytes, maar om een website die goed crawlbaar is én bezoekers duidelijk naar een volgende stap begeleidt. LYNX combineert die disciplines binnen conversie- en SEO-optimalisatie.

Praktische scorecard voor je audit

Controlepunt	Goed genoeg wanneer	Actie bij risico
HTML-response	De ongecomprimeerde HTML blijft onder 2 MB.	Inventariseer inline code, base64-data en grote HTML-componenten.
Hoofdinhoud	De primaire tekst en koppen staan vroeg in het HTML-document.	Verplaats niet-kritische widgets, scripts en uitgebreide blokken naar later of extern.
Interne links	Belangrijke navigatie- en contextlinks staan vóór mogelijke afkapping.	Verminder herhaalde links en plaats cruciale links hoger in de markup.
Structured data	Relevante markup is compact en vroeg beschikbaar.	Verwijder dubbele of irrelevante structured data en controleer de implementatie.
Afbeeldingen	Afbeeldingen worden als losse bestanden geladen.	Vervang base64-afbeeldingen door reguliere afbeeldings-URL's.
Template-output	Het thema en de builder genereren geen onnodige herhaling.	Vereenvoudig secties, containers en globale componenten.

Wat de 2 MB-limiet nadrukkelijk niet betekent

• Het is geen automatische rankingstraf voor iedere URL boven 2 MB.
• Het is geen algemene maximale omvang van je volledige website.
• Het is niet hetzelfde als crawlbudget.
• Het betekent niet dat elke externe resource bij de HTML-response wordt opgeteld.
• Het vervangt geen controle op serverfouten, rendering of inhoudelijke kwaliteit.

Conclusie

De Googlebot response-limiet van 2 MB is vooral relevant wanneer een belangrijke HTML-pagina uitzonderlijk groot is. Meet de ongecomprimeerde HTML, lokaliseer de grootste onderdelen en zorg dat essentiële content en signalen vroeg in de response staan. Zo voorkom je dat technische overhead de crawlbaarheid van commerciële pagina's onnodig beperkt.

Wil je technische SEO, inhoud en conversie als één verbetertraject aanpakken? Bekijk de diensten van LYNX Media of bespreek je website of online groeikansen met LYNX Media.