JavaScript-SEO

TL;DR — JavaScript-SEO dreht sich um eine Frage: Können Suchmaschinen Ihre Inhalte sehen? Moderne Websites erstellen einen Großteil der Seite im Browser mit JavaScript. Wenn Ihre wichtigen Texte und Links erst nach der Ausführung von Skripten sichtbar werden, müssen Sie sicherstellen, dass Google sie weiterhin erreichen kann. Google kann das in der Regel – die Probleme liegen im Detail.

Was JavaScript-SEO ist

Viele Websites erstellen einen Teil (oder die gesamte) Seite in Ihrem Browser mit JavaScript. Der Server sendet etwas HTML, und dann laufen Skripte, um Inhalte zu füllen, weitere Elemente zu laden oder Ansichten ohne vollständiges Neuladen der Seite zu wechseln. JavaScript-SEO ist die Praxis, sicherzustellen, dass Suchmaschinen diese Inhalte weiterhin crawlen, rendern und indexieren können.

So läuft die Reihenfolge bei Google ab:

1. Crawlen – Google lädt das rohe HTML Ihrer URL herunter.
2. Rendern – Google führt das JavaScript der Seite in einem Browser aus, um die fertige Seite zu erstellen (der Rendering-Schritt).
3. Indexieren – Google liest die fertige Seite und legt sie ab.

Google dokumentiert diese als die drei Hauptphasen für die Verarbeitung von JavaScript-Webanwendungen.

Wenn Ihre Inhalte erst nach der Ausführung von JavaScript erscheinen, muss Google die Seite rendern, bevor es sie sehen kann. Meistens gelingt das. Wenn nicht, können Ihre Inhalte stillschweigend aus der Suche verschwinden.

Die gute Nachricht zuerst

JavaScript ist nicht schlecht für SEO. Google verwendet eine aktuelle Version von Chrome und kann dasselbe JavaScript ausführen wie Ihre Besucher. Die alte Angst – „Google kann kein JavaScript lesen“ – ist einfach nicht mehr wahr.

Was schiefgehen kann, ist spezifischer:

• Ihre Inhalte benötigen einen Klick oder ein Scrollen, um zu laden, und Google klickt oder scrollt nicht. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content
• Ihre Links sind keine echten Links (es sind Buttons oder Klick-Handler), sodass Google sie nicht folgen kann. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable
• Sie haben versehentlich Ihre JavaScript- oder CSS-Dateien in robots.txt blockiert, sodass Google die Seite nicht richtig rendern kann.
• Die Seite sieht in Ihrem Browser gut aus, aber die Inhalte erscheinen nie in der gerenderten Ansicht von Google.

Die einfache Checkliste

• Vergleichen Sie Ihr rohes HTML (Rechtsklick → Seitenquelltext anzeigen) mit dem gerenderten HTML (URL-Inspektion in der Google Search Console). Wenn wichtige Inhalte in der gerenderten Ansicht fehlen, ist das Ihr Problem.
• Stellen Sie sicher, dass Links echte <a href>-Links sind, keine Klick-Handler auf einem <div>.
• Blockieren Sie Ihre JavaScript- oder CSS-Dateien nicht in robots.txt.
• Wenn eine Funktion einen Klick oder ein Scrollen benötigt, um Inhalte zu laden, stellen Sie sicher, dass diese Inhalte auch auf andere Weise erreichbar sind.
• Für Inhalte, die unbedingt ranken müssen, bevorzugen Sie Server-Side Rendering oder einen statischen/vorgerenderten Build, bei dem die Inhalte bereits im rohen HTML vorhanden sind. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Möchten Sie die tiefere Version – die echten Fehlermodi, die Unendlich-Scroll-Falle, die dazu führt, dass zwei Seiten als eine indexiert werden, und wie Sie gerendertes HTML testen? Wechseln Sie zum Erweitert-Tab. Wie der Renderer von Google selbst funktioniert und welches Rendering-Setup Sie wählen sollten, finden Sie auf der Rendering-Seite.

TL;DR — Google kann Ihr JavaScript ausführen, also ist „Kann Google JS lesen?“ die falsche Frage. Die Fehlermodi sind Parität (rohes vs. gerendertes DOM), Interaktion (Google scrollt oder klickt nicht), Zustand (der Renderer ist zustandslos) und Timing. Halten Sie Links als echte <a href>-Anker, blockieren Sie JS/CSS nicht, laden Sie lazy auf Viewport statt Interaktion, geben Sie echte Statuscodes für clientseitige Fehlerseiten zurück, und denken Sie daran, dass ein rohes noindex das Rendern verhindern kann, bevor JavaScript es entfernen kann. Kombinieren Sie Direktiven, die tatsächlich verarbeitet wurden, aber gehen Sie nicht von einem universellen roh/gerendert-Gewinner aus. Achten Sie besonders auf unendliches Scrollen: Ein hoher Render-Viewport kann den Loader auslösen und zwei URLs zu einer indexierten Seite zusammenführen. Für die Renderer-Interna und welchen Rendering-Modus Sie wählen sollten, siehe Rendering.

Kann Google JavaScript lesen? Ja — das ist nicht die Frage

Google verarbeitet JavaScript-Apps in drei Phasen: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (Übersetzung) „Google verarbeitet JavaScript-Web-Apps in drei Hauptphasen: 1. Crawling 2. Rendering 3. Indexing.“ Die mittlere Phase führt Ihr JS in einem Evergreen-Headless-Chrome aus, um das DOM zu erstellen, das indexiert wird. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (Übersetzung) „Rendering ist wichtig, weil Websites oft auf JavaScript angewiesen sind, um Inhalte auf die Seite zu bringen, und ohne Rendering könnte Google diese Inhalte möglicherweise nicht sehen.“

Google kann Ihr JavaScript also ausführen. Die nützlichen Fragen sind spezifischer:

• Parität — enthält das gerenderte DOM tatsächlich das, was Sie denken?
• Interaktion — erfordert etwas ein Scrollen/Klicken, das Google nicht ausführt?
• Zustand — verlassen Sie sich auf Cookies/localStorage, die der zustandslose Renderer löscht?
• Timing — wird kritischer Inhalt hinter langsamem oder spätem JavaScript zurückgestellt?

Zum Timing im Speziellen: Google stellt eine gecrawlte Seite (die einen 200-Status zurückgibt) in die Warteschlange für das Rendering, und “the page may stay on this queue for a few seconds, but it can take longer than that.” (Übersetzung) „Die Seite kann einige Sekunden in dieser Warteschlange bleiben, aber es kann auch länger dauern.“ Es gibt keine veröffentlichte feste Verzögerung oder Zeitüberschreitung — und eine Seite, die einen Nicht-200-Status zurückgibt oder die mit einer noindex-Direktive beginnt, kann die Rendering-Warteschlange überspringen, anstatt darauf zu warten, dass JavaScript sie ändert.

Die Mechanik wie Google rendert — der Web-Rendering-Dienst, Zustandslosigkeit, Caching, der Mythos der „zwei Wellen“ — finden Sie auf der Seite Rendering. Hier konzentriere ich mich auf die praktischen Probleme und Lösungen.

Links müssen echte <a href>-Anker sein

Das ist der häufigste JS-SEO-Fehler. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (Übersetzung) „Google kann Ihre Links nur entdecken, wenn es sich um <a>-HTML-Elemente mit einem href-Attribut handelt.“ Ein klickbares <div> mit einem onclick-Handler ist für Google als Link unsichtbar — es wird nicht verfolgt, und Seiten, die für die Entdeckung davon abhängen, können ungecrawlt bleiben. Es ist völlig in Ordnung, Links mit JavaScript zu injizieren, solange sie im gerenderten DOM als echte <a href>-Anker enden. Diese gerenderten Anker werden jedoch nach der Ausführung von JavaScript geparst — im gerenderten DOM zu landen macht einen Link auffindbar, ist aber keine Garantie dafür, dass die URL gecrawlt, indexiert oder genauso behandelt wird wie ein Link im rohen HTML.

Lazy-Loaded und interaktionsabhängige Inhalte

Der Renderer verhält sich nicht wie ein neugieriger Benutzer: “Google Search does not interact with your page.” (Übersetzung) „Google Search interagiert nicht mit Ihrer Seite.“ Kein Scrollen, kein Klicken, kein Schweben. Inhalte, die nur bei einem dieser Ereignisse geladen werden, werden also nicht gesehen.

Googles Leitfaden: Laden Sie Inhalte, wenn sie in den Viewport gelangen, nicht wenn der Benutzer handelt — “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (Übersetzung) „stellen Sie sicher, dass Ihre Lazy-Loading-Implementierung alle relevanten Inhalte lädt, wann immer sie im Viewport sichtbar sind,“ und “don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.” (Übersetzung) „fügen Sie Lazy-Loading nicht zu Inhalten hinzu, die wahrscheinlich sofort sichtbar sind, wenn ein Benutzer eine Seite öffnet.“ Verwenden Sie IntersectionObserver oder natives loading="lazy" für Bilder — niemals einen Scroll- oder Klick-Handler — damit die Inhalte während eines normalen Renderings geladen werden.

Unendliches Scrollen: wenn zwei Seiten als eine indexiert werden

Das ist das, was fast niemand erklärt, und es ist den gesamten Abschnitt wert.

Googlebot kann mit einem Viewport rendern, das deutlich höher ist als ein typisches Browserfenster. Google veröffentlicht keine genaue Render-Viewport-Größe – und sie kann sich ändern –, also planen Sie nicht für eine bestimmte Zahl; testen Sie stattdessen Ihre eigene Implementierung. Entscheidend ist der Mechanismus: Wenn Ihr Infinite-Scroll-Loader basierend auf Scrollposition oder Viewport-Höhe auslöst, kann ein höheres als erwartetes Rendering-Viewport den Loader während des Renderns selbst auslösen – und der Inhalt des nächsten Artikels oder der nächsten Produktseite wird in dasselbe DOM eingefügt. Jetzt wurden die Inhalte zweier verschiedener URLs zusammen gerendert, und Google kann sie als eine Seite indexieren. Meiner eigenen Erfahrung nach gilt: “occasionally, two pages get indexed as one” (Übersetzung) „Gelegentlich werden zwei Seiten als eine indexiert.“ – ich hatte Seiten, die als “not indexed” gemeldet wurden, aber tatsächlich als Teil einer anderen Seite indexiert waren (normalerweise des vorherigen Beitrags im Feed), weil “when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (Übersetzung) „Als Google den Viewport verlängerte, löste dies das unendliche Scrollen aus und lud beim Rendern einen weiteren Artikel.“ Bestätigen Sie, ob Ihr eigenes Setup dies tut, indem Sie das gerenderte HTML der URL Inspection für eine Seite prüfen, von der Sie erwarten, dass sie vorher endet – gehen Sie nicht von einer Größe aus und gehen Sie nicht davon aus, dass Sie sicher sind.

Es gibt zwei Ebenen, um das richtig zu machen.

Machen Sie Infinite Scroll von vornherein suchmaschinenfreundlich. Unterstützen Sie paginiertes Laden unter dem Infinite Scroll. Jeder Abschnitt sollte “its own persistent, unique URL” (Übersetzung) „eine eigene dauerhafte, eindeutige URL“ haben. Der Inhalt jeder URL sollte bei jedem Laden gleich bleiben. Vermeiden Sie relative Parameter wie ?date=yesterday und “link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set” (Übersetzung) „verlinken Sie die einzelnen URLs der Reihe nach, damit Suchmaschinen die URLs eines paginierten Satzes entdecken können“. Wenn ein neuer Abschnitt beim Scrollen geladen wird, sollten Sie “update the displayed URL using the History API” (Übersetzung) „die angezeigte URL mit der History API aktualisieren“. Verwenden Sie echte <a href>-Paginierungslinks und eindeutige URLs. “Don’t use URL fragment identifiers” (Übersetzung) „Verwenden Sie keine URL-Fragmentbezeichner“ (der Teil nach einem #) für Seitenzahlen, weil Google sie ignoriert. Wie ich in meinem JavaScript-SEO-Leitfaden sage: “if you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (Übersetzung) „Bei unendlichem Scrollen empfehle ich weiterhin eine paginierte Seitenversion, damit Google ordnungsgemäß crawlen kann.“

Wenn ein fehlerhafter Loader Seiten aktiv zusammenführt, ist der schnellste Fix direkt: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (Übersetzung) „Blockieren Sie die JavaScript-Datei für das unendliche Scrollen, damit die Funktion nicht ausgelöst werden kann.“ Wenn der Loader während des Renderns nicht ausgeführt werden kann, kann er den Inhalt der nächsten Seite nicht anhängen, und jede URL rendert wieder als sie selbst.

Soft-404s nach clientseitigem Routing

Single-Page-Apps können Inhalte austauschen, ohne den HTTP-Statuscode zu ändern, sodass eine „Nicht gefunden“-Ansicht weiterhin 200 zurückgeben kann. Google kann diese Antwort nach der Auswertung des zurückgegebenen Inhalts als Soft-404 einstufen, aber ein statischer Abruf allein kann nicht beweisen, dass Google diese Einstufung vorgenommen hat. Zwei Korrekturen: navigieren Sie mit der History API, und für einen echten Not-Found-Zustand leiten Sie entweder auf eine URL um, die einen echten 404-Status zurückgibt, oder fügen Sie ein noindex-Tag hinzu. Und verlassen Sie sich nicht auf URL- Fragmente für das Routing – “the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.” (Übersetzung) „Das AJAX-Crawling-Schema ist seit 2015 veraltet; deshalb können Sie sich bei Googlebot nicht auf URL-Fragmente verlassen.“

Eine clientseitige Weiterleitung hat dasselbe Beweisproblem: Die erste Antwort kann 200 bleiben, bis JavaScript ausgeführt wird. Google unterstützt JavaScript-Weiterleitungen nur als Fallback, wenn serverseitige oder Meta-Refresh-Weiterleitungen nicht möglich sind. Melden Sie den statischen Status und die beobachtete gerenderte Navigation getrennt; schreiben Sie den HTTP-Status im Audit nicht um und bezeichnen Sie nicht jede Änderung der gerenderten URL als Weiterleitung.

Blockieren Sie JavaScript oder CSS nicht in robots.txt

Google rendert kein JavaScript aus blockierten Dateien oder auf blockierten Seiten. Eine robots.txt-Regel, die Ihr Bundle (oder das Verzeichnis /_next/, /static/, /assets/, in dem es liegt) nicht zulässt, kann das Rendering vollständig brechen – Google ruft die Hülle ab, kann die Skripte nicht ausführen und indexiert eine leere Seite. Prüfen Sie in der URL Inspection die Seitenressourcen auf blockierte Elemente.

DOM-Parität und stufenbewusste robots-Direktiven

Vergleichen Sie Ihr rohes HTML (Seitenquelltext anzeigen) mit dem gerenderten HTML (URL-Prüfung). Inhalte, die nur im gerenderten HTML vorhanden sind, werden trotzdem indexiert – wenn sie gerendert werden. Inhalte, die in keinem von beiden vorhanden sind, existieren für Google nicht.

Es gibt ein von Google direkt dokumentiertes Risiko der Phasenreihenfolge: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (Übersetzung) „Wenn Google auf das noindex-Tag stößt, kann es das Rendering und die JavaScript-Ausführung überspringen, was bedeutet, dass die Verwendung von JavaScript zum Ändern oder Entfernen des Robots-Meta-Tags von noindex möglicherweise nicht wie erwartet funktioniert.“ Wenn Ihr rohes HTML ein anfängliches noindex enthält, das Sie mit JavaScript austauschen wollten, kann Google auf dieses rohe noindex reagieren und das Skript, das es entfernt hätte, nie ausführen.

Machen Sie daraus keine universelle Regel „gerendert gewinnt“. Die Abgleichung ist feldabhängig:

Diese Matrix ist der Grund, warum ein Prüfer Quelle, gerenderten Zustand, Antwort-Header und beobachteten Suchzustand getrennt halten sollte, anstatt sie zu einem einzigen „effektiven“ Wert zusammenzufassen.

Wählen Sie einen Rendering-Modus, der Inhalte in das DOM bringt

Das meiste JS-SEO-Risiko hängt davon ab, wie das HTML erzeugt wird. Kurz gesagt: SSR, statisches Rendering/Prerendering und Hydration bringen Inhalte in (oder schnell in) das DOM, wodurch die Sichtbarkeit weniger davon abhängt, dass der Renderer erfolgreich ist; vollständiges clientseitiges Rendering lässt mehr davon abhängen, dass das Rendering korrekt, rechtzeitig und jedes Mal abgeschlossen wird. Dynamisches Rendering ist ein Workaround, keine gleichwertige Option – laut Googles Leitfaden, zuletzt aktualisiert im Dezember 2025, beschreibt es dynamisches Rendering als Workaround und nicht als langfristige Lösung und empfiehlt stattdessen serverseitiges Rendering, statisches Rendering oder Hydration. Wie ich es in meinem JavaScript-SEO-Leitfaden formuliert habe: “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (Übersetzung) „Jede Art von SSR, statischem Rendering und Prerendering-Setup ist für Suchmaschinen in Ordnung.“ Die vollständige Übersicht – CSR, SSR, SSG, Hydration, ISR, Edge, Streaming und dynamisches Rendering – mit einer Vergleichstabelle finden Sie auf der Seite Rendering. Google beschreibt serverseitiges Rendering oder Pre-Rendering separat als gute Idee für Nutzer und Crawler. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

So testen Sie

Die URL-Prüfung in der Search Console ist die Quelle der Wahrheit: Führen Sie einen Live-Test durch und sehen Sie sich dann das gerenderte HTML, den Screenshot und die Seitenressourcen / Konsolenmeldungen an, um zu sehen, was geladen wurde und was fehlgeschlagen ist. Der Rich-Results-Test bietet eine schnelle Prüfung des gerenderten HTML. Im großen Maßstab verwenden Sie einen Crawler, der JavaScript ausführt (Ahrefs Site Audit, Screaming Frog im JS-Rendering-Modus), um Roh- und gerenderten Zustand über die gesamte Website zu vergleichen.

JavaScript ist nicht schlecht für SEO und es ist nicht böse. Es ist nur anders als das, was viele SEOs gewohnt sind. Arbeiten Sie mit Ihren Entwicklern zusammen, bringen Sie Ihre wichtigen Inhalte in das DOM und lassen Sie Googles eigene Tools – nicht Ihre Annahmen – darüber entscheiden, was gerendert wurde.

Wohin als Nächstes: der JavaScript-SEO-Cluster

Dieser Hub ist die Karte. Jedes Thema unten ist ein eigener Deep Dive:

Rendering und Architektur

• SEO für ein Headless-CMS – wie entkoppelte Frontends Crawling, Rendering, Metadaten, Sitemaps und kanonische Tags beeinflussen; welche Rendering-Methode Sie wählen sollten; und die Headless-spezifischen Fehlermodi, die Sie kennen müssen.

Framework-spezifische Anleitungen

• React SEO – warum CSR-first React ein Indexierungsrisiko darstellt, wie Google React-Apps rendert, React Router und History API, react-helmet-async für Meta-Tags und wann Sie zu Next.js greifen sollten.
• Angular SEO – Angulars SPA-Standardeinstellungen, @angular/ssr (der Nachfolger von Angular Universal), die integrierten Title- und Meta-Dienste, Prerendering und inkrementelle Hydration in modernem Angular.
• Next.js SEO – Pages Router vs. App Router, die Metadata API, next/image und CWV, ISR-Timing und Googlebot, Sitemaps und die häufigsten Next.js-SEO-Fehler.
• Nuxt SEO – SSR standardmäßig, useSeoMeta(), Nuxts Rendering-Modi, das @nuxtjs/seo-Modul-Ökosystem und wie Nuxt im Vergleich zu reinem Vue für die Indexierbarkeit abschneidet.
• Vue SEO – Vue 3s CSR-Standard und was das für Crawler bedeutet, createWebHistory(), @unhead/vue, Prerendering-Optionen ohne Meta-Framework und wann Nuxt die richtige Wahl ist.
• Svelte SEO – Svelte vs. SvelteKit, SSR standardmäßig in SvelteKit, <svelte:head>, die adapter-static + ssr: false-Falle, Adapter-Optionen und Auswirkungen auf KI-Crawler.
• Astro SEO – standardmäßig null JS, Insel-Architektur, @astrojs/sitemap, astro:assets, View Transitions und History API, Server-Islands-Fallback-Verhalten und Astros Core-Web-Vitals-Vorteile.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• „Kann Google JS lesen?“ ist die falsche Frage – es kann. Die Fehlermodi sind Parität (roh vs. gerendert), Interaktion (Google scrollt/klickt nicht), Zustand (zustandsloser Renderer) und Timing.
• Timing hat keine feste Verzögerung – Google stellt eine 200-Seite für das Rendering in die Warteschlange und kann „ein paar Sekunden“ oder länger warten, ohne veröffentlichten Timeout; ein Nicht-200-Status oder ein anfängliches noindex kann die Rendering-Warteschlange vollständig überspringen.
• Links müssen echte <a href>-Anker sein – onclick auf einem <div> ist als Link unsichtbar. Das Injizieren von Links mit JS ist in Ordnung, wenn sie am Ende als Anker vorliegen, aber gerenderte Anker werden nach der JS-Ausführung geparst – auffindbar, keine Garantie für Crawling/Indexierung.
• Lazy-Load am Viewport, nicht bei Interaktion – Google „interagiert nicht mit Ihrer Seite.“ Verwenden Sie IntersectionObserver / natives Lazy-Load; blenden Sie Inhalte nicht hinter Scrollen oder Klicken aus.
• Unendliches Scrollen kann zwei Seiten zu einer verschmelzen – Googlebot kann mit einem größeren Viewport rendern als ein typischer Browser (keine genaue veröffentlichte Größe – testen Sie Ihr eigenes Setup), und diese Lücke kann den Loader auslösen und den Inhalt der nächsten Seite anhängen. Lösung: paginierte URLs + echte <a href>-Links + History API; wenn ein Loader Seiten verschmilzt, blockieren Sie seine JS-Datei.
• Soft-404s nach clientseitigem Routing – geben Sie eine echte 404 oder noindex zurück; indexieren Sie keine leeren Hüllen; verlassen Sie sich nicht auf URL-Fragmente (AJAX-Crawling 2015 veraltet).
• Blockieren Sie JS/CSS nicht in robots.txt – Google rendert nicht aus blockierten Dateien.
• noindex kann seine eigene Entfernung blockieren – Google überspringt möglicherweise das Rendering, wenn es ein anfängliches noindex sieht, sodass JS, das es entfernen soll, möglicherweise nie ausgeführt wird.
• DOM-Parität + Stufenreihenfolge (Robots-Meta-Tags) – vergleichen Sie roh vs. gerendert, aber denken Sie daran, dass ein anfängliches rohes noindex das Rendering stoppen kann. Wenden Sie Kombinationsregeln nur auf tatsächlich verarbeitete Direktiven an; testen Sie die kanonische Parität unter ihren eigenen Regeln.
• Die Rendering-Methode ändert die Abhängigkeit, nicht das Ergebnis – SSR/statisch/Prerender/Hydration bringen Inhalte früher ins DOM und verringern die Abhängigkeit vom Rendering; vollständiges CSR ist am stärksten darauf angewiesen; dynamisches Rendering ist ein veralteter Google-Workaround, keine gleichwertige Option. Vollständige Aufschlüsselung auf der Rendering-Seite.
• Testen Sie mit URL Inspection (gerendertes HTML + Screenshot + Konsole), Rich Results Test und einem JS-Rendering-Crawler.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Grundlagen der JavaScript-SEO verstehen – die drei Phasen, crawlbare Links und das Testen von gerendertem HTML.
• Suchbezogene JavaScript-Probleme beheben – Soft-404-Behandlung, die History-API und Renderer-Einschränkungen.
• Lazy-geladene Inhalte beheben – Laden beim Viewport (nicht bei Interaktion) und suchfreundliches Infinite Scroll.
• E-Commerce-Paginierung und inkrementelles Laden von Seiten – eindeutige URLs, <a href>-Links und warum Google Fragmentbezeichner ignoriert.
• Ausführlicher Leitfaden zur Funktionsweise der Google-Suche – wo das Rendering im Ablauf Crawl → Index → Auslieferung steht.

Bing / Microsoft

• bingbot-Serie: JavaScript, dynamisches Rendering und Cloaking. Oh je! – Bings Sichtweise zum Rendern von JavaScript und dynamischem Rendering.

Zitate aus der Quelle

Aussagen auf der Grundlage öffentlicher Quellen von Google (plus einige aus meiner eigenen Arbeit). Jeder Suchmaschinen-Link ist ein Deep Link, der direkt zur zitierten Passage auf der Quellseite springt.

Google – Rendering & Links

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (Übersetzung) „Google verarbeitet JavaScript-Web-Apps in drei Hauptphasen: 1. Crawling 2. Rendering 3. Indexierung.“ Zum Zitat springen
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” (Übersetzung) „Google kann Ihre Links nur entdecken, wenn es sich um <a>-HTML-Elemente mit einem href-Attribut handelt.“ Zum Zitat springen
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (Übersetzung) „Rendering ist wichtig, weil Websites oft auf JavaScript angewiesen sind, um Inhalte auf die Seite zu bringen, und ohne Rendering könnte Google diese Inhalte möglicherweise nicht sehen.“ Zum Zitat springen
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (Übersetzung) „Die Seite kann einige Sekunden in dieser Warteschlange bleiben, aber es kann auch länger dauern.“ Zur Render-Warteschlangen-Zeit ist keine feste Verzögerung veröffentlicht. Zum Zitat springen
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (Übersetzung) „Wenn Google das noindex-Tag erkennt, kann es das Rendering und die JavaScript-Ausführung überspringen, was bedeutet, dass die Verwendung von JavaScript zum Ändern oder Entfernen des Robots-Meta-Tags von noindex möglicherweise nicht wie erwartet funktioniert.“ Zum Zitat springen

Google – Interaktion, Lazy-Load & Infinite Scroll

• “Google Search does not interact with your page.” (Übersetzung) „Google Search interagiert nicht mit Ihrer Seite.“ Zum Zitat springen
• “…loads all relevant content whenever it is visible in the viewport.” (Übersetzung) „…lädt alle relevanten Inhalte, sobald sie im Viewport sichtbar sind.“ Zum Zitat springen
• “Give each chunk its own persistent, unique URL.” — suchfreundliches unendliches Scrollen. (Übersetzung) „Geben Sie jedem Abschnitt eine eigene, dauerhafte, eindeutige URL.“ Zum Zitat springen
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” (Übersetzung) „Verwenden Sie keine URL-Fragmentbezeichner (den Text nach einem # in einer URL) für Seitenzahlen in einer Sammlung. Google ignoriert Fragmentbezeichner.“ Zum Zitat springen

Google – Soft-404 & Routing

• “We recommend using the History API to load different views.” (Übersetzung) „Wir empfehlen, die History API zum Laden verschiedener Ansichten zu verwenden.“ Zum Zitat springen

Patrick Stox (eigene Arbeit – JavaScript-SEO: Ein umfassender Leitfaden)

• Zu Meta-Robots-Tags im Speziellen: “With meta robots tags, Google is always going to take the most restrictive option it sees — no matter the location… Google will choose the most restrictive statements between HTML and the rendered version of a page.” (Übersetzung) „Bei Meta-Robots-Tags wählt Google immer die restriktivste Option, die es sieht – unabhängig vom Ort … Google wählt die restriktivsten Aussagen zwischen HTML und der gerenderten Version einer Seite.“
• “If you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (Übersetzung) „Wenn Sie ein unendliches Scroll-Setup haben, empfehle ich dennoch eine paginierte Seitenversion, damit Google weiterhin ordnungsgemäß crawlen kann.“
• Zur Zusammenführung: “occasionally, two pages get indexed as one” (Übersetzung) „Gelegentlich werden zwei Seiten als eine indexiert.“ Das geschieht, wenn “Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (Übersetzung) „Google vergrößerte den Viewport … dadurch wurde das unendliche Scrollen ausgelöst und beim Rendern ein weiterer Artikel geladen.“ Die Lösung lautet: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (Übersetzung) „Blockieren Sie die JavaScript-Datei, die das unendliche Scrollen steuert, damit die Funktion nicht ausgelöst werden kann.“

JavaScript-SEO-Checkliste

Ein schneller Durchlauf, um zu bestätigen, dass Google Ihre JS-abhängigen Inhalte rendern und indexieren kann:

• Wichtige Inhalte erscheinen im gerenderten HTML (prüfen Sie die URL-Inspektion, nicht nur den Seitenquelltext).
• Links sind echte <a href>-Anker – keine onclick-Handler auf <div>/<span>.
• JavaScript- und CSS-Dateien sind nicht in robots.txt blockiert.
• Keine Inhalte sind hinter einem Klick, Scrollen oder Hover verborgen (Google interagiert nicht); Lazy-Loading bei Sichtbarkeit über IntersectionObserver oder loading="lazy".
• Inhalte oberhalb der Falz werden nicht lazy-geladen.
• Robots-Anweisungen stimmen zwischen rohem und gerendertem HTML überein (kein JS, das noindex injiziert) – Google wählt die restriktivste.
• Clientseitige Routenänderungen, die auf eine fehlende Ressource treffen, geben einen echten 404 oder noindex zurück (keine Soft-404-Hüllen).
• Unendliches Scrollen hat eine paginierte Version mit eindeutigen <a href>-URLs und History-API-Updates – und führt nicht zu einer Zusammenführung von Seiten bei einem hohen Viewport.
• Inhalte, die ranken sollen, verwenden SSR / statisches / Prerendering, nicht vollständiges CSR (siehe die Rendering-Seite).
• Sie haben den gerenderten Screenshot und Konsolenfehler im Live-Test der URL-Inspektion stichprobenartig geprüft.

Die mentalen Modelle

1. „Kann Google mein JS ausführen?“ ist die falsche Frage. Das kann es. Die eigentlichen Fragen betreffen Parität, Interaktion, Zustand und Timing:

• Parität — enthält das gerenderte DOM das, was Sie denken?
• Interaktion — erfordert etwas ein Scrollen/Klicken, das Google nicht ausführt?
• Zustand — benötigt die Seite Cookies oder localStorage, obwohl der zustandslose Renderer diese Werte verwirft?
• Timing — ist kritischer Inhalt hinter langsamem/spätem JS zurückgestellt?

2. Wenn es nicht im gerenderten DOM ist, existiert es nicht. View Source zeigt das rohe HTML; URL Inspection zeigt das gerenderte DOM. Indexierungsentscheidungen werden auf Basis des gerenderten DOMs getroffen — also ist dies das Artefakt, das Sie jedes Mal prüfen sollten.

3. Echte Links oder keine Links. Die Entdeckung hängt von <a href>-Ankern ab. Click-Handler, Buttons und JS-Navigation, die niemals einen Anker erzeugt, sind Sackgassen für das Crawling.

4. Entwerfen Sie für einen Bot, der die Seite nie berührt. Kein Scrollen, kein Klicken, kein Hover. Wenn Inhalt eine Aktion benötigt, um zu erscheinen, gehen Sie davon aus, dass Google ihn nicht sieht — laden Sie ihn stattdessen im Viewport.

5. Testen Sie auf die Falle des hohen Viewports beim unendlichen Scrollen. Googlebot kann in einem Viewport rendern, der höher ist als ein typischer Browser (keine feste Größe ist veröffentlicht, also entwerfen Sie nicht gegen eine bestimmte Zahl), sodass ein Scroll-/Höhen-ausgelöster Loader während des Renderns feuern und die nächste Seite einfügen kann. Entwerfen Sie dafür: paginierte URLs + echte Links + History API; wenn es aktiv zusammenführt, blockieren Sie das JS des Loaders.

6. Lassen Sie die Tools entscheiden. Ihr Browser ist nicht Googlebot. Das gerenderte HTML, der Screenshot und die Konsole von URL Inspection sind die Quelle der Wahrheit — nicht „es sieht auf meinem Rechner gut aus.“

JavaScript-SEO-Fallstricke — Spickzettel

Welcher Rendering-Modus? (Abhängigkeit vom erfolgreichen Rendering)

Das ist keine Erfolgsgarantie — SSR/SSG/Hydration müssen trotzdem korrekt rendern und alle anderen Prüfungen in diesem Artikel bestehen. Vollständige Aufschlüsselung (ISR, Edge, Streaming, dynamisches Rendering und die Kompromisse) auf der Rendering-Seite.

Sehen Sie, was Googlebot sieht

Rendering-Fehler verstecken sich in der Lücke zwischen dem rohen HTML (was der Server sendet) und dem gerenderten HTML (was nach Ausführung von JS existiert). Ein paar schnelle Befehlszeilenprüfungen, bevor Sie zu einem vollständigen Crawler greifen.

Roh-HTML abrufen (was zurückkommt, bevor JS ausgeführt wird)

macOS / Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

Wenn der Text in raw.html fehlt, aber in Ihrem Browser sichtbar ist, wird er von JavaScript hinzugefügt – er hängt also vom Rendering ab. (Für das gerenderte HTML verwenden Sie URL Inspection → „View Crawled Page → rendered HTML“ oder einen Headless-Chrome-Crawler – ein normales curl kann kein JS ausführen.)

Bestätigen Sie, dass Sie JS/CSS nicht in robots.txt blockieren

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

Ein Disallow, das Ihr JavaScript oder CSS abdeckt, bedeutet, dass Google die Seite nicht richtig rendern kann – das ist fast immer ein Fehler. (URL Inspection listet auch blockierte Seitenressourcen auf; der grep fängt nur die offensichtlichen Fälle schnell ab.)

Tools zum Debuggen von JavaScript-SEO

Sehen Sie den Unterschied zwischen rohem HTML und dem, was Google rendert, mit Render Gap:

1. Fügen Sie die vollständige URL der Seite ein, die Sie testen möchten – eine JavaScript-lastige Vorlagenseite zeigt am meisten.
2. Deaktivieren Sie die Anti-Missbrauchs-Prüfung und klicken Sie auf Test page; es ruft zuerst das rohe HTML ab und rendert nur dann in Headless Chrome, wenn dieses HTML wie eine leere Hülle aussieht.
3. Lesen Sie das farbcodierte Urteil und durchsuchen Sie dann die Tabelle Initial HTML vs Rendered DOM nach Zeilen, die als changed markiert sind.
4. Wechseln Sie zur Registerkarte Raw vs rendered diff, um zeilenweise zu sehen, was JavaScript hinzugefügt oder entfernt hat.

• URL Inspection (Google Search Console) – die Quelle der Wahrheit. Führen Sie einen Live-Test durch und zeigen Sie dann das gerenderte HTML, den Screenshot, die Seitenressourcen (was geladen wurde vs. was blockiert wurde) und JavaScript-Konsolenmeldungen an.
• Rich Results Test – eine schnelle Möglichkeit, gerendertes HTML und strukturierte Daten für eine URL zu prüfen, ohne die Website zu verifizieren.
• Chrome DevTools – vergleichen Sie View Source (rohes HTML) mit dem Elements-Panel (gerendertes DOM); die Konsole zeigt JS-Fehler, die Inhalte ausblenden können.
• JavaScript-rendernde Crawler – Ahrefs Site Audit und Screaming Frog SEO Spider (JS-Rendering-Modus) führen JS aus, sodass Sie roh vs. gerendert in großem Maßstab vergleichen können.
• View-rendered-source-Tools – Browsererweiterungen, die das gerenderte DOM neben dem rohen HTML für schnelle Stichproben anzeigen.
• Server-Log-Analyse – bestätigen Sie, dass Googlebot Ihre JS/CSS-Ressourcen tatsächlich abruft (siehe Logdatei-Analyse).

Prompts zur JavaScript-SEO-Diagnose

Rohes und gerendertes HTML vergleichen

Fügen Sie die rohe Antwort und das gerenderte DOM für dieselbe URL ein. Entfernen Sie zuerst Kundendaten und Tokens.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

Eine Routenstichprobe triagieren

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

Eine JavaScript-SEO-Änderung validieren

Beweisen, dass Routeninhalte vor JavaScript existieren

Durchzuführender Test: Rufen Sie repräsentative Routen mit curl ab und prüfen Sie den Antworttext. Erwartetes Ergebnis: Jede Antwort enthält ihren eindeutigen Titel, die primäre Überschrift, den Text und crawlbare Links. Fehlerinterpretation: Die Bereitstellung liefert weiterhin eine gemeinsame App-Shell. Überwachungsfenster: Sofort. Rollback-Auslöser: Eine zuvor server-sichtbare Route wird vom Rendering abhängig.

Beweisen, dass Direktiven über Verarbeitungsstufen hinweg übereinstimmen

Durchzuführender Test: Vergleichen Sie das rohe HTML mit dem gerenderten HTML von URL Inspection für robots- und Canonical-Tags. Erwartetes Ergebnis: Ein beabsichtigtes Direktiven-Set erscheint in beiden, ohne restriktivere Werte in der rohen Shell. Fehlerinterpretation: JavaScript versucht, ein Indexierungssignal zu spät zu überschreiben. Überwachungsfenster: Sofort beim lokalen Rendering; nach dem erneuten Crawlen in der Search Console. Rollback-Auslöser: noindex oder ein falsches Canonical erscheint in einer der Stufen.

Beweisen, dass Links crawlbar bleiben

Durchzuführender Test: JavaScript deaktivieren und die Navigation zu repräsentativen Routen prüfen. Erwartetes Ergebnis: Ziele bleiben in echten Anker-href-Attributen erhalten. Fehlerinterpretation: Client-Handler, nicht Links, steuern die Erkennung. Überwachungszeitraum: Sofort. Rollback-Auslöser: Wichtige Routen verschwinden aus dem Linkgraphen, wenn Skripte fehlschlagen.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• JavaScript-SEO: Ein umfassender Leitfaden – mein vollständiger Leitfaden zu Rendering, DOM-Parität, der Regel der restriktivsten Direktive, unendlichem Scrollen und dem Problem von zwei Seiten als einer. Dieser Artikel ist die komprimierte, mit Quellen versehene Version.
• Der Anfängerleitfaden für technisches SEO – wo JavaScript-SEO im größeren Zusammenhang steht.

Meine Vorträge

• How Search Works (SlideShare) – meine Erläuterung von Crawling, Rendering, Indexierung und Ranking. (Mein üblicher Haftungsausschluss gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis von Systemen … es wird nicht zu 100 % vollständig oder genau sein.“)

Von anderen

• r/TechSEO – die Community zum Debuggen von Render-/Index-Problemen.
• web.dev – Rendering on the Web – die maßgebliche Erklärung der Rendering-Abwägungen vom Chrome-Team.
• Google Search Central – JavaScript-SEO – offizielle Primärquellen-Dokumentation zum Drei-Phasen-Prozess, crawlbarer Links und zum Testen von gerendertem HTML.
• Onely – JavaScript-SEO-Hub – tiefgehende technische Beiträge zu Rendering, Zwei-Wellen-Indexierung und JS-SEO-Audits von einer spezialisierten Agentur.
• Martin Splitts JavaScript-SEO-Playlist – die offizielle Google-Videoserie, die jedes JS-SEO-Konzept durchgeht, produziert vom Web-Ökosystem-Team von Google.
• Search Engine Journal – JavaScript-SEO-Berichterstattung – Branchennachrichten und Praxisleitfäden zu JS-Rendering-Problemen, sobald sie auftreten.

Audioformate

• Search Off the Record, der Podcast von Google Search Relations – Martin Splitt, John Mueller und Gary Illyes behandeln regelmäßig JavaScript-SEO und Rendering von innen. Anhören

Videos

• Google Search Central (YouTube) – Martin Splitts JavaScript-SEO-Serie ist der beste offizielle Video-Durchgang, wie Google mit Ihrem JS umgeht. Kanal

Statistiken, die sich zu zitieren lohnen

• Aktueller offizieller Rahmen: keine feste Verzögerung. Googles eigene Dokumentation (aktualisiert am 04.03.2026) besagt, dass eine gecrawlte 200-Seite “may stay on this queue for a few seconds, but it can take longer than that” (Übersetzung) „einige Sekunden in dieser Warteschlange bleiben kann, es aber auch länger dauern kann“. Es gibt keine veröffentlichte feste Verzögerung oder Zeitüberschreitung, und Seiten, die einen Nicht-200-Status zurückgeben oder mit noindex beginnen, können das Rendering vollständig überspringen. Zum Zitat springen
• Historischer Datenpunkt (veraltet) – ~5 Sekunden mediane Render-Verzögerung. In früheren Konferenzbemerkungen beschrieben Google-Mitarbeiter (Martin Splitt und Tom Greenaway), dass Seiten den Renderer im Median nach ~5 Sekunden erreichen, wobei das 90. Perzentil bei Minuten lag – nicht jene „Wochen“, die in der alten Befürchtung genannt wurden. Ich zitiere dies in meinem JavaScript-SEO-Leitfaden. Behandeln Sie es als historischen Datenpunkt aus diesem Vortrag, nicht als aktuelle veröffentlichte Kennzahl – Google hat es nicht als laufende Zahl erneut veröffentlicht, und das obige Zitat zur Warteschlangenzeit ist der aktuelle offizielle Rahmen.
• „Zwei Wellen des Indexierens“ verschwinden laut Martin Splitt (Bemerkungen von 2019). In einem Gespräch mit John Mueller im August 2019 sagte Splitt, dass die Zwei-Wellen-Indexierung “play[s] less and less of a role” (Übersetzung) „eine immer geringere Rolle spielt“, da Rendering billiger wird und Crawling, Rendering und Indexierung konvergieren – ohne Zeitrahmen dafür, wann sie vollständig aufhören könnte. Abdeckung Dies ist Splitts Charakterisierung aus diesem spezifischen Gespräch, keine datierte, zitierbare Google-Spezifikation – verwenden Sie es als richtungsweisenden Kontext, nicht als aktuelle Garantie in die eine oder andere Richtung.

Google verarbeitet JavaScript-Apps durch Crawling, Rendering und Indexierung. Evidence for this claim Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Scope: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Es crawlt im Allgemeinen Links, wenn es sich um Anker mit href-Attributen handelt. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable Google beschreibt Server-Side Rendering oder Pre-Rendering als gute Idee für Nutzer und Crawler. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Die Google-Suche interagiert auch nicht mit einer Seite, um Inhalte auszulösen. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content

Änderungsprotokoll