Kategorie: Technical SEO · ca. 15 Min. Lesezeit · Wissens-Artikel · Autorin: Anna Hartung
Wenn du eine Website auf Next.js, React oder einem anderen komponentenbasierten Framework betreibst und einen Semrush-Site-Audit geöffnet hast, ist dir die Warnung vermutlich schon begegnet: „Niedriges Text-zu-HTML-Verhältnis". Das klingt wie ein Urteil — als hätte Google deine Seiten still abgewertet, weil sie zu code-lastig sind. In der Praxis ist es eines der am häufigsten missverstandenen Signale im technischen SEO, und auf einem modernen Stack feuert es laufend bei Seiten, die völlig gesund sind.
Dieser Leitfaden geht über das übliche „Ignorier es"-Einzeiler-Wissen hinaus. Wir klären, was die Kennzahl tatsächlich misst, warum Frameworks wie Next.js sie konstruktionsbedingt auslösen, ob Google sie überhaupt als Rankingfaktor behandelt und — der Teil, der wirklich zählt — wie du eine harmlose Warnung von einem echten Rendering-Problem unterscheidest, das sich dahinter verstecken kann.
Wichtigste Erkenntnisse
| Punkt | Details |
|---|---|
| Kein Google-Zielwert | Google dokumentiert Crawling, Rendering und Indexierung, definiert aber keine Text-zu-HTML-Schwelle für Rankings. |
| Next.js löst es konstruktionsbedingt aus | Komponenten-Frameworks erzeugen tiefes Struktur-Markup, Hydration-Daten und Skripte, daher liest sich das Verhältnis selbst bei kerngesunden Seiten niedrig. |
| Die eigentliche Frage ist das Rendering | Frage, ob dein Content in dem Server-HTML steht, das Crawler erhalten — nicht, ob ein Prozentwert irgendeine Schwelle überschreitet. |
| Nicht jeder Crawler führt JavaScript aus | Google weist ausdrücklich darauf hin, dass nicht alle Bots JavaScript ausführen können; nützliches initiales HTML bleibt daher die robuste Basis. |
| Behebe die Ursache, nicht die Zahl | Text aufzublähen, um das Verhältnis zu heben, bewegt kein Ranking; löse Thin Content oder eine Rendering-Lücke, und das Verhältnis folgt von selbst. |
Ist das Text-zu-HTML-Verhältnis ein Google-Rankingfaktor?
Google definiert in seiner Search-Dokumentation keinen Text-zu-HTML-Zielwert. Die aktuelle Dokumentation zu JavaScript SEO beschreibt Crawling, Rendering und Indexierung; die Performance-Leitlinien arbeiten mit gemessenen Lade- und Interaktionswerten, nicht mit dem Verhältnis von Text- zu Markup-Bytes. Google-Vertreter haben zudem öffentlich erklärt, dass dieses Verhältnis kein Rankingfaktor ist.
Woher stammt also der Wert „ideales Verhältnis von 25–70 %", den manche Tools zitieren? Nicht von Google. Diese Spanne ist Folklore, die unter Audit-Tools und SEO-Blogs zirkuliert; sie beschreibt eine Korrelation, die früher auf einfachen statischen Seiten galt — textlastige Seiten waren tendenziell sauberer und leichter — keine Regel, die Google durchsetzt. Sie als Zielwert zu behandeln, ist genau der Fehler, vor dem Mueller gewarnt hat.
Das macht die Warnung aber nicht bedeutungslos. Es macht sie indirekt. Eine wirklich aufgeblähte Seite — Megabytes an Markup, Skripten und Styles um einen Satz Content herum — kann langsam sein, ineffizient crawlbar und dünn in der Substanz. Nichts davon ist „das Verhältnis"; es sind eigenständige, reale Probleme, auf die ein niedriges Verhältnis manchmal hindeutet. Das Verhältnis ist die Motorkontrollleuchte, nicht der Motor.
Was misst Semrush eigentlich — und warum löst Next.js es aus?
Die aktuelle Liste der Site-Audit-Prüfungen von Semrush nennt für diese Warnung eine Schwelle von 10 % oder weniger. Semrush klassifiziert sie als Warnung und nicht als Fehler. Das ist ein werkzeugspezifischer Diagnosewert, keine von Google veröffentlichte Schwelle; er sollte zusammen mit Rendering, Performance, Inhalt und Indexierungsdaten bewertet werden.
Nun betrachte, wie eine Next.js- oder React-Seite aufgebaut ist. Das Framework liefert einen Baum aus Komponenten, jede in ihr eigenes Struktur-Markup verpackt. Layout-Primitive, Design-System-Wrapper, Navigation, Card-Grids, Filter und wiederkehrende UI-Elemente erzeugen <div> um <div> — die „Divitis", die visuelle Builder und Komponentensysteme als Nebeneffekt produzieren. Darüber liegt die eigene Laufzeit des Frameworks: Hydration-Payloads, inline eingebetteter JSON-State, Preload-Tags und Skript-Referenzen im <head>. Das Ergebnis ist eine Seite, deren Markup konstruktionsbedingt groß ist, während der sichtbare Text einer bestimmten Seite — etwa eine Leistungsübersicht oder ein Portfolio-Grid — vergleichsweise kurz ausfällt. Teilt man das eine durch das andere, landet man unter 10 %, ohne dass irgendetwas falsch ist.
Genau deshalb häuft sich die Warnung bei exakt den Seitentypen, bei denen sie am wenigsten aussagekräftig ist: Listen- und Index-Seiten (Blog-Indizes, Tag-Archive, Case-Study-Übersichten), Rechts- und Utility-Seiten (Datenschutz, AGB, Marken-Disclaimer) und designgeführte Landingpages, die mit Bildern und Komponenten statt mit langem Text starten. E-Commerce- und Shopify-Shops trifft es aus demselben Grund — Produkt-Grids plus Drittanbieter-Skripte blähen den Nenner auf. Die Kennzahl wurde für ein Web aus handgeschriebenen HTML-Dokumenten entworfen. Komponenten-gerenderte Anwendungen passen schlicht nicht in ihre Annahmen.
Die Frage, die wirklich zählt: Kann Google deinen Content sehen?
Hier ist der Perspektivwechsel, der das Ganze von einer Eitelkeits-Kennzahl in eine nützliche Diagnose verwandelt. Die richtige Frage war nie „liegt mein Verhältnis über irgendeiner Zahl?". Sie lautet: „Ist mein echter Content in dem HTML vorhanden, das Crawler erhalten — und können Suchmaschinen ihn zuverlässig rendern?" Auf einem JavaScript-Framework hat diese Frage echtes Gewicht, und es lohnt sich, die Mechanik zu verstehen.
Google beschreibt für JavaScript-Seiten drei Phasen: Crawling, Rendering und Indexierung. Es liest die HTTP-Antwort zunächst auf crawlbare Links und stellt indexierbare Seiten anschließend in eine Render-Queue, in der der Web Rendering Service JavaScript ausführt. Google weist darauf hin, dass eine Seite länger als einige Sekunden in dieser Queue bleiben kann, veröffentlicht aber keine garantierte Renderingdauer. Laut Dokumentation können alle geeigneten 200-Seiten gerendert werden; server-gerendertes HTML „überspringt" den Renderer daher nicht wörtlich. Der praktische Vorteil ist einfacher: Wesentlicher Content und Links sind bereits in der Antwort verfügbar, auch bevor Client-Code erfolgreich läuft.
Hier entscheidet die Rendering-Strategie alles, und Next.js gibt dir die volle Bandbreite:
Beim Client-Side Rendering (CSR) kann der Server nur eine Anwendungshülle plus Skripte zurückgeben. Google kann JavaScript rendern, doch die Seite hängt dann davon ab, dass Skripte, Ressourcen und Datenabfragen beim Rendering erfolgreich abgeschlossen werden. Wichtige Links, die erst danach entstehen, werden außerdem später entdeckt als Links in der Serverantwort. Eine CSR-Seite kann deshalb gleichzeitig ein niedriges Text-zu-HTML-Verhältnis und ein echtes Renderingproblem haben; das Verhältnis ist lediglich der Anlass zur Prüfung.
Beim Server-Side Rendering (SSR) und bei der statischen Generierung (SSG) können wesentlicher Content, Links und Metadaten bereits in der HTTP-Antwort stehen. Next.js unterstützt außerdem gecachte und routenspezifische Renderingstrategien, sodass öffentliche Marketing- und Redaktionsseiten nicht wie eingeloggte Anwendungsscreens funktionieren müssen. Der Punkt ist nicht „nutze nie Client-Rendering", sondern: Mache wichtigen öffentlichen Content nicht unnötig von einem fragilen Client-only-Pfad abhängig.
Wenn die Semrush-Warnung also auftaucht, ist der produktive Schritt nicht, dem Prozentwert hinterherzujagen. Es ist die Bestätigung, dass der wesentliche Content der Seite in der Server-Antwort vorhanden ist. Die schnellsten Checks: den Quelltext der Seite ansehen (nicht den gerenderten DevTools-DOM) und nach einem Kernsatz suchen; und die URL durch die URL-Prüfung der Google Search Console schicken, um das tatsächlich gerenderte HTML zu sehen, das Google erfasst hat. Stehen deine Überschriften und Kernabsätze dort, ist ein Verhältnis von 7 % kein Thema. Fehlen sie im rohen HTML und erscheinen erst, nachdem JavaScript läuft, hast du etwas Behebenswertes gefunden — und es hat nichts mit dem Verhältnis zu tun.
Warum initiales HTML auch jenseits von Google wichtig bleibt
Crawler haben unterschiedliche Fähigkeiten. Google selbst empfiehlt Server-Side Rendering oder Pre-Rendering weiterhin auch deshalb, weil nicht alle Bots JavaScript ausführen können. Bot-Dokumentationen erklären häufig User Agents und Zugriffskontrollen; daraus lässt sich aber nicht automatisch das genaue Renderingverhalten jedes nachgelagerten Abrufsystems ableiten. Die sichere technische Annahme bleibt deshalb bescheiden: Liefere den wesentlichen öffentlichen Content im initialen HTML, statt von jedem Crawler eine vollständige Browser-Sitzung zu verlangen.
Das garantiert keine Aufnahme in eine Antwortmaschine, und Client-Side Rendering schließt eine Seite nicht automatisch aus. Es entfernt lediglich eine vermeidbare Abhängigkeit: Systeme, die brauchbares HTML abrufen, können die Seite auslesen, ohne dieselbe JavaScript-Unterstützung, dasselbe Timing und denselben Netzwerkzugriff wie ein Nutzerbrowser zu benötigen.
Wann die Warnung wirklich gefahrlos zu ignorieren ist
Zusammengenommen ist ein niedriges Text-zu-HTML-Verhältnis fast immer harmlos, wenn die Seite ihre Aufgabe erfüllt und ihr Content server-gerendert ist. Ein Blog-Index, der Beiträge auflistet, eine Tag-Seite, eine Datenschutzerklärung, eine visuell reiche Landingpage, auf der das Framework tiefes Komponenten-Markup erzeugt — diese reißen die 10-%-Schwelle routinemäßig, und das ist erwartbar. Google bewertet das Verhältnis nicht; es fragt, ob die Seite ihre Intention erfüllt, ob es den Content rendern und indexieren kann und ob die Seite intern verlinkt und erreichbar ist. Wenn ein Mensch innerhalb weniger Sekunden erkennt, was die Seite bietet, und der Kerntext im rohen HTML vorhanden ist, ist die Warnung Rauschen. Eine solche Seite mit Fülltext aufzublähen, um die Zahl zu „beheben", bringt für Rankings nichts und schadet oft dem Design und der Conversion-Rate, für die sie gebaut wurde.
Wann ein niedriges Verhältnis ein verfolgenswertes Symptom ist
Die Warnung verdient deine Aufmerksamkeit, wenn sie mit anderen Signalen einhergeht — das ist die Disziplin. Behandle sie als Anlass zur Untersuchung und suche dann nach den Dingen, die wirklich zählen:
Eine Seite mit tatsächlich wenig Content hinter dem Markup (das klassische Beispiel: eine Leistungsseite mit zwei Sätzen und einem Grid aus Cards), die auf eine kommerzielle oder informationelle Suchanfrage zielt, für die ihr die Tiefe zum Gewinnen fehlt. Wenn Semrush für dieselbe URL „Low Word Count" oder „Thin Content" meldet — das sind die aussagekräftigeren Warnungen, und ein niedriges Verhältnis daneben untermauert eine echte Lücke. Wenn die Google Search Console schwache Impressionen zeigt oder die Seite unter „Gecrawlt – zurzeit nicht indexiert" oder „Erkannt – zurzeit nicht indexiert" liegt. Und das oben genannte Rendering-Warnzeichen: wichtiger Content, der nur nach Client-seitiger Ausführung vorhanden ist und im initialen HTML fehlt. In jedem dieser Fälle ist das Verhältnis nicht die Krankheit — niedrige Wortzahl, Thin Content, schwache Intent-Abdeckung oder eine Rendering-Abhängigkeit ist es. Behebe diese, und das Verhältnis erledigt sich als Nebenprodukt.
Ein konkreter Fallstrick ist eine robots.txt-Regel, die für das Rendering benötigte JavaScript- oder CSS-Dateien blockiert. Google erklärt, dass JavaScript aus blockierten Dateien oder auf blockierten Seiten nicht gerendert wird. Ob das die Indexierung verändert, hängt davon ab, welcher Content diese Ressourcen benötigt; die Verhältnis-Kennzahl selbst kann dieses Problem nicht diagnostizieren.
Wie wir das bei H-Studio prüfen
Wenn diese Warnung in einem Kunden-Audit auftaucht, öffnen wir keinen Texteditor — wir fahren eine kurze Folge von Checks, in Prioritätsreihenfolge.
Erstens, Rendering-Parität: Enthält das rohe Server-HTML die Überschriften, Kernabsätze, internen Links und strukturierten Daten der Seite? Wir vergleichen den Quelltext mit dem gerenderten DOM und bestätigen über die URL-Prüfung der Search Console, was Google tatsächlich erfasst hat. Zweitens, Intention und Tiefe: Hat die Seite genug Substanz, um die Anfrage zu erfüllen, auf die sie zielt — beurteilt so, wie ein Leser urteilen würde, nicht allein nach Wortzahl, sondern danach, ob sie die Frage beantwortet. Drittens, die untermauernden Signale: niedrige Wortzahl, Thin Content, Indexierungsstatus in der GSC und ob die Seite überhaupt von irgendwo Relevantem intern verlinkt ist. Viertens, die größeren Probleme, die diesem fast immer übergeordnet sind: Core Web Vitals und Performance, Indexierbarkeit und Kanonisierung sowie Keyword-Kannibalisierung zwischen Seiten, die um dieselbe Intention konkurrieren. Nur wenn die Content-Qualität wirklich mangelhaft ist, empfehlen wir Erweiterung oder Umstrukturierung — und dann für den Leser, nicht für die Kennzahl.
In all den Jahren dieser Arbeit kann ich mich an keinen einzigen Fall erinnern, in dem das Anheben eines Text-zu-HTML-Verhältnisses für sich genommen ein Ranking bewegt hätte. Jedes Mal, wenn die Warnung relevant war, stand sie vor einem echten Problem — meist Thin Content oder eine Client-seitige Rendering-Lücke — und genau das zu beheben, hat das Ergebnis verändert.
Es richtig beheben (nur wenn gerechtfertigt)
Wenn ein Audit doch eine echte Schwäche zutage fördert, geht es um Qualität und Rendering, nie um Auffüllen. Die Hebel, die tatsächlich helfen:
Stelle sicher, dass essenzieller Content — Überschriften, Haupttext und primäre Links — in der Serverantwort steht. Prüfe strukturierte Daten zusätzlich im gerenderten Ergebnis. Ist eine Seite für ihre Intention wirklich zu dünn, ergänze nur die Erklärung, die ein Leser benötigt; eine universelle Wortzahl gibt es nicht. Halte entscheidende Informationen ohne Nutzerinteraktion zugänglich, die ein Crawler möglicherweise nicht ausführt. Kürze auf Code-Seite ungenutztes JavaScript und überdimensionierte Drittanbieter-Skripte, weil das Nutzern und gemessener Performance hilft; eine Veränderung des Verhältnisses ist nur ein Nebenprodukt.
Was nie hilft, ist Text zu fabrizieren, um eine Zahl zu treffen. Eine saubere Landingpage mit Absätzen vollzustopfen, die niemand liest, bläht das Verhältnis auf, verwässert die Botschaft und senkt tendenziell die Conversion — ein Phantom-SEO-Gewinn gegen einen echten geschäftlichen Verlust eingetauscht.
Was Rankings hier tatsächlich bewegt
Zieht man die Warnung zurück, sind die Prioritäten klar: Prüfe, ob die Seite indexierbar ist, ob ihr wesentlicher Content das Rendering übersteht, ob sie ihrem Leser dient und ob reale Performance-Messwerte akzeptabel sind. Core Web Vitals — LCP, CLS und INP — gehören zu Googles Page-Experience-Signalen, doch Relevanz lässt sich auf keine einzelne Kennzahl reduzieren. Das Text-zu-HTML-Verhältnis liegt hinter diesen Entscheidungen; seine Verbesserung allein weist keine davon nach.
Für moderne Next.js-Seiten ist das Urteil einfach: Behandle „niedriges Text-zu-HTML-Verhältnis" als diagnostischen Hinweis, nicht als To-do. Lass es die zwei Fragen anstoßen, die sich lohnen — steht mein Content im Server-HTML, und verdient diese Seite ein Ranking für ihre Intention? — und handle nur nach den Antworten.
Wenn du einen zweiten Blick darauf möchtest, wie deine Next.js-Seite für Crawler rendert, beginnt unsere Arbeit zu SEO-Migration & Relaunch genau hier — Rendering-Parität, Indexierbarkeit und Intention — bevor irgendjemand eine Wortzahl anfasst. Ein 30-minütiges Erstgespräch ist der einfachste Einstieg.
— Anna
Häufige Fragen
Ist ein niedriges Text-zu-HTML-Verhältnis schlecht für SEO?
Nicht für sich genommen. Googles John Mueller hat klar gesagt, dass das Verhältnis kein Rankingfaktor ist und nie war. Es zählt nur indirekt, als möglicher Hinweis auf Seiten-Bloat, Thin Content oder ein Rendering-Problem — und jedes davon würdest du direkt angehen, nicht über das Verhältnis.
Was ist ein gutes Text-zu-HTML-Verhältnis?
Es gibt keinen von Google definierten Zielwert. Die „25–70 %", die manche Tools zitieren, sind Branchen-Folklore, keine Google-Regel. Semrush markiert schlicht Seiten bei 10 % oder darunter. Eine Seite kann unter dieser Schwelle völlig problemlos ranken.
Warum hat meine Next.js- oder React-Seite ein niedriges Text-zu-HTML-Verhältnis?
Weil Komponenten-Frameworks große Mengen an Struktur-Markup erzeugen — verschachtelte Layout-Elemente, Design-System-Wrapper, Hydration-Daten und Skripte — im Verhältnis zum sichtbaren Text. Der Nenner ist konstruktionsbedingt groß, daher liest sich das Verhältnis selbst bei gesunden Seiten niedrig.
Woher weiß ich, ob Google meinen Content tatsächlich sehen kann?
Sieh dir das rohe Server-HTML an (Quelltext, nicht den gerenderten DevTools-DOM) und suche nach einem Kernsatz; nutze dann die URL-Prüfung in der Google Search Console, um das gerenderte HTML zu sehen, das Google erfasst hat. Sind deine Überschriften und Kernabsätze vorhanden, passt es.
Schadet Client-Side Rendering der SEO?
Es kann vermeidbare Rendering-Abhängigkeiten erzeugen. Google kann JavaScript ausführen, doch Client-only-Content hängt davon ab, dass Skripte und Datenabfragen beim Rendering gelingen; außerdem unterstützt nicht jeder Crawler JavaScript. Server-Side Rendering oder statische Generierung legt wesentlichen Content ins initiale HTML und ist eine robuste Basis für öffentliche Seiten.
Soll ich Text hinzufügen, um die Warnung zu beheben?
Nur, wenn die Seite für die Anfrage, auf die sie zielt, wirklich dünn ist. Füge Content hinzu, der dem Leser hilft — eine klare Einleitung, eine Erklärung des Angebots, ein echtes FAQ. Polstere eine Seite nie nur auf, um das Verhältnis zu heben; das hilft Rankings nicht und schadet meist Klarheit und Conversion.
Redigiert und auf Fakten geprüft von Anna Hartung.