JavaScript-SEO: Warum Ihre Seiten für Google unsichtbar werden

JavaScript-SEO bedeutet sicherzustellen, dass Google und andere Suchmaschinen Inhalte crawlen, rendern und indexieren können, die ein Browser mit JavaScript statt mit reinem HTML aufbaut. Google rendert Seiten in einem eigenen, zeitlich versetzten Schritt nach dem ersten Crawl, sodass Inhalte unter Umständen wochenlang unbemerkt bleiben.

Wenn Sie Ihre Website mit React oder Vue oder mit einem Framework wie Next.js gebaut haben, ist die Lücke zwischen „gecrawlt“ und „gerendert“ wahrscheinlich der häufigste Grund dafür, dass Seiten nicht im Index landen. Die Lösung ist meist nicht kompliziert, sobald Sie wissen, an welcher Stelle es hakt.

Was ist JavaScript-SEO, und warum bringt es Google ins Straucheln?

JavaScript-SEO ist ein Teilgebiet des technischen SEO, das sich auf ein Problem konzentriert: mit JavaScript gebaute Seiten so crawlbar und indexierbar zu machen wie reine HTML-Seiten. Eine klassische HTML-Website liefert Google in einer einzigen Antwort alles, was es braucht. Eine JavaScript-Website liefert oft nur eine fast leere Hülle und baut die eigentlichen Inhalte erst im Browser auf.

Google kann JavaScript ausführen und sagt das seit Jahren. Das kostet jedoch Rechenressourcen, und Google muss diese auf Milliarden von Seiten verteilen. Genau hier beginnen die Probleme.

So crawlt und indexiert Google eine JavaScript-Seite

Die Dokumentation von Google auf Search Central beschreibt das Rendern als eigenen Schritt, getrennt vom Crawlen, und nicht als etwas, das beim ersten Besuch passiert. Der Prozess läuft in drei Teilen ab:

1. Crawling: Googlebot ruft die Seite ab und liest das rohe HTML. Bei einer JavaScript-lastigen Seite besteht dieses HTML womöglich kaum aus mehr als einem <div id="root"></div> und einem Script-Tag.
2. Rendering: Die Seite landet in einer Rendering-Warteschlange, in der der Web Rendering Service von Google, der auf einer stets aktuellen Chromium-Engine basiert, das JavaScript ausführt und die fertige Seite aufbaut.
3. Indexierung: Erst nach Abschluss des Renderings indexiert Google die Inhalte, Links und Metadaten, die es dabei findet.

Der Web Rendering Service versucht inzwischen, nahezu 100 % der HTML-Seiten zu rendern, die Google crawlt. Der Versuch zu rendern bedeutet aber nicht, schnell zu rendern. Zwischen Crawl und Rendering können bei einer etablierten Website wenige Stunden liegen, bei einer Website mit geringerer Autorität mehrere Wochen. Bei einer neuen Produktseite oder einem zeitkritischen Artikel kann das bedeuten, dass Sie das Traffic-Fenster verpassen.

Das Problem der zweistufigen Indexierung

Das überrascht die meisten Website-Betreiber. Ihre Seite wird fast sofort gecrawlt, doch der Inhalt darin wird erst viel später gesehen – wenn überhaupt.

Phase	Was passiert	Typischer Zeitpunkt	SEO-Auswirkung
Erster Crawl	Googlebot ruft das rohe HTML ab und liest statischen Text, Links und Tags aus	Sofort	Nur Inhalte, die nicht von JS abhängen, werden sofort indexiert
Rendering-Warteschlange	Chromium führt das JavaScript aus und baut die fertige Seite auf	Stunden bis mehrere Wochen, bei Websites mit geringer Autorität länger	Per Skript erzeugte Inhalte, Links und strukturierte Daten bleiben unsichtbar, bis dieser Schritt abgeschlossen ist
Rendering-Fehler	Ein Skriptfehler, eine blockierte Ressource oder ein Timeout verhindert den Abschluss des Renderings	Unvorhersehbar	Der Inhalt wird überhaupt nie indexiert

Mehrere Faktoren schieben eine Seite ans langsame Ende dieser Spanne: große JavaScript-Bundles, in der robots.txt blockierte Skripte, nicht abgefangene JavaScript-Fehler, Skripte von Drittanbietern, die nicht laden, und geringe Website-Autorität. Das Crawl-Budget wird ungleich verteilt, deshalb warten größere oder neuere Websites oft länger in der Warteschlange.

Client-seitiges vs. serverseitiges Rendering: Was sollten Sie einsetzen?

Setzen Sie für jede Seite, die indexiert werden soll, auf Server-Side Rendering (SSR) oder Static Site Generation (SSG) statt auf Client-Side Rendering (CSR). Bei CSR muss Google die Rendering-Warteschlange abwarten. Bei SSR oder SSG erhält Google bereits bei der ersten Anfrage fertiges HTML, und es gibt gar keine Wartezeit.

Ansatz	Wie der Inhalt zum Browser gelangt	SEO-Eignung	Am besten geeignet für
Client-Side Rendering (CSR)	Der Browser (oder Googlebot) führt nach dem Laden JavaScript aus, um die Seite aufzubauen	Schwach für öffentliche Seiten; hängt von der Rendering-Warteschlange ab	Dashboards hinter einem Login, interne Tools
Server-Side Rendering (SSR)	Der Server baut bei jeder Anfrage vollständiges HTML auf	Stark; der Inhalt steckt in der ersten Antwort	Produktseiten, Blogs, Landingpages
Static Site Generation (SSG)	Das HTML wird beim Deployment vorab erzeugt	Stark und am schnellsten auszuliefern	Marketing-Websites, Dokumentationen, Portfolios
Incremental Static Regeneration (ISR)	Statische Seiten, die nach Zeitplan oder auf Abruf aktualisiert werden	Stark	E-Commerce-Kataloge, häufig aktualisierte Inhalte
Vorab gerenderte Snapshots für Bots	Ein separater HTML-Snapshot wird nur an Bots ausgeliefert	Als Übergangslösung akzeptabel, nicht als Dauerlösung	Ältere CSR-Websites mitten in der Migration

Google hat erklärt, dass die Auslieferung eines vorab gerenderten Snapshots an Bots kein Cloaking ist, solange Bots und Nutzer am Ende gleichwertige Inhalte sehen. Zugleich betont Google ausdrücklich, dass dies nur eine vorübergehende Notlösung sein sollte. Zwei parallele Rendering-Wege bedeuten zusätzliche Komplexität, die Sie auf unbestimmte Zeit synchron halten müssen.

Die meisten Entwicklungsteams landen bei einer Mischform: SSR oder SSG für alles, was Suchmaschinen oder KI-Antwortmaschinen finden sollen, und CSR für Bereiche hinter einem Login, bei denen Indexierung nie das Ziel war. Ein Next.js-Projekt trifft diese Entscheidung auf Seitenebene; die Einzelheiten behandelt diese Anleitung zu den SEO-Einstellungen für Next.js.

Anzeichen dafür, dass Ihre Website ein JavaScript-SEO-Problem hat

Um die ersten Warnsignale zu erkennen, brauchen Sie keinen Entwickler. Achten Sie in der Google Search Console und in Ihren Analysedaten auf diese Muster:

• Seiten bleiben nach der Veröffentlichung wochenlang „Gefunden – zurzeit nicht indexiert“ (Discovered, currently not indexed).
• In der gerenderten Ansicht einer Seite in der Search Console fehlen Text, Links oder Bilder, die im Browser deutlich zu sehen sind.
• Interne Links, die als JavaScript-onClick-Handler statt als echte <a href>-Tags gebaut sind, erscheinen in der Search Console nicht als „verlinkt von“.
• Title-Tags oder Meta-Descriptions in den Suchergebnissen stimmen nicht mit dem Inhalt der Seite überein.
• Strukturierte Daten, die clientseitig eingefügt werden, werden im Rich-Results-Test nicht validiert.
• Eine Paginierung, die aus JavaScript-Zuständen statt aus eigenen URLs aufgebaut ist, verhindert, dass tiefer liegende Seiten gecrawlt werden.

Treten mehrere dieser Anzeichen gemeinsam auf, liegt die Ursache fast immer in einer Rendering-Lücke und nicht in einem Problem mit Inhalt oder Keywords. Ein technisches SEO-Audit, das gerendertes und rohes HTML vergleicht, bestätigt das schnell.

Was im ursprünglichen HTML enthalten sein muss

Wie sehr JavaScript die Seite später auch aufwertet: Bestimmte Elemente müssen bereits in der ersten HTML-Antwort vorhanden sein. Fehlen sie, kann Google die Seite beim Crawl als nahezu leer behandeln, selbst wenn die gerenderte Version vollständig aussieht.

Element	Warum es für JavaScript-SEO wichtig ist	Risiko, wenn nur per JS vorhanden
Title-Tag und Meta-Description	Zentrales Ranking- und Klicksignal	Erscheint unter Umständen wochenlang nicht in den Suchergebnissen
H1-, H2- und H3-Überschriften	Geben Google die thematische Struktur der Seite vor	Verzögerte Indexierung, entgangene Snippet-Berechtigung
Fließtext	Schafft Relevanz und thematische Tiefe	Die Seite wirkt beim ersten Crawl leer
Interne Links (<a href>)	Der Crawl-Pfad, dem Googlebot zu anderen Seiten folgt	Verlinkte Seiten werden womöglich nie entdeckt
Strukturierte Daten (JSON-LD)	Voraussetzung für erweiterte Ergebnisse und Zitate in KI-Antworten	Werden von erweiterten Ergebnissen komplett ausgeschlossen
Canonical-Tags	Verhindern Verwirrung durch doppelte Inhalte	Die falsche URL-Version wird indexiert

Führen Sie neben Ihren Rendering-Prüfungen ein Schema-Markup-Audit durch. JSON-LD, das ausschließlich durch clientseitiges JavaScript eingefügt wird, gehört zu den Dingen, die am häufigsten aus der von Google indexierten Version verschwinden.

Core Web Vitals: Wo JavaScript den größten Schaden anrichtet

Umfangreiches JavaScript verzögert die Indexierung und bremst außerdem die Seite für echte Besucher, was sich als Rankingfaktor gegen Sie auswirkt. Die Core Web Vitals von Google messen genau die Art von Verzögerung, die nicht optimierte Skripte verursachen.

Metrik	Was sie misst	Guter Schwellenwert	Typische JavaScript-Ursache
Largest Contentful Paint (LCP)	Wie schnell der Hauptinhalt erscheint	Unter 2,5 Sekunden	Große JS-Bundles verzögern das Rendern sichtbarer Inhalte
Interaction to Next Paint (INP)	Wie schnell die Seite auf Klicks und Taps reagiert	Unter 200 Millisekunden	Lange JavaScript-Aufgaben blockieren den Main Thread des Browsers
Cumulative Layout Shift (CLS)	Wie stark das Layout beim Laden springt	Unter 0,1	Von JavaScript verspätet eingefügte Elemente verschieben Inhalte

INP hat im März 2024 First Input Delay als offizielle Core Web Vital abgelöst, wie in der Dokumentation von Google auf web.dev nachzulesen ist. Es misst die Reaktionsfähigkeit strenger und realistischer als sein Vorgänger und bestraft die lang laufenden Skripte, die JavaScript-lastige Websites häufig ausliefern.

Als Richtwert wird häufig ein anfängliches komprimiertes Bundle von unter 200 KB genannt, wobei jede Aufgabe, die länger als 50 Millisekunden dauert, in kleinere Teile zerlegt wird, damit sie den Main Thread nicht blockiert. Google erzwingt keine der beiden Zahlen als feste Grenze, aber beide korrelieren eng mit Websites, die die Core Web Vitals problemlos bestehen. Eine kurze Checkliste deckt den Großteil der Arbeit ab:

• Verschieben Sie Skripte, die für das erste Rendern nicht nötig sind (defer).
• Entfernen Sie ungenutztes JavaScript aus dem Bundle.
• Zerlegen Sie lange Aufgaben, damit der Main Thread für Klicks und Taps frei bleibt.
• Beheben Sie Skriptfehler und geben Sie Ressourcen frei, die die robots.txt derzeit vor Googlebot verbirgt.

Warum das für SaaS- und B2B-Websites noch wichtiger ist

SaaS-Plattformen, Unternehmensportale und Tech-Marktplätze sind häufig von Grund auf als JavaScript-Anwendungen gebaut. Verzögert indexierte Produktseiten, unsichtbare strukturierte Daten und schwache Core Web Vitals schaden ihnen alle zugleich und drücken die Website bei den Suchanfragen mit hoher Kaufabsicht hinter die Wettbewerber, bei denen sich Abschlüsse entscheiden.

Der typische Fehler: Eine Marketing-Website und eine Produkt-App teilen sich eine einzige clientseitig gerenderte Codebasis. Sicherer ist ein Aufbau, bei dem die öffentlichen Seiten (Preise, Funktionen, Dokumentation, Blog) auf dem Server oder zur Build-Zeit gerendert werden und CSR der App hinter dem Login vorbehalten bleibt, wo die Indexierung keine Rolle spielt.

Lösungen für die einzelnen Plattformen

Die richtige Lösung hängt davon ab, worauf Sie aufbauen.

• Shopify-Themes setzen für Filter, Variantenauswahl und Warenkorb-Aktualisierungen stark auf JavaScript. Für SEO ist das meist unproblematisch, solange Produkttitel, Beschreibungen und Canonical-Tags im serverseitig gerenderten HTML bleiben. Welche Einstellungen sich zu prüfen lohnen, steht in diesem Shopify-SEO-Leitfaden.
• Wix hat die Verarbeitung beim Rendern deutlich verbessert, doch vom Editor erzeugte interaktive Bereiche können die Indexierung weiterhin verzögern, wenn sie Inhalte asynchron laden. Die relevanten Einstellungen gehen Sie in diesem Wix-SEO-Leitfaden durch.
• Lovable-Apps werden standardmäßig oft als Single-Page-React-Apps gebaut, was sie in den CSR-Bereich bringt, sofern Sie nichts anderes konfigurieren. Dieser Leitfaden zu SEO für Lovable-Websites zeigt, wie Sie Blog-Inhalte einer per Prompt gebauten Website in den Index bekommen.
• WordPress-Websites sind in der Regel schon HTML-first, doch JavaScript-lastige Themes, Page Builder und manche Plugins bringen das Rendering-Risiko zurück. Die Lösungen behandelt dieser Leitfaden zu WordPress-SEO-Einstellungen.
• Git-basierte Websites, die mit Static Site Generators gebaut und über GitHub bereitgestellt werden, setzen meist standardmäßig auf SSG, die sicherste verfügbare Rendering-Wahl. Einzelheiten zu Deployment und Indexierung finden Sie in diesem Leitfaden zu SEO für über GitHub bereitgestellte Websites.
• Next.js gibt Ihnen die meiste Kontrolle und lässt Sie SSR, SSG oder ISR pro Seite wählen. Metadaten, Sitemaps und robots.txt sind ebenso wichtig wie der Rendering-Modus; der Next.js-SEO-Leitfaden behandelt sie.

KI-Suche verändert die Einsätze

JavaScript-SEO war früher ein reines Google-Thema. Die meisten KI-Crawler, darunter die Bots hinter ChatGPT, Claude und Perplexity, führen JavaScript überhaupt nicht aus. Gemini ist die bemerkenswerte Ausnahme, weil es den eigenen Rendering-Stack von Google nutzt, wobei dies als experimentell beschrieben wird und man sich nicht darauf verlassen sollte.

Eine Seite, die zur Anzeige ihrer Inhalte auf clientseitiges JavaScript angewiesen ist, kann daher für KI-Antwortmaschinen unsichtbar sein, selbst wenn Googlebot sie irgendwann sieht. Um für Zitate in KI-generierten Antworten infrage zu kommen, muss der Inhalt im rohen HTML stehen. Dasselbe Prinzip zieht sich durch die Answer Engine Optimization: Schreiben Sie die Antwort dorthin, wo jeder Crawler sie lesen kann, ob von Menschen gebaut oder von einer KI.

So testen und überwachen Sie JavaScript-SEO

Sie können ohne Rätselraten prüfen, ob Google Ihre Seite so sieht, wie Sie es beabsichtigen.

1. Vergleichen Sie rohes und gerendertes HTML. Rufen Sie für die rohe Version den Quelltext auf und legen Sie ihn neben das, was Chrome DevTools nach dem vollständigen Laden der Seite anzeigt. Große Abweichungen deuten auf eine Rendering-Abhängigkeit hin.
2. Nutzen Sie das URL-Prüftool (URL Inspection) der Search Console. Es zeigt den gerenderten Screenshot und das HTML, das Google verwendet hat, sowie alle aufgetretenen JavaScript-Konsolenfehler.
3. Crawlen Sie mit deaktiviertem JavaScript. Ein reiner Textmodus zeigt, was ein nicht renderingfähiger Bot sieht – wichtig angesichts der vielen KI-Crawler, die JavaScript überspringen.
4. Beobachten Sie Server-Logdateien über einen längeren Zeitraum. Die Crawl-Häufigkeit über drei bis sechs Monate zeigt, ob wichtige Templates oft genug erneut besucht werden und ob Rendering-Korrekturen die Crawl-Aktivität danach verbessert haben.
5. Führen Sie nach größeren Framework-Änderungen erneut ein technisches Audit durch. Bei der Migration auf ein neues Framework schleichen sich Rendering-Rückschritte unbemerkt ein, und ein technisches SEO-Audit davor und danach fängt sie ab, solange sie sich günstig beheben lassen.

Können Sie JavaScript-SEO selbst in Ordnung bringen?

Teilweise, ja. Ob Ihre Title-Tags und Überschriften im rohen HTML stehen, prüfen Sie in fünf Minuten mit einem Klick auf „Quelltext anzeigen“. Das Attribut defer bei nicht kritischen Skripten zu ergänzen, ungenutztes JavaScript zu entfernen und sicherzustellen, dass interne Links echte <a href>-Tags verwenden: All das sind Änderungen, die ein Website-Betreiber bei einem Entwickler ohne Neuaufbau in Auftrag geben kann.

Eine CSR-App auf SSR umzustellen oder vorab gerenderte Snapshots als Zwischenlösung einzurichten, ist ein größeres Projekt. Dafür braucht es meist einen Entwickler, der Ihr Framework kennt, denn eine falsche Umsetzung kann genau die Funktionen beschädigen, die Sie erhalten wollen. Wenn die Rendering-Architektur als Ursache im Verdacht steht, holen Sie einen Entwickler dazu, bevor jemand den Produktivcode anfasst, und legen Sie mit einem strukturierten SEO-Plan die Reihenfolge der Korrekturen fest, damit nicht eine die andere zunichtemacht.

Wo das in Ihre übrige SEO-Arbeit passt

Eine Website mit Rendering-Problemen hat oft auch Lücken bei der lokalen Sichtbarkeit, bei strukturierten Daten oder bei der allgemeinen technischen Gesundheit. Wenn Sie bestimmte Gebiete bedienen, kombinieren Sie Ihre Rendering-Korrekturen mit lokalen SEO-Seiten, die auf die Stadtteile ausgerichtet sind, in denen Sie ranken möchten. Erzeugt Ihr Framework außerdem doppelte URLs oder uneinheitliche Canonicals, wie es clientseitige Router häufig tun, erledigen Sie das im selben technischen Durchgang, statt es später als separates Projekt zu behandeln.

Häufig gestellte Fragen

Bestraft Google JavaScript-Websites?

Nein. Google bestraft eine Website nicht dafür, dass sie JavaScript nutzt. Das Problem ist indirekt: Wenn JavaScript das Rendering verzögert oder Inhalte verbirgt, werden Seiten spät oder gar nicht indexiert. Das sieht nach einem Ranking-Problem aus, ist aber ein Indexierungsproblem.

Wie lange braucht Google, um eine JavaScript-Seite zu indexieren?

Das schwankt stark. Gut etablierte Websites mit hoher Autorität erleben das Rendering mitunter innerhalb von Stunden, während neuere oder weniger autoritative Websites Wochen warten können, bis dieselbe Seite die Warteschlange durchlaufen hat – so beschreibt es Google selbst.

Ist React schlecht für SEO?

React selbst nicht, wohl aber eine React-App, die komplett clientseitig gerendert wird. Wenn Sie React mit einem Framework kombinieren, das Server-Side Rendering oder statische Generierung unterstützt, etwa Next.js, entfällt der Großteil des Risikos.

Was ist der Unterschied zwischen SSR und Pre-Rendering?

SSR baut bei jeder Anfrage in Echtzeit vollständiges HTML auf dem Server auf. Beim Pre-Rendering wird vorab (oder bei der ersten Anfrage eines Bots) ein statischer HTML-Snapshot erzeugt, und diese zwischengespeicherte Version wird an Crawler ausgeliefert. Das ist im Betrieb günstiger, muss aber aktualisiert werden, um korrekt zu bleiben.

Lesen KI-Chatbots wie ChatGPT JavaScript-Inhalte?

In der Regel nicht. Die meisten KI-Crawler führen kein JavaScript aus, daher sind Inhalte, die erst nach Ausführung eines Skripts erscheinen, für sie meist unsichtbar. Googles Gemini ist die Ausnahme, weil es die eigene Rendering-Infrastruktur von Google nutzt, gilt aber weiterhin als Randfall.

Lassen Sie Ihr Rendering prüfen, bevor es Sie weitere Rankings kostet

JavaScript-SEO-Probleme sind leise. Seiten werfen keine Fehler, sie tauchen einfach nicht auf, und nichts in Ihrem Dashboard weist auf eine Rendering-Verzögerung hin, solange Sie nicht gezielt danach suchen. Am schnellsten sehen Sie, wo Sie stehen, wenn Sie vergleichen, was Google rendert und was Ihre Website ausliefert. Sprechen Sie mit dem Team und holen Sie sich einen SEO-Beispielbericht, der zeigt, was gerade auf Ihren Seiten passiert.

Ressourcen / Referenzen

1. Search Central
2. web.dev

Quellen

• The Complete JavaScript SEO Guide
• JavaScript SEO: 6 Best Practices to Boost Rankings
• Mastering JavaScript SEO: pre-rendering and log analysis
• Get the Best Javascript SEO Practices
• What is JavaScript SEO?