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 im März 2026 die Crawler-Docs aktualisiert und bestätigt, dass Googlebot maximal 2 MB HTML pro URL verarbeitet. In den alten Docs stand 15 MB. Die Panik-Posts ließen nicht lange auf sich warten.

Meine Einschätzung: Das ist deutlich weniger dramatisch als alle behaupten. Aber es lohnt sich trotzdem zu verstehen, was sich tatsächlich geändert hat. Die Zahl an sich ist schon relevant, auch wenn 99 % aller Seiten sich keine Sorgen machen müssen.

Was sich geändert hat

Google hat nicht verändert, wie der Googlebot arbeitet. Sie haben die Dokumentation an die Realität angepasst. Die 15-MB-Angabe stand jahrelang in den Docs, aber jeder, der das tatsächliche Crawling-Verhalten getestet hat, wusste: Der echte Schwellenwert liegt viel niedriger. Der Blogpost vom März 2026 hat es endlich schwarz auf weiß gesetzt: 2 MB unkomprimiertes HTML pro URL.

Deine Seite ist also nicht plötzlich über Nacht kaputtgegangen. Aber eine bestätigte, konkrete Zahl ist nützlich. Jetzt kannst du aufhören zu raten und anfangen zu messen.

Die tatsächlichen Limits

Google Crawl-Größen-Limits (2026)

  • HTML-Seiten (Googlebot): 2 MB unkomprimiert
  • PDF-Dateien: 64 MB
  • Andere Ressourcen (CSS, JS, Bilder): 15 MB Standard für Crawler ohne spezifisches Limit

Das 2-MB-Limit gilt für rohes, unkomprimiertes HTML, inklusive allem Inline-Content: CSS, JavaScript, SVGs, base64-kodierte Bilder. Externe Ressourcen (separate CSS/JS-Dateien, Bilder per <img>) werden separat abgerufen, jeweils mit eigenem 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. Die mittlere HTML-Größe im Web? Gerade mal 20 KB. Selbst am 90. Perzentil liegen Seiten bei rund 392 KB, nicht einmal 20 % des Limits.

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 — bei React/Next.js-Apps hab ich schon 1,4 MB JSON in einem einzigen <script>-Tag gesehen
  • Inline-SVGs — komplexe Illustrationen oder komplette Icon-Systeme direkt im Markup

Normale Unternehmensseiten, Blogs, mittelgroße Online-Shops? Alles im grünen Bereich. Verschwende keine Zeit mit einem Problem, das du nicht hast.

So prüfst du deine Seiten

Dauert ungefähr 30 Sekunden. Such dir eine Methode aus:

Browser DevTools

Chrome DevTools öffnen (F12), Network-Tab, Seite neu laden, auf die Haupt-Dokumentanfrage klicken. Schau dir die Response-Größe an, nicht die Transfer-Größe (die ist gzip-komprimiert und viel kleiner). Die unkomprimierte Zahl ist das, was Google zählt.

Lumina Tech Stack Detector

Ich hab eine HTML-Größen-Metrik zum Lumina Tech Stack Detector hinzugefügt, direkt nachdem die Nachricht rauskam. Gib eine URL ein und du siehst die HTML-Größe mit Farbcode: Grün wenn sicher, Gelb wenn knapp, Rot wenn drüber.

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

Wenn du tatsächlich drüber (oder nah dran) bist, hier die Fixes nach Wirkung sortiert:

  • Inline-Assets in externe Dateien auslagern. Base64-Bilder, fette Inline-SVGs, eingebettetes CSS/JS — in separate Dateien packen. Jede wird unabhängig abgerufen mit eigenem 15-MB-Limit.
  • 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.

Aber mal ehrlich: wenn deine Seiten unter 500 KB liegen (und das tun sie fast sicher), verschwende keine Zeit damit. Das 2-MB-Limit ist für dich irrelevant. Steck deine Technical-SEO-Stunden dahin, wo sie wirklich Rankings bewegen.

HTML-Größe mit einem Klick prüfen

Der Lumina Tech Stack Detector zeigt jetzt die HTML-Größe neben den erkannten Technologien. Grün heißt sicher, Gelb heißt aufpassen.

Tech Stack Detector testen