Niedriges Text-zu-HTML-Verhältnis in Semrush: Muss man das auf modernen Next.js-Websites beheben?

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

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. Ein werkzeugspezifischer Prozentwert sollte nicht als Google-Anforderung dargestellt werden.

Woher stammt also der Wert „ideales Verhältnis von 25–70 %", den manche Tools zitieren? Nicht von Google. Eine unbelegte empfohlene Spanne ist keine Search-Anforderung. Prüfe Inhaltsnutzen, Rendering und gemessene Performance direkt.

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. Eine Komponentenimplementierung kann umfangreiches Struktur-Markup erzeugen. Nicht jede Komponente benötigt allerdings ein eigenes Wrapper-Element. 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. Das Verhältnis allein unterscheidet notwendiges Markup nicht von unnötigem Implementierungsaufwand.

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. Sind Überschriften und Kernabsätze vorhanden, begründet das Verhältnis allein keinen zusätzlichen Text. Sichtbarer Content beweist noch keine Indexierung: Prüfe Status, Robots, Canonical und den erfassten Indexstand gesondert. Erscheint Inhalt erst nach JavaScript, untersuche eine tatsächliche Rendering-Störung, bevor du einen Umbau empfiehlst.

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:

Prüfe, ob die Seite ihre konkrete Leserfrage beantwortet, statt eine Wortzahl zu verlangen. Wenige Impressionen oder „Gecrawlt – zurzeit nicht indexiert“ begründen eine Untersuchung von Auffindbarkeit, Canonical-Auswahl, Inhalt und Rendering. Sie beweisen weder ein zu niedriges Verhältnis noch zu wenig Text als Ursache. Vergleiche Serverantwort, gerenderten Inhalt und verfügbare Search-Console-Nachweise vor der Korrektur.

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.

Halte den konkreten Befund und seine Prüfmethode fest. Verbessert eine Änderung Ladeverhalten oder Inhaltsverfügbarkeit, wird dieses Ergebnis dokumentiert, statt es dem Verhältnis selbst zuzuschreiben.

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. Beschreibe die betroffene URL und die Warnung, damit der tatsächliche Prüfbedarf abgegrenzt werden kann.

— Anna

Häufige Fragen

Ist ein niedriges Text-zu-HTML-Verhältnis schlecht für SEO?

Nicht für sich genommen. Google veröffentlicht keinen erforderlichen Verhältniswert. Untersuche Seitengewicht, Inhaltsnutzen und Rendering, wenn Hinweise auf Probleme vorliegen. Der Prozentwert allein prüft keines davon.

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. Das bestätigt die Inhaltsverfügbarkeit in der geprüften Antwort, nicht die Indexierung oder das Ranking der aktuellen Fassung.

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.