Google 2 MB Crawl Limit: Was es für deine Website bedeutet

Das Google 2 MB Crawl Limit kam in einem leisen Docs-Update — und mein LinkedIn-Feed ist wegen einer einzigen Zahl explodiert: 2 MB. Google hat am 3. Februar 2026 die Googlebot-Dokumentation aktualisiert und klargestellt, dass der Googlebot die ersten 2 MB einer Datei abruft. In den alten Docs stand nur 15 MB. Die Panik-Posts ließen nicht lange auf sich warten, Ende März folgte ein Blogpost von Search Central mit den Details.

Meine Einschätzung: Das ist deutlich weniger dramatisch, als alle behaupten. Die Zahl an sich ist trotzdem relevant, auch wenn sich 99 % aller Seiten keine Sorgen machen müssen.

Was sich geändert hat

Google hat nicht verändert, wie der Googlebot arbeitet, sondern die Dokumentation an die Realität angepasst. Die 15 MB gibt es weiterhin: Sie sind der Standard für Google-Crawler ohne eigenes Limit. Der Googlebot für die Suche hat ein engeres, und die Docs sagen das jetzt ausdrücklich: die ersten 2 MB jeder Datei, unkomprimiert gemessen.

Deine Seite ist also nicht über Nacht kaputtgegangen. Aber jetzt gibt es eine konkrete Zahl, an der du messen kannst.

Die tatsächlichen Limits

Für dein HTML gilt das Limit für die rohe, unkomprimierte Antwort, inklusive allem Inline-Content: CSS, JavaScript, SVGs, base64-kodierte Bilder. Externe CSS- und JavaScript-Dateien werden separat abgerufen, und jede davon hat ihr eigenes 2-MB-Limit.

Das wichtige Detail: Googlebot lehnt Seiten über 2 MB nicht ab. Er schneidet ab: verarbeitet die ersten 2 MB und ignoriert stillschweigend den Rest. Wenn deine strukturierten Daten, wichtige Links oder der Hauptinhalt unterhalb dieses Limits liegen, sieht Google sie nie. Das ist das eigentliche Risiko.

Wer wirklich betroffen ist

Fast niemand, und ich meine das wörtlich. Eine Seobility-Analyse von 44,5 Millionen Seiten zeigt: Nur 0,82 % überschreiten 2 MB.

Aber einige Seiten sind gefährdet:

• E-Commerce-Filterseiten: wenn jede Farb-/Größen-/Markenkombination serverseitig gerendert wird, bläht sich das HTML schnell auf
• Base64-kodierte Bilder inline im HTML: ein großes Bild als base64 frisst allein schon 300+ KB
• SPAs, die State als JSON ablegen: Frameworks wie Next.js können große Datenmengen ins initiale HTML schreiben, und auf datenlastigen Seiten kann dieses JSON mehrere hundert Kilobyte erreichen
• Inline-SVGs: komplexe Illustrationen oder komplette Icon-Systeme direkt im Markup

Normale Unternehmensseiten, Blogs, mittelgroße Online-Shops? Alles im grünen Bereich.

So prüfst du deine Seiten

Browser DevTools

Chrome DevTools öffnen (F12), Network-Tab, Seite neu laden, auf die Haupt-Dokumentanfrage klicken. Fahr in der Spalte „Size“ mit der Maus über den Wert und schau dir die Ressourcengröße an, nicht die übertragene Größe (die ist komprimiert und viel kleiner). Die unkomprimierte Zahl ist das, was Google zählt.

Lumina Tech Stack Detector

Der Lumina Tech Stack Detector zeigt für jede URL eine HTML-Größen-Metrik, grün bei viel Abstand zum Limit und gelb ab 1 MB. Gemessen wird das HTML, das Lumina erhält, meist die gerenderte Seite. Den exakten Rohwert, den der Googlebot sieht, bekommst du über die Kommandozeile unten. Seiten über etwa 2 MB kann Lumina gar nicht abrufen, und das Tool sagt dir das auch.

Kommandozeile

curl -s https://example.com | wc -c

Das gibt dir die Byte-Anzahl der rohen HTML-Antwort.

Was tun, wenn du über dem Limit liegst

Drüber oder nah dran? Das hier zuerst, nach Wirkung sortiert:

• Inline-Assets in externe Dateien auslagern. Base64-Bilder, fette Inline-SVGs, eingebettetes CSS/JS: in separate Dateien packen. Jede Datei wird separat mit eigenem 2-MB-Limit abgerufen, ein ausgelagertes großes Stylesheet zählt also nicht mehr gegen die Seite.
• Wichtige Inhalte nach oben. Falls abgeschnitten wird: Dein Hauptinhalt, JSON-LD-Schema und die wichtigsten internen Links sollten weit oben im HTML stehen. Nicht unter 1,5 MB Navigations-Markup begraben.
• Lange Listings paginieren. 500 Produkte serverseitig in einer HTML-Datei ist ein Problem. Paginieren oder den Tail lazy-loaden.
• Totes Markup entfernen. Ungenutzte CSS-Klassen, redundante Data-Attribute, überflüssiger Whitespace: Das summiert sich schneller, als man denkt.

Wenn deine Seiten unter 500 KB liegen (und das tun sie fast sicher), verschwende keine Zeit damit. Steck deine Technical-SEO-Stunden dahin, wo sie wirklich Rankings bewegen.