JavaScript-SEO: Rendering-Fallen vermeiden
JavaScript-SEO scheitert selten am Framework, sondern an unsichtbaren Links, hängenden Renders und Content, den Google nie zu sehen bekommt.
Jonas Brandt
Technical SEO

JavaScript-SEO scheitert selten am Framework, sondern an unsichtbaren Links, hängenden Renders und Content, den Google nie zu sehen bekommt.
Jonas Brandt
Technical SEO

JavaScript-SEO gelingt, wenn dein wichtigster Content und deine Links schon im ersten HTML stehen. Alles, was Google erst per JavaScript nachladen muss, läuft Gefahr, gar nicht oder zu spät indexiert zu werden.
Google rendert JavaScript, das ist seit Jahren Fakt. Nur passiert das nicht sofort und nicht immer vollständig. Der Bot holt zuerst dein rohes HTML, stellt die Seite in eine Render-Warteschlange und führt das JavaScript erst später aus, manchmal Minuten, manchmal Tage nach dem ersten Crawl. In diesem Fenster kennt Google nur, was ohne JavaScript sichtbar ist. Steht dort nichts, indexiert Google nichts.
Wenn dein Content erst nach dem Klick auf einen Button existiert, existiert er für Google gar nicht.
Das Missverständnis beginnt beim Wort rendern. Entwickler bauen eine Single-Page-App, sehen im Browser perfekten Content und schließen daraus, Google sehe dasselbe. Tut es aber verzögert. Die Render-Phase kostet Google Rechenzeit, deshalb wird sie entkoppelt vom Crawlen. Bei großen Sites kann die Warteschlange spürbar lang werden. Für einen News-Artikel, der heute ranken soll, ist ein Render in drei Tagen wertlos.
Dazu kommt: Der Web Rendering Service nutzt zwar eine aktuelle Chromium-Version, aber er wartet nicht ewig. Hängt ein Fetch, blockiert eine langsame API oder wirft ein Skript einen Fehler, bricht das Rendering ab. Dann sieht Google die halb fertige Seite. Genau hier verlieren die meisten Projekte still und leise ihre Inhalte, ohne dass im Browser je etwas auffällt.
Die perfide Gemeinsamkeit: Im Browser funktioniert alles tadellos. Du merkst das Problem erst, wenn Rankings ausbleiben oder die Search Console leere Seiten meldet. Deshalb reicht der visuelle Check nie. Du musst die Seite so betrachten, wie der Bot sie sieht, nicht wie dein Browser sie rendert.
Fang beim einfachsten Test an: Öffne die Seite und deaktiviere JavaScript in den Chrome DevTools über das Command-Menü mit „Disable JavaScript“. Lade neu. Was jetzt fehlt, ist ein Kandidat fürs Problem. Danach gehst du in die Search Console und nutzt die URL-Prüfung. Der Button „Live-Test“ zeigt dir den gerenderten HTML-Code und einen Screenshot exakt so, wie Googles Renderer die Seite verarbeitet hat. Fehlt dort dein Content, ist die Diagnose eindeutig.
Für eine ganze Site nimmst du Screaming Frog mit aktiviertem JavaScript-Rendering. Der Crawler zeigt dir pro URL die Differenz zwischen rohem und gerendertem HTML und markiert Links, die erst nach dem Rendern erscheinen. Lighthouse ergänzt das um die Perspektive der Ladezeit, denn ein Render, das zehn Sekunden braucht, ist auch für den Bot ein Risiko. Drei Tools, drei Blickwinkel, ein klares Bild.
Die robusteste Lösung heißt, kritische Inhalte gar nicht erst dem Client-Rendering zu überlassen. Server-Side Rendering liefert die fertige Seite als HTML aus, der Bot bekommt beim ersten Crawl alles. Static Site Generation geht noch weiter und baut die Seiten schon zur Build-Zeit. Frameworks wie Next.js, Nuxt oder Astro machen beides zum Standardweg. Reines Client-Side Rendering solltest du nur dort einsetzen, wo Inhalte hinter Login liegen und ohnehin nicht ranken sollen.
Ein Mittelweg ist Dynamic Rendering, bei dem Bots eine vorgerenderte Version bekommen. Google nennt das ausdrücklich eine Übergangslösung, keine dauerhafte Empfehlung. Der Grund: Zwei Auslieferungswege bedeuten doppelte Fehlerquellen und das Risiko, versehentlich Cloaking zu betreiben. Wer neu baut, fährt mit SSR oder statischen Seiten sauberer und langfristig günstiger.
Kann Google React- oder Vue-Seiten indexieren? Ja, grundsätzlich kann der Googlebot moderne Frameworks rendern und den Inhalt indexieren. Das Risiko liegt nicht am Framework, sondern an der Konfiguration. Setzt du auf reines Client-Side Rendering, hängt deine Indexierung an der Render-Warteschlange und an fehlerfreiem JavaScript. Mit SSR umgehst du dieses Risiko komplett.
Wie lange dauert es, bis Google JavaScript rendert? Es gibt keine feste Zahl. In vielen Fällen passiert es innerhalb von Minuten bis Stunden, bei großen oder trägen Sites können es Tage werden. Für zeitkritische Inhalte wie Nachrichten oder Angebote ist diese Verzögerung der Hauptgrund, den Content serverseitig auszuliefern.
Muss ich robots.txt für JavaScript-SEO anpassen? Fast immer lautet die Antwort: Blockiere deine JavaScript- und CSS-Dateien nicht. Sperrst du das Bundle, kann Google die Seite nicht rendern und sieht nur ein leeres Grundgerüst. Prüfe in der Search Console über die URL-Prüfung, ob geladene Ressourcen als blockiert gemeldet werden.
Baue so, dass du den Test mit deaktiviertem JavaScript bestehst. Was dann noch sichtbar ist, wird zuverlässig indexiert. Der Rest ist ein Versprechen auf gutes Wetter in Googles Render-Warteschlange.
Wie der Canonical-Tag Duplicate Content ohne Rankingverlust bündelt, welche Fehler ihn ignorieren lassen und wie du ihn korrekt setzt.
Warum die passende Suchintention über Ranking entscheidet und wie du in vier Schritten Content baust, der die Frage hinter der Suche trifft.
Answer Engine Optimization bringt deine Marke in die Antworten von ChatGPT und Perplexity. So wirst du zur zitierten Quelle statt zum blauen Link.