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. Alles danach existiert für Google nicht.
- 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 – aber fordert keine Bilder oder Videos an.
- Reihenfolge zählt: Meta-Tags, Canonicals und Structured Data müssen im oberen Bereich des HTML stehen, bevor der Cutoff zuschlägt.
Einleitung
Google hat Ende März 2026 einen der wichtigsten technischen Blogposts der letzten Jahre veröffentlicht. Gary Illyes hat 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.
Die zentrale Erkenntnis: Googlebot holt sich pro URL maximal 2 Megabyte. Was danach kommt, wird nicht gecrawlt, nicht gerendert, nicht indexiert. Klingt harmlos? Für eine schlanke, sauber gecodete Seite: Ja. Für eine mit PageBuilder aufgeblähte WordPress-Installation: ein echtes Problem.
2 MB klingt nach viel? Eine einzelne Elementor-Seite kann locker 800 KB bis 1.5 MB reines HTML produzieren – ohne CSS und JS. Packe ein WooCommerce-Shop-Template mit 50 Produkten in eine Kategorie-Seite und du bist schneller an der Grenze als du denkst. 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. Hier die Übersicht:
| Ressource | Crawl-Limit |
|---|---|
| HTML-Seiten (Googlebot) | 2 MB (inkl. HTTP-Header) |
| PDF-Dateien | 64 MB |
| Bilder & Videos | Variable Schwellenwerte, produktabhängig |
| 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.
- Warum das für dich relevant ist
- Wenn dein Content erst durch JavaScript geladen wird (z.B. per AJAX oder SPA-Framework), muss das resultierende HTML immer noch innerhalb der 2MB-Grenze liegen, nachdem der WRS es gerendert hat. Maschinenlesbarkeit fängt beim sauberen DOM an.
So optimierst du: Googles Best Practices + Praxis
Google hat drei offizielle Best Practices veröffentlicht. Ich ergänze sie um die Praxis-Perspektive, die im Original fehlt.
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). Die radikalste Optimierung: Weg vom PageBuilder, hin zum nativen Block-Editor oder Custom Theme Development. Was ein PageBuilder mit 200 verschachtelten <div>-Containern löst, schafft sauberer Code in 10 Zeilen. 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>, wenn PageBuilder den DOM mit tausenden Nodes aufblasen und dein wichtiges Structured Data oder Canonical erst am Ende 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 offizielle Dokumentation der Crawling-Limits ist ein Weckruf für jeden, der noch glaubt, dass HTML-Größe keine Rolle spielt. Die 2MB-Grenze ist kein theoretisches Szenario – sie ist die harte Realität, in der dein <meta>-Tag, dein Canonical oder dein JSON-LD-Schema schlicht nicht existiert, wenn es zu weit unten im Quellcode steht.
Die wichtigsten Punkte auf einen Blick:
- 2 MB pro URL: Googlebot schneidet HTML-Dokumente nach 2 MB ab. Der abgeschnittene Teil wird als vollständiges Dokument behandelt. Punkt.
- 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: Der Web Rendering Service fordert keine Bilder oder Videos an – nur Text, Struktur und Code.
Die Konsequenz ist klar: Schluss mit Code-Bloat. Jedes überflüssige <div>, jeder Inline-Style, jeder PageBuilder-Shortcode frisst Bytes, die dein wichtiger Content braucht. Wer 2026 in Googles Index und in den KI-Antworten sichtbar sein will, muss seinen Code so behandeln wie Speicherplatz auf einer Raumstation: Jedes Gramm zählt, jedes Byte muss seinen Platz verdienen.
Hä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 Headless-Chromium-Browser, verarbeitet clientseitigen Code und versteht den finalen Zustand einer Seite – Text, Struktur, Layout. Bilder und Videos werden vom WRS nicht angefordert. Auch für WRS-Ressourcen gilt das 2MB-Limit pro Datei.
Wie prüfe ich, ob meine Seite zu groß für Googlebot ist?
Öffne den Quellcode deiner Seite im Browser und prüfe die Dateigröße des HTML-Dokuments. Über curl -sI URL | grep content-length erhältst du die Größe in Bytes. Alles unter 500 KB ist unkritisch, ab 1 MB solltest du optimieren, ab 2 MB wird aktiv abgeschnitten. Alternativ: Google Search Console → URL-Prüfung → „Gecrawlte Seite anzeigen" zeigt dir exakt, was Google gesehen hat.
Betrifft das 2MB-Limit auch Single-Page-Applications (SPAs)?
Ja und nein. Das initiale HTML einer SPA ist meist klein. Aber der WRS rendert das JavaScript und erzeugt daraus den finalen DOM. Wenn das gerenderte Ergebnis mehr als 2 MB textuellen Inhalt enthält, greift das Limit erneut. SPAs sind zusätzlich gefährdet, weil essenzielle Inhalte oft erst durch asynchrone Calls nachgeladen werden – und wenn diese scheitern, sieht Google eine leere Seite.
Dein Code unter der Lupe
Wie viel Byte-Ballast schleppt deine Seite mit sich? Ich analysiere deinen Quellcode und zeige dir exakt, wo Googlebot aufhört zu lesen.