JavaScript SEO und Rendering: was Suchmaschinen von Ihrer modernen App sehen

Eine moderne Web App geht eine stille Wette ein. Das HTML, das vom Server kommt, ist klein, fast leer. Die eigentliche Seite wird im Browser gebaut, von JavaScript, das nach dem Laden der Seite läuft. Für Nutzer mit schnellem Laptop und gutem Netz funktioniert das wunderbar. Für Suchmaschinen funktioniert es manchmal gar nicht.

Dieser Leitfaden zeigt, wie Google JavaScript heute wirklich rendert, das zweistufige Modell, das erklärt, warum manche Seiten länger zur Indexierung brauchen, die vier üblichen Rendering Strategien und wann jede passt, die Muster, die Indexierung auf JavaScript reichen Sites leise brechen, was KI Crawler tun und was nicht, wie Sie testen, was Google tatsächlich sieht, und ein Entscheidungsrahmen, der Rendering Entscheidungen aus Glaubensfragen in Engineering verwandelt.

Rendering 2026, kurz gefasst

Wenn eine Seite angefragt wird, muss etwas Code und Daten in HTML verwandeln. Dieses Etwas kann auf einem Server sitzen, beim Build laufen oder im Browser des Nutzers laufen. Die Wahl prägt Performance, Komplexität und Sichtbarkeit in der Suche.

Vor fünf Jahren war das eine Debatte zwischen zwei Lagern. Server seitiges Rendering gegen Client seitiges Rendering, mit starken Meinungen auf beiden Seiten. Das Gespräch ist reifer geworden. Die ehrliche Antwort 2026 ist, dass die Frage selbst falsch gestellt ist. Verschiedene Teile derselben Site brauchen verschiedene Strategien. Eine Marketing Landingpage ist kein eingeloggtes Dashboard. Eine Produktdetailseite ist keine Suchergebnisseite. Die richtige Rendering Wahl hängt davon ab, was die Seite tut, wer sie liest und wie oft die zugrundeliegenden Daten sich ändern.

Für SEO gibt es drei Randbedingungen. Suchmaschinen müssen den Inhalt finden. KI Engines müssen den Inhalt lesen. Beide müssen das in einem Geduldsbudget tun, das kürzer ist als das eines menschlichen Besuchers. Eine Seite, die einem Menschen nach drei Sekunden vollständig erscheint, kann für einen Crawler, der bei einer Sekunde aufgegeben hat, immer noch unsichtbar sein.

Das zweistufige Indexierungsmodell

Googles öffentliche Dokumentation erklärt Indexierung seit Jahren als zweistufigen Prozess für JavaScript reiche Seiten.

In der ersten Welle holt der Googlebot das rohe HTML und indexiert, was er dort findet. Wenn das HTML weitgehend leer ist (ein <div id="root"> mit einem Script Tag und nicht viel mehr), indexiert die erste Welle sehr wenig.

In der zweiten Welle gelangt die Seite in eine Render Warteschlange. Der Web Rendering Service führt das JavaScript aus, rendert die Seite wie ein echter Browser und produziert das endgültige HTML. Erst dieses HTML wird indexiert. Erst zu diesem Zeitpunkt wird der per JavaScript erzeugte Inhalt für die Suche sichtbar.

Die Lücke zwischen den beiden Wellen wurde früher in Tagen oder Wochen gemessen. Bis 2026 hat Google das für die meisten Domains auf Minuten oder Stunden komprimiert, aber das Modell besteht weiter. Für niedrig priorisierte Seiten auf kleineren Sites kann die zweite Welle immer noch hinterherhinken.

In der Praxis heißt das, JavaScript Inhalt ist für Google nicht unsichtbar, aber er ist verzögert und budgetiert. Seiten mit wertvollem Inhalt bereits im HTML der ersten Welle werden schneller indexiert und früher gerankt. Seiten, bei denen alles von der zweiten Welle abhängt, sind im Nachteil, vor allem bei zeitkritischen Inhalten wie Nachrichten, Preisen und Lagerbeständen.

Dieselbe Logik gilt für andere Suchmaschinen und für crawlerbasierte KI Systeme, mit einem wichtigen Unterschied, der später kommt: KI Crawler führen JavaScript weit weniger zuverlässig aus als der Googlebot.

Vier Rendering Strategien

Moderne Frameworks bieten vier verbreitete Strategien an. Sie schließen sich nicht aus. Eine reale Site nutzt meist zwei oder drei davon für verschiedene Teile derselben App.

Client Side Rendering (CSR). Der Server schickt eine minimale HTML Hülle. Der Browser lädt JavaScript herunter, holt Daten und baut die Seite zusammen. Beispiele, eine klassische React oder Vue Single Page Application ohne Framework darüber.

Für SEO ist CSR die riskanteste Option. Inhalt hängt vollständig von JavaScript Ausführung ab, was bei Google die zweite Welle erfordert und bei KI Crawlern und kleineren Suchmaschinen unzuverlässig ist. Nutzen Sie CSR für Seiten, die keine Sichtbarkeit in der Suche brauchen, wie ein eingeloggtes Dashboard, ein Einstellungsmenü oder eine Tool Oberfläche hinter Authentifizierung.

Server Side Rendering (SSR). Bei jeder Anfrage führt der Server den Anwendungscode aus und liefert vollständig gerendertes HTML. Der Browser bekommt zusätzlich das JavaScript Bundle, damit die Seite nach Hydration interaktiv wird.

Für SEO ist SSR die zuverlässigste Option. Die erste Welle hat bereits den vollen Inhalt. Suchmaschinen und KI Crawler sehen, was sie brauchen, ohne JavaScript auszuführen. Der Preis ist Serverlast, jede Anfrage ist ein Render, und die Infrastruktur muss mit dem Traffic skalieren. Nutzen Sie SSR für Seiten, deren Inhalt sich pro Anfrage ändert und bei denen Aktualität zählt, etwa personalisierte Feeds, Echtzeit Preise, Suchergebnisseiten und durch Anfrageparameter gesteuerte Inhalte.

Static Site Generation (SSG). Zur Buildzeit wird jede Seite einmal in HTML gerendert und gespeichert. Die deployte Site ist ein Ordner mit statischen HTML Dateien, die ein CDN ausliefert. Beispiele, Astro, Next.js mit output: "export", Hugo, Jekyll.

Für SEO ist SSG die schnellste und zuverlässigste Option. Das HTML existiert schon, bevor irgendein Nutzer kommt, also erfasst die Indexierung der ersten Welle den vollständigen Inhalt sofort. Der Preis ist wachsende Buildzeit, eine Site mit 50.000 Seiten kann eine Stunde brauchen. Nutzen Sie SSG für Seiten, deren Inhalt sich zwischen Deployments selten ändert, etwa Blogposts, Dokumentation, Marketing Seiten und Produktkataloge, die nach Plan neu gebaut werden.

Incremental Static Regeneration (ISR). Ein Hybrid. Seiten werden als statisches HTML ausgeliefert, aber jede Seite hat ein Revalidierungsintervall. Nach Ablauf des Intervalls löst die nächste Anfrage eine Hintergrundregenerierung aus, und folgende Anfragen bekommen die neue Version. Beispiele, Next.js ISR, Astro Server Endpunkte mit Cache Headern.

Für SEO erreicht ISR die Verlässlichkeit von SSG in der ersten Welle und erlaubt gleichzeitig Aktualisierungen ohne komplettes Rebuild. Der Preis sind operative Komplexität, Cache Invalidierungsstrategien und Zeitfenster mit veraltetem Inhalt. Nutzen Sie ISR für Sites mit zu vielen Seiten für ein praktikables Vollrebuild, deren Inhalt aber frischer ist als bei einer Marketing Site, etwa E Commerce Kataloge mit Tausenden Produkten und mehrmals täglicher Preisänderung.

Eine Übersicht:

Muster, die Indexierung leise brechen

Die obigen Strategien sind in der Theorie sauber. In Produktion brechen bestimmte Muster Indexierung selbst auf Sites, die das Richtige tun wollten.

Inhalt, der erst nach einer Nutzerinteraktion erscheint. Eine Seite lädt mit einem Teaser, der vollständige Artikel erscheint erst nach Klick auf “Weiterlesen”. Der Googlebot klickt nicht. Was hinter dem Klick verborgen ist, bleibt in der Suche unsichtbar. Die Lösung ist, den vollen Inhalt im initialen HTML zu rendern und ihn per CSS oder JavaScript für Nutzer visuell zu falten.

Lazy Loading per Scroll. Eine lange Seite rendert den ersten Viewport, weitere Abschnitte erscheinen, während der Nutzer scrollt. Der Googlebot scrollt nicht wie ein Mensch, er rendert die Seite mit einem hohen Viewport (standardmäßig etwa 12.000 Pixel) und indexiert, was sichtbar ist. Inhalt, der echtes Scrollen jenseits dieser Höhe verlangt, ist gefährdet. Die Lösung ist das Attribut loading="lazy" auf Bildern und iframes (das Google versteht), nicht JavaScript getriggertes Scroll Loading für Inhalt.

Routen, die ausschließlich auf Browser APIs setzen. Der Inhalt einer Route holt Daten aus localStorage, sessionStorage, IndexedDB oder Session Cookies. Der Web Rendering Service erhält keinen State zwischen Renderings, also erscheint jeder Inhalt, der von im Browser gespeicherten Daten abhängt, leer. Die Lösung ist, sicherzustellen, dass der kanonische SEO Inhalt zur Renderzeit vom Server geholt wird und nicht aus dem Speicher des Browsers.

Inhalt, den Cookie Banner oder Paywalls blockieren. Ein Consent Banner überlagert die Seite, bis der Nutzer zustimmt. Bleibt der Inhalt darunter im DOM, ist alles gut. Wird der Inhalt bis zum Consent aus dem DOM entfernt, sieht Google nur das Banner. Die Lösung ist, den SEO Inhalt vor dem Consent im DOM zu lassen, auch wenn er visuell verdeckt ist, oder ein weiches Consent Gate zu nutzen, das den Inhalt nicht entfernt.

Wichtiger Inhalt in <noscript> Tags. Manche Teams spiegeln, im Wissen um die Risiken von JavaScript Rendering, ihren Inhalt in <noscript> Blöcken. Das hat früher funktioniert. Aktuelle Hinweise von Google flaggen massenhaften <noscript> Inhalt als Qualitätsproblem, weil Missbrauchsmuster diesen Tag zu einem Cloaking Signal gemacht haben. Nutzen Sie <noscript> für Fallback Hinweise (etwa “JavaScript ist erforderlich”), nicht für indexierbaren Inhalt.

JavaScript Weiterleitungen. Eine Seite liefert 200 OK mit <script>window.location = "/new-url"</script>. Die erste Welle sieht eine leere Seite. Die zweite Welle erkennt die Weiterleitung irgendwann, aber dazwischen wurde die ursprüngliche URL leer indexiert. Die Lösung ist HTTP 301 oder 302 Weiterleitung am Server, keine JavaScript Navigation.

Dynamische Meta Tags nach dem Laden. Eine React App setzt document.title und aktualisiert Meta Tags, nachdem die Routen Komponente gemountet wurde. Der Googlebot sieht den ursprünglichen <title> aus dem statischen HTML, meist ein generischer Site Name. Die Seite wird mit falschem Titel und falscher Description indexiert. Die Lösung ist eine Head Management Bibliothek, die Tags während SSR injiziert, etwa next/head, react-helmet-async oder Framework spezifische Lösungen.

Hash basiertes Routing. URLs wie /products#electronics statt /products/electronics. Google indexiert den Pfad, ignoriert das Fragment, also fallen alle Hash Routen auf eine indexierte URL zusammen. Die Lösung ist Routing über die HTML5 History API mit echten Pfaden.

Ein verlässlicher Test, schauen Sie sich den gerenderten Quellcode in dem Mobile Friendly Test an und suchen Sie nach dem erwarteten Inhalt. Fehlt ein Satz aus Ihrer Hero Copy im gerenderten HTML, ist das ein Problem, das es zu beheben lohnt, bevor der Traffic es für Sie tut. Eine ähnliche Prüfung profitiert von einer regelmäßig laufenden technischen SEO Audit Checkliste, um Regressionen früh zu erkennen.

KI Crawler und JavaScript

Die Crawler Landschaft 2026 ist nicht mehr nur Googlebot. KI Trainings und Inferenz Systeme betreiben eigene Crawler, und sie verhalten sich anders.

Zitate aus ChatGPT, Claude, Perplexity und Gemini stützen sich in der Regel auf Crawler, die HTML holen und JavaScript kaum oder gar nicht ausführen. Wenn eine KI Engine eine Seite zitiert, zitiert sie fast immer das, was sie im HTML der ersten Welle gefunden hat. Eine Seite, die JavaScript braucht, um den Artikeltext zu rendern, ist für die meisten KI Trainings Crawler unsichtbar und für Inferenz Crawler (jene für Live Zitate) nur teilweise sichtbar.

Bingbot betreibt einen JavaScript Renderer auf Edge Basis, in seiner Leistung dem Googlebot ähnlich. Bing indexiert JavaScript Inhalt, aber mit derselben Verzögerungslogik in zwei Wellen.

Kleinere Suchmaschinen und SEO Tools unterscheiden sich stark. Viele führen überhaupt kein JavaScript aus und sehen nur das rohe HTML.

Die Folge ist unangenehm für reine SPA Sites. Auch wenn Google JavaScript inzwischen verlässlich indexiert, tut das das breitere Ökosystem aus KI Engines und kleineren Suchmaschinen nicht. Eine Seite, die für ihren Inhalt auf JavaScript angewiesen ist, ist eine Seite, die in Google rankt, aber von ChatGPT nicht zitiert wird, in Bing AI Zusammenfassungen nicht erscheint und in Perplexity Quellen nicht auftaucht.

Für Sites, denen KI Traffic und Zitate wichtig sind (was 2026 die meisten Sites mit Content Strategie betrifft), lautet die praktische Antwort, für indexierbare Seiten zu SSR oder SSG zu wechseln. Das Prinzip ist, alles, was eine Maschine lesen soll, gehört in das HTML der ersten Welle.

Das verbindet sich direkt mit Generative Engine Optimization, die voraussetzt, dass KI Crawler den Inhalt lesen können. JavaScript gerenderter Inhalt, den Google sehen kann, bleibt für die meisten KI Engines unsichtbar, und das heißt, KI Optimierung erfordert eine Lösung beim Rendering.

Was Suchmaschinen wirklich sehen

Mehrere Werkzeuge zeigen, was Google und andere Crawler beim Abruf einer Seite sehen. Setzen Sie sie ein, bevor Sie annehmen, eine Seite sei korrekt indexiert.

URL Prüfung in der Google Search Console. Das wichtigste Werkzeug. Für jede URL einer verifizierten Property fordern Sie “Live Test” an und schauen Sie sich das gerenderte HTML, den Screenshot und die JavaScript Konsolenfehler an, die Google gesehen hat. Fehlt im gerenderten HTML der Hauptinhalt, indexiert die Seite leer. Zeigt der Screenshot eine leere Seite, ist der Renderer gescheitert.

Mobile Friendly Test (search.google.com/test/mobile-friendly). Öffentliches Werkzeug, ohne Verifizierung. Weniger detailliert als die Search Console, aber nützlich für Seiten auf fremden Sites und für Stichproben.

Rich Results Test (search.google.com/test/rich-results). Eigentlich für strukturierte Daten gedacht, gibt aber auch das gerenderte HTML zurück. Nützlich als zweite Meinung, wenn das Ergebnis der URL Prüfung mehrdeutig wirkt.

curl ohne JavaScript. Führen Sie curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yoursite.com/page aus und prüfen Sie die Antwort. Das zeigt, was KI Crawler und jeder JavaScript freie Fetcher sehen werden. Fehlt der Hero Inhalt, können KI Engines ihn nicht lesen.

Browser DevTools mit deaktiviertem JavaScript. In den Chrome DevTools, Einstellungen, Debugger, “Disable JavaScript”, neu laden. Das kommt der Sicht eines nicht rendernden Crawlers am nächsten. Ist die Seite leer, haben Sie ein Problem für jeden anderen Crawler außer Google.

Ein echter SEO Crawler mit JavaScript Rendering. Werkzeuge wie Seodisias crawlen Ihre Site wie der Googlebot, rendern das JavaScript und melden den extrahierten Inhalt. Das ist unverzichtbar für Sites mit Hunderten oder Tausenden Seiten, bei denen manuelle Stichproben nicht reichen.

Das Muster lautet, vertrauen Sie nicht darauf, dass JavaScript Inhalt “vermutlich indexiert”. Verifizieren Sie, an einer Stichprobe pro Template, bei jedem Release.

Ein Entscheidungsrahmen

Die Wahl einer Rendering Strategie wird einfacher, wenn Sie sie an drei Fragen ausrichten.

Frage eins, muss diese Seite in der Suche ranken?

Wenn nein (ein eingeloggtes Dashboard, ein Admin Panel, ein internes Tool), reicht CSR und spart Komplexität. Springen Sie zu Nutzererlebnis und Bundle Größe.

Wenn ja, weiter.

Frage zwei, wie oft ändert sich der zugrundeliegende Inhalt?

Wenn selten (Änderungen pro Deployment oder ein paar Mal am Tag auf einer kleinen Site), ist SSG die sauberste Antwort. Bauen, deployen, das CDN macht den Rest.

Wenn häufig, aber vorhersehbar (Kataloge, die Preise stündlich aktualisieren, Nachrichten, die täglich erscheinen), passt ISR zur Taktung. Setzen Sie die Revalidierung auf das kleinste Intervall, in dem veralteter Inhalt akzeptabel ist.

Wenn pro Anfrage (personalisierte Feeds, Echtzeit Preise, Suchergebnisse), ist SSR Pflicht.

Frage drei, kann die Seite das Risiko teilweiser Indexierung bei KI Engines tolerieren?

Wenn die Seite nur für Google ist und Sie den Verlust von KI Zitaten in Kauf nehmen, kann CSR mit Inhalt nach dem Laden akzeptabel sein.

Wenn die Seite Teil einer Content Strategie ist, die KI Engine Sichtbarkeit umfasst, muss die Antwort SSR oder SSG enthalten. KI Crawler führen JavaScript nicht zuverlässig aus, das ist eine harte Randbedingung, keine Vorliebe.

Eine Übersicht:

Eine moderne Site landet meist in der letzten Zeile. Marketing Seiten und Blogposts als SSG. Produktkataloge als ISR. Suche und personalisierte Seiten als SSR. Eingeloggter App Shell als CSR. Jeder Teil der Site nutzt, was passt, und die SEO Oberfläche bleibt im HTML der ersten Welle.

Diese Entscheidungsform verbindet sich mit Crawl Budget Optimierung, denn eine Site, die Rendering Strategien überlegt mischt, verbrennt auch weniger Crawl Budget bei langsamen JavaScript Rendern. Seiten, die in der ersten Welle vollständig laden, ersparen dem Googlebot eine Render Runde, was bedeutet, dass mehr Seiten im selben Budget gecrawlt werden können.

Was als Nächstes

Die Rendering Wahl ist nicht die letzte technische SEO Entscheidung einer Site, aber sie ist eine der frühesten und prägt vieles danach. Interne Links zwischen SSG Seiten sind günstig. Interne Links in eine CSR App Shell registrieren selten. Schema Markup auf einer SSR Seite wird von jedem Crawler gelesen. Schema Markup, das auf einer CSR Seite per JavaScript injiziert wird, wird von Google gelesen und von wenigen anderen.

Wenn eine Site, die Sie betreuen, für indexierbare Seiten weiterhin auf CSR setzt, behandeln Sie die Migration zu SSR oder SSG als Fundamentmaßnahme. Die Sichtbarkeitsgewinne summieren sich, jede andere technische SEO Verbesserung (Canonical Tags, interne Verlinkung, Schema, hreflang) findet auf festerem Boden statt, wenn der Inhalt im HTML der ersten Welle steht.

Für einen tieferen Blick darauf, was Crawler tun, wenn sie eine Seite erreichen, erklärt die SEO Crawler Komplettanleitung, wie Crawler JavaScript reiche Sites durchgehen, rendern und melden. Für ein Audit Raster, das Rendering Prüfungen enthält, hat die technische SEO Audit Checkliste einen JavaScript Abschnitt, der jedes Quartal eine Runde wert ist. Und für ein Werkzeug, das mit echter Browser Engine crawlt und meldet, was extrahiert wurde, ist Seodisias gebaut, um die Lücke zwischen dem, was Ihr Code produziert, und dem, was ein Such oder KI Crawler tatsächlich sieht, sichtbar zu machen.

Die Site, die die nächste Suchära gewinnt, ist nicht die mit der saubersten Architektur. Es ist die Site, deren Inhalt im HTML der ersten Welle erscheint, jedes Mal, für jeden Crawler, der zählt.