JavaScript-Seiten nicht indexiert: SPA- und Framework-Rendering für Google beheben
Deine JavaScript-Anwendung sieht im Browser perfekt aus, aber Google sieht eine leere Seite. Verstehe genau, wie Googles Zwei-Wellen-Indexierungs-Prozess JavaScript-Inhalt handhabt und was du ändern musst.
In dieser Anleitung
React, Vue, Angular, Next.js und andere JavaScript-Frameworks treiben Millionen von Websites an, aber es gibt eine grundlegende Spannung zwischen clientseitigem Rendering und wie Google Seiten indexiert.
Google verarbeitet Seiten in zwei Wellen. Die erste Welle parst rohes HTML sofort. Die zweite Welle, die Stunden oder Tage später passieren kann, rendert JavaScript. Wenn dein HTML ein leeres div mit einem Script-Tag ist, sieht Googles erste Welle keinen Inhalt. Die Rendering-Warteschlange kann Tage dauern, und Fehler durch API-Timeouts oder JS-Fehler können zur permanenten Thin-Content-Klassifizierung führen.
Dieser Guide behandelt Diagnosen für rendering-basierte Indexierungs-Fehler und praktische Lösungen für jedes große Framework.
Wie Googles Zwei-Wellen-Indexierung tatsächlich funktioniert
Das Verständnis von Googles Rendering-Pipeline ist essenziell für die Diagnose und Behebung von JavaScript-Indexierungs-Problemen. Der Prozess arbeitet in distinkten Phasen, und Probleme in jeder Phase können verhindern, dass dein Inhalt indexiert wird.
In der ersten Phase sendet Googlebot eine HTTP-Anfrage für deine URL und empfängt die HTML-Antwort. Das ist identisch mit dem, was du sehen würdest, wenn du den Seitenquelltext (Strg+U) in deinem Browser ansiehst. Googlebot parst dieses HTML, um Text-Inhalt, Links, Meta-Tags, Canonical-Tags und strukturierte Daten zu extrahieren. Jeder Inhalt, der in dieser initialen HTML-Antwort vorhanden ist, ist sofort für die Indexierung verfügbar. Diese Phase ist schnell und passiert während des normalen Crawl-Prozesses.
In der zweiten Phase wird die URL in eine Rendering-Warteschlange gestellt. Google betreibt einen Web Rendering Service (WRS), der einen Headless-Chromium-Browser nutzt, um JavaScript auszuführen und das finale gerenderte DOM zu produzieren. Der WRS lädt deine Seite, führt alle Skripte aus, wartet auf das Laden dynamischer Inhalte und erfasst dann den finalen Seitenzustand. Dieses gerenderte DOM wird gegen das initiale HTML verglichen. Jeder neue Inhalt, der im gerenderten DOM entdeckt wird, wird zu Googles Index hinzugefügt.
Die kritische Einsicht ist, dass die Rendering-Warteschlange nicht in Echtzeit arbeitet. Google hat anerkannt, dass die Rendering-Warteschlange erhebliche Verzögerungen haben kann, weil das Ausführen von JavaScript ressourcenintensiv ist. Obwohl Google die Rendering-Geschwindigkeit über die Jahre erheblich verbessert hat, kann die Warteschlange noch immer Verzögerungen von mehreren Stunden bis zu mehreren Tagen einführen, besonders für Seiten von Domains mit niedrigerer Autorität oder Sites, die Google nicht für häufiges Crawling priorisiert.
Während der Wartezeit zwischen erster und zweiter Welle kann deine Seite allein auf Basis ihres initialen HTML-Inhalts bewertet werden. Enthält das initiale HTML nur ein Root-Div, eine Lade-Animation und eine JavaScript-Bundle-Referenz, bewertet Google die Seite als ohne bedeutsamen Inhalt. Diese Bewertung kann dazu führen, dass die Seite für das Rendering deprioritisiert oder als Thin Content klassifiziert wird, bevor die zweite Welle überhaupt eine Chance hatte, sie zu verarbeiten.
Die Rendering-Warteschlange ist auch fehleranfällig. Wirft dein JavaScript während des Renderings einen Fehler, läuft ein API-Aufruf in einen Timeout, erfordert die Seite Authentifizierung oder blockiert ein Drittanbieter-Skript die Ausführung, kann der WRS einen unvollständigen oder leeren Render produzieren. Google wiederholt fehlgeschlagene Renders nicht sofort, was bedeutet, dass ein transienter Fehler während des Renderings die Indexierung über einen längeren Zeitraum verhindern kann.
Googles WRS läuft mit einer modernen Version von Chromium, die ES6+, async/await, fetch, Web Components und die meisten modernen JavaScript-APIs unterstützt. Es unterstützt jedoch nicht alle Browser-APIs. Insbesondere hat es keinen sinnvollen Zugriff auf localStorage, sessionStorage oder IndexedDB. Es unterstützt keine User-Interaktions-Events (Scrollen, Klicken, Hovern), was bedeutet, dass Inhalt, der durch Scroll-Events, Click-to-Expand-Elemente oder Hover-getriggerte Popups geladen wird, für Google unsichtbar ist. Der WRS hat auch einen Timeout für die JavaScript-Ausführung. Braucht deine Seite länger als etwa fünf Sekunden, um ihren kritischen Inhalt zu rendern, kann der WRS einen unvollständigen Zustand erfassen.
Client-Side Rendering vs. SSR vs. SSG: Die Indexierungs-Auswirkung
Die Rendering-Strategie, die du für deine JavaScript-Anwendung wählst, hat einen direkten und messbaren Einfluss auf Indexierungs-Ergebnisse. Das Verständnis der Kompromisse zwischen Client-Side Rendering (CSR), Server-Side Rendering (SSR) und Static Site Generation (SSG) ist essenziell für fundierte architektonische Entscheidungen.
Client-Side Rendering ist der Standard für Single-Page-Anwendungen, die mit Create React App, Vue CLI oder Angular CLI gebaut sind. Der Server sendet ein minimales HTML-Dokument mit einem Root-Element und Script-Tags. Das gesamte Inhalts-Rendering passiert im Browser, nachdem JavaScript geladen und ausgeführt wurde. Aus Googles Sicht sind CSR-Seiten leer, bis die Rendering-Warteschlange sie verarbeitet, was die oben beschriebenen Verzögerungen und Fehler-Risiken erzeugt. CSR ist die risikoreichste Rendering-Strategie für SEO und Indexierung.
Server-Side Rendering generiert das vollständige HTML auf dem Server für jede Anfrage. Wenn Googlebot eine Seite anfordert, führt der Server das JavaScript-Framework aus, produziert das vollständige HTML und sendet es in der Antwort. Googles erste Welle sieht sofort den gesamten Inhalt, ohne auf die Rendering-Warteschlange warten zu müssen. Nachdem das HTML im Browser eines echten Nutzers geladen ist, hydratisiert JavaScript die Seite, um sie interaktiv zu machen. SSR bietet das Beste aus beiden Welten: sofortige Inhalts-Verfügbarkeit für Google und volle Interaktivität für Nutzer. Frameworks wie Next.js, Nuxt und SvelteKit bieten SSR-Fähigkeiten von Haus aus.
Static Site Generation rendert Seiten zur Build-Zeit vor, statt bei jeder Anfrage. Das Ergebnis ist eine Sammlung statischer HTML-Dateien, die direkt von einem CDN bedient werden. Google empfängt vollständiges HTML sofort, und es gibt keine serverseitigen Rendering-Verzögerungen oder -Fehler. SSG ist ideal für Inhalt, der sich nicht mit jeder Anfrage ändert: Blogbeiträge, Dokumentation, Marketingseiten und Produktkataloge, die sich periodisch statt in Echtzeit aktualisieren. Die Einschränkung ist, dass SSG einen Rebuild erfordert, um Inhalt zu aktualisieren, was es unpraktisch für sehr dynamische Seiten wie Dashboards, Suchergebnisse oder Echtzeit-Inventar-Anzeigen macht.
Incremental Static Regeneration (ISR), verfügbar in Next.js und ähnlichen Frameworks, kombiniert SSG mit periodischem Re-Rendering. Seiten werden zur Build-Zeit vorgerendert, können aber in definierten Intervallen oder bei Inhalts-Änderungen on-demand neu generiert werden. Das bietet die Indexierungs-Zuverlässigkeit von SSG mit der Inhalts-Frische von SSR. Für E-Commerce-Sites mit Tausenden von Produktseiten, die sich periodisch ändern, ist ISR oft die optimale Wahl.
Die praktische Empfehlung ist klar: Vermeide reines Client-Side-Rendering für jede Seite, die du indexiert haben möchtest. Verwende SSR für dynamische Seiten, die sich pro Anfrage ändern, und SSG oder ISR für Inhalt, der sich periodisch ändert. Ist eine Migration von CSR zu SSR kurzfristig nicht machbar, implementiere dynamisches Rendering als Brückenlösung.
JavaScript-Rendering-Fehler diagnostizieren
Zu identifizieren, ob JavaScript-Rendering deine Indexierungs-Probleme verursacht, erfordert systematisches Testen mit Tools, die dir genau zeigen, was Google in jeder Phase der Indexierungs-Pipeline sieht.
Das primäre Diagnose-Tool ist das URL-Prüfungs-Feature der Google Search Console. Gib die URL einer nicht indexierten JavaScript-gerenderten Seite ein und klicke auf „Live-URL testen“. Das Tool führt einen Live-Crawl und -Render der Seite durch und simuliert Googles tatsächliche Verarbeitungs-Pipeline. Überprüfe zwei Ausgaben: den Screenshot der gerenderten Seite (der zeigt, was Google nach JavaScript-Ausführung sieht) und die Details der getesteten Seite (die das rohe HTML und alle Ressourcen-Lade-Fehler zeigen). Vergleiche den Screenshot mit dem, was du im Browser siehst. Zeigt der Screenshot unvollständigen Inhalt, fehlende Bereiche oder eine leere Seite, schlägt Google fehl, dein JavaScript korrekt zu rendern.
Der zweite diagnostische Schritt ist die Untersuchung des rohen HTML-Quelltexts. Öffne deine Seiten-URL in einem Browser und drücke Strg+U, um den ungerenderten Quelltext anzusehen. Das ist, was Google in der ersten Indexierungs-Welle sieht. Zeigt der Quelltext bedeutsamen Inhalt (Titel, Überschriften, Text-Absätze, Links), ist dein Inhalt sofort verfügbar. Zeigt er nur ein div mit einer ID wie „root“ oder „app“ und Script-Tags, hängt dein Inhalt komplett vom JavaScript-Rendering ab.
Drittens prüfe auf JavaScript-Fehler, die das Rendering verhindern könnten. Öffne in den Developer Tools deines Browsers die Console-Registerkarte und lade die Seite neu. Notiere alle roten Fehlermeldungen. Dieselben Fehler treten in Googles Rendering-Umgebung auf und können verhindern, dass Inhalt geladen wird. Häufige Übeltäter sind API-Aufrufe an Server, die Anfragen ohne korrekte Authentifizierungs-Header ablehnen (Googles Renderer sendet keine Cookies oder Auth-Tokens), CORS-Fehler bei Drittanbieter-Ressourcen und Referenzen auf browser-spezifische APIs, die in Headless-Chromium nicht existieren.
Viertens teste die Rendering-Geschwindigkeit. Googles WRS hat einen Timeout für die JavaScript-Ausführung. Öffne in den Developer Tools deines Browsers die Performance-Registerkarte und zeichne einen Seitenlade-Vorgang auf. Braucht dein kritischer Inhalt mehr als drei bis fünf Sekunden, um nach dem Laden des initialen HTML zu erscheinen, kann Google in einen Timeout laufen, bevor der Inhalt rendert. Langsame API-Antworten, große JavaScript-Bundles und komplexe Rendering-Logik können deine Seite über das Rendering-Timeout hinausdrängen.
Fünftens prüfe auf Inhalt hinter Interaktions-Gates. Manche JavaScript-Anwendungen laden Inhalt nur als Antwort auf Nutzer-Interaktionen: Klicken eines „Mehr laden“-Buttons, Scrollen über eine Schwelle hinaus oder Auswählen eines Tabs. Googles Renderer führt diese Interaktionen nicht aus. Inhalt, der hinter Interaktions-Anforderungen versteckt ist, wird für Google nie sichtbar. Stelle sicher, dass aller Inhalt, den du indexiert haben möchtest, beim initialen Seiten-Rendering ohne erforderliche Nutzer-Interaktion sichtbar ist.
Framework-spezifische Fixes für häufige Indexierungs-Blocker
Jedes JavaScript-Framework hat seine eigenen Muster, die Indexierungs-Probleme verursachen. Die framework-spezifischen Fallstricke und Fixes zu kennen, kann Stunden Debugging sparen.
Für React-Anwendungen mit Create React App (CRA) wird die gesamte Anwendung standardmäßig clientseitig gerendert. Es gibt keine eingebaute SSR-Fähigkeit. Der empfohlene Migrationspfad ist der Wechsel zu Next.js, das SSR und SSG out-of-the-box bereitstellt und dabei dasselbe React-Komponenten-Modell nutzt. Ist eine Migration zu Next.js nicht machbar, implementiere dynamisches Rendering mit einem Pre-Rendering-Service, der statische HTML-Snapshots für Googles Crawler generiert.
Für Next.js-Anwendungen stammen die meisten Indexierungs-Probleme von Seiten, die nur clientseitiges Datenabrufen (useEffect + fetch) statt serverseitiges Datenabrufen (getServerSideProps oder getStaticProps oder die neueren App-Router-Server-Components) verwenden. Wird der Inhalt deiner Seite innerhalb eines useEffect-Hooks geladen, erscheint er nicht im serverseitig gerenderten HTML. Verschiebe Datenabrufe auf die Server-Ebene. Verwende im App Router standardmäßig Server Components und füge „use client“ nur zu Komponenten hinzu, die wirklich Interaktivität benötigen. Verwende im Pages Router getServerSideProps für dynamische Daten und getStaticProps für statische Daten.
Für Vue-Anwendungen mit Nuxt gelten ähnliche Prinzipien. Verwende asyncData oder useFetch im Server-Kontext statt clientseitiger Fetch-Aufrufe. Nuxts Standard-SSR-Modus rendert Inhalt auf dem Server, aber Plugins und Komponenten, die nur clientseitig laufen, können Löcher in der gerenderten Ausgabe erzeugen. Verwende die ClientOnly-Wrapper-Komponente explizit für clientseitig-only-Inhalt und stelle sicher, dass sie nicht um kritischen indexierbaren Inhalt verwendet wird.
Für Angular-Anwendungen bietet Angular Universal serverseitiges Rendering. Implementiere Angular Universal und stelle sicher, dass deine Haupt-Inhalts-Komponenten auf dem Server gerendert werden. Achte auf Komponenten, die direkt auf browser-spezifische Objekte wie window, document oder navigator verweisen, da diese während serverseitigem Rendering Fehler werfen und das Rendering der Seite komplett verhindern können.
Für alle Frameworks achte besonders auf Lazy Loading und Code Splitting. Dynamische Imports, die Komponenten on-demand laden (React.lazy, dynamische Imports in Vue und Angular), können verhindern, dass Inhalt im initialen Server-Render vorhanden ist. Kritischer Above-the-Fold-Inhalt sollte nie Lazy Loaded sein. Verschiebe Schlüssel-Inhalts-Komponenten in das Haupt-Bundle, um sicherzustellen, dass sie in der initialen HTML-Antwort gerendert werden.
Web Components bringen ihre eigenen Herausforderungen mit. Während Google Standard-Web-Components rendern kann, rendern komplexe Shadow-DOM-Strukturen und tief verschachtelte Custom Elements möglicherweise nicht zuverlässig im WRS. Teste Web-Component-Rendering explizit mit dem URL-Prüftool und erwäge, kritischen Inhalt aus dem Shadow DOM herauszuflachen, um die Indexierungs-Zuverlässigkeit zu verbessern.
Dynamisches Rendering als Brückenlösung
Dynamisches Rendering ist eine Technik, bei der dein Server erkennt, ob die eingehende Anfrage von einem Suchmaschinen-Crawler oder einem regulären Nutzer kommt, und entsprechend unterschiedlichen Inhalt liefert. Crawler-Anfragen erhalten eine vollständig vorgerenderte statische HTML-Version der Seite, während Nutzer-Anfragen die normale JavaScript-Anwendung erhalten. Google hat dynamisches Rendering explizit als akzeptablen Ansatz für Sites unterstützt, die kein vollständiges SSR implementieren können.
Das Setup umfasst drei Komponenten. Erstens einen User-Agent-Erkennungs-Mechanismus auf deinem Server oder CDN, der Anfragen von Googlebot und anderen Suchmaschinen-Crawlern identifiziert. Googlebot identifiziert sich mit einem User-Agent-String, der „Googlebot“ enthält, was einfach zu matchen ist. Zweitens einen Pre-Rendering-Service (wie Puppeteer, Rendertron oder einen kommerziellen Service wie Prerender.io), der statische HTML-Snapshots deiner JavaScript-Seiten generiert und cacht. Drittens Routing-Logik, die das vorgerenderte HTML an erkannte Crawler-Anfragen ausliefert und die normale JavaScript-Anwendung an alle anderen Anfragen.
Dynamisches Rendering ist explizit kein Cloaking, das gegen Googles Richtlinien verstößt. Cloaking bedeutet, Nutzern und Crawlern komplett unterschiedlichen Inhalt zu zeigen, um Rankings zu manipulieren. Dynamisches Rendering zeigt denselben Inhalt in einem unterschiedlichen technischen Format. Der vorgerenderte HTML-Snapshot sollte exakt denselben Text, dieselben Bilder, Links und strukturierten Daten enthalten wie die JavaScript-gerenderte Version. Google hat diese Unterscheidung wiederholt bestätigt.
Implementierungs-Ansätze variieren je nach Infrastruktur. Für Node.js-Server kannst du Middleware nutzen, die den User-Agent-Header prüft und Googlebot-Anfragen durch Puppeteer oder Rendertron routet. Für Sites hinter einem CDN wie Cloudflare kannst du Edge-Workers nutzen, um Googlebot-Anfragen abzufangen und gecachte vorgerenderte Seiten auszuliefern. Für statisches Hosting mit einem API-Backend kann ein Pre-Rendering-Service HTML-Snapshots während deines Build- oder Deployment-Prozesses generieren.
Die Caching-Strategie für vorgerenderte Seiten ist wichtig. Vorgerenderte Snapshots werden stale, während dein Inhalt sich ändert. Für statischen Inhalt wie Blogbeiträge oder Dokumentation können Snapshots Tage oder Wochen gecacht werden. Für dynamischen Inhalt wie Produktseiten mit sich ändernden Preisen und Verfügbarkeit sollten Snapshots mindestens täglich regeneriert werden. Für Echtzeit-Inhalt wie Aktien-Ticker oder Live-Scores kann dynamisches Rendering ungeeignet sein, weil der gecachte Snapshot immer veraltet sein wird.
Dynamisches Rendering sollte als Übergangslösung gesehen werden, nicht als permanente Architektur. Die langfristige Best Practice ist die Implementierung von nativem serverseitigem Rendering, sodass alle Nutzer und Crawler dieselbe Antwort erhalten. Dynamisches Rendering fügt Komplexität, Wartungsaufwand und einen potenziellen Fehlerpunkt hinzu (geht der Pre-Rendering-Service offline, sieht Googlebot kaputte Seiten). Verwende es als Brücke, während du zu SSR oder SSG migrierst.
Schritt-für-Schritt-Anleitung
Bestimme deine aktuelle Rendering-Strategie
Öffne eine deiner nicht indexierten Seiten und sieh dir den HTML-Quelltext an (Strg+U, nicht den Developer-Tools-Inspector). Sieh dir den Body-Inhalt an. Siehst du ein einzelnes div mit einer ID wie „root“ oder „app“ und ein oder mehrere Script-Tags, verwendet deine Seite reines clientseitiges Rendering. Siehst du vollständigen HTML-Inhalt einschließlich Überschriften, Absätze und strukturierter Daten, ist deine Seite zumindest teilweise serverseitig gerendert. Dokumentiere, welche Rendering-Strategie jeder Bereich deiner Site verwendet. Viele moderne Anwendungen nutzen eine Mischung: serverseitig gerenderte Navigation und Layout mit clientseitig gerenderten Inhalts-Bereichen.
Teste Seiten mit Googles URL-Prüftool
Gib in der Google Search Console die URL einer nicht indexierten Seite ein und klicke auf „Live-URL testen“. Warte, bis der Test abgeschlossen ist, und überprüfe die Ergebnisse. Untersuche den Screenshot der gerenderten Seite, um zu sehen, ob dein Inhalt erscheint. Prüfe den Bereich „Mehr Infos“ auf Ressourcen-Lade-Fehler, JavaScript-Fehler oder blockierte Ressourcen. Zeigt der Screenshot deinen vollständigen Seiteninhalt, die Seite ist aber noch nicht indexiert, funktioniert das Rendering, aber es kann andere Probleme geben (Thin Content, noindex-Tags, Canonical-Konflikte). Zeigt der Screenshot fehlenden Inhalt oder eine leere Seite, blockieren Rendering-Fehler die Indexierung. Teste fünf bis zehn Seiten über verschiedene Bereiche deiner Site, um Muster zu identifizieren.
Identifiziere und behebe JavaScript-Rendering-Fehler
Prüfe in den Ergebnissen des URL-Prüftools auf blockierte Ressourcen und Seiten-Ressourcen-Fehler. Häufige Probleme sind API-Aufrufe, die fehlschlagen, weil Googles Renderer keine Authentifizierungs-Cookies sendet, CORS-blockierte Cross-Origin-Ressourcen, Referenzen auf Browser-APIs, die in Googles Headless-Renderer nicht verfügbar sind (window.localStorage, navigator.geolocation), und Drittanbieter-Skripte, die das Rendering blockieren. Bestimme für jeden Fehler, ob er kritischen Inhalt betrifft. Behebe API-Authentifizierung, indem du öffentliche Endpunkte für Inhalts-Daten bereitstellst. Ersetze browser-spezifische API-Aufrufe durch serverseitige Alternativen oder biete Fallback-Verhalten, wenn die APIs nicht verfügbar sind.
Implementiere Server-Side Rendering oder Static Generation
Basierend auf deinem Framework, implementiere die geeignete Server-Rendering-Strategie. Für React-CRA-Projekte migriere zu Next.js mit seinem App Router und Server Components. Für Vue-CLI-Projekte migriere zu Nuxt mit seinem eingebauten SSR. Für Angular-Projekte implementiere Angular Universal. Für bestehende Next.js- oder Nuxt-Projekte, die clientseitiges Datenabrufen nutzen, verschiebe das Datenabrufen in serverseitige Funktionen (getServerSideProps, getStaticProps, Server Components oder asyncData). Nach der Implementierung von SSR oder SSG verifiziere, indem du den Seitenquelltext ansiehst und bestätigst, dass Inhalt im rohen HTML ohne JavaScript-Ausführung erscheint.
Implementiere dynamisches Rendering als kurzfristigen Fix bei Bedarf
Ist eine Migration zu SSR nicht sofort machbar, implementiere dynamisches Rendering als Brückenlösung. Richte einen Pre-Rendering-Service ein (Puppeteer, Rendertron oder Prerender.io). Konfiguriere deinen Server oder dein CDN, Googlebot-Anfragen am User-Agent-String zu erkennen und sie zum vorgerenderten HTML zu routen. Teste, indem du curl mit einem Googlebot-User-Agent-String verwendest, um zu verifizieren, dass das vorgerenderte HTML korrekt ausgeliefert wird. Vergleiche das vorgerenderte HTML mit der normalen Seite, um Inhalts-Parität sicherzustellen. Richte automatisierte Pre-Render-Cache-Refreshs ein, um Snapshots aktuell zu halten.
Verifiziere Fixes und reiche zur Indexierung ein
Nach der Implementierung von SSR, SSG oder dynamischem Rendering teste deine Seiten erneut mit dem URL-Prüftool. Verifiziere, dass der gerenderte Screenshot vollständigen Inhalt zeigt und keine Ressourcen-Fehler gemeldet werden. Sieh dir den Seitenquelltext an, um zu bestätigen, dass Inhalt im initialen HTML ist. Sobald verifiziert, nutze das URL-Prüftool, um die Indexierung für deine wichtigsten Seiten anzufordern. Für Sites mit vielen von JavaScript-Rendering-Problemen betroffenen Seiten nutze IndexBolt, um alle behobenen URLs für schnelle Indexierung in Massen einzureichen. Überwache den Seiten-Bericht in den folgenden zwei Wochen, um die Indexierungs-Erholung zu verfolgen.
Richte laufende Überwachung für Rendering-Regressionen ein
JavaScript-Rendering-Probleme können nach Code-Deployments, Dependency-Updates oder API-Änderungen wieder auftreten. Richte automatisierte Überwachung ein, um Regressionen früh zu erkennen. Verwende Lighthouse CI oder ein ähnliches Tool in deiner CI/CD-Pipeline, um die serverseitig gerenderte HTML-Ausgabe für Schlüssel-Seiten zu testen. Konfiguriere Alerts für Rendering-Fehler in deinem Pre-Rendering-Service. Plane wöchentliche Prüfungen des Seiten-Berichts der Google Search Console, um neue Spikes bei „Gecrawlt – zurzeit nicht indexiert“-Seiten abzufangen, die auf eine Rendering-Regression hindeuten könnten. Dokumentiere deine Rendering-Architektur und SSR-Anforderungen, damit neue Teammitglieder nicht versehentlich clientseitig-only-Inhalts-Muster einführen.
Häufige Probleme und wie du sie behebst
React-App zeigt eine leere Seite oder einen Lade-Spinner im URL-Prüftool
Ursache: Die Anwendung verwendet reines clientseitiges Rendering (Create React App oder ähnlich), bei dem der Server eine leere HTML-Hülle sendet und JavaScript die gesamte Seite im Browser baut. Googles erste Indexierungs-Welle sieht keinen Inhalt, und die Rendering-Warteschlange kann die Seite aufgrund von API-Fehlern, langen Ladezeiten oder ressourcenintensivem Rendering nicht verarbeiten.
Lösung: Migriere zu Next.js für eingebautes serverseitiges Rendering. In der Zwischenzeit implementiere dynamisches Rendering mit Prerender.io oder einer selbst gehosteten Rendertron-Instanz. Stelle sicher, dass API-Endpunkte, die von der Anwendung genutzt werden, öffentlich ohne Authentifizierung zugänglich sind, sodass Googles Renderer Daten abrufen kann. Ist eine Migration nicht sofort möglich, füge mindestens kritische Meta-Tags (Title, Description, Canonical) und Schlüssel-Überschrift-Text in das statische HTML-Template ein, das der Server sendet, bevor JavaScript lädt.
Next.js-Seiten indexiert, zeigen aber veralteten Inhalt in Google-Ergebnissen
Ursache: Seiten, die Static Site Generation (getStaticProps) nutzen, werden zur Build-Zeit vorgerendert, und Google hat die Build-Zeit-Version gecacht. Ändert sich dein Inhalt zwischen Builds, wird die indexierte Version stale. Das ist kein Rendering-Fehler, sondern ein Frische-Problem. Seiten mit Incremental Static Regeneration können auch veralteten Inhalt zeigen, wenn das Revalidierungs-Intervall länger ist als Googles Crawl-Frequenz.
Lösung: Für Seiten mit häufig wechselndem Inhalt wechsle von SSG zu SSR (getServerSideProps oder dynamische App-Router-Seiten). Für Seiten, die ISR nutzen, reduziere das Revalidierungs-Intervall, um deiner Inhalts-Update-Frequenz zu entsprechen. Nach einer größeren Inhalts-Aktualisierung nutze IndexBolt oder die Search Console, um ein erneutes Crawlen aktualisierter Seiten anzufordern, damit Google die neueste Version aufgreift. Erwäge die Implementierung von On-Demand-ISR, das die Seitenregeneration triggert, wenn Inhalt aktualisiert wird, statt sich auf zeitbasierte Revalidierung zu verlassen.
Single-Page-Anwendung mit Hash-basiertem Routing bekommt innere Seiten nicht indexiert
Ursache: Hash-basiertes Routing (URLs wie deinedomain.de/#/about, deinedomain.de/#/products) ist für Google unsichtbar. Google behandelt alles nach dem # als Fragment-Identifier und sendet es nicht an den Server. Aus Googles Sicht lösen alle Hash-basierten URLs zur selben Seite auf. Googles WRS navigiert nicht zwischen Hash-Routen, sodass nur der initiale Seiteninhalt gerendert wird.
Lösung: Migriere von Hash-basiertem Routing zu History-basiertem Routing (saubere URLs wie deinedomain.de/about, deinedomain.de/products). Wechsle in React Router von HashRouter zu BrowserRouter. Setze in Vue Router den Modus auf „history“ statt „hash“. Konfiguriere deinen Server so, dass er alle Routen-Pfade handhabt und das HTML der Anwendung für jeden URL-Pfad zurückgibt. Nach der Migration reiche die neuen sauberen URLs über die Google Search Console oder IndexBolt ein und überwache die Indexierung jeder Route.
Lazy-geladene Komponenten und Bilder erscheinen nicht in Googles Render
Ursache: Inhalt, der über React.lazy(), dynamische Imports oder Intersection-Observer-basiertes Lazy Loading geladen wird, rendert in Googles WRS möglicherweise nicht, wenn er von Scroll-Position oder Viewport-Intersection-Events abhängt. Googles Renderer lädt die Seite, scrollt oder ändert aber nicht die Viewport-Größe, sodass Inhalt, der durch Scroll-Events getriggert wird, ungeladen bleibt.
Lösung: Lade kritischen Above-the-Fold-Inhalt nie lazy. Für Below-the-Fold-Inhalt, den du indexiert haben möchtest, nutze natives Lazy Loading (loading=„lazy“-Attribut auf Bildern), das Google unterstützt, statt JavaScript-basiertem Intersection-Observer-Lazy-Loading, das Scroll-Events erfordert. Für dynamisch importierte Komponenten, die indexierbaren Inhalt enthalten, lade sie eifrig auf der Server-Seite und lazy-lade sie nur clientseitig für Performance. Schließe einen noscript-Fallback mit kritischem Inhalt für maximale Rendering-Robustheit ein.
API-getriebene Inhalts-Seiten schlagen beim Rendering fehl, weil die API Authentifizierung erfordert
Ursache: Viele JavaScript-Anwendungen rufen Inhalt von APIs ab, die Authentifizierungs-Tokens, API-Keys in Headers oder Session-Cookies erfordern. Googles WRS hat keinen Zugriff auf dein Authentifizierungs-System, kann sich nicht einloggen und sendet keine Authentifizierungs-Cookies. API-Aufrufe, die während Googles Rendering 401- oder 403-Fehler zurückgeben, führen zu leeren Inhalts-Bereichen.
Lösung: Für Inhalt, der öffentlich zugänglich sein sollte, erstelle öffentliche API-Endpunkte, die keine Authentifizierung erfordern. Liefere den Seiteninhalt, den Google sehen muss, von öffentlichen Endpunkten, während du nutzer-spezifische Daten (Account-Details, Personalisierung) hinter authentifizierten Endpunkten behältst. Implementiere serverseitiges Datenabrufen, bei dem der Server sich mit der API authentifiziert und den Inhalt in die HTML-Antwort einbettet, bevor er sie an den Browser sendet. Das eliminiert die Notwendigkeit clientseitiger API-Authentifizierung während des Renderings.
Profi-Tipps
JavaScript-Rendering-Verzögerungen bedeuten, dass deine Seiten tagelang in Googles Rendering-Warteschlange warten können, bevor sie indexiert werden. IndexBolt umgeht das Warten, indem es deine URLs direkt an Googles Indexierungs-Pipeline einreicht. Egal ob du React, Vue, Angular oder Next.js nutzt, lass deine JavaScript-gerenderten Seiten sofort indexieren, statt zu hoffen, dass Googles Renderer sie korrekt verarbeitet.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Kann Google JavaScript-Seiten tatsächlich zuverlässig rendern?+
Googles WRS nutzt modernes Chromium und rendert die meisten JS-Inhalte, aber es ist nicht sofortig (Warteschlangen-Verzögerungen), nicht zu 100 % zuverlässig (API-Fehler verursachen unvollständige Renders) und nicht universell (keine Interaktions-APIs). Für wichtige Seiten ist es riskant, sich komplett auf JS-Rendering zu verlassen. SSR eliminiert dieses Risiko, indem es sicherstellt, dass Inhalt immer im initialen HTML ist.
Ist serverseitiges Rendering für SEO notwendig oder nur empfohlen?+
Nicht technisch notwendig. Google kann CSR-Inhalt indexieren. Aber SSR bietet dramatisch bessere Zuverlässigkeit, Geschwindigkeit und Abdeckung. CSR-Seiten stehen vor Rendering-Warteschlangen-Verzögerungen, Fehler-Risiken und Crawl-Deprioritisierung. SSR-Inhalt wird sofort in der ersten Welle bewertet. Für jede Seite, bei der organischer Traffic zählt, wird SSR stark empfohlen. CSR ist für authentifizierte Dashboards und Admin-Panels okay.
Wie erkenne ich, ob Google meine JavaScript-Seiten erfolgreich rendert?+
Nutze das URL-Prüftool der Google Search Console, um genau zu sehen, was Google rendert. Gib eine URL ein, klicke auf „Live-URL testen“ und vergleiche den gerenderten Screenshot mit dem, was du in deinem Browser siehst. Passt der Inhalt, funktioniert das Rendering. Prüfe auch den Bereich „Gecrawlte Seite“ auf das HTML, das Google empfangen hat, und den Bereich „Mehr Infos“ auf Ressourcen-Lade-Fehler. Für laufende Überwachung verfolge das Verhältnis eingereichter Seiten (in deiner Sitemap) zu indexierten Seiten im Seiten-Bericht. Eine große Lücke deutet auf Rendering- oder Qualitäts-Probleme hin.
Welche Chrome-Version verwendet Googlebot fürs Rendering?+
Googles Web Rendering Service läuft mit einer Evergreen-Version von Chromium, was bedeutet, dass er mit der neuesten stabilen Chrome-Version aktuell bleibt. Ab 2026 bedeutet das volle Unterstützung für modernes JavaScript (ES2022+), CSS Grid, Flexbox, Web Components, dynamische Imports, IntersectionObserver und die meisten modernen Web-Plattform-Features. Die Rendering-Umgebung unterstützt jedoch keine User-Interaktions-APIs (kein Klick, Scroll, Hover oder Tastatur-Events), keine Payment- oder Notification-APIs und hat begrenzte localStorage/sessionStorage-Unterstützung. Prüfe Googles offizielle Dokumentation für die aktuelle Liste unterstützter und nicht unterstützter APIs.
Sollte ich dynamisches Rendering oder den Wechsel zu serverseitigem Rendering nutzen?+
Hast du die Engineering-Ressourcen, SSR zu implementieren, ist es immer die bessere langfristige Wahl. SSR bringt allen Nutzern Vorteile (schnellere initiale Seitenladezeiten, bessere Accessibility, verbesserte Core Web Vitals), nicht nur Suchmaschinen-Crawlern. Dynamisches Rendering ist eine gültige kurzfristige Lösung für Teams, die nicht schnell zu SSR migrieren können, fügt aber Wartungskomplexität hinzu (du musst den Pre-Rendering-Service am Laufen halten und den Cache frisch halten) und erzeugt ein System, in dem Nutzer und Crawler technisch unterschiedliche Antworten sehen. Verwende dynamisches Rendering als Brücke, während du eine SSR-Migration planst und durchführst.
Meine Next.js-App verwendet Server Components. Warum sind die Seiten trotzdem nicht indexiert?+
Next.js Server Components werden standardmäßig serverseitig gerendert, was exzellente Indexierung bieten sollte. Häufige Probleme sind: Import einer Komponente mit „use client“, die den Haupt-Inhalt umhüllt (zwingt sie zum clientseitigen Rendering), Datenabrufen in einer Client-Komponente statt es als Props von einer Server-Komponente zu übergeben, eine loading.tsx-Datei, die während des Server-Renderings ein Skeleton statt Inhalt zeigt, oder Middleware, die Googlebot zu einer anderen Seite umleitet. Prüfe deinen Komponenten-Baum und stelle sicher, dass die primären inhaltsführenden Komponenten Server Components sind (keine „use client“-Direktive) und dass Datenabrufen auf der Server-Ebene passiert.