In diesem Artikel
Deine Produktseite sieht im Browser vollständig aus. Überschrift, Beschreibung und passende Angebote sind vorhanden. Ein SEO-Check findet trotzdem kaum Text. Bei Websites, die Inhalte mit JavaScript nachladen, können beide Beobachtungen stimmen: Der Server liefert zunächst ein Grundgerüst, erst der Browser baut daraus die fertige Seite.
JavaScript-SEO sorgt dafür, dass Suchmaschinen auch solche Inhalte erreichen, verarbeiten und für die Suche berücksichtigen können. Dieser Leitfaden zeigt dir, wie du Rendering-Probleme systematisch eingrenzt, welche Fehler häufig dahinterstecken und welche Lösung zu deinem Seitentyp passt.
Wie Google JavaScript-Inhalte verarbeitet
Google kann JavaScript ausführen. Die Verarbeitung umfasst Crawling, Rendering und Indexierung: Zunächst wird eine URL abgerufen, anschließend kann Google die Seite mit Chromium rendern und den erzeugten HTML-Code auswerten. Blockierte Skripte werden dabei nicht ausgeführt. Das Rendering kann zeitversetzt erfolgen. Google beschreibt diesen Ablauf in den Grundlagen von JavaScript-SEO.
Für die Diagnose brauchst du deshalb drei getrennte Ansichten:
| Ansicht | Was du untersuchst | Welche Frage sie beantwortet |
|---|---|---|
| Server-HTML | Die ursprüngliche HTML-Antwort der URL | Welche Inhalte liefert der Server direkt? |
| Browser-DOM | Die aktuelle Dokumentstruktur nach der Skriptausführung | Was hat dein Browser daraus aufgebaut? |
| Google-Rendering | Das gerenderte HTML aus einem Google-Test | Welche Inhalte waren unter diesen Testbedingungen vorhanden? |
Das DOM ist die Dokumentstruktur, mit der der Browser arbeitet. Ein Unterschied zwischen Server-HTML und DOM zeigt zunächst eine Abhängigkeit von JavaScript. Ob daraus ein Suchproblem entsteht, musst du gesondert prüfen.
Schritt 1: Repräsentative URLs und Prüfinhalte festlegen
Teste mehrere Seitentypen. Bei einem Shop wären das etwa eine Kategorie, ein verfügbares Produkt und eine nicht mehr existierende Produktadresse. Bei einem Dienstleister eignen sich eine Leistungsseite, ein Ratgeber und eine Standortseite. Die Startseite allein sagt wenig über andere Templates aus.
Lege für jede URL konkrete Prüfinhalte fest: die Hauptüberschrift, einen eindeutigen Satz aus dem Haupttext und einen wichtigen internen Link. Notiere die erwarteten Werte, bevor du die technischen Ansichten öffnest. So vermeidest du eine vage Bewertung nach dem Eindruck „sieht vollständig aus“.
Eine kleine Tabelle reicht für den Anfang:
| URL-Typ | Eindeutiger Prüftext | Wichtiger Link | Erwarteter Status |
|---|---|---|---|
| Leistungsseite | Satz zur angebotenen Leistung | Passender Fachartikel | 200 |
| Produktseite | Individuelle Produktbeschreibung | Zugehörige Kategorie | 200 |
| Gelöschte URL ohne Nachfolge | Verständliche Fehlermeldung | Hilfreicher Rückweg | 404 oder 410 |
Die Beispiele sind eine Vorlage. Ergänze die tatsächlichen URLs und Inhalte deiner Website.
Schritt 2: Die ursprüngliche Serverantwort prüfen
Öffne die gewünschte URL direkt in einem neuen Browser-Tab. In den Entwicklertools findest du im Bereich „Network“ beziehungsweise „Netzwerk“ die Anfrage für das HTML-Dokument. Lade die Seite bei geöffnetem Netzwerkbereich neu und untersuche die Antwort dieses Dokuments. Achte darauf, die Dokumentanfrage und keinen API-Aufruf auszuwählen.
Suche im Antworttext nach deinem festgelegten Prüfsatz und dem internen Link. Kontrolliere außerdem den HTTP-Status und den Seitentitel. Als schnelle zusätzliche Ansicht eignet sich die Browserfunktion „Seitenquelltext anzeigen“.
Ein stark vereinfachtes Grundgerüst könnte so aussehen:
<main id="app"></main>
<script src="/assets/app.a81c9.js" defer></script>Hier steht der Hauptinhalt noch nicht in der Serverantwort. Eine serverseitig aufgebaute Seite könnte dagegen bereits Folgendes enthalten:
<main>
<h1>Wartung für gewerbliche Lüftungsanlagen</h1>
<p>Wir prüfen Filter, Luftmengen und den Zustand deiner Anlage.</p>
<a href="/ratgeber/wartungsintervalle">Wartungsintervalle planen</a>
</main>Diese Beispiele verdeutlichen den Unterschied; sie sind keine vollständigen Seitentemplates. Halte im Prüfprotokoll fest, welche Bestandteile direkt ausgeliefert und welche erst später ergänzt werden.
Schritt 3: Browseransicht und Google-Rendering vergleichen
Wechsle in den Entwicklertools zu „Elements“ beziehungsweise „Elemente“. Suche dort erneut nach deinen Prüfinhalten. Vergleiche jeweils dieselbe URL und denselben Zustand. Eine personalisierte Ansicht nach Anmeldung ist kein sinnvoller Maßstab für eine öffentlich erreichbare Suchseite.
Prüfe die URL anschließend in der Google Search Console. Öffne die URL-Prüfung, führe einen Live-Test aus und sieh dir die getestete Seite an. Untersuche das gerenderte HTML und, soweit verfügbar, Screenshot sowie Hinweise zu Ressourcen und JavaScript-Fehlern. Die Hilfe zum URL-Prüftool erklärt die verfügbaren Ansichten.
Suche wieder gezielt nach Überschrift, Prüfsatz und Linkziel. Ein Screenshot ergänzt diese Prüfung, ersetzt die Suche im HTML aber nicht. Notiere auch, ob du die indexierte Version oder den aktuellen Live-Test betrachtest. Beide können unterschiedliche Zeitpunkte abbilden.
Ein erfolgreicher Live-Test garantiert keine Indexierung. Er zeigt außerdem nicht, welche URL Google später als kanonisch auswählen wird. Wenn die Inhalte im Test vorhanden sind, die Seite aber nicht indexiert ist, untersuche weitere Ursachen wie Duplikate, Inhaltsqualität oder die von Google ausgewählte kanonische URL. Die Grundlagen der Berichte findest du im Artikel Google Search Console einrichten und richtig auswerten.
Schritt 4: Den Befund einer Ursache zuordnen
Die folgende Matrix ist eine praktische Arbeitshilfe für deine Untersuchung. Sie beschreibt mögliche Ursachen, keine automatische Fehlerdiagnose.
| Beobachtung | Mögliche Ursache | Nächster Prüfschritt |
|---|---|---|
| Serverantwort enthält wenig Text, Browser und Google-Test enthalten den Hauptinhalt | Funktionierendes clientseitiges Rendering | Weitere Templates und Fehlerzustände testen |
| Haupttext erscheint im Browser, fehlt aber im Google-Test | Ressourcenfehler oder abweichender Ausgangszustand | Fehlende Skripte, API-Antworten und Zugriffsvoraussetzungen untersuchen |
| Direkter URL-Aufruf scheitert, interne Navigation funktioniert | Fehlerhafte Server-Zuordnung beim Routing | URL in einem neuen Tab öffnen und Dokumentantwort prüfen |
| Produktlinks erscheinen erst nach „Mehr laden“ | Entdeckung hängt von einer Interaktion ab | Eigenständige, verlinkte Folgeseiten prüfen |
| Nicht vorhandene Produktadresse liefert eine allgemeine Seite mit Status 200 | Unpassende Fehlerbehandlung im Router | Status und Inhalt einer gezielt ungültigen URL vergleichen |
| Google-Test enthält alles, Indexierung bleibt aus | Ursache liegt möglicherweise außerhalb des Renderings | Indexierungsbericht und inhaltliche Abgrenzung untersuchen |
Behebe zuerst den frühesten nachgewiesenen Fehler. Wenn bereits der direkte Seitenaufruf scheitert, hilft das Umschreiben der Produktbeschreibung bei diesem Problem wenig.
Typische JavaScript-SEO-Fehler gezielt beheben
Wichtige Inhalte hängen von Sitzung oder Nutzeraktion ab
Teste in einem frischen Browserprofil ohne Anmeldung und ohne zuvor gespeicherte Auswahl. Erscheint der Haupttext erst nach einem Klick, einem gespeicherten Standort oder einer erfolgreichen API-Anfrage? Dann dokumentiere die Abhängigkeit und prüfe einen öffentlichen Ausgangszustand mit vollständiger Grundinformation.
Google weist darauf hin, dass Cookies sowie lokaler und Sitzungsspeicher zwischen Rendering-Vorgängen nicht erhalten bleiben. Auch fragmentbasierte Routen wie /#/produkte sind für unterschiedliche indexierbare Inhalte ungeeignet. Die Anleitung zur Behebung von JavaScript-Problemen erläutert diese Einschränkungen.
Für deine Abnahme heißt das: Jede wichtige Ziel-URL muss sich einzeln öffnen lassen. Prüfe sowohl den ersten direkten Aufruf als auch einen erneuten Aufruf nach der Navigation innerhalb der Anwendung. Beziehe die Fehlerzustände der Datenquelle ein.
Die Navigation verwendet nur Klick-Ereignisse
Eine klickbare Fläche ist noch kein verlässlicher HTML-Link. Verwende für die Navigation ein Ankerelement mit einer echten Zieladresse:
<a href="/leistungen/lueftungswartung">Lüftungswartung</a>JavaScript darf die Navigation ergänzen. Das href sollte weiterhin ein erreichbares Ziel enthalten. Google kann auch nachträglich erzeugte Links auswerten, wenn sie diesem Aufbau entsprechen. Ein Element mit ausschließlich einem Klick-Handler ist dafür keine zuverlässige Grundlage. Siehe die Google-Empfehlungen für crawlbare Links.
Kontrolliere am fertigen Element die tatsächlichen Attribute. Ein Framework-Komponentenname im Projektcode verrät noch nicht, welches HTML im Browser entsteht. Wie du die passenden Linkziele auswählst, erklärt unser Leitfaden zur internen Verlinkung.
Infinite Scroll hat keine erreichbaren Folgeseiten
Google interagiert nicht wie ein Besucher durch Klicken oder Scrollen mit deiner Seite. Für endlos nachladende Listen empfiehlt Google deshalb eigene, dauerhafte URLs für die einzelnen Abschnitte und Links zwischen diesen URLs. Weitere Informationen bietet die Dokumentation zu Lazy Loading und Infinite Scroll.
Bei einer Produktkategorie könntest du beispielsweise prüfen, ob /kategorie?page=2 direkt die zweite Produktgruppe zeigt und von der ersten Seite aus verlinkt ist. Lade diese Adresse separat neu. Dokumentiere, ob dieselben Produkte erscheinen und ob deren Detailseiten erreichbar sind.
Trenne diese Prüfung von der Bildoptimierung: Ein verzögert geladenes Vorschaubild und eine erst nach einem Klick erzeugte Produktliste haben unterschiedliche Auswirkungen auf die Entdeckung der Zielseiten.
Metadaten ändern sich widersprüchlich
Vergleiche Title, Canonical und Robots-Anweisungen in Serverantwort und gerendertem Dokument. Ein besonders kritischer Fehler ist ein anfängliches noindex, das JavaScript später entfernen soll: Google kann das Rendering wegen der ursprünglichen Anweisung überspringen. Liefere bei einer zur Indexierung vorgesehenen Seite deshalb kein vorläufiges noindex aus. Auch widersprüchliche Canonical-Werte solltest du vermeiden. Diese Fälle behandelt Google in den JavaScript-SEO-Grundlagen zu Metadaten.
Notiere für jede geprüfte URL den erwarteten Canonical-Wert. Wenn ein gemeinsames Template zunächst die Startseite einträgt und die Anwendung später eine Produktadresse setzt, gehört dieser Widerspruch ins Entwickler-Ticket. Für die grundsätzliche Konfiguration hilft unser Artikel zu Canonical, robots.txt und Sitemap.
SSR, statisches HTML oder clientseitiges Rendering wählen
Die Rendering-Strategie sollte zur Aufgabe der Seite passen. Beim serverseitigen Rendering, kurz SSR, erzeugt der Server das HTML für die Anfrage. Statisches Rendering erstellt es vorab. Clientseitiges Rendering, kurz CSR, baut Inhalte im Browser auf. Hydration ergänzt bereits ausgeliefertes HTML um Interaktivität. Die technischen Begriffe und ihre Zielkonflikte erklärt web.dev in der Übersicht zum Rendering.
Für die Projektplanung lässt sich daraus diese Entscheidungshilfe ableiten:
| Seitentyp | Sinnvoller Ausgangspunkt | Was du zusätzlich klären solltest |
|---|---|---|
| Ratgeber oder Unternehmensseite | Vorab erzeugtes HTML oder serverseitige Ausgabe | Wie gelangen redaktionelle Änderungen in die Auslieferung? |
| Öffentliche Produkt- oder Leistungsseite | Vollständiger Hauptinhalt in der HTML-Antwort | Wie aktuell müssen Preise, Verfügbarkeit oder Standortdaten sein? |
| Interaktiver Konfigurator | Verständliche Einstiegsseite mit clientseitiger Anwendung | Welche Informationen brauchen Besucher vor dem Start? |
| Persönlicher Kundenbereich | Architektur nach Bedienung und Zugriffsschutz | Welche Ansichten sollen überhaupt öffentlich auffindbar sein? |
Diese Empfehlungen ersetzen keine Architekturprüfung. Berücksichtige Datenaktualität, Cache-Verhalten, Serveraufwand und Wartbarkeit. Auch serverseitig erzeugte Seiten können im Browser unnötig viel JavaScript ausführen; prüfe ihre Bedienbarkeit gesondert.
Eine Sonderausgabe nur für Bots verursacht zusätzliche Pflege. Google bezeichnet dieses sogenannte Dynamic Rendering als Behelfslösung und empfiehlt stattdessen unter anderem serverseitiges oder statisches Rendering. Für neue Projekte ist es deshalb kein geeigneter Standardweg. Quelle: Google zu Dynamic Rendering.
So wird aus dem Befund ein prüfbares Entwickler-Ticket
Schreibe zu jedem Fehler eine konkrete Erwartung und einen reproduzierbaren Test. „SEO bei JavaScript verbessern“ lässt sich schwer abnehmen. „Die Leistungsbeschreibung fehlt beim direkten Aufruf im Google-Live-Test“ benennt dagegen einen überprüfbaren Befund.
Ein hilfreiches Ticket enthält:
- Betroffene URLs und Template: Zwei Beispiele derselben Seitengruppe sowie eine funktionierende Vergleichsseite.
- Ausgangszustand: Direkter Aufruf ohne Anmeldung, Zeitpunkt des Tests und verwendete Ansicht.
- Erwartung und Beobachtung: Exakter Prüfsatz, Linkziel oder Metadatenwert, der fehlt oder abweicht.
- Nachweise: Gesicherte Dokumentantwort, Auszug aus dem gerenderten HTML und relevante Fehlermeldungen.
- Abnahmekriterium: Welche Inhalte nach der Änderung in welcher Ansicht vorhanden sein müssen.
Wiederhole nach der Umsetzung denselben Test mit denselben URLs. Ergänze eine bisher ungeprüfte URL des Templates. So kontrollierst du, ob die Korrektur für die Seitengruppe greift.
JavaScript-SEO mit VitoScore in deinen Prüfablauf einordnen
Der kostenlose VitoScore-Onpage-Check untersucht die abgerufene HTML-Antwort. Er führt dabei kein JavaScript wie ein Browser aus. Meldet er bei einer dynamischen Seite fehlende Überschriften oder wenig Text, ist das ein Anlass für den beschriebenen Vergleich der Ansichten.
Nutze den Onpage-Check für die Serverantwort und die Search Console für die Untersuchung des Google-Renderings. Bewerte Ladezeit und Reaktionsfähigkeit zusätzlich mit einer Website-Analyse auf VitoScore. Für konkrete Performance-Maßnahmen gibt es den separaten Leitfaden Website-Performance optimieren.
Häufige Fragen zu JavaScript-SEO
Ist eine Website mit React oder Vue schlecht für SEO?
Aus dem Framework-Namen lässt sich das nicht ableiten. Prüfe die tatsächlich ausgelieferten URLs, Inhalte und Links. Ein öffentliches Seitentemplate und ein angemeldeter Anwendungsbereich können innerhalb desselben Projekts unterschiedliche Rendering-Strategien brauchen.
Muss der gesamte Inhalt im Server-HTML stehen?
Google kann auch JavaScript-Inhalte verarbeiten. Für wichtige öffentliche Texte und Navigationslinks ist die direkte HTML-Ausgabe dennoch ein sinnvoller Ausgangspunkt: Du reduzierst die Abhängigkeit vom späteren Aufbau der Seite und kannst die Auslieferung einfacher kontrollieren.
Beweist fehlender Text im SEO-Check ein Indexierungsproblem?
Das hängt davon ab, welche Ansicht der Check untersucht. Vergleiche Serverantwort, Browser-DOM und Google-Rendering. Erst dieser Abgleich zeigt, ob der Text nur in der ursprünglichen Antwort fehlt oder auch unter Googles Testbedingungen nicht erscheint.
Wann sollte ich den Rendering-Test wiederholen?
Nach Änderungen an Templates, Routing, Datenquellen und Rendering-Konfiguration. Bewahre dafür eine kleine Liste repräsentativer URLs samt Prüfsätzen auf. Dieselbe Liste hilft bei der nächsten Veröffentlichung, Abweichungen früh zu erkennen.
