Paginagroottechecker: controleer de crawllimiet van 2 MB van Google

Een paginagroottechecker beantwoordt een precieze vraag: leest Google je hele pagina? Google stelt dat Googlebot bij het crawlen voor Search de eerste 2 MB van een ondersteund bestandstype en de eerste 64 MB van een pdf crawlt, het ophalen bij de grens stopt en alleen het al gedownloade deel voor indexering doorgeeft (Google Search Central, Googlebot). Alles na dat punt, of het nu een productbeschrijving, een FAQ, footerlinks of een JSON-LD-blok is, bestaat voor Google Search gewoon niet.

Waarop is de limiet van 2 MB precies van toepassing?

Hij geldt voor elk bestand dat Googlebot ophaalt, één voor één, en wordt gemeten op ongecomprimeerde gegevens. Gzip of Brotli verkleinen de overdracht, maar veranderen de telling niet. Het HTML-document heeft zijn eigen budget van 2 MB, en elk CSS- of JavaScript-bestand waarnaar het verwijst, wordt apart opgehaald met dezelfde limiet.

Daarom wordt het cijfer van 2 MB vaak verkeerd begrepen. In 2025 woog de mediane mobiele homepage in totaal 2,6 MB, maar slechts 22 KB daarvan was HTML; afbeeldingen en JavaScript vormden het grootste deel van de rest (HTTP Archive Web Almanac 2025, page weight). Een zware pagina is geen probleem voor deze limiet. Een zwaar HTML-bestand wel.

De waarde van 2 MB is specifiek voor Google Search. De algemene documentatie van Google zegt dat zijn crawlers en fetchers standaard de eerste 15 MB van een bestand lezen, en dat afzonderlijke producten een kleinere limiet kunnen instellen (Google, overview of crawlers and fetchers). Oudere artikelen die 15 MB voor Googlebot noemen, beschrijven die standaardwaarde, niet de Search-crawler.

Hoe gebruik je de paginagroottechecker?

Plak de volledige URL van een openbare pagina, doorloop de anti-botcontrole en start de analyse. De tool downloadt de pagina zoals een crawler dat doet, volgt redirects en meet de HTML zoals de server hem verstuurt, voordat er JavaScript draait.

1. Lees de meter. Hij toont de ongecomprimeerde HTML-grootte, de limiet van Googlebot (2 MB, oftewel 2097152 bytes) en het percentage dat je gebruikt, met de resterende ruimte.
2. Bekijk de vier kaarten: ruwe HTML-grootte, gewicht van inline JS en CSS met hun aandeel in de HTML, aantal HTML-tags en HTTP-status.
3. Open de HTML-uitsplitsing: inline scripts, inline stijlen, externe scripts, externe stylesheets, afbeeldingen en opmerkingen, elk met aantal, grootte en aandeel.
4. Bekijk de servergegevens: titel, metabeschrijving, definitieve URL na redirects, gebruikte compressie en servertype.
5. Pas de aanbevelingen toe, die alleen verschijnen wanneer een drempel wordt overschreden.

De gratis versie staat drie analyses per dag toe. Test eerst je zwaarste sjablonen: een categoriepagina met honderden producten of een lang artikel met ingesloten widgets zegt meer dan je homepage.

Hoe lees je het resultaat?

De status hangt alleen af van het aandeel van de limiet van 2 MB dat de ongecomprimeerde HTML gebruikt.

De aanbevelingen gebruiken vaste drempels: inline scripts boven 50 KB, inline stijlen boven 30 KB en opmerkingen boven 5 KB worden gemarkeerd, net als een server die HTML zonder compressie verstuurt. Compressie verkleint niet de grootte die Google telt, maar verkort wel de overdrachtstijd voor crawlers en bezoekers.

Wat maakt een HTML-pagina te zwaar?

Pagina's bereiken zelden 2 MB door tekst. Een artikel van 3000 woorden is ongeveer 20 KB. Het gewicht komt van wat sjablonen en frameworks in het document injecteren:

• Geserialiseerde frameworkstatus. Server-side gerenderde JavaScript-apps sluiten vaak alle paginagegevens als JSON-object in een scripttag in, soms met elk product of artikel dubbel in de pagina.
• Inline SVG-iconen die in elke kaart van een lijst worden herhaald, en base64-afbeeldingen die in de HTML zijn geplakt.
• Inline CSS van paginabouwers die de stijlen van elk blok in het document schrijven.
• Lange lijsten: categoriepagina's, tagarchieven of interne zoekpagina's die honderden items met al hun varianten afdrukken.
• Te grote gestructureerde gegevens, bijvoorbeeld een Product-blok dat elke variant met volledige beschrijvingen opsomt.
• Opmerkingen en debugmarkup die in productie zijn blijven staan.

De uitsplitsing in de tool laat zien welke daarvan overheerst. Als inline scripts 70% van de HTML innemen, begin dan daar; als het aantal tags in de tienduizenden loopt, ligt het probleem bij het sjabloon of de lengte van de lijst.

Hoe verklein je de HTML zonder content te verliezen?

Werk van het grootste blok naar beneden en houd wat Google nodig heeft bovenaan het document.

1. Verplaats inline JavaScript en CSS naar externe bestanden. Ze krijgen een eigen budget van 2 MB en browsers kunnen ze cachen.
2. Snoei de geserialiseerde status: stuur alleen de velden die de pagina nodig heeft, niet het volledige API-antwoord.
3. Vervang herhaalde inline SVG door een extern sprite of afbeeldingsbestanden, en base64-afbeeldingen door gewone afbeeldings-URL's. De afbeeldingscompressor houdt die bestanden licht.
4. Pagineer lange lijsten of laad extra items op verzoek, en houd elke gepagineerde URL crawlbaar via links.
5. Plaats cruciale content vroeg: hoofdtekst, interne links en gestructureerde gegevens horen niet na megabytes aan scripts te staan. De schemagenerator maakt compacte JSON-LD.
6. Minimaliseer de HTML en verwijder opmerkingen in productie.

Voer na elke wijziging de checker opnieuw uit en bevestig in Search Console. De URL-inspectietool toont via “Gecrawlde pagina weergeven” de HTML die Google echt heeft opgehaald (Search Console Help, URL Inspection tool), zodat je kunt controleren of het einde van je pagina aanwezig is.

Wat zijn de beperkingen van deze controle?

De tool meet één URL, één keer, zoals aan een crawler geleverd. Houd drie punten in gedachten.

• Geen JavaScript-rendering. De tool meet de HTML die de server teruggeeft. Content die later met JavaScript wordt toegevoegd, telt hier niet mee, en Google indexeert alleen het deel van de HTML dat binnen de limiet is opgehaald.
• Eén user-agent. Als je server andere HTML naar Googlebot, naar mobiele apparaten of naar ingelogde gebruikers stuurt, kan de grootte verschillen.
• Eén pagina tegelijk. Een sjabloonprobleem raakt elke pagina die erop is gebouwd, dus test één URL per sjabloon en audit daarna de site als geheel met de on-page SEO-audit.

Is paginagrootte ook belangrijk voor AI-crawlers?

Ja, en vaak meer. De Web Almanac merkt op dat kerninformatie in de oorspronkelijke ruwe HTML aanwezig moet zijn, omdat AI-crawlers geen JavaScript renderen. Een slank HTML-bestand met de hoofdcontent bovenaan dient zowel Google als AI-assistenten. De audit van AI-crawlbaarheid controleert of AI-bots je pagina's kunnen openen en lezen, en crawlbudget legt uit waarom lichtere pagina's ook efficiënter worden gecrawld.

Om het na verloop van tijd te volgen toont het GEO / SEO-dashboard de pagina's waarvan de Google-klikken dalen, vaak het eerste teken van een indexeringsprobleem, en kan SEO Chat een pagina auditen en de oplossing in gewone woorden uitleggen.

Houd elk HTML-bestand ruim onder 2 MB, met de belangrijke content eerst. Controleer hierboven je zwaarste sjablonen en bekijk daarna de abonnementen van Sorank om je zichtbaarheid in Google en AI op autopilot te monitoren.