Vor einiger Zeit kam die Frage auf, ob Googles 2‑MB‑Limit für das Crawlen von HTML‑Dokumenten in der Praxis überhaupt ein Problem darstellen könnte. Neue Daten widerlegen jede Sorge: Selbst große Websites bleiben weit unter dieser Grenze. Wenn du also dachtest, du müsstest den Code deiner Seite wegen dieser Beschränkung „abspecken“, kannst du beruhigt durchatmen.
Was steckt hinter der 2‑MB‑Grenze?
Googles Crawler lädt beim Besuch einer Seite zunächst nur den eigentlichen HTML‑Quelltext herunter – also all die Buchstaben, Zahlen und Zeichen, die den strukturellen Rahmen deiner Website bilden. Bilder, CSS‑Dateien oder JavaScript‑Bibliotheken zählen dabei nicht mit. Rein textbasiert sind 2 MB enorm viel: Um auf diese Größe zu kommen, müsstest du über zwei Millionen Zeichen im Quelltext unterbringen. Das schaffen eigentlich nur synthetisch erzeugte oder fehlerhafte Seiten.
Das klingt banal, aber man vergisst leicht, dass Suchmaschinen zunächst nur diese Textinformationen auswerten. Falls du also Sorge hattest, dein komplexes Seitengerüst könnte abgeschnitten werden – die Wahrscheinlichkeit dafür ist verschwindend gering.
Was zeigen reale Messungen?
Die HTTPArchive‑Analyse, die regelmäßig Millionen von Websites auswertet, gibt ziemlich klare Antworten. Das Median‑HTML‑Gewicht liegt bei etwa 33 KB. Selbst am oberen Ende – beim 90‑Prozent‑Perzentil – erreichen die gemessenen Seiten gerade einmal rund 155 KB. Das heißt: 90 Prozent aller Sites bleiben deutlich unter 200 KB, während 2 MB erst ganz, ganz am Ende dieser Verteilung vorkommen – bei einer Handvoll Ausreißer, die wahrscheinlich durch Inline‑Skripte, umfangreiche Styles oder Copy‑Paste‑Fehler aufgebläht sind.
Interessant ist auch die Beobachtung, dass zwischen Startseiten und Unterseiten kaum Unterschiede bestehen. Die inneren Seiten werden erst ab dem 75‑Prozent‑Perzentil merklich größer. Bei den verrückten 100‑Prozent‑Fällen explodieren die Werte zwar theoretisch auf Hunderte Megabyte – was aber so realistisch ist wie ein HTML‑Romannachmittag.
Mobile vs. Desktop – kaum Unterschiede
Lange Zeit gingen viele davon aus, dass Desktop‑Versionen deutlich umfangreicher wären. Doch die Daten zeigen heute: Die Gewichtsunterschiede zwischen Mobil‑ und Desktop‑HTML sind minimal. In der Praxis liefern viele Websites ohnehin ein identisches Dokument an beide Gerätetypen aus, was die Wartung erleichtert – und sich offenbar nicht negativ auf Crawl‑Effizienz auswirkt. Natürlich kann sich dadurch der gesamte Page‑Load erhöhen, aber nicht das, was Google für die Indexierung ausliest.
Wenn du also auf Responsive Design setzt und deine Inhalte in einem einzigen HTML‑Dokument auslieferst, schadet das nicht. Google bekommt denselben Code und verarbeitet ihn problemlos.
Was das für dich bedeutet
Ganz ehrlich: Die 2 MB sind kein Thema, über das du nachts nachgrübeln musst. Selbst komplexe Inhalte, lange Landingpages oder Newsletter‑Archive bewegen sich meist in der Größenordnung von maximal 200 – 300 KB. Erst wenn du ewig lange Skripte oder Inline‑CSS direkt in den HTML‑Body packst, kommst du gefährlich in die Nähe des Limits.
Wenn du also feststellst, dass der Googlebot eine Seite nicht vollständig erfasst, liegt das fast immer an anderen Dingen: blockierte Ressourcen, Weiterleitungsketten, kaputte Scripts oder Timeouts. Nicht am Gewicht des Quellcodes.
Neue Tools zum Testen: „Tame the Bots“ & Co.
Der Entwickler Dave Smart von „Tame the Bots“ hat kürzlich seine Analyse‑Tools erweitert. Die Plattform simuliert jetzt den Punkt, an dem Google theoretisch beim 2‑MB‑Limit stoppen würde. Du kannst damit prüfen, wie dein HTML bis zu dieser Grenze dargestellt wird. Spannend ist das vor allem für technische SEOs, die einmal sehen wollen, wie ein Crawler den Seiteninhalt blockweise wahrnimmt.
Allerdings liefert das Tool keine exakte Angabe, wie groß dein HTML tatsächlich ist – es zeigt nur, was passiert, wenn Google die 2 MB erreicht. Wenn du konkrete Zahlen willst, brauchst du andere Helfer.
Nützliche Alternativen zur Größenkontrolle
Ich hab zwei einfache Online‑Prüfer ausprobiert und fand beide erstaunlich direkt:
- Toolsaday Page Size Checker: Minimalistisch, aber zuverlässig. Du gibst eine URL ein und siehst sofort den HTML‑Umfang in KB. Perfekt, wenn du nur schnell sicherstellen willst, dass du weit unterhalb der magischen Grenze bleibst.
- Small SEO Tools Checker: Etwas flexibler – hier kannst du bis zu zehn URLs gleichzeitig testen. Ideal, wenn du die Größen mehrerer Unterseiten vergleichen möchtest.
Beide Varianten liefern ähnliche Ergebnisse, und in der Regel wirst du dich wundern, wie winzig deine Seiten tatsächlich sind. Eine WordPress‑Startseite mit sauberem Code und ein bisschen Inline‑CSS liegt oft unter 100 KB. Selbst umfangreiche Online‑Shops bleiben selten über 300 KB.
Praktische Tipps, falls du wirklich hohe Werte misst
Vielleicht gehörst du ja doch zu den Ausnahmen. Wenn dein HTML auffällig groß ist, kannst du meist mit einfachen Schritten gegensteuern:
- Trenne Skripte und Styles aus dem Hauptdokument aus und lade sie extern.
- Vermeide zu viele Inline‑SVGs oder Base64‑Bilder im Code.
- Setze auf saubere Template‑Strukturen, statt denselben Codeblock mehrfach einzubetten.
- Nutze Minifizierung (HTML Minifier, Gzip, Brotli etc.), um Leerzeichen und Kommentare zu komprimieren.
In wenigen Minuten lässt sich damit oft eine Halbierung deines HTML‑Gewichts erreichen – nicht weil Google das verlangt, sondern weil jede Kilobyte weniger den Seitenaufbau beschleunigt.
Warum solche Mythen überhaupt entstehen
Das SEO‑Universum liebt Grenzwerte, und 2 MB klingt eben nach einer harten Zahl, die man „optimieren muss“. In Wirklichkeit ist sie aber eher eine technische Sicherheitsgrenze von Google, damit Crawler nicht in endlosen Dokumenten stecken bleiben. Die allermeisten Sites kratzen nicht einmal an 10 % dieser Grenze. Trotzdem findet das Thema regelmäßig den Weg in Foren, vermutlich, weil es sich griffig anhört.
Aus meiner Erfahrung neigen wir SEOs dazu, auch aus Nebensätzen von Google Fragen zu basteln, die in der Praxis kaum Relevanz haben. Wer schon einmal eine große Site mit Millionen von URLs verwaltet hat, weiß: Die entscheidenden Probleme liegen anderswo – beim Crawl‑Budget, der internen Verlinkung oder bei fehlerhaften Canonicals, aber nicht beim HTML‑Volumen.
Kurz getestet: Wie viel ist 2 MB wirklich?
Nur um ein Gefühl zu bekommen: Wenn du 2 Millionen Zeichen als reinen Text öffnest, würdest du etwa 2 000 Seiten eines gedruckten Romans füllen. Wie wahrscheinlich ist es, dass dein HTML‑Code so viel Text enthält? Genau.
Selbst bei einem technisch komplexen CMS mit Tracking‑Codes, eingebetteten JSON‑LD‑Daten und Inline‑CSS bleibt der Quelltext oft bei rund 200 – 250 KB. Dafür müsstest du also das Achtfache deiner jetzigen Struktur erzeugen, um auch nur in die Nähe der Crawl‑Grenze zu kommen. Das schafft niemand aus Versehen.
Also: worauf lieber achten?
Wenn du deine Energie in nachhaltige Optimierungen stecken willst, konzentriere dich lieber auf Dinge wie:
- Saubere interne Verlinkung – damit der Googlebot deine wichtigen Seiten schneller findet.
- Server‑Antwortzeiten – ein schneller First Byte Load spart dem Crawler und deinen Nutzern Zeit.
- Strukturierte Daten – sorgen dafür, dass Google Inhalte besser versteht, anstatt mit der Dateigröße zu kämpfen.
- Fehlerfreie Statuscodes – nichts blockiert den Indexierungsfluss so stark wie fehlerhafte Weiterleitungen.
All das bringt deutlich mehr Ranking‑Wirkung als sich in Zahlen über 2 MB zu verbeißen.
Mein Fazit
Die neuen Daten zeigen schwarz auf weiß: Das 2‑MB‑Limit ist vollkommen ausreichend. Es gibt keinen Grund, HTML‑Größen manuell nach unten zu pressen, solange deine Seite technisch sauber und inhaltlich strukturiert ist. Und falls du zu den wenigen Ausreißern gehörst, helfen Tools wie „Tame the Bots“ oder die einfachen Größen‑Checker dabei, das zu prüfen – meistens nur, um bestätigt zu bekommen, dass alles im grünen Bereich liegt.
Für 99,99 % aller Webprojekte gilt daher: Vergiss den Mythos von der Crawl‑Grenze. Fokussiere dich lieber darauf, Inhalte verständlich, schnell und zugänglich zu machen – darauf kommt es bei Google weit mehr an als auf ein paar zusätzliche Kilobyte HTML.
