Text-Ratio und Payload: warum 500 KB HTML für 1'700 Wörter in der KI-Suche verlieren

Eine Seite mit 1'700 Wörtern und 500 KB HTML ist keine Ausnahme, sondern der Normalfall bei Websites, die mit einem hydrierenden JavaScript-Framework gebaut und über die Jahre mit Widgets, Consent-Layern und Trackern ergänzt wurden. Sie sieht im Browser gut aus, lädt akzeptabel schnell und wirkt technisch modern. Für die klassische Google-Suche ist das meist verkraftbar. Für Systeme, die Seiten nicht anschauen, sondern lesen, ist es ein echtes Problem.

Der Grund ist unspektakulär: KI-Suchsysteme arbeiten mit harten Byte-Budgets, ohne Rendering und mit einem Extraktionsschritt, der aus HTML wieder Text machen muss. Je mehr Gerüst zwischen den Sätzen steht, desto teurer und ungenauer wird dieser Schritt. Dieser Artikel rechnet die Bytes einer typischen Seite durch, benennt die dokumentierten Grenzen von Googlebot und ChatGPT und trennt die Massnahmen, die wirklich etwas verschieben, von der Kosmetik.

Was die Text-Ratio wirklich misst

Die Text-zu-HTML-Ratio ist kein Rankingfaktor, sondern eine Diagnosekennzahl: Sie sagt aus, wie viele Bytes reines HTML eine Seite pro Byte sichtbaren Text ausliefert. Google hat das mehrfach unmissverständlich gesagt, John Mueller nannte die Kennzahl für SEO schlicht sinnlos und empfahl, entsprechende Tool-Reports zu ignorieren. Wer die Ratio als Zielwert behandelt und Text hinzufügt, um sie zu verbessern, hat sie missverstanden.

Als Symptom bleibt sie trotzdem brauchbar. Eine Ratio von zwei Prozent bedeutet nicht, dass Google die Seite abstraft, sondern dass 98 Prozent der ausgelieferten Bytes für jedes System, das den Inhalt verstehen will, Rauschen sind. Dieses Rauschen kostet in der klassischen Suche wenig, weil Google seit zwanzig Jahren nichts anderes tut, als Boilerplate zu erkennen und wegzuwerfen. In der KI-Suche kostet es mehr, weil dort weniger Verarbeitungsschritte zwischen Abruf und Antwort liegen.

Die praktische Konsequenz: Die Ratio ist ein Alarmsignal, kein Optimierungsziel. Sie führt zur richtigen Frage, nämlich wohin die Bytes gehen, wenn sie nicht in den Text gehen. Und diese Frage lässt sich beantworten, indem man den Quelltext einer einzelnen Seite anschaut und die Blöcke zusammenzählt.

Die Rechnung: 1'700 Wörter in 500 KB

1'700 deutsche Wörter ergeben rund 11 KB Text, das sind bei 500 KB HTML exakt 2,2 Prozent des Dokuments. Die Rechnung ist einfach nachvollziehbar: Ein deutsches Wort hat im Schnitt etwa 5,4 Zeichen, mit Leerzeichen und Interpunktion kommt man auf rund 6,4 Zeichen pro Wort. 1'700 mal 6,4 ergibt etwa 10'900 Zeichen, in UTF-8 also knapp 11 KB, weil Umlaute zwei Bytes brauchen und der Rest einen.

Die verbleibenden 489 KB verteilen sich bei einer Seite dieses Typs ungefähr so:

Die genauen Werte verschieben sich von Projekt zu Projekt, die Grössenordnung nicht. Der grösste Einzelposten ist fast immer der serialisierte State: Frameworks, die im Browser weiterarbeiten sollen, schreiben die Daten, mit denen der Server gerendert hat, ein zweites Mal als JSON ins Dokument. Bei einer Seite mit Produktlisten, Filtern oder einem grossen Navigationsbaum wird dieser Block schnell grösser als der gesamte redaktionelle Inhalt der Website.

Zum Vergleich: Laut dem Web Almanac 2025 der HTTP Archive lag das HTML-Dokument einer medianen Startseite bei 22 KB, bei einem Gesamtgewicht von 2'862 KB auf dem Desktop und 2'559 KB mobil. Das Gewicht steckt also im Normalfall in Bildern (1'058 KB) und JavaScript (697 KB), nicht im Dokument. Eine Seite mit 500 KB HTML liefert das Zwanzigfache des Medians aus, ohne dafür mehr Inhalt zu transportieren.

Warum die harten Grenzen jetzt relevant werden

Beide grossen Abrufsysteme haben dokumentierte Byte-Obergrenzen, und beide sind niedriger, als die meisten annehmen. Googlebot lädt laut dem Search-Central-Beitrag vom März 2026 pro URL nur die ersten 2 MB, PDFs ausgenommen. Wird das Dokument grösser, bricht der Abruf exakt an dieser Stelle ab. Der geladene Teil geht an die Indexierung und an den Web Rendering Service, als wäre er das vollständige Dokument. Alles danach wird nicht abgerufen, nicht gerendert und nicht indexiert.

ChatGPT ist noch strikter, aber anders. Seiten über 4 MB werden nicht gekürzt, sondern mit HTTP 400 abgelehnt. Was durchkommt, wird beim Ablegen im Lese-Cache von HTML in Markdown umgewandelt. Dabei fallen Skripte, iframes und JSON-LD heraus. Alt-Texte überleben, und auch per CSS ausgeblendeter Text wird extrahiert. Der Robot führt kein JavaScript aus. Das ist keine Randnotiz, sondern verschiebt die Prioritäten: Strukturierte Daten erreichen das Modell auf diesem Weg gar nicht, während der sichtbare Textkörper alles trägt.

Dazu kommt der Befund aus der gemeinsamen Analyse von Vercel und MERJ: Keiner der grossen KI-Crawler rendert JavaScript. GPTBot lädt in 11,5 Prozent der Anfragen JavaScript-Dateien herunter, ClaudeBot in 23,84 Prozent, ausgeführt wird nichts davon. Wer Inhalte erst im Browser einsetzt, ist für diese Systeme unsichtbar. Server-seitiges Rendern ist damit keine Performance-Entscheidung mehr, sondern eine Sichtbarkeitsvoraussetzung.

Der Extraktionsschritt entscheidet, nicht die Dateigrösse

Nicht die Grösse des Dokuments bestimmt das Ergebnis, sondern wie sauber sich der Inhalt aus dem Dokument herauslösen lässt. Jedes System, das eine Seite zitieren will, führt eine Boilerplate-Erkennung durch: Es trennt den Hauptinhalt von Navigation, Footer, Bannern und Werbung. Diese Erkennung ist Heuristik, keine Wissenschaft. Sie arbeitet mit semantischem HTML, Textdichte pro Knoten und Wiederholungsmustern über mehrere Seiten desselben Hosts.

Genau hier verlieren aufgeblähte Seiten. Wenn der eigentliche Artikel in einer tiefen Verschachtelung aus Layout-Containern steckt, jeder Absatz in ein zusätzliches Element mit fünf Utility-Klassen gewickelt ist und daneben ein 40 KB grosses Mega-Menu mit hundert Links liegt, dann ist die Textdichte im Inhaltsbereich nicht auffällig höher als im Gerüst. Die Extraktion nimmt dann entweder zu viel mit, was die Passage verwässert, oder zu wenig, was sie abschneidet.

Der Gegenentwurf ist unspektakulär und wirksam: ein klar abgegrenzter Hauptinhaltsbereich, echte Überschriftenebenen statt gestylter Absätze, Listen und Tabellen als solche ausgezeichnet, und alles Wiederkehrende so kompakt wie möglich. Das ist dieselbe Arbeit, die auch die zitierfähige Absatzstruktur verlangt, nur eine Ebene tiefer im Markup. Beides zusammen entscheidet, ob eine Passage überhaupt sauber freigestellt bei einem Modell ankommt.

Was tatsächlich Bytes verschiebt

Die wirksamen Massnahmen setzen an der Ursache an, nicht am Ergebnis, und sie lassen sich nach Hebelwirkung ordnen. Minifizierung und das Entfernen von Kommentaren stehen dabei ganz unten: Sie sparen typischerweise 10 bis 20 Prozent und ändern an der Struktur nichts.

Der grösste Hebel ist der serialisierte State. Wer prüft, welche Daten das Framework wirklich im Browser braucht, und den Rest nicht ins Dokument schreibt, entfernt oft die Hälfte des HTML in einem Schritt. Bei modernen Setups mit Server-Komponenten fällt dieser Block ohnehin weitgehend weg, was ein handfestes Argument für die Wahl des Frameworks ist und nicht bloss Geschmackssache.

An zweiter Stelle steht der Drittanbieter-Code. Consent-Manager, Chat-Widgets, Heatmap-Tools und Tag-Manager schreiben Konfiguration direkt ins Dokument. Vieles davon lässt sich verzögert laden oder ganz streichen. Der Nebeneffekt ist messbar: Genau dieser Code ist auch der Hauptgrund für schlechte Interaction to Next Paint-Werte, wie wir im Beitrag zu Core Web Vitals und INP ausgeführt haben.

An dritter Stelle steht die Navigation. Ein vollständig ausgeliefertes Mega-Menu mit allen Unterpunkten aller Ebenen kostet auf jeder einzelnen Seite dieselben Bytes und erzeugt zusätzlich Hunderte interner Links, die den Crawl-Budget-Verbrauch in die Höhe treiben, ohne dem Nutzer zu helfen. Zwei Ebenen im Markup und der Rest auf einer Übersichtsseite reichen fast immer.

Wo die Grenze des Arguments liegt

Payload-Arbeit gewinnt keine Rankings, sie beseitigt nur einen Grund, nicht gefunden zu werden. Diese Einordnung ist wichtig, weil technische Massnahmen leicht zum Selbstzweck werden. Eine Seite, die zur Suchanfrage nicht passt, wird auch mit 15 KB HTML nicht zitiert. Und eine Seite auf Position 40 hat kein Byte-Problem, sondern ein Relevanz- und Autoritätsproblem.

Wir sehen das an der eigenen Domain deutlich. Die Auswertung der Search Console für dlm-digital.ch zeigt über sechs Monate 131'465 Impressionen auf Seitenebene bei 138 Klicks, und 63 Prozent aller Impressionen liegen jenseits von Position 20. Das ist kein Payload-Befund, sondern ein Positionsbefund. Wer in dieser Lage zuerst an der Dateigrösse arbeitet, optimiert an der falschen Stelle.

Die richtige Reihenfolge lautet deshalb: erst Relevanz und Substanz, dann Struktur, dann Payload. Payload ist der Schritt, der verhindert, dass die ersten beiden Schritte auf dem Weg zum Modell verloren gehen. Als Einstieg reicht ein einfacher Test, für den es kein Tool braucht: Seite aufrufen, Quelltext anzeigen, Dateigrösse notieren, den Fliesstext herauskopieren und beides ins Verhältnis setzen. Liegt das Ergebnis unter fünf Prozent, lohnt sich ein genauer Blick. Wer dabei Unterstützung braucht, findet den Einstieg über unseren SEO-Check oder direkt über die SEO- und GEO-Betreuung.