Googlebot 2 MB Crawl-Limit: Chronologie, Praxisdaten und was du jetzt prüfen solltest

Im Februar 2026 hat Google innerhalb von nur neun Tagen seine Crawler-Dokumentation gleich dreimal überarbeitet – und mit jeder Version ein Stück mehr Verwirrung gestiftet. Die Schlagzeile, die durch die SEO-Szene wanderte: Googlebot liest jetzt nur noch die ersten 2 MB einer HTML-Datei statt der bisher dokumentierten 15 MB. Rechnerisch ein Rückgang um 86,7 %, wenn man es dramatisch formulieren möchte. Und genau das haben dann auch einige auf LinkedIn getan.

Chris Long (Nectiv) brachte das Thema auf LinkedIn viral in Umlauf. Branchenstimmen wie Barry Schwartz, Jamie Indigo und Steve Toth stiegen in die Diskussion ein. Zwischen Panikmache und Verharmlosung liegt – wie so oft – die Wahrheit in der Mitte. Die Änderung betrifft die allermeisten Websites schlicht nicht. Aber wer betroffen ist, bekommt das nicht einmal mit: Google gibt keinerlei Warnung aus, wenn Inhalte am 2-MB-Limit abgeschnitten werden.

In diesem Artikel findest du die vollständige Chronologie aller drei Dokumentationsänderungen, die zentrale Unterscheidung zwischen Fetching und Indexing, eigene Messdaten von deutschen Websites, fünf konkrete Prüfmethoden mit Schritt-für-Schritt-Anleitungen und eine nüchterne Einordnung, was das für deine SEO- und KI-Sichtbarkeit bedeutet.

Die Chronologie ist entscheidend, denn Google hat die Dokumentation nicht einmal, sondern dreimal in kurzer Folge angepasst. Und die letzte Änderung relativiert die erste.

Update 1: 3. Februar 2026

Google aktualisiert die offizielle Googlebot-Dokumentation und die allgemeine Crawler-Dokumentation. Die zentrale neue Passage auf der Googlebot-Seite: „When crawling for Google Search, Googlebot crawls the first 2MB of a supported file type, and the first 64MB of a PDF file.“ Gleichzeitig wird klargestellt, dass CSS- und JavaScript-Dateien separat geladen werden und jeweils einem eigenen 2-MB-Limit unterliegen. Das Limit gilt für unkomprimierte Daten.

Wie Barry Schwartz auf Search Engine Roundtable berichtet, erklärte Google: Man habe bei der Umstrukturierung der Dokumentation Googlebot-spezifische Limits präziser dokumentiert. Die Information war vorher an einer weniger logischen Stelle platziert.

Update 2: ca. 6.–8. Februar 2026

John Mueller (Google) reagiert auf die Community-Verunsicherung mit Klarstellungen auf Bluesky und Reddit. Seine wichtigsten Aussagen: Es handele sich um eine Dokumentationsklarstellung, nicht um eine Verhaltensänderung. Die 2 MB seien spezifisch für Googlebot und die Websuche. Er empfiehlt Dave Smarts Tame-the-Bots-Tool zum Testen und hält das Thema für „extremely rare“ in der Praxis.

Update 3: 11. Februar 2026 – die entscheidende Abschwächung

Google passt die allgemeine Crawler-Dokumentation ein drittes Mal an. Die neue Formulierung lautet jetzt: „a Google crawler like Googlebot may have a smaller size limit (for example, 2MB).“

Das „for example“ ist bemerkenswert. Es positioniert die 2 MB nicht mehr als absolutes Limit, sondern als Beispielwert für ein mögliches Limit. Die vorherige Version hatte die 2 MB deutlich konkreter formuliert. Ob Google sich hier bewusst Spielraum lässt oder ob die Formulierungen aus verschiedenen Dokumentationsteams stammen, bleibt offen.

Diesen Punkt haben die meisten Berichterstattungen nicht sauber herausgearbeitet, obwohl er für das Verständnis zentral ist. Googles Crawling-Infrastruktur arbeitet in zwei getrennten Phasen – und für jede Phase gilt ein anderes Limit.

Phase 1 – Fetching (Herunterladen): Googles Crawler laden bis zu 15 MB einer Datei von deinem Server herunter. Das ist das allgemeine Limit für die gesamte Google-Infrastruktur. Dein Server liefert die Datei, Google speichert sie. An dieser Grenze hat sich nichts geändert.

Phase 2 – Indexing (Verarbeitung für die Suche): Für die Google-Websuche verarbeitet Googlebot nur die ersten 2 MB des heruntergeladenen HTML. Alles darüber hinaus wird für Ranking-Zwecke ignoriert. Es existiert auf dem Server, aber Google nutzt es nicht für die Suchergebnisse.

Wenn deine HTML-Datei beispielsweise 5 MB groß ist, wird Google sie möglicherweise komplett herunterladen – aber nur die ersten 2 MB für das Ranking auswerten. Der gesamte Rest ist für die Websuche unsichtbar.

Dave Smart (Tame the Bots) ordnet das pragmatisch ein: „At the risk of overselling how much of a real world issue this is – it really isn’t for 99.99% of sites I’d imagine.“

Die verschiedenen Zahlen haben in der SEO-Community für erhebliche Verwirrung gesorgt. John Mueller hat auf Bluesky klargestellt, woran das liegt: Google betreibt viele verschiedene Crawler, und Googlebot ist nur einer davon. Sein Kommentar dazu: „Google has a lot of crawlers, which is why we split it. It’s extremely rare that sites run into issues in this regard, 2 MB of HTML is quite a bit.“

Mueller betonte auf Reddit: „None of these recently changed, we just wanted to document them in more detail.“ Und als schnellsten Praxis-Check empfiehlt er einen Ansatz ohne jedes Tool: Einfach nach einem eindeutigen Textzitat von weit unten auf einer Seite googeln. Findet Google es, ist alles indexiert.

Wie groß ist das Limit eigentlich in der Praxis? Laut dem HTTP Archive Web Almanac 2025 liegt der Median der HTML-Dateigröße auf mobilen Seiten bei gerade einmal 33 KB. Selbst am 90. Perzentil sind es nur rund 151 KB – wie John Mueller selbst auf Reddit bestätigte: „This means 90% of the pages out there have less than 151kb HTML.“

Um das in Relation zu setzen: 2 MB entsprechen etwa 2 Millionen Zeichen. Das füllt locker einen Roman mit 400 Seiten – zusammengepresst auf eine einzige Webseite. Um das Limit zu erreichen, müsste eine Seite rund 60-mal größer sein als der Durchschnitt.

Die Analyse von Seobility, basierend auf 44,5 Millionen gecrawlten Seiten, bestätigt das Bild: Nur 0,82 % aller untersuchten Seiten überschreiten 2 MB.

SEO-Consultant Nikki Pilkington hat dazu eine der schärfsten Warnungen formuliert – und sie hat einen Punkt, den sich jeder Website-Betreiber merken sollte: „If someone contacts you about your website’s HTML file size being a problem, ask them what your current HTML file size is.“ Nur das HTML, nicht die gesamte Seitengröße inklusive Bildern und Scripts. Wer das nicht beantworten kann, verkauft Angst statt Hilfe.

Statt nur über internationale Statistiken zu sprechen, habe ich die unkomprimierte HTML-Dateigröße deutscher Websites tatsächlich gemessen – darunter auch die Seiten von seo-kreativ.de.

seo-kreativ.de im Selbsttest

Unser längster Artikel – mit mehreren Tabellen, Code-Beispielen und ausführlichen Erklärungen – liegt bei 327 KB unkomprimiert. Das sind 16 % des 2-MB-Limits. Selbst eine Verdreifachung des Umfangs würde noch im sicheren Bereich liegen. Die Komprimierungsrate liegt konsistent bei rund 23–25 % der Originalgröße, was zeigt, warum du immer die unkomprimierten Werte prüfen musst.

Vergleich: Wie groß sind bekannte Websites wirklich?

Zum Vergleich habe ich die unkomprimierte HTML-Größe einiger der größten Websites der Welt im Inkognito-Modus mit Chrome DevTools gemessen. Das Ergebnis: Keine einzige Seite überschreitet das 2-MB-Limit.

Selbst YouTube – eine der komplexesten Webanwendungen überhaupt – kommt bei Suchergebnisseiten auf rund 1 MB und bleibt damit deutlich unter dem Limit. Netflix liefert als SPA nur eine schlanke Shell von rund 500 KB; der eigentliche Content wird per JavaScript nachgeladen. Und seo-kreativ.de? Selbst unser längster Artikel nutzt gerade mal 16 % des verfügbaren Budgets.

Das bestätigt die Einschätzung von John Mueller: Das 2-MB-Limit ist für die allermeisten Websites schlicht irrelevant. Wer betroffen ist, hat in der Regel ein grundsätzliches Problem mit Inline-Code oder aufgeblähtem HTML – nicht mit zu viel Content.

Obwohl die Zahl betroffener Seiten gering ist, verdient der Mechanismus Aufmerksamkeit. Das Team von Spotibo hat echte Indexierungstests durchgeführt und dabei Erkenntnisse gewonnen, die über die reine Dokumentation hinausgehen.

Was die Tests zeigen

Spotibo erstellte Testseiten mit 3 MB und 16 MB HTML und reichte sie bei Google zur Indexierung ein. Die 3-MB-Datei wurde nach exakt 2 MB abgeschnitten. Im indexierten Quellcode bricht der Text mitten im Wort ab, gefolgt nur noch vom schließenden </html>-Tag. Alles jenseits der 2-MB-Grenze wurde stillschweigend ignoriert.

Das Tückische daran: Der Status in der Google Search Console zeigte trotzdem „URL is on Google“ und „Page is indexed“ – vollkommen ohne Warnung oder Fehlermeldung. Es gab keinerlei Hinweis darauf, dass Inhalte abgeschnitten wurden.

Die 16-MB-Datei wurde von Google nicht einmal verarbeitet. Beim Versuch, die Indexierung anzustoßen, erschien eine Fehlermeldung.

Kollateralschaden: Wenn strukturierte Daten mitten im Code brechen

Ein Aspekt, der in der bisherigen Berichterstattung kaum beachtet wird: Die Truncation betrifft nicht nur Fließtext, sondern auch maschinenlesbare Daten. Und hier wird es richtig tückisch.

Viele Websites platzieren ihre strukturierten Daten (JSON-LD) am Ende des HTML-Dokuments – oft direkt vor dem schließenden </body>-Tag. Das ist technisch korrekt und eine gängige Best Practice. Aber bei einer Seite, die das 2-MB-Limit überschreitet, wird genau dieser Bereich abgeschnitten.

Das Problem: JSON-LD ist streng syntaktisch. Wenn Google den Code mittendrin kappt, fehlen schließende Klammern, Anführungszeichen oder Kommas. Die gesamte strukturierte Daten-Auszeichnung wird dadurch ungültig – nicht nur der abgeschnittene Teil, sondern der komplette Block. Stell dir ein FAQ-Schema mit 30 Fragen vor, bei dem Google nach Frage 22 aufhört zu lesen: Die fehlende schließende Klammer macht das gesamte JSON ungültig, und Google verwirft alle 30 FAQ-Einträge, nicht nur die letzten acht.

Dasselbe gilt für Product-Schema mit vielen Varianten, Review-Aggregationen oder BreadcrumbList-Markup. Jedes Mal, wenn der JSON-LD-Block die 2-MB-Grenze überspannt, riskierst du den vollständigen Verlust deiner Rich Results – ohne dass die Search Console einen Schema-Fehler meldet, weil das URL Inspection Tool ja den vollständigen Code sieht.

Wer wirklich betroffen sein kann

Es sind nicht nur schlecht gepflegte Hobby-Seiten. Komplexe Websites mit umfangreichen Filtern, Tracking-Setups oder dynamischen Inhalten können an das Limit stoßen. Die typischen Risikogruppen im Überblick:

E-Commerce-Seiten mit clientseitigem Filtering stehen ganz oben auf der Liste. Shops auf Magento oder Shopify, die große JSON-Objekte für Produktfilter direkt ins HTML schreiben, sind eine typische Risikogruppe – vor allem bei vielen Produktvarianten.

Single-Page Applications (SPAs) mit Inline-Bundles bilden die zweite Kategorie. Wenn JavaScript und CSS nicht in externe Dateien ausgelagert werden, sondern komplett im HTML-Dokument landen, summiert sich das schnell.

Base64-kodierte Bilder im HTML sind ein oft unterschätzter Faktor. Wer Bilder per Data-URL direkt ins Markup einbettet statt sie als externe Dateien zu referenzieren, bläht das HTML-Dokument massiv auf – ein einzelnes hochauflösendes Bild kann hunderte Kilobyte ausmachen.

Page-Builder wie Elementor oder WPBakery erzeugen bei komplexen Layouts erheblichen zusätzlichen HTML-Code, der sich mit jedem Element weiter akkumuliert.

Infinite-Scroll-Implementierungen, die beim Scrollen immer mehr Content ins DOM laden, können die Grenze dynamisch überschreiten – auch wenn der initiale HTML-Code unterhalb des Limits liegt.

Es gibt fünf verlässliche Methoden, um die HTML-Dateigröße deiner Seiten zu prüfen. Hier sind sie mit konkreten Anleitungen – denn auf die Details kommt es an.

Methode 1: Chrome DevTools (meine bevorzugte Methode)

Öffne die Entwicklertools mit F12. Wechsle zum Tab „Network“. Lade die Seite komplett neu (Strg+Shift+R). Filtere nach „Doc“ – das zeigt nur das HTML-Dokument an.

Klicke auf den Eintrag deiner Seite und schaue auf die „Size“-Spalte. Du siehst dort zwei Werte: die komprimierte Transfergröße und die unkomprimierte Ressource-Größe. Nur die unkomprimierte Größe (resource) zählt für das 2-MB-Limit. Die GZIP/Brotli-komprimierte Transfergröße ist für die Bewertung irrelevant – sie hilft beim Sparen von Übertragungszeit, schützt aber nicht vor dem Indexierungslimit.

Methode 2: Der Mueller-Test (einfachste Methode)

John Mueller selbst nutzt diesen Ansatz und hat ihn auf Bluesky empfohlen. Die Idee: Suche bei Google nach einem eindeutigen Textzitat, das möglichst weit unten auf deiner Seite steht.

Öffne deine Seite im Browser, scrolle ganz nach unten und kopiere einen eindeutigen Satz – idealerweise etwas, das nur auf dieser einen Seite vorkommt. Suche dann bei Google: site:deinedomain.de "dein exaktes Zitat von weit unten". Wenn Google die Seite als Ergebnis anzeigt, ist dein Content vollständig indexiert. Findet Google den Text nicht, obwohl die Seite grundsätzlich indexiert ist, könnte sie am 2-MB-Limit abgeschnitten worden sein.

Der Vorteil: Dieser Test prüft genau das, was dich tatsächlich interessiert – ist der Inhalt indexiert? Keine Umwege über Dateigröße-Berechnungen.

Methode 3: Tame the Bots (von Mueller empfohlen)

Dave Smart hat sein Fetch-and-Render-Tool am 6. Februar aktualisiert und eine Checkbox „Cap text to 2MB“ hinzugefügt. John Mueller hat das Tool noch am selben Tag auf Bluesky empfohlen: „If you’re curious about the 2MB Googlebot HTML fetch limit, here’s a way to check.“

So nutzt du es: Gib die URL ein, aktiviere die Checkbox „Cap text to 2MB“, wähle den Googlebot-Mobile-User-Agent und starte den Fetch. Das Tool zeigt dir, wie deine Seite aussieht, wenn sie bei 2 MB abgeschnitten wird – inklusive gerendertem HTML, initialem Quellcode und Screenshot.

Methode 4: Screaming Frog (für Bulk-Checks)

Für eine Website-weite Prüfung ist Screaming Frog das Mittel der Wahl. Achte dabei auf die richtige Spalte: „Size“ zeigt die unkomprimierte Dateigröße – das ist der relevante Wert. „Transferred“ zeigt hingegen die komprimierte Größe und ist für das Limit nicht aussagekräftig. Sortiere nach „Size“ absteigend und markiere alles über 1 MB für eine genauere Prüfung. Seiten über 1,5 MB solltest du als Warnsignal behandeln.

Methode 5: Response-HTML vs. Rendered-HTML vergleichen

Für eine tiefere Analyse – besonders relevant für die KI-Sichtbarkeit – lohnt sich der Vergleich von Response-HTML (was dein Server direkt ausliefert) mit Rendered-HTML (was nach JavaScript-Ausführung im DOM steht). Wenn zwischen beiden ein großer Unterschied besteht, wird deine Seite von Systemen, die kein JavaScript rendern, möglicherweise ganz anders wahrgenommen. Da die meisten KI-Crawler JavaScript nur eingeschränkt oder gar nicht ausführen, zeigt dieser Vergleich deine potenzielle KI-Sichtbarkeitslücke auf.

Bonus: Der Truncation-Gegencheck in 4 Schritten

Du willst nicht nur wissen, ob dein HTML groß ist – du willst wissen, ob Google tatsächlich alles indexiert hat. Dieser systematische Check kombiniert Dateigröße und Indexierung:

Schritt 1 – Größe messen: Prüfe die unkomprimierte HTML-Größe per Chrome DevTools oder Screaming Frog (Methode 1 oder 4). Liegt sie unter 500 KB, kannst du hier aufhören – du bist sicher.

Schritt 2 – Anker setzen: Identifiziere auf deiner Seite ein eindeutiges Textelement möglichst weit unten im Quellcode. Das kann ein Satz im letzten Absatz sein, eine FAQ-Antwort am Ende, oder ein Ankerpunkt im Footer-Content. Kopiere diesen Text exakt.

Schritt 3 – Mueller-Test durchführen: Suche bei Google: site:deinedomain.de "dein exakter Text vom Seitenende". Findet Google ihn, ist die Seite vollständig indexiert. Findet Google ihn nicht, prüfe im nächsten Schritt, ob es an der Truncation liegt.

Schritt 4 – Gegenprobe mit Text von oben: Wiederhole die Suche mit einem eindeutigen Text vom Seitenanfang. Findet Google den Text oben, aber nicht den Text unten, hast du einen starken Indikator für Truncation. Findet Google auch den oberen Text nicht, ist die Seite möglicherweise gar nicht indexiert – dann liegt das Problem woanders.

Dieser Gegencheck kostet fünf Minuten und ist zuverlässiger als jede reine Größenmessung, weil er das tatsächliche Indexierungsergebnis prüft.

Wenn du dein Crawl-Budget ohnehin regelmäßig im Blick hast, ergänze die HTML-Dateigröße und den Response-vs-Rendered-Vergleich als feste Checkpoints in deinem technischen SEO-Audit.

Fortgeschritten: Truncation auf der eigenen Domain nachweisen

Die meisten Quellen zu diesem Thema zitieren Spotibos Testbefunde – und die sind solide. Aber als technischer SEO solltest du dich nicht auf Drittquellen verlassen müssen. Du kannst die Truncation auf deiner eigenen Domain reproduzieren. So gehst du vor:

Erstelle eine Testseite auf deiner Domain (z.B. /truncation-test/) und fülle sie mit 2,5 MB generiertem Lorem-Ipsum-Text. Platziere am Anfang, nach exakt 1 MB, nach exakt 2 MB und am Ende jeweils einen eindeutigen Marker-String – etwa MARKER-START-001, MARKER-1MB-002, MARKER-2MB-003 und MARKER-END-004. Reiche die URL über die Search Console zur Indexierung ein und warte 3–7 Tage.

Prüfe anschließend per site:deinedomain.de "MARKER-START-001" alle vier Marker. Die Hypothese: Google findet die Marker vor und bei 2 MB, aber nicht den Marker danach und am Ende. Damit hast du einen empirischen Nachweis auf deiner eigenen Domain – eigene Daten statt Fremdquellen.

Falls du Seiten über oder nahe 2 MB identifiziert hast, sind die Maßnahmen in den meisten Fällen überschaubar.

Deine Checkliste

Das 2-MB-Budget: Wohin gehen deine Bytes?

Es hilft, die 2 MB nicht als abstraktes Limit zu betrachten, sondern als Budget, das verschiedene Bestandteile deines HTML aufbrauchen. Basierend auf unseren eigenen Messungen ergibt sich ein typisches Verteilungsmuster:

Bei einer schlanken Website wie seo-kreativ.de (327 KB größter Artikel) entfallen rund 55 % auf Inline-CSS und Inline-JS – bei JavaScript-lastigen SPAs kann dieser Anteil deutlich höher liegen, wobei die tatsächliche initiale HTML-Größe je nach Rendering-Strategie stark variiert. Das zeigt: Der effektivste Schritt ist fast immer derselbe – Inline-Code in externe Dateien auslagern. Damit schrumpft das HTML-Budget auf den eigentlichen Content, und der ist selbst bei langen Artikeln selten größer als 200–300 KB.

Sinnvoller Zielwert

Halte deine HTML-Dateien idealerweise unter 500 KB. Nicht weil Google es verlangt, sondern weil das einen komfortablen Puffer bietet, die Performance verbessert und dir Spielraum für wachsende Inhalte gibt. Richte in deinem Monitoring ein: Warnstufe bei 1,5 MB, kritisch bei 2 MB. So fällt dir ein schleichendes Aufblähen auf, bevor es zum Problem wird.

Die Reihenfolge zählt: HTML-Quellcode wie ein Notfallkoffer packen

Wenn Google bei 2 MB abschneidet, ist nicht die Gesamtgröße allein entscheidend – sondern was in den ersten 2 MB steht. Denk an deinen HTML-Quellcode wie an einen Notfallkoffer: Was zuerst reinkommt, überlebt sicher. Was ganz unten liegt, geht im Ernstfall verloren.

Eine durchdachte Quellcode-Reihenfolge sieht so aus:

Priorität 1 – Muss in den ersten 100 KB stehen: <head> mit Meta-Tags und Canonical, JSON-LD (strukturierte Daten), <h1> und Einleitung, kritisches CSS (falls nicht extern).

Priorität 2 – Gehört in die erste Hälfte (bis ~1 MB): Hauptinhalt mit allen H2/H3-Überschriften, die wichtigsten internen Links, Above-the-Fold-Elemente.

Priorität 3 – Kann in die zweite Hälfte (1–2 MB): Sekundärer Content (Related Posts, Sidebar), Kommentare, weniger wichtige interne Verlinkungen, nicht-kritische UI-Elemente.

Darf niemals das Limit gefährden: Inline-CSS und Inline-JS (gehört in externe Dateien), Base64-Bilder (gehören als externe URLs referenziert), Page-Builder-Wrapper-Divs (reduzieren oder Markup optimieren).

Der entscheidende Unterschied zu einer generischen „Seite schneller machen“-Empfehlung: Hier geht es nicht um Ladezeit, sondern um Indexierungs-Sicherheit. Selbst wenn deine Seite das Limit nicht erreicht, stellt die richtige Quellcode-Reihenfolge sicher, dass bei einer unerwarteten Größenexplosion (neues Plugin, zusätzliches Tracking, Content-Update) die ranking-relevanten Elemente geschützt bleiben.

Neben dem klassischen Googlebot gibt es einen weiteren Grund, HTML schlank zu halten: KI-Crawler und LLM-basierte Suchsysteme. ChatGPT, Perplexity, Google AI Overviews und andere Systeme sind darauf angewiesen, Webinhalte effizient zu erfassen und zu verarbeiten.

Viele dieser Systeme rendern JavaScript deutlich schlechter als der Googlebot – oder gar nicht. Sie arbeiten bevorzugt mit dem Roh-HTML. Das bedeutet: KI-Crawler reagieren typischerweise empfindlicher auf aufgeblähtes HTML als der Googlebot. Wenn dein Content erst durch JavaScript-Ausführung sichtbar wird, sehen diese Systeme möglicherweise nur einen Bruchteil deiner Inhalte.

Deshalb wird der Vergleich von Response-HTML (was der Server direkt liefert) mit Rendered-HTML (was nach JavaScript-Ausführung entsteht) zu einem zunehmend wichtigen Audit-Kriterium. Er zeigt, wie groß deine KI-Sichtbarkeitslücke tatsächlich ist.

Nach meiner Einschätzung passt Googles Dokumentations-Update in ein größeres Bild: In einer Welt, in der KI-Systeme das Web als Datenquelle nutzen, wird technische Effizienz vom Nice-to-have zum Muss. Das gilt nicht nur für die klassische Google-Suche, sondern für die gesamte Sichtbarkeit in SEO, AIO, GEO und LLMO.

Wer seinen HTML-Code schlank hält, macht es nicht nur dem Googlebot leichter – sondern allen Systemen, die Webinhalte verarbeiten. Einen Überblick dazu, wie sich der gesamte Google-Algorithmus vom Crawling bis zum Ranking verhält, findest du in unserem ausführlichen Leitfaden.

Ist das Crawl-Limit wirklich von 15 MB auf 2 MB gesenkt worden?

Es ist komplizierter als die Schlagzeilen vermuten lassen. Es gibt jetzt zwei klar dokumentierte Phasen: Fetching (Herunterladen) mit dem unveränderten 15-MB-Limit und Indexing (Verarbeitung für die Suche) mit dem 2-MB-Limit für Googlebot. Google bezeichnet es als Dokumentationsklarstellung, nicht als Verhaltensänderung. Das Update vom 11. Februar 2026 formuliert die 2 MB zusätzlich als Beispiel („for example, 2MB“), was die Verbindlichkeit nochmals abschwächt.

Gilt das 2-MB-Limit für die komprimierte oder unkomprimierte Dateigröße?

Für die unkomprimierte Dateigröße. Das ist ein häufiges Missverständnis: Selbst wenn dein Server HTML per GZIP oder Brotli komprimiert überträgt, zählt für das Limit die Originalgröße der Datei. Zum Vergleich: Die seo-kreativ.de Startseite wird mit nur 67 KB übertragen, ist unkomprimiert aber 286 KB groß. In den Chrome DevTools erkennst du den Unterschied an „transferred“ (komprimiert) vs. „resource“ (unkomprimiert).

Kann ich mich auf das URL Inspection Tool verlassen?

Nein – und das ist einer der wichtigsten Punkte dieses Themas. Das URL Inspection Tool nutzt den „Google-InspectionTool“-Crawler mit dem 15-MB-Fetching-Limit. Es zeigt dir den vollständigen Quellcode, auch wenn Googlebot bei der Indexierung bei 2 MB abgeschnitten hat. Spotibo hat das mit konkreten Testdateien nachgewiesen: Die Search Console zeigte „Page is indexed“ ohne Warnung, obwohl der Content bei 2 MB gekürzt wurde.

Was passiert mit Inhalten jenseits der 2 MB?

Google schneidet den HTML-Code nach 2 MB ab und indexiert nur den Teil davor. Das geschieht ohne jede Warnung. Texte, interne Links und strukturierte Daten, die hinter der 2-MB-Grenze liegen, werden für Ranking-Zwecke ignoriert – existieren aber weiterhin auf dem Server und sind für andere Google-Crawler (z.B. Image, Video) mit dem 15-MB-Limit zugänglich.

Zählen Bilder und Videos zum 2-MB-Limit?

Extern referenzierte Bilder und Videos zählen nicht – sie werden separat geladen und haben eigene Limits. Auch externe CSS- und JavaScript-Dateien haben jeweils ihr eigenes 2-MB-Budget. Aber Achtung: Base64-kodierte Bilder (Data-URLs), Inline-Styles und Inline-Scripts zählen zum HTML-Budget und können es erheblich aufblähen. Das Auslagern von Inline-Code in externe Dateien ist deshalb der wirkungsvollste einzelne Optimierungsschritt.

Die nüchterne Bilanz: Das 2-MB-Limit ist für über 99 % aller Websites irrelevant. Aber der Mechanismus dahinter – stille Kürzung ohne Warnung, irreführendes URL Inspection Tool – verdient deutlich mehr Aufmerksamkeit als die reine Zahl.

Was mich bei der Recherche dieses Artikels am meisten überrascht hat: Nicht das Limit selbst, sondern die Tatsache, dass Google keine Warnung in der Search Console ausgibt, wenn Content abgeschnitten wird. Die Seite steht als „indexiert“ da, während am Ende Inhalte, Links und strukturierte Daten stillschweigend ignoriert werden.

Die drei Dokumentationsänderungen in neun Tagen zeigen, dass Google selbst mit der Kommunikation gerungen hat. Die Abschwächung auf „for example, 2MB“ am 11. Februar deutet darauf hin, dass die Grenze weniger rigide ist als zunächst angenommen – was aber nichts daran ändert, dass bei den Spotibo-Tests bei exakt 2 MB abgeschnitten wurde.

Für die Praxis: Prüfe deine wichtigsten Seiten mit dem Mueller-Test oder Tame the Bots. Halte dein HTML unter 500 KB wo möglich. Verlagere Inline-Code konsequent in externe Dateien. Und nimm den Vergleich von Response-HTML vs. Rendered-HTML als neues Audit-Kriterium auf – denn dieser Vergleich wird mit wachsender KI-Sichtbarkeit immer wichtiger.