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 Rankingfaktor | Googles John Mueller hat mehrfach bestätigt, dass das Text-zu-HTML-Verhältnis kein Ranking-Signal in der Suche ist — und nie war. |
| 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. |
| AI-Crawler führen kein JavaScript aus | GPTBot, ClaudeBot und PerplexityBot lesen nur das rohe HTML, client-gerenderter Content ist für sie faktisch unsichtbar. |
| 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?
Die kurze Antwort lautet nein, und Google war dabei ungewöhnlich deutlich. Search Advocate John Mueller hat wiederholt gesagt, dass das Code-zu-Text- (oder Text-zu-HTML-) Verhältnis kein Faktor in der Google-Suche ist und es nie war. Direkt darauf angesprochen, hat er es mehrfach als Kennzahl beschrieben, die „für SEO absolut keinen Sinn ergibt", und Gary Illyes hat dieselbe Linie wiederholt — dass es egal ist, solange die Seite anständigen Content hat. Es gibt keine interne „Verhältnis"-Schwelle, die eine Seite zum Ranken überschreiten muss.
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?
Der Site-Audit von Semrush wirft die Warnung, wenn das Text-zu-HTML-Verhältnis einer Seite auf 10 % oder weniger fällt, grob berechnet als Byte-Größe des sichtbaren Textes geteilt durch die Byte-Größe des vollständigen, unkomprimierten HTML-Dokuments. Entscheidend: Semrush führt das unter Warnungen, nicht unter Fehlern — der niedrigsten Prioritätsstufe, unterhalb der Probleme, die Crawling oder Indexierung tatsächlich brechen. Semrush selbst behält die Prüfung vor allem aus Kontinuität; es nimmt etablierte Issue-Typen selten aus dem Programm, auch solche, deren SEO-Relevanz verblasst ist.
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.
Googlebot verarbeitet JavaScript-Seiten in zwei getrennten Wellen. In Welle eins ruft er das rohe HTML ab, das dein Server zurückgibt, und indexiert alles, was unmittelbar vorhanden ist — Text, Links, Metadaten, strukturierte Daten. Dieser Durchgang ist schnell. Steht dein Content in diesem initialen HTML, ist er sofort indexierbar. In Welle zwei kommen Seiten, die von JavaScript abhängen, in eine Render-Queue, in der Googles Web Rendering Service — ein headless, evergreen gehaltenes Chromium auf aktuellem JS-Stand — die Skripte ausführt, den finalen „gerenderten DOM" aufbaut und den Index aktualisiert. Der Haken: Diese zweite Welle steht in einer Queue mit endlichen Ressourcen und kann der ersten um Stunden, Tage oder in manchen Fällen Wochen hinterherhinken. Die Verzögerung ist eine Funktion der Render-Queue-Kapazität, nicht davon, ob Googlebot deinen Code ausführen kann; server-gerendertes HTML überspringt die Queue vollständig.
Hier entscheidet die Rendering-Strategie alles, und Next.js gibt dir die volle Bandbreite:
Beim Client-Side Rendering (CSR) — einer reinen React-SPA — gibt der Server eine nahezu leere Hülle zurück, oft kaum mehr als ein <div id="root"></div> plus ein Skript-Bundle. In Welle eins sieht Googlebot praktisch keinen Content, keine internen Links und häufig keine echten Metadaten. Alles hängt davon ab, dass Welle zwei gelingt und rechtzeitig eintrifft. Verzögert sich das Rendering oder schlägt es fehl (ein Skriptfehler, eine langsame API, eine Fehlkonfiguration), gibt es nichts zu indexieren. Interne Verlinkung — das Bindegewebe, mit dem Google Seiten entdeckt und Autorität über die Website verteilt — ist im ersten Durchgang unsichtbar. Eine CSR-Seite kann gleichzeitig ein niedriges Text-zu-HTML-Verhältnis und ein echtes Indexierungsproblem zeigen, und das Verhältnis ist das Symptom, das auffällt, während die Rendering-Abhängigkeit die Krankheit ist.
Beim Server-Side Rendering (SSR) und bei der statischen Generierung (SSG) kommt das HTML vollständig an: Content, Links, Meta-Tags und strukturierte Daten stehen alle in Welle eins. Das ist die verlässliche Basis für alles, was ranken soll. Next.js bietet außerdem Incremental Static Regeneration (ISR) — vorab gebaute Seiten, die im Hintergrund aktualisiert werden — und Steuerung pro Route, sodass du Marketing- und Content-Seiten für SEO statisch rendern und echte app-artige, eingeloggte Screens als CSR belassen kannst. Der Punkt ist nicht „nutze nie Client-Rendering"; er lautet „mach niemals öffentlichen, rankfähigen Content davon 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.
Die Wendung 2026: AI-Crawler erhöhen den Einsatz beim initialen HTML
Es gibt einen neueren Grund, sich darum zu kümmern, was in deinem server-gerenderten HTML steht, und er formt den Long Tail dieses Themas neu. Die Crawler hinter AI-Antwortmaschinen — GPTBot, ClaudeBot, PerplexityBot und andere — führen in der Regel überhaupt kein JavaScript aus. Sie lesen das rohe HTML und hören dort auf. Content, der erst im Rendering der zweiten Welle entsteht, ist für sie faktisch unsichtbar, selbst wenn Google ihn irgendwann indexieren mag.
Während sich immer mehr Discovery hin zu Antwortmaschinen und AI-Overviews verschiebt — das Terrain, das man heute Answer Engine Optimization (AEO) und Generative Engine Optimization (GEO) nennt — schließt dich eine CSR-Architektur still aus Zitaten und Einbindung in diesen Oberflächen aus. Der alte Rat („Google kann JS rendern, also passt das schon") war wegen der Verzögerung der zweiten Welle ohnehin wackelig; gegenüber AI-Crawlern hält er schlicht nicht. Deinen substanziellen Content server-seitig zu rendern, ist nicht länger nur eine Annehmlichkeit für die Google-Indexierung. Es ist der Preis dafür, von den Systemen lesbar zu sein, die Discovery zunehmend vermitteln.
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 verdient einen Namen: eine robots.txt-Regel, die JavaScript- oder CSS-Dateien blockiert. Das ist verbreitet auf Seiten, die Staging-Assets blockiert und vor dem Launch nie aufgeräumt haben. Blockierst du diese Ressourcen, brichst du das Rendering der zweiten Welle für jede Seite, die auf sie angewiesen ist — Googlebot kann nicht ausführen, was er nicht abrufen kann. Das ist ein echtes, rankingrelevantes Problem, das keine Verhältnis-Kennzahl sichtbar macht.
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, der Haupttext, strukturierte Daten — in Next.js server-gerendert wird, damit er in Welle eins landet und für nicht-rendernde Crawler lesbar ist. Wo eine Seite für ihre Intention berechtigterweise dünn ist, füge eine knappe, nützliche Einleitung hinzu (oft 150–300 Wörter), die einordnet, was die Seite bietet, plus eine klare „Was wir tun / Wie es funktioniert"-Erklärung und ein FAQ, das echte Fragen von Käufern beantwortet. Halte Kern-Content nicht hinter Tabs und Accordions versteckt, die ihn vor dem initialen Rendering verbergen. Und auf der Code-Seite: kürze, was wirklich verschwenderisch ist — ungenutztes JavaScript, redundante Komponenten-Verschachtelung, überdimensionierte Drittanbieter-Skripte — denn das hilft Page Speed und Core Web Vitals, die echte Signale sind, auch wenn das Verhältnis, das sich nebenbei verbessert, nicht das Ziel ist.
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. Google rankt Seiten, nicht Kennzahlen. Belohnt wird Content, der die Intention trifft, geliefert in HTML, das zuverlässig gerendert und indexiert werden kann, auf einer Seite, die schnell ist (Core Web Vitals — LCP, CLS und INP, das 2024 FID als Reaktionsfähigkeits-Metrik abgelöst hat, sind bestätigte Signale), gut strukturiert und intern verlinkt, sodass Autorität und Discovery fließen. Das Text-zu-HTML-Verhältnis sitzt all dem nachgelagert. Verbessere die Dinge, die zählen, und das Verhältnis steigt von selbst; jage das Verhältnis isoliert, und du hast Aufwand in die eine Zahl gesteckt, die Google dir zu ignorieren riet.
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. Bei CSR sieht Googlebots erste Welle eine nahezu leere Hülle und hängt von einer verzögerten zweiten Rendering-Welle ab — und AI-Crawler wie GPTBot und ClaudeBot führen überhaupt kein JavaScript aus. Server-Side Rendering oder statische Generierung legt deinen Content ins initiale HTML, was die verlässliche Wahl für alles ist, das ranken oder zitiert werden soll.
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.