Googles 2MB-Grenze: Was Googlebot 2026 wirklich von deiner Seite sieht.
Das Wichtigste in Kürze
Das Wichtigste in Kürze:
- 2MB-Cutoff: Googlebot liest maximal die ersten 2 MB deines HTML-Dokuments (inklusive HTTP-Header). Alles danach existiert für Google nicht.
- Aber: kein Massenproblem. Google schreibt selbst, dass 2 MB für die überwiegende Mehrheit des Webs riesig sind und die Grenze nie erreicht wird. Kritisch sind drei konkrete Muster – base64-Inline-Bilder, große Inline-CSS/JS-Blöcke und megabyteweise Menüs am Dokumentanfang.
- Separate Budgets: Externe CSS-, JS- und XHR-Dateien haben jeweils eigene 2MB-Limits und zählen nicht zum Parent-Dokument.
- Rendering via WRS: Der Web Rendering Service führt JavaScript aus wie ein moderner Browser – fordert aber keine Bilder oder Videos an und arbeitet stateless.
- Reihenfolge zählt: Meta-Tags, Canonicals und Structured Data müssen im oberen Bereich des HTML stehen, bevor der Cutoff zuschlägt.
Schematische Darstellung mit konstruierten Beispielwerten – keine Live-Messung deiner Seite.
Einleitung
Ende März 2026 hat Gary Illyes im Beitrag „Inside Googlebot: demystifying crawling, fetching, and the bytes we process" detailliert beschrieben, wie Googles Crawling-Ökosystem funktioniert – und vor allem: wo es aufhört zu lesen. Dieser Artikel fasst die Byte-Grenzen zusammen und ordnet ein, für wen sie überhaupt relevant sind.
Die zentrale Zahl: Googlebot holt sich pro URL maximal 2 Megabyte. Was danach kommt, wird nicht gecrawlt, nicht gerendert, nicht indexiert. Bevor jetzt Panik ausbricht – Google selbst schreibt in demselben Beitrag, dass eine HTML-Payload von 2 MB für die überwiegende Mehrheit des Webs riesig ist und die meisten Seiten diese Grenze nie erreichen. Interessant wird es erst bei bestimmten Bauweisen, etwa einer stark mit PageBuilder aufgeblähten WordPress-Installation.
Google nennt drei konkrete Muster, die kritische Bytes über die Grenze schieben: inline eingebettete base64-Bilder, große Blöcke inline-CSS oder -JavaScript und Seiten, die mit megabyteweise Menüs beginnen. Base64-Bilder sind dabei der häufigste reale Auslöser – ein einziges großes Hero-Bild direkt im HTML kann mehr Bytes fressen als der gesamte Rest der Seite. Und ja: Die 2 MB umfassen auch den HTTP-Header.
Nicht ein Bot: Ein ganzes Ökosystem
Erster Mythos, der stirbt: „Googlebot" ist kein einzelner Crawler. Google betreibt dutzende spezialisierter Crawler für unterschiedliche Zwecke – vom klassischen Webseiten-Crawler über den Bild-Crawler bis hin zu spezialisierten Fetchers für AdsBot, Feedfetcher und Storebot. Die vollständige Liste hat Google in seiner Crawler-Dokumentation veröffentlicht.
Jeder Crawler hat seine eigenen Byte-Limits. Googlebot für Webseiten: 2 MB. PDF-Crawler: 64 MB. Bild- und Video-Crawler: variable Schwellenwerte je nach Zielprodukt. Alle anderen Crawler ohne spezifisches Limit: 15 MB Default.
Die Byte-Limits: Was Google wirklich liest
Das Kernstück des Updates sind die exakten Byte-Grenzen, die Google jetzt offiziell dokumentiert hat (Quelle: Google Search Central):
| Ressource | Crawl-Limit |
|---|---|
| HTML-Seiten (Googlebot) | 2 MB (inkl. HTTP-Header) |
| PDF-Dateien | 64 MB |
| Bild- & Video-Crawler | Variable Schwellenwerte, je nach Zielprodukt |
| Andere Crawler (ohne spezif. Limit) | 15 MB Default |
| Externe CSS/JS/XHR | 2 MB pro Datei (separater Zähler) |
Der entscheidende Punkt: Wenn dein HTML-Dokument größer als 2 MB ist, wird Googlebot es nicht ablehnen – er schneidet es exakt an der 2MB-Grenze ab. Die abgeschnittene Version wird dann so an die Indexierungs-Pipeline und den Web Rendering Service weitergegeben, als wäre sie die vollständige Datei.
Der Crawl-Ablauf: Vom Fetch zum Index
Was passiert eigentlich, nachdem Googlebot deine URL abruft? Der Prozess läuft in klar definierten Schritten ab:
Die gute Nachricht: Wenn du schweren CSS- und JavaScript-Code in externe Dateien auslagerst, zählen diese nicht zum 2MB-Limit deines HTML-Dokuments. Jede referenzierte Datei hat ihren eigenen, unabhängigen Zähler. Das ist der Schlüssel zur Optimierung.
Der WRS: Googles unsichtbarer Browser
Nachdem Googlebot die rohen Bytes geholt hat, übernimmt der Web Rendering Service (WRS). Der WRS ist im Grunde ein Headless-Chromium-Browser, der JavaScript ausführt und den finalen Zustand deiner Seite versteht – Text, Struktur, Layout.
- Was der WRS tut
- JavaScript und CSS ausführen, clientseitigen Code verarbeiten, XHR-Requests absetzen, den finalen textuellen und strukturellen Zustand der Seite erfassen. Für jede angeforderte Ressource gilt ebenfalls das 2MB-Limit.
- Was der WRS nicht tut
- Bilder und Videos anfordern. Das bedeutet: Googles Rendering sieht deine Seite im Klartext – ohne visuelle Medien. Was zählt, ist die textuelle und strukturelle Substanz, nicht das hübsche Hero-Image.
- Was oft übersehen wird: Der WRS ist stateless
- Local Storage und Session Data werden zwischen Requests geleert. Alles, was erst nach einem gespeicherten Zustand erscheint – Inhalte hinter einer einmal weggeklickten Consent-Auswahl, hinter einem gemerkten Login oder hinter einem „schon gesehen"-Flag – bekommt Google nie zu Gesicht. In der Praxis ist das deutlich häufiger die Ursache für fehlende Inhalte als irgendein Byte-Limit.
- Warum das für dich relevant ist
- Wenn dein Content erst durch JavaScript geladen wird, hängt seine Sichtbarkeit an zwei Bedingungen: Das initiale HTML muss innerhalb der 2 MB liegen, und jede nachgeladene Ressource muss ihr eigenes 2MB-Budget einhalten. Ein häufiges Missverständnis dabei: Die Grenze gilt für den Fetch pro URL, nicht für die Größe des fertig gerenderten DOM – der wird nicht noch einmal abgerufen. Maschinenlesbarkeit fängt beim sauberen DOM an.
So optimierst du: Googles Best Practices + Praxis
Google nennt drei Best Practices. Ich ergänze sie um die Praxis-Perspektive – mit der Vorbemerkung, dass die meisten Seiten hier ohnehin nichts zu tun haben.
1. Keep your HTML lean – Schlankes HTML ist Pflicht
Lagere schweren CSS- und JavaScript-Code in externe Dateien aus. Das initiale HTML-Dokument hat ein 2MB-Limit, aber externe Scripts und Stylesheets werden separat gecrawlt (mit jeweils eigenen Limits). Der mit Abstand wirksamste Einzelschritt: keine base64-Bilder im HTML. Ein einziges inline eingebettetes Hero-Bild kann mehr Bytes belegen als der komplette übrige Quelltext – als externe Datei referenziert kostet es dagegen null Bytes im HTML-Budget. Danach kommt der Verzicht auf große Inline-CSS- und -JS-Blöcke. Und wenn du ohnehin umbaust: Was ein PageBuilder mit 200 verschachtelten <div>-Containern löst, schafft sauberer Code in einem Bruchteil davon. Wie du dein WordPress konkret abspeckst, steht im WordPress-Diät-Guide.
2. Order matters – Reihenfolge entscheidet
Platziere deine kritischsten Elemente so weit oben im HTML wie möglich: <meta>-Tags, <title>, <link rel="canonical">, strukturierte Daten (JSON-LD) und essenzielle <link>-Elemente. Was im <head> steht, ist praktisch immer sicher. Das Problem beginnt im <body> – klassisch bei Seiten, die mit megabyteweise Menü-Markup starten, bevor der eigentliche Inhalt kommt.
3. Monitor your server logs – Servergesundheit überwachen
Wenn dein Server unter Last gerät und Bytes langsam ausliefert, drosselt Googlebot automatisch seine Crawl-Frequenz, um deine Infrastruktur nicht zu überlasten. Das Ergebnis: Weniger Crawls, langsamere Indexierung, veraltete Inhalte im Index. Überwache deine Server-Antwortzeiten konsequent – insbesondere den TTFB. Eine schlanke WordPress-Installation mit einem TTFB unter 0.5 Sekunden ist dein bester Verbündeter.
Fazit: Jedes Byte muss verdient werden
Googles Dokumentation der Crawling-Limits ist vor allem eines: eine willkommene Präzisierung. Für die meisten Websites ändert sie praktisch nichts – das sagt Google ausdrücklich selbst. Relevant wird die 2MB-Grenze dort, wo base64-Bilder, Inline-Code-Blöcke oder aufgeblähte Menüstrukturen die kritischen Elemente nach unten drängen. Dann allerdings gilt kompromisslos: Was jenseits der Grenze steht, existiert für Google nicht.
Die wichtigsten Punkte auf einen Blick:
- 2 MB pro URL: Googlebot schneidet HTML-Dokumente nach 2 MB ab; der geladene Teil wird als vollständiges Dokument behandelt. Betrifft in der Praxis wenige Seiten – aber die dann vollständig.
- Die drei realen Auslöser: base64-Bilder im HTML, große Inline-CSS/JS-Blöcke, megabyteweise Menüs vor dem Content.
- Externe Dateien = eigenes Budget: CSS, JS und XHR-Requests haben separate 2MB-Limits. Auslagerung ist die effektivste Optimierung.
- Reihenfolge im Code:
<head>-Elemente, Canonicals, Meta-Tags und Structured Data gehören so weit nach oben wie möglich. - Server-Speed = Crawl-Budget: Langsame Server führen zu gedrosseltem Crawling. TTFB unter 0.5s ist das Ziel.
- WRS rendert ohne Medien – und ohne Gedächtnis: Keine Bilder oder Videos, und Local Storage sowie Session Data werden zwischen Requests geleert.
Die ehrliche Konsequenz: Prüf einmal die Größe deiner größten Seite, und wenn du unter 500 KB liegst, hak das Thema ab. Liegst du darüber, such nach base64-Bildern und Inline-Blöcken, bevor du irgendetwas anderes optimierst. Schlanker Code lohnt sich ohnehin – nur eben für Ladezeit, Wartbarkeit und dafür, dass auch KI-Crawler deine Inhalte im Roh-HTML finden. Das Crawl-Limit ist dabei das schwächste der drei Argumente.
Änderungsprotokoll (Überarbeitung 07.08.2026)
Erstfassung April 2026. Die Byte-Limits waren von Anfang an korrekt – geändert wurden Einordnung und Details:
curl -sI URL | grep content-length als PrüfbefehlContent-Length, und bei gzip steht dort die komprimierte Größe – ersetzt durch curl -s -H 'Accept-Encoding: identity' URL | wc -cHäufig gestellte Fragen
Wie viel einer Webseite crawlt Googlebot maximal?
Googlebot fetcht maximal die ersten 2 MB einer einzelnen URL (inklusive HTTP-Header). Bei PDF-Dateien liegt die Grenze bei 64 MB. Für Crawler ohne spezifisches Limit gilt ein Default von 15 MB. Alles jenseits dieser Grenze wird komplett ignoriert – nicht gecrawlt, nicht gerendert, nicht indexiert.
Was passiert mit Inhalten jenseits der 2MB-Grenze?
Diese Bytes werden weder gecrawlt, noch gerendert, noch indexiert. Google behandelt die abgeschnittene Version so, als wäre sie die vollständige Datei. Meta-Tags, Canonical-URLs oder Structured Data im unteren Bereich der Seite existieren für Google schlicht nicht.
Zählen externe CSS- und JavaScript-Dateien zum 2MB-Limit?
Nein. Jede referenzierte Ressource (CSS, JS, XHR-Requests) wird separat gecrawlt und hat ihren eigenen, unabhängigen Byte-Zähler. Sie zählen nicht zum 2MB-Limit des übergeordneten HTML-Dokuments. Das ist der Grund, warum das Auslagern in externe Files die effektivste Maßnahme ist.
Was ist der Web Rendering Service (WRS)?
Der WRS ist Googles System zur Ausführung von JavaScript und CSS. Er funktioniert wie ein moderner Browser, verarbeitet clientseitigen Code und XHR-Requests und erfasst den finalen textuellen und strukturellen Zustand einer Seite. Bilder und Videos fordert er dabei nicht an. Für jede angeforderte Ressource gilt erneut das 2MB-Limit, und er arbeitet stateless.
Wie prüfe ich, ob meine Seite zu groß für Googlebot ist?
Am zuverlässigsten mit curl -s -H 'Accept-Encoding: identity' URL | wc -c – das liefert die unkomprimierte Größe in Bytes. Ein HEAD-Request via curl -sI taugt dafür nur bedingt: Viele Server senden dabei gar kein Content-Length, und bei aktivem gzip oder Brotli steht dort die komprimierte Größe. Alternativ zeigt die Google Search Console unter URL-Prüfung → „Gecrawlte Seite anzeigen" exakt, was Google gesehen hat.
Ist das 2MB-Limit für normale Websites ein reales Problem?
Für die meisten nicht. Google schreibt selbst, dass eine HTML-Payload von 2 MB für die überwiegende Mehrheit des Webs riesig ist und die Grenze nie erreicht wird. Kritisch wird es bei drei konkreten Mustern: inline eingebettete base64-Bilder, große Blöcke inline-CSS oder -JavaScript und Seiten, die mit megabyteweise Menüs beginnen. Wer keines davon hat, kann das Thema entspannt abhaken.
Betrifft das 2MB-Limit auch Single-Page-Applications?
Das initiale HTML einer SPA ist meist klein, insofern ist die Grenze dort selten das Problem. Wichtig ist die richtige Lesart: Die 2 MB sind ein Fetch-Limit pro URL, kein Limit für die Größe des gerenderten DOM – der wird nicht noch einmal abgerufen. Jede nachgeladene Ressource hat ihr eigenes 2MB-Budget. Das eigentliche SPA-Risiko liegt woanders: Wenn asynchrone Calls scheitern, sieht Google eine leere Seite.
Arbeitet der Web Rendering Service mit Zustand?
Nein, der WRS arbeitet stateless: Local Storage und Session Data werden zwischen Requests geleert. Inhalte, die erst nach einem gespeicherten Zustand erscheinen – etwa nach einer weggeklickten Consent-Auswahl oder einem gemerkten Login – sieht Google deshalb nicht. Das ist in der Praxis eine deutlich häufigere Ursache für fehlende Inhalte als jedes Byte-Limit.
Dein Code unter der Lupe
Unsicher, ob deine Seite betroffen ist? Der Selbsttest oben dauert eine Minute. Wenn dabei etwas Auffälliges herauskommt oder du wissen willst, was Google sonst noch von deinem Quellcode sieht: