Google kann JavaScript ausführen. Das garantiert jedoch nicht, dass jede davon abhängige Seite oder jeder Inhaltsabschnitt indexiert wird. Wichtiger Inhalt muss abrufbar sein, im gerenderten Ergebnis erscheinen und konsistente Indexierungssignale tragen. Vergleichen Sie Serverantwort, Browserdarstellung und Googles Prüfausgabe, bevor Sie Rendering, Entdeckung oder etwas anderes als Ursache festlegen.
Für öffentliche Inhalte machen serverseitiges Rendering oder statische Generierung die Auslieferung häufig verlässlicher, weil weniger Schritte nötig sind, bevor Text und Links vorliegen. Clientseitiges Rendering kann ebenfalls funktionieren. Entscheidend ist, ob die konkrete Route unter den Bedingungen eines Crawlers funktioniert, nicht der allgemeine SEO-Ruf ihres Frameworks.
Verfolgen Sie Crawling, Rendering und Indexierung
Google beschreibt für JavaScript-Seiten drei Hauptphasen: Crawling, Rendering und Indexierung. Beim Crawling ruft Googlebot eine erlaubte URL ab und verarbeitet die Antwort. Dabei können Links im ursprünglichen HTML entdeckt werden. Googles Web Rendering Service führt JavaScript in einer Chromium-Umgebung ohne grafische Oberfläche aus. Das resultierende HTML liefert Inhalte und weitere Links für die Verarbeitung.
Für die Rendering-Warteschlange gibt es keine veröffentlichte feste Wartezeit. Behaupten Sie weder, dass JavaScript-Inhalte immer sofort erscheinen, noch dass sie grundsätzlich eine bestimmte Zahl von Tagen warten. Google erklärt, dass geeignete 200-Seiten einschließlich Seiten ohne JavaScript in die Rendering-Warteschlange gelangen, sofern Indexierungsanweisungen dies nicht verändern. Fehler und gesperrte Ressourcen können den weiteren Ablauf beeinflussen.
Rendering und Indexierung bleiben unterschiedliche Ergebnisse. Eine korrekt gerenderte Seite kann wegen Duplikaten, Qualität oder anderen Faktoren nicht für den Index ausgewählt werden. Eine erfolglose Suche nach einer Formulierung beweist daher nicht, dass Google das JavaScript nicht ausführen kann. Klären Sie, was die Prüfbelege tatsächlich zeigen.
Prüfen Sie mit dem Grundlagenleitfaden zu technischem SEO zunächst Zugriff, Canonicals und Statuscodes. Nicht jeder Ausschluss ist ein Renderingfehler. Googles JavaScript-SEO-Dokumentation ist die wichtigste Referenz für das hier verwendete Verarbeitungsmodell.
Vergleichen Sie drei Fassungen einer wichtigen Route
Wählen Sie eine Route, bei der fehlender Inhalt relevant ist, etwa eine Produktdetailseite oder ausführliche Anleitung. Notieren Sie erwartete Überschrift, eigenständigen Text, Hauptlinks, Canonical und Indexierungsanweisung. Vergleichen Sie anschließend ursprüngliche Antwort und Rendering, statt sich auf den optischen Eindruck zu verlassen.
Rufen Sie zuerst Server-HTML und Header ab. Öffnen Sie die URL danach direkt in einer frischen Browsersitzung und untersuchen Sie DOM, Netzwerkfehler und Konsolenausnahmen. Prüfen Sie die URL schließlich in Search Console und verwenden Sie gegebenenfalls den Live-Test. Gespeicherter Indexierungsbericht und Live-Prüfung beantworten unterschiedliche Fragen und können verschiedene Seitenversionen abbilden.
Die Belege haben unterschiedliche Aussagekraft:
| Beleg | Geeignet für | Beweist nicht |
|---|---|---|
| HTTP-Antwort und Quell-HTML | Anfangsinhalt, Header und Status | Vollständigen gerenderten DOM |
| Lokaler DOM und Netzwerkaufzeichnung | Laufzeitverhalten dieser Sitzung | Was Google zuvor indexiert hat |
| Gespeicherte URL-Prüfinformationen | Googles gespeicherte Crawl- und Indexdaten | Verhalten nach einem neuen Deployment |
| Live-Prüfung oder Rich Results Test | Aktuelles Rendering und unterstützte Prüfungen | Garantierte Indexierung oder Rankings |
Suchen Sie im gerenderten HTML nach dem tatsächlichen Text und den Zieladressen der Links. Ein Screenshot hilft bei Layoutfragen, zeigt aber nicht alle Metadaten oder Linkeigenschaften. Auch ein erfolgreicher Rich-Results-Test ersetzt nicht die Kontrolle, ob die zentrale Erklärung vorhanden ist.
Dokumentieren Sie Deployment-Version und Testzeit. Wenn ein altes Bundle im Cache bleibt, während der Server neues Markup liefert, tritt der Fehler möglicherweise nur während eines Releases auf. Testen Sie direkten Aufruf und Client-Navigation zur gleichen Route. Eine funktionierende Navigation von der Startseite beweist nicht, dass die tiefe URL unabhängig erreichbar ist.
Entfernen Sie Abhängigkeiten von Interaktion und Sitzungszustand
Googlebot verhält sich nicht wie ein angemeldeter Käufer, der einen Ablauf durchklickt. Öffentlicher Inhalt sollte für seinen Abruf weder einen Klick noch ein Scroll-Ereignis oder einen bestimmten Local-Storage-Wert benötigen. Eine Beschreibung, die erst beim Aufklappen angefordert wird, unterscheidet sich von bereits im DOM vorhandenem Text in einer kompakten Oberfläche.
Untersuchen Sie die Datenanfrage hinter dem fehlenden Abschnitt. Funktioniert sie ohne Sitzungscookies, private Zugangsdaten und vorherigen Besuch einer anderen Route? Eine Sitzung mit gefülltem Cache kann einen kaputten Initialisierungspfad verdecken. Wesentliche APIs und Skripte müssen unter den Bedingungen verfügbar sein, die das öffentliche Rendering benötigt.
Nehmen Sie nicht an, dass jede Browser-API im Renderingdienst identisch arbeitet. Erkennen Sie optionale Funktionen und bieten Sie brauchbare Alternativen. Wesentlicher Text sollte unabhängig von Berechtigungen wie Standortzugriff bleiben. Eine Sprach- oder Regionalfassung benötigt eine stabile direkte URL und sollte nicht erst nach dem Speichern einer Client-Präferenz existieren.
Entkoppeln Sie außerdem sachfremde Dienste vom Hauptinhalt. Verhindert eine fehlgeschlagene Analyseanfrage die Produktanzeige, sind unabhängige Aufgaben unnötig verbunden. Rendern Sie den Kerninhalt eigenständig und behandeln Sie optionale Integrationen separat. Das erhöht die Robustheit für Besucher und Crawler.
Lassen Sie Links und Routen ohne vorgegebenen Klickpfad funktionieren
Verwenden Sie für Navigation Ankerelemente mit nutzbaren href-Werten. Ein Button mit onClick eignet sich für Aktionen, ersetzt aber keinen entdeckbaren Link zu einem Dokument. JavaScript darf normale Links erweitern, ohne ihre Ziele aufzugeben.
Dieser Paginierungslink bleibt eine echte Adresse, selbst wenn die Oberfläche ihn für einen schnelleren Übergang abfängt:
<nav aria-label="Catalog pages">
<a href="/catalog/?page=2">Next catalog page</a>
</nav>Auch das Ziel muss bei direktem Abruf funktionieren. Konfigurieren Sie Server und Router so, dass eine tiefe URL den vorgesehenen Inhalt mit passendem Status liefert. Eine allgemeine Anwendungshülle kann für bestimmte Architekturen nötig sein, darf aber nicht jeden ungültigen Pfad in eine scheinbar erfolgreiche Seite verwandeln.
Verwenden Sie die History API für Client-Routing zwischen aussagekräftigen URLs. Verlassen Sie sich nicht auf Fragmente wie #/products, um eigenständige indexierbare Dokumente zu kennzeichnen. Fragmente können Stellen innerhalb eines Dokuments markieren, ersetzen aber Googles dokumentierte URL-Strategie nicht zuverlässig.
Testen Sie fehlende Produkte, abgelaufene Routen und fehlerhafte Parameter. Eine Client-Fehlermeldung innerhalb einer 200-Antwort kann als Soft 404 gelten. Bevorzugen Sie nach Möglichkeit den passenden Serverstatus. Google beschreibt Ausweichlösungen für reine Client-Anwendungen; diese rechtfertigen jedoch nicht, die Serverantwort zu ignorieren.
Halten Sie Metadaten zwischen Antwort und Rendering konsistent
Jede indexierbare Route benötigt einen beschreibenden Titel, eine passende Beschreibung und ein konsistentes Canonical. Werden diese bereits im Server-HTML ausgeliefert, sinkt die Zahl der Abhängigkeiten und die Prüfung wird klarer. JavaScript kann Metadaten setzen. Ein vorhandenes Canonical später auf eine andere Adresse zu ändern erzeugt jedoch widersprüchliche Signale.
Dieser beispielhafte Produktkopf enthält ein Canonical und konkrete Metadaten:
<title>Oak desk specifications and dimensions</title>
<meta name="description" content="Dimensions, materials and assembly information for the oak desk.">
<link rel="canonical" href="https://example.com/products/oak-desk/">Eine Metadatenbibliothek sollte die vorgesehenen Elemente aktualisieren, statt mehrere Canonicals oder widersprüchliche Robots-Anweisungen anzuhäufen. Prüfen Sie den endgültigen DOM nach Routenwechseln und nicht nur das Template. Ein Zustand der vorherigen Route kann einen falschen Titel oder ein falsches Canonical hinterlassen.
Seien Sie bei noindex besonders vorsichtig. Google kann das Rendering überspringen, wenn das ursprüngliche HTML die Indexierung untersagt. noindex auszuliefern und es durch JavaScript entfernen zu wollen ist daher unzuverlässig. Soll eine öffentliche Seite indexiert werden, muss diese Absicht bereits in der ersten Antwort konsistent sein.
Strukturierte Daten dürfen ebenfalls per JavaScript entstehen, müssen aber sichtbare, korrekte Inhalte beschreiben. Prüfen Sie ihre Anwesenheit nach dem Rendering und die Übereinstimmung mit der Seite. Gültiges Markup kompensiert weder eine fehlende Beschreibung noch einen nicht geladenen Preis und garantiert kein Rich Result.
Laden Sie Ressourcen verzögert, ohne das Dokument zu verstecken
Ein Bild außerhalb des Sichtbereichs verzögert zu laden kann unnötige Übertragung sparen. Den Hauptartikel erst nach einem Scroll-Ereignis abzurufen kann dagegen verhindern, dass er im indexierbaren Ergebnis auftaucht. Unterscheiden Sie Ressourcenoptimierung vom Zurückhalten des Inhalts, der die Seite definiert.
Google empfiehlt, relevante Inhalte beim Sichtbarwerden im Viewport zu laden und Nutzeraktionen nicht vorauszusetzen. Verwenden Sie für Bilder unterstütztes natives Ladeverhalten oder eine geprüfte sichtbarkeitsabhängige Umsetzung. Echte Bildadressen müssen beim Rendering verfügbar sein. Reservierter Platz verhindert, dass spätes Eintreffen den umliegenden Inhalt verschiebt.
Stellen Sie bei Infinite Scroll paginierte URLs mit erreichbaren Links und sinnvollen Inhaltsabschnitten bereit. Besucher mögen einen fortlaufenden Feed bevorzugen, doch einzelne Teile benötigen weiterhin abrufbare Adressen und Entdeckungswege. Testen Sie eine spätere Seite direkt. Wiederholtes Scrollen im eigenen Browser beweist keine vollständige Erfassung.
Laden Sie das wichtige LCP-Bild im ersten Sichtbereich nicht allein deshalb verzögert, weil alle Bildkomponenten denselben Standard verwenden. Auslieferung beeinflusst Suche und Leistung. Stellen Sie zuerst zuverlässige Inhaltsverfügbarkeit sicher und verfeinern Sie dann den Bandbreitenverbrauch zweitrangiger Ressourcen.
Wählen Sie Rendering nach den entfallenden Abhängigkeiten
Statische Generierung erzeugt HTML vor Anfragen. Serverseitiges Rendering erzeugt es während der Bearbeitung. Beide können wichtige Texte und Links in der Antwort liefern. Clientseitiges Rendering erstellt Inhalte nach dem Laden von Skripten und häufig Daten im Browser. Hydration ergänzt vorhandenes HTML um Interaktivität.
Diese Optionen schließen sich innerhalb einer Anwendung nicht aus. Ein öffentlicher Artikel kann statisch sein, eine persönliche Kontoansicht dynamisch und ein kleiner Filter interaktiv. Der Next.js-Performance-Leitfaden erklärt die Verbindung zu Server- und Client-Komponentengrenzen.
Serverseitiges Rendering garantiert keine Geschwindigkeit. Langsame Datenabhängigkeiten können die gesamte Antwort verzögern; ein großes Client-Bundle kann die Hydration nach dem sichtbaren Text teuer machen. Streaming liefert nützliche Abschnitte möglicherweise früher. Prüfen Sie trotzdem, ob der Hauptinhalt noch auf eine langsame Abhängigkeit wartet.
Hydration sollte den ursprünglichen Inhalt erhalten, statt ihn durch einen widersprüchlichen Ladezustand zu ersetzen. Unterschiede zwischen Server- und Client-Ausgabe können Fehler und unerwartete Änderungen verursachen. Testen Sie während und nach dem Skriptladen, einschließlich langsamer und fehlgeschlagener Anfragen.
Dynamisches Rendering erkennt Crawler und liefert ihnen eine getrennt gerenderte Fassung. Google beschreibt dies als Ausweichlösung, nicht als langfristige Empfehlung. Zusätzliche Infrastruktur und gleichwertige Ausgaben müssen gepflegt werden. Bevorzugen Sie nach Möglichkeit eine einheitliche Architektur und liefern Sie Crawlern keine wesentlich anderen Inhalte als Optimierungstaktik.
Verbinden Sie Renderingprobleme mit Leistungsbelegen
Ein großes JavaScript-Bundle kann Download-, Parsing- und Ausführungsaufwand erhöhen. Das verzögert Inhalte für Besucher und verlängert die Abhängigkeitskette des Renderings. Eine schlechte Performance-Bewertung beweist jedoch keine Inhaltsauslassung durch Google. Eine gute Bewertung beweist ebenso wenig Indexierbarkeit.
Verfolgen Sie die konkrete Kette: Dokument, Skript, API-Anfrage, DOM-Änderung und Darstellung. Hängt der Kerninhalt davon ab, prüfen Sie, welche Schritte auf den Server verlagert oder entfernt werden können. Blockiert eine Aufgabe erst nach der Inhaltsanzeige Interaktionen, ist der Leitfaden zur JavaScript-Ausführung der passende nächste Schritt.
Verwenden Sie den PageSpeed-Analysator für Leistung und Googles Prüfwerkzeuge für Such-Rendering. Halten Sie beide Ergebnisse im Fehlerprotokoll getrennt. Die Aussage „Die Produktüberschrift fehlt im live gerenderten HTML“ ist konkret bearbeitbar. „JavaScript schadet SEO“ ist dafür zu ungenau.
Prüfen Sie die Korrektur auf Template-Ebene
Testen Sie nach Änderungen die fehlerhafte Route und eine weitere aus derselben Vorlage. Berücksichtigen Sie direkten Tiefenlink, fehlende Ressource, mobilen Viewport und Client-Navigation. Kontrollieren Sie Hauptinhalt, Links, Metadaten und Status, statt nur eine normale Darstellung festzustellen.
Verwenden Sie inhaltsabhängige Dateinamen für geänderte JavaScript- und CSS-Dateien, damit aktualisierter Code eine eigene URL erhält. Google weist auf aggressives Ressourcen-Caching seines Renderingdienstes hin. Versionierte Assets erleichtern außerdem die Zuordnung zu einem Deployment, ersetzen jedoch keine stimmige Release- und Cache-Strategie.
Dokumentieren Sie die Korrektur und die Grenzen ihrer Belege. Ein erfolgreicher Live-Render zeigt die Verfügbarkeit im konkreten Test. Indexierung und Ranking benötigen weitere Beobachtung. Nehmen Sie den Fehlerfall in die Release-Prüfungen Ihres technischen SEO-Ablaufs auf, damit die nächste Routingänderung die entfernte Abhängigkeit nicht unbemerkt zurückbringt.
