Rendering und SEO

TL;DR — Rendering ist der Schritt, in dem eine Suchmaschine den Code Ihrer Seite – einschließlich JavaScript – in einem Browser ausführt, um die fertige Seite zu erstellen, damit sie Ihre Inhalte und Links sehen kann. Google tut dies für praktisch jede Seite in seinem Web Rendering Service, und es funktioniert normalerweise. Wie Ihre Seite ihr HTML erzeugt (Server, Browser, oder zur Build-Zeit) entscheidet darüber, wie sicher Sie sind.

Was Rendering ist

Wenn Sie eine Seite öffnen, lädt Ihr Browser etwas HTML herunter und führt dann das CSS und JavaScript aus, um die Seite zu erstellen, die Sie tatsächlich sehen. Suchmaschinen tun dasselbe. Rendering ist der Schritt, in dem eine Suchmaschine den Code Ihrer Seite ausführt, um die endgültige Version der Seite zu erstellen, damit sie den Inhalt lesen und den Links folgen kann, so wie Sie es können.

Es sitzt in der Mitte davon, wie Google eine Seite behandelt:

1. Crawl – Google lädt das rohe HTML Ihrer URL herunter.
2. Render – Google führt das JavaScript der Seite in einem Browser aus, um die fertige Seite zu erstellen.
3. Index – Google liest diese fertige Seite und legt sie ab.

Wenn Ihre Inhalte erst nach der Ausführung von JavaScript sichtbar werden, muss Google die Seite erfolgreich rendern, bevor es sie sehen kann. Rendering ist also die Brücke zwischen dem Abrufen einer Seite und dem Verstehen.

Google rendert in einem echten (aber ungewöhnlichen) Browser

Googles Renderer heißt Web Rendering Service (WRS). Es ist ein headless Chrome, der “evergreen” ist, was bedeutet, dass er mit der aktuellen Version von Chrome Schritt hält und moderne Webfunktionen unterstützt. Die alte Angst – „Google kann kein JavaScript ausführen“ – stimmt also nicht. Es kann. Evidence for this claim Google Search runs JavaScript with an evergreen version of Chromium. Scope: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

Es ist nur ein ungewöhnlicher Browser. Er scrollt nicht und klickt nicht, vergisst alles zwischen Seiten (kein Eingeloggtbleiben) und cached Dateien stark. Diese Eigenheiten sind die Quelle der meisten Überraschungen, und der Advanced-Tab behandelt sie.

Die große Entscheidung: Wo Ihr HTML erstellt wird

Die wichtigste Entscheidung für SEO ist, wo das HTML Ihrer Seite erzeugt wird:

• Im Browser (Client-Side Rendering) – der Server sendet eine fast leere Seite und JavaScript erstellt alles. Am riskantesten für die Suche.
• Auf dem Server (Server-Side Rendering) – der Server sendet eine vollständige Seite. Sicher.
• Zur Build-Zeit (statisch / Prerendering) – Seiten werden einmal im Voraus erstellt. Am sichersten und schnellsten.

Die meisten modernen Frameworks mischen diese. Die Faustregel: Wenn Ihre wichtigen Inhalte im HTML sind, bevor JavaScript ausgeführt wird (oder fast sofort ankommen), sind Sie gut aufgestellt.

Möchten Sie die tiefere Version – wie sich der Web Rendering Service tatsächlich verhält, ob „zwei Wellen des Indexierens“ noch aktuell ist, und einen vollständigen Vergleich aller Rendering- Optionen? Wechseln Sie zum Fortgeschritten-Tab. Für die praktischen JavaScript-Probleme und Lösungen siehe JavaScript SEO.

TL;DR — Google rendert Ihr JS in einem evergreen, headless Chromium – dem Web Rendering Service – um das DOM zu erstellen, das es indexiert. Dies geschieht für praktisch alle Seiten, normalerweise innerhalb von Sekunden bis Minuten, sodass „zwei Wellen des Indexierens“ weitgehend veraltet ist und es kein Render-Budget pro Seite gibt. Der WRS ist zustandslos, lehnt Berechtigungsabfragen ab, interagiert nicht mit der Seite und cached aggressiv. Ihre Rendering-Option entscheidet über Ihr SEO-Risiko: SSR / statisch / Prerendering / Hydration sind risikoarm; volles CSR ist das riskante; dynamisches Rendering ist ein Workaround, den Google nicht empfiehlt. Für die praktischen JS-Probleme, die dies verursacht, siehe JavaScript SEO.

Wo Rendering sitzt

Google macht deutlich, dass JavaScript-Apps drei Phasen durchlaufen: „Google verarbeitet JavaScript-Web-Apps in drei Hauptphasen: 1. Crawling 2. Rendering 3. Indexierung.“ Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Rendering ist die Brücke. Crawling ruft das rohe HTML ab; Rendering führt das JavaScript aus, um das fertige DOM zu erstellen; Indexierung liest dieses gerenderte DOM, und alle neuen Links, die der Renderer findet, werden wieder ins Crawling eingespeist. In Googles Worten: „Während des Crawlens rendert Google die Seite und führt jegliches JavaScript aus, das es findet, mit einer aktuellen Version von Chrome, ähnlich wie Ihr Browser Seiten rendert, die Sie besuchen.“

Der Web-Rendering-Dienst

Google rendert im Web-Rendering-Dienst (WRS) – einem Headless-Chrome, der evergreen ist: „Während die Google-Suche JavaScript mit einer Evergreen-Version von Chromium ausführt …“ folgt er dem aktuellen Chrome, sodass moderne JavaScript- und CSS-Funktionen funktionieren.

Der Haken ist, dass der WRS ein eigenartiger Browser ist, und seine Eigenheiten verursachen die meisten echten Probleme:

• Er ist zustandslos. Wie ich es in meinem JavaScript-SEO-Leitfaden formuliert habe, „Google lädt jede Seite zustandslos, als wäre es ein frischer Aufruf.“ Googles Dokumentation führt die Einzelheiten aus: „Local Storage und Session Storage Daten werden über Seitenaufrufe hinweg gelöscht“ und „HTTP-Cookies werden über Seitenaufrufe hinweg gelöscht.“ Verlassen Sie sich nicht auf etwas, das clientseitig persistiert wird, um Ihre Inhalte auszuliefern.
• Er lehnt Berechtigungen ab. „Erwarten Sie, dass Googlebot Benutzerberechtigungsanfragen ablehnt.“ Inhalte, die hinter einer Geolokalisierungs-, Benachrichtigungs- oder Kameraabfrage gesperrt sind, werden nicht gerendert.
• Er interagiert nicht. Kein Scrollen, Klicken oder Hovern – Inhalte, die nur bei einem dieser Ereignisse geladen werden, sind standardmäßig unsichtbar. (Dies ist die Wurzel der meisten Lazy-Load- und Infinite-Scroll-Fehler; die Lösungen finden Sie auf der JavaScript-SEO-Seite.)
• Er cached aggressiv. „Googlebot cached aggressiv, um Netzwerkanfragen und Ressourcennutzung zu reduzieren. WRS kann Caching-Header ignorieren.“ Das bedeutet, dass Google eine veraltete Version Ihres JavaScripts oder CSS ausführen kann. Beheben Sie es mit Datei- Fingerprinting – versionieren Sie Ihre Dateinamen (app.4f2a9c.js), sodass eine Inhaltsänderung einen neuen Abruf erzwingt.

Ein Experiment von 2026: Fünf Sekunden sind keine harte Ausführungsgrenze

Ein Drittanbieter-WRS-Experiment, das im Juli 2026 berichtet wurde, testete verzögertes JavaScript und Netzwerkaktivität, anstatt ein Fünf-Sekunden-Timeout anzunehmen. Der beobachtete Renderer verwendete eine virtuelle Uhr und schloss verzögerte Anfragen ab, die etwa 6–12 Sekunden Echtzeit dauerten. Das nützliche Ergebnis ist eng begrenzt: Es widerspricht der gängigen Audit-Regel, dass alles, was nach genau fünf Sekunden passiert, automatisch für Google unsichtbar ist. Es beweist nicht, dass jede verzögerte Abhängigkeit abgeschlossen wird, dass Google unbegrenzt wartet oder dass langsame clientseitige Auslieferung sicher ist.

Lesen Sie das Experiment und seine Methodik als Drittanbieter-Beleg neben Googles offizieller Aussage, dass die Render-Warteschlangen-Zeit keine veröffentlichte feste Verzögerung hat. Testen Sie in der Praxis das endgültige DOM und die angeforderten Ressourcen. Eine fehlende API-Antwort, Interaktionsanforderung, blockiertes Skript oder Zustandsabhängigkeit bleibt ein echtes Rendering-Fehler, selbst wenn eine Stoppuhr-basierte „Fünf-Sekunden-Regel“ es nicht ist.

Gibt es „zwei Wellen der Indexierung“ noch?

Jahrelang war das mentale Modell „zwei Wellen der Indexierung“: Google würde das rohe HTML zuerst indexieren und dann Tage oder Wochen später zurückkommen, um den JavaScript-Inhalt zu rendern und zu indexieren. Dieses Modell ist heute weitgehend veraltet. Martin Splitt hat gesagt, dass die Zwei-Wellen-Idee immer weniger eine Rolle spielt, dass viele Seiten die Render-Phase durchlaufen, selbst wenn sie nicht auf JavaScript angewiesen sind, und dass Crawling, Rendering und Indexierung im Laufe der Zeit konvergieren.

In der Praxis wird das Rendering für praktisch jede Seite durchgeführt, und es ist in der Regel schnell. Die aktuelle Dokumentation von Google besagt, dass eine gecrawlte Seite “may stay on this queue for a few seconds, but it can take longer than that” — es gibt keine veröffentlichte feste Verzögerung oder Zeitüberschreitung. Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: 2026-07-25 Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. Als historischer Datenpunkt nannten Google-Mitarbeiter (Martin Splitt und Tom Greenaway) einmal einen Median von etwa fünf Sekunden, mit dem 90. Perzentil im Minutenbereich — nicht die “Wochen”, die die alte Befürchtung implizierte. Ich zitiere diese Zahl in meinem JavaScript-SEO-Leitfaden, behandle sie jedoch als veralteten Konferenz-Datenpunkt und nicht als aktuelle veröffentlichte Kennzahl — Google hat sie nicht als laufende Zahl erneut veröffentlicht, und das obige Zitat zur Warteschlangenzeit ist der aktuelle offizielle Rahmen.

Und es gibt kein Render-Budget in der Art, wie man es sich vorstellt. Google verfolgt keinen pro Seite “wie teuer war das Rendering”-Score, den man schonen müsste. Rendering ist bei Googles Größenordnung günstig — optimieren Sie für Ihre Nutzer und Leistung, nicht für ein Phantom-Render-Budget.

Die Rendering-Optionen

“Wo wird das HTML erstellt?” ist die Frage, die Ihr SEO-Risiko bestimmt. Die vollständige Auswahl:

• Client-seitiges Rendering (CSR). Der Server sendet eine fast leere Hülle; der Browser (oder WRS) führt JavaScript aus, um alles zu erstellen. Dies ist “the most problematic one … full client-side rendering where all of the rendering happens in the browser.” Es kann funktionieren, aber Sie setzen alles auf das Gelingen des Renderings, und es ist am langsamsten, um indexiert zu werden.
• Server-seitiges Rendering (SSR). Der Server erstellt das vollständige HTML für jede Anfrage. Der Inhalt ist im rohen HTML, daher ist es risikoarm für die Suche.
• Statische Seitengenerierung (SSG) / Prerendering. HTML wird einmalig zur Bereitstellungszeit erstellt. Geringstes Risiko — der Inhalt ist im rohen HTML und es ist schnell.
• Hydration (isomorph / universell). Sie rendern den ersten Paint per SSR oder SSG, dann “hydratisiert” JavaScript ihn im Browser, um Interaktivität hinzuzufügen. Dies ist, was die meisten modernen Frameworks tun, und es ist risikoarm für Inhalte — achten Sie nur auf Hydrations- Abweichungen, die Inhalte leeren oder ersetzen.
• Inkrementelle statische Regenerierung (ISR). Statische Seiten, die nach Zeitplan oder bei Bedarf regeneriert werden. Wie SSG, mit frischeren Inhalten — gut für große Kataloge.
• Edge-Rendering. SSR, das an CDN-Edge-Knoten ausgeführt wird — gleiches geringes Risiko wie SSR, mit schnellerer Time-to-First-Byte für ein globales Publikum.
• Streaming-SSR. HTML wird in Teilen an den Browser gestreamt, sobald es bereit ist. Geringes Risiko, aber stellen Sie sicher, dass indexierbarer Inhalt nicht nur in einem späten oder verzögerten Teil gefangen ist.

Mein Fazit aus meinem JavaScript-SEO-Leitfaden: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” Das Framework ist weniger wichtig als der Rendering-Modus, den Sie ausliefern — dieselbe Next.js- App ist sicher oder riskant, je nachdem, ob Sie SSR/SSG oder vollständiges CSR bereitstellen.

Dynamisches Rendering — ein Workaround, keine Strategie

Dynamisches Rendering bedeutet, Bots zu erkennen und ihnen eine vorgerenderte, JavaScript-freie Version zu liefern, während Benutzer die Client-seitige Version erhalten. Google ist jetzt deutlich dazu: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” und “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: 2026-07-14 Google Search Central: Dynamic rendering as a workaround Ich stimme zu, und das habe ich immer getan — um ehrlich zu sein, habe ich es nie empfohlen, und ich bin froh, dass Google es jetzt ebenfalls nicht mehr empfiehlt. Es liefert unterschiedliche Inhalte an Bots und Benutzer, was dem Cloaking sehr nahe kommt. Greifen Sie stattdessen zu SSR, statischem Rendering oder Hydration.

Eine Besonderheit: Bing empfiehlt dynamisches Rendering weiterhin. Microsoft sagt, “bingbot ist im Allgemeinen in der Lage, JavaScript zu rendern”, aber dass dies in großem Maßstab schwierig ist, und empfiehlt daher “dynamisches Rendering als großartige Alternative für Websites, die stark auf JavaScript angewiesen sind.” Die praktische Schlussfolgerung: SSR/SSG hält beide Suchmaschinen zufrieden und umgeht die gesamte Debatte.

Was das für Ihre Inhalte bedeutet

Das Rendering entscheidet, ob Google Ihre JavaScript-Inhalte jemals sieht – aber das Sehen ist nur die halbe Miete. Sobald die Seite gerendert ist, sind die praktischen Belange echte <a href>-Links, feldbezogene Parität zwischen rohem und gerendertem HTML, die Reihenfolge der robots-Direktiven, Lazy Content, Infinite Scroll und Soft-404s. Diese werden alle auf der Seite JavaScript-SEO behandelt, zusammen mit dem Test-Workflow (gerendertes HTML, Screenshot und Konsole der URL-Inspektion).

Dies ist die Rendering-Phase der Such-Pipeline. Für die Phasen davor und danach siehe Crawling (wie Seiten abgerufen werden) und Indexierung (was mit der gerenderten Seite als Nächstes passiert) oder den Hub So funktioniert die Suche für die gesamte Reise.

Eine Audit-Regel ist hier erwähnenswert: Gerendert ist ein Zustand, kein universeller Gewinner. Für Body-Inhalte und crawlbare Links zeigt das gerenderte DOM, was erfolgreiches JavaScript hinzugefügt oder entfernt hat. Für Titel und Beschreibungen zeigt es zusätzliche Eingaben, während Google möglicherweise weiterhin einen Titel-Link oder ein Snippet aus anderen Quellen generiert. Bei robots-Direktiven kann ein rohes noindex das Rendering verhindern, sodass die JavaScript-Entfernung asymmetrisch ist. Für Canonical empfiehlt Google, eine Quelle oder einen per JavaScript gesetzten Wert zu verwenden, anstatt einen vorhandenen Wert zu ändern. Und JavaScript kann den bereits empfangenen HTTP-Statuscode nicht ändern. Halten Sie diese Spalten in den Beweisen getrennt und verwenden Sie die aktuelle JavaScript-SEO-Anleitung von Google für das feldbezogene Verhalten.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Rendering = die Brücke vom Crawling zur Indexierung. Google führt Ihr JS in einem immer aktuellen, headless Chromium aus – dem Web Rendering Service – um das DOM aufzubauen, das es indexiert. Drei Phasen: Crawl → Render → Index.
• “Zwei Wellen der Indexierung” sind weitgehend veraltet (Splitt). Rendering erfolgt für praktisch alle Seiten, normalerweise schnell. Die aktuellen Dokumente von Google sagen, dass eine Seite “möglicherweise einige Sekunden in dieser Warteschlange bleibt, aber es kann auch länger dauern” – es gibt keine veröffentlichte feste Verzögerung. (Ein ~5-Sekunden-Median/Minuten-90. Perzentil-Wert existiert, aber es ist ein veralteter Konferenz-Datenpunkt, keine aktuelle Metrik.) Es gibt kein Pro-Seite-Render-Budget.
• Der WRS ist ein seltsamer Browser: zustandslos (localStorage/Cookies werden zwischen den Ladevorgängen gelöscht), lehnt Berechtigungsaufforderungen ab, scrollt/klickt/fährt nicht mit der Maus und cached JS/CSS aggressiv (kann Cache-Header ignorieren) → Fingerprinten Sie Ihre Dateinamen.
• Rendering-Optionen, nach SEO-Risiko: SSG/Prerendering (niedrigstes) ≈ SSR ≈ Hydration ≈ ISR ≈ Edge/Streaming (niedrig) ≪ volles CSR (höchstes). Patrick: “SSR, statisches Rendering und Prerendering … sind alle großartig”; volles CSR ist “das problematischste.”
• Dynamisches Rendering ist ein Workaround, Google rät davon ab (nahe an Cloaking). Bing empfiehlt es weiterhin – aber SSR/SSG erfüllt beide Anforderungen.
• Das Framework entscheidet nicht über das Risiko – der Rendering-Modus tut es. Dieselbe App ist sicher oder riskant, je nachdem, ob Sie SSR/SSG oder volles CSR ausliefern.
• Rendering ist die halbe Miete – die praktischen JS-Probleme (Links, Parität, Lazy Content, Infinite Scroll, Soft-404s, Testen) werden auf der JavaScript-SEO-Seite behandelt.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Verstehen Sie die JavaScript-SEO-Grundlagen – die drei Phasen (Crawlen → Rendern → Indexieren) und der Evergreen-Chromium-Renderer.
• Beheben Sie JavaScript-bezogene Suchprobleme – die WRS-Einschränkungen: zustandsloser Speicher/Cookies, abgelehnte Berechtigungen, aggressives Caching.
• Dynamisches Rendering als Workaround – warum dynamisches Rendering ein Workaround und keine empfohlene langfristige Lösung ist.
• Ausführlicher Leitfaden zur Funktionsweise der Google-Suche – wo das Rendering im Ablauf Crawlen → Indexieren → Ausliefern steht.

Bing / Microsoft

• bingbot-Serie: JavaScript, dynamisches Rendering und Cloaking. Oh je! – Bings Haltung, dass es JS rendern kann, aber dynamisches Rendering in großem Umfang empfiehlt.
• Der neue Evergreen-Bingbot – Bingbot-Rendering auf Chromium-basiertem Microsoft Edge.

Zitate aus der Quelle

Offizielle Aussagen von Google und Bing (plus einige aus meiner eigenen Arbeit). Jeder Suchmaschinen-Link ist ein Deep-Link, der direkt zum zitierten Abschnitt auf der Quellseite springt.

Google – die Rendering-Pipeline

• “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. Crawlen 2. Rendern 3. Indexieren.“ Zum Zitat springen
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (Übersetzung) „Während des Crawlens rendert Google die Seite und führt jedes gefundene JavaScript mit einer aktuellen Version von Chrome aus, ähnlich wie Ihr Browser Seiten rendert, die Sie besuchen.“ Zum Zitat springen
• “While Google Search runs JavaScript with an evergreen version of Chromium…” (Übersetzung) „Während die Google-Suche JavaScript mit einer Evergreen-Version von Chromium ausführt …“ Zum Zitat springen
• “The page may stay on this queue for a few seconds, but it can take longer than that.” – die aktuelle offizielle Darstellung zur Render-Warteschlangen-Zeit; es ist keine feste Verzögerung veröffentlicht. Zum Zitat springen

Google – der Web-Rendering-Dienst

• “Local Storage and Session Storage data are cleared across page loads.” (Übersetzung) „Local-Storage- und Session-Storage-Daten werden bei Seitenaufrufen gelöscht.“ Zum Zitat springen
• “HTTP Cookies are cleared across page loads.” (Übersetzung) „HTTP-Cookies werden bei Seitenaufrufen gelöscht.“ Zum Zitat springen
• “Expect Googlebot to decline user permission requests.” (Übersetzung) „Erwarten Sie, dass Googlebot Benutzerberechtigungsanfragen ablehnt.“ Zum Zitat springen
• “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (Übersetzung) „Googlebot cached aggressiv, um Netzwerkanfragen und Ressourcennutzung zu reduzieren. WRS kann Caching-Header ignorieren.“ Zum Zitat springen

Google – dynamisches Rendering

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (Übersetzung) „Dynamic rendering war eine Notlösung und keine langfristige Lösung für Probleme mit JavaScript-generierten Inhalten in Suchmaschinen.“ Zum Zitat springen
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (Übersetzung) „Dynamic rendering ist eine Notlösung und keine empfohlene Lösung, da es zusätzliche Komplexität und Ressourcenanforderungen schafft.“ Zum Zitat springen

Microsoft Bing

• “bingbot is generally able to render JavaScript…” (Übersetzung) „bingbot ist im Allgemeinen in der Lage, JavaScript zu rendern …“ Zum Zitat springen
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (Übersetzung) „wir empfehlen Dynamic Rendering als großartige Alternative für Websites, die stark auf JavaScript angewiesen sind.“ Zum Zitat springen

Martin Splitt, Google (übermittelt über Onelys Transkript eines Webmaster-Central-Hangouts von 2019)

• Zum Zwei-Wellen-Modell: Splitt hat gesagt, dass es eine immer geringere Rolle spielt, dass viele Websites auch ohne JavaScript die Render-Phase durchlaufen und dass Crawling, Rendering und Indexierung zusammenwachsen. Zur Berichterstattung

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

• “Google loads each page stateless like it’s a fresh load.” (Übersetzung) „Google lädt jede Seite zustandslos, als wäre es ein frischer Aufruf.“
• “pages went to the renderer at a median time of five seconds” (90. Perzentil in Minuten) — ein veralteter Datenpunkt aus der Konferenzzeit, keine aktuelle veröffentlichte Kennzahl; siehe das aktuelle offizielle Zitat zur Warteschlangenzeit oben. (Übersetzung) „Seiten gingen im Median nach fünf Sekunden an den Renderer“
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (Übersetzung) „Das problematischste wird das vollständige clientseitige Rendering sein, bei dem das gesamte Rendering im Browser stattfindet.“
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (Übersetzung) „Jede Art von SSR, statischem Rendering und Prerendering-Setup ist für Suchmaschinen in Ordnung. Gatsby, Next, Nuxt usw. sind alle großartig.“

Die mentalen Modelle

1. Crawlen → Rendern → Indexieren. Rendering ist die Brücke. Crawling ruft das rohe HTML ab; Rendering führt das JS aus, um das DOM aufzubauen; Indexierung liest dieses DOM. Wenn JS-Inhalte fehlen, fragen Sie, welcher Schritt fehlgeschlagen ist — wurde abgerufen? gerendert? enthielt das gerenderte DOM den Inhalt?

2. Der Renderer ist ein echter Browser mit Amnesie. Evergreen Chrome, aber zustandslos (vergisst Cookies/Speicher zwischen Seiten), ohne Interaktion (scrollt oder klickt nicht) und cache-freudig (kann veraltetes JS/CSS ausführen). Gestalten Sie so, als ob jeder Besuch ein frischer, unberührter erster Aufruf ist.

3. Die Rendering-Methode entscheidet über Ihr Risiko, nicht Ihr Framework. SSR, statisches Rendering, Prerendering und Hydration bringen Inhalte in (oder schnell in) das DOM — geringes Risiko. Vollständiges CSR setzt alles auf das Rendering — höchstes Risiko. Dieselbe Next.js-App ist sicher oder riskant, je nachdem, welche Methode Sie ausliefern.

4. „Zwei Wellen“ ist die alte Karte. Planen Sie nicht um eine verzögerte zweite Render-Welle Tage später herum. Rendering passiert für im Wesentlichen alle Seiten, normalerweise innerhalb von Sekunden bis Minuten — und es gibt kein Render-Budget, das es zu rationieren gilt.

5. Dynamic Rendering ist ein Warnsignal, keine Strategie. Bots anderen HTML-Code zu servieren als Nutzern ist eine Notlösung, die Google ablehnt (und nahe am Cloaking ist). Wenn Sie danach greifen, ist die eigentliche Lösung meist SSR/SSG.

6. Bringen Sie Inhalte in das DOM und überprüfen Sie sie dann. Wählen Sie einen Modus, der Inhalte schnell in das gerenderte DOM bringt, und bestätigen Sie dies dann mit dem gerenderten HTML der URL-Inspektion. Ihr Browser ist nicht Googlebot.

Rendering-Optionen – SEO-Abwägungen

Web-Rendering-Dienst – Kurzübersicht

Checkliste für den Render-Bereitschafts-Audit

Ein Durchlauf, um zu bestätigen, dass Ihre wichtigen Inhalte das Rendering tatsächlich überleben:

• Primärinhalte und Hauptnavigationslinks sind im rohen HTML vorhanden (Quelltext anzeigen, nicht das untersuchte DOM der DevTools) – nicht nur nach Ausführung von JavaScript injiziert.
• Jeder interne Link, dem ein Leser folgen muss, ist ein echtes <a href="..."> – kein <div onclick>, keine Hash-only-Route (#/page) oder ein Button, der clientseitig Zustand pusht, ohne passenden Link.
• Keine kritischen JS- oder CSS-Dateien sind in robots.txt blockiert (ein blockiertes Bundle kann dazu führen, dass der WRS die Seite, die er rendern muss, nicht aufbauen kann).
• Inhalte, die beim Scrollen, Überfahren oder Klicken geladen werden, haben auch einen Pfad, der ohne Interaktion rendert – der WRS scrollt, klickt oder fährt nicht mit der Maus.
• Nichts Wichtiges hängt davon ab, dass localStorage, sessionStorage oder Cookies zwischen Anfragen bestehen bleiben – der WRS ist zustandslos und löscht all das zwischen Seitenaufrufen.
• Nichts Wichtiges liegt hinter einer Geolokalisierungs-, Benachrichtigungs- oder Kamera- Berechtigungsabfrage – der WRS lehnt diese standardmäßig ab.
• JS/CSS-Dateinamen sind mit Fingerprint versehen (app.4f2a9c.js), sodass eine Inhaltsänderung einen frischen Abruf erzwingt, anstatt aus dem aggressiven Cache des WRS ausgeliefert zu werden.
• Das gerenderte HTML/Screenshot der URL-Inspektion in der Google Search Console zeigt denselben Inhalt und dieselben Links, die Sie in Ihrem eigenen Browser sehen.
• Die Website verwendet kein dynamisches Rendering als Antwort auf ein CSR-Problem – die Lösung ist SSR, statisches Rendering oder Hydration, nicht das Ausliefern einer anderen Version der Seite an Bots.

Rendering-Fehler, die wirklich wehtun

Blockieren des für die Darstellung benötigten JS oder CSS in robots.txt. Wenn der WRS ein Skript oder Stylesheet, das die Seite benötigt, nicht abrufen kann, kann er kein genaues gerendertes DOM aufbauen – Sie erhalten eine defekte oder leere Darstellung anstatt der gewünschten Seite. Stattdessen: Erlauben Sie das Crawlen Ihrer JS/CSS-Assets; robots.txt sollte Bots von Bereichen mit geringem Wert fernhalten, nicht von den Ressourcen, die Ihre eigenen Seiten benötigen.

Ausliefern von inhaltskritischen Seiten als reines Client-Side-Rendering (CSR) ohne Fallback. CSR ist “the most problematic one … full client-side rendering where all of the rendering happens in the browser” – es setzt Ihre gesamte Seite auf den Erfolg des Renderings und ist die langsamste Option, um indexiert zu werden. Stattdessen: Nutzen Sie SSR, statisches Generieren/Prerendering oder Hydration, damit Inhalte im (oder sehr schnell im) rohen HTML sind.

Verlassen auf hash-basierte Routen (#/product/123) als einzige Navigation. Der WRS folgt echten <a href>-Links; ein Hash-Fragment, das nur den clientseitigen Zustand ändert, ohne eine serverseitig gerenderte äquivalente URL, gibt dem Renderer nichts zum Weitercrawlen. Stattdessen: Verwenden Sie echte Pfade, auf die der Server direkt antworten kann (/product/123), auch in einer clientlastigen App.

Lazy-Loading von Inhalten ohne nicht-interaktiven Pfad dorthin. Da der WRS “doesn’t scroll, click, or hover,” ist Inhalt, der erst nach einem dieser Ereignisse erscheint, für ihn standardmäßig unsichtbar. Stattdessen: Laden Sie Inhalte oberhalb des Falzes und in angemessener Nähe zum Viewport, ohne dass eine Interaktion erforderlich ist, und reservieren Sie echtes Lazy-Loading für Inhalte, die wirklich unterhalb des Falzes liegen, mit einem ordnungsgemäßen Nicht-JS-Fallback.

Dynamisches Rendering als langfristige Lösung statt als Workaround behandeln. Google ist explizit, dass “dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements” – und Bots andere Inhalte zu liefern als Nutzer liegt unangenehm nahe an Cloaking. Stattdessen: Beheben Sie den Rendering-Modus selbst (SSR/statisch/Hydration), anstatt eine Bot-Erkennungsschicht um ein CSR-Problem herum aufzubauen.

Validierungstests

Bestanden/Nicht bestanden-Checks, um zu bestätigen, dass eine Rendering-Korrektur tatsächlich wirksam wurde – führen Sie diese nach der Auslieferung der Änderung aus, nicht als laufende Gesundheitsmetrik.

Test: Inhalt erscheint jetzt im gerenderten DOM

• Durchzuführender Test – Übermitteln Sie die URL an das URL Inspection-Tool der Google Search Console und verwenden Sie “Test Live URL”, öffnen Sie dann den Tab mit dem gerenderten HTML (oder führen Sie die Seite durch das Render Gap-Tool, um rohes vs. gerendertes HTML direkt zu vergleichen).
• Erwartetes Ergebnis – Der hinzugefügte oder korrigierte Inhalt erscheint in der gerenderten HTML/DOM-Ansicht, nicht nur in den DevTools Ihres eigenen Browsers.
• Fehlerinterpretation – Wenn er im gerenderten HTML immer noch fehlt, aber beim normalen Anzeigen der Seite vorhanden ist, kann der WRS ihn immer noch nicht aufbauen – prüfen Sie auf eine blockierte JS/CSS-Ressource, ein nur durch Interaktion ladendes Element oder eine Abhängigkeit vom Client-Speicher, bevor Sie annehmen, dass die Korrektur funktioniert hat.
• Überwachungsfenster – Sofort; der Live-Test der URL Inspection spiegelt den aktuellen Zustand der URL sofort wider.
• Rollback-Auslöser – Das gerenderte HTML enthält den Inhalt nach der Korrektur immer noch nicht, oder der Live-Test wirft einen neuen Crawl-/Render-Fehler, den er vorher nicht geworfen hat.

Test: Wichtige Links überleben das Rendering

• Durchzuführender Test – Prüfen Sie das gerenderte HTML (URL Inspection oder Render Gap) auf echte <a href>-Tags um jeden Link, dem ein Leser folgen muss, nicht nur auf sichtbare klickbare Elemente.
• Erwartetes Ergebnis – Jeder Link im gerenderten DOM hat ein auflösbares href, das auf eine echte, crawlbare URL zeigt.
• Fehlerinterpretation – Ein fehlendes oder leeres href bei einem scheinbar funktionierenden Link bedeutet normalerweise, dass es sich um ein <div>/<button> mit einem clientseitigen Klick-Handler und ohne serverrenderbaren Pfad handelt – der WRS kann ihm nicht folgen.
• Überwachungsfenster – Sofort.
• Rollback-Auslöser – Links, die vor der Änderung wichtig waren, fehlen href-Attribute oder zeigen im gerenderten Output auf ein reines Hash-Fragment.

Test: Die Korrektur regrediert beim nächsten Deployment nicht unbemerkt

• Durchzuführender Test – Führen Sie die Prüfung des gerenderten HTML erneut aus (URL Inspection Live-Test oder Render Gap), nachdem Ihr nächster Deploy diese Seite betreffende Templates oder die Build-Pipeline verändert hat.
• Erwartetes Ergebnis – Dieselben Inhalte und Links sind weiterhin im gerenderten DOM vorhanden wie bei der ersten Bestätigung der Korrektur.
• Fehlerinterpretation – Wenn zuvor vorhandene Inhalte erneut verschwinden, hat eine spätere Änderung wahrscheinlich eine Client-only-Abhängigkeit wieder eingeführt oder einen serverseitig gerenderten Pfad beschädigt.
• Überwachungszeitraum – Überprüfen Sie nach jedem Deploy erneut, der die betroffenen Templates betrifft; keine einmalige Prüfung.
• Rollback-Auslöser – Inhalte oder Links, die als vorhanden bestätigt wurden, fallen erneut aus dem gerenderten DOM heraus.

Ressourcen, die Ihre Zeit wert sind

Meine weiteren Artikel

• JavaScript SEO: A Definitive Guide – mein vollständiger Leitfaden zu Rendering, Rendering-Modi, DOM-Parität, Infinite Scroll und dem Problem „zwei Seiten als eine“.
• The Beginner’s Guide to Technical SEO – wo Rendering zwischen Crawling und Indexierung einzuordnen ist.

Meine Vorträge

• How Search Works (SlideShare) – meine Erläuterung von Crawling, Rendering (dem WRS, zustandslosen Ladevorgängen, ohne Interaktion), Indexierung und Ranking. (Mein üblicher Hinweis gilt: „This is my understanding of systems… not going to be 100% complete or accurate.“)

Von anderen

• web.dev — Rendering on the Web – die maßgebliche Erklärung der CSR-/SSR-/SSG-/Hydration-Abwägungen vom Chrome-Team.
• Onely — Google’s Two Waves of Indexing – transkriptbasierte Abdeckung von Martin Splitts Office-Hours-Sitzung, die erklärt, warum das Zwei-Wellen-Modell an Bedeutung verliert; im Artikel zitiert.
• Search Engine Roundtable — Google: No Per-Page Search Cost – Google-Vertreter stellt klar, dass es keine Kosten pro Seite für Crawling/Rendering/Indexierung zu rationieren gibt.
• Search Engine Journal — JavaScript SEO – Branchenberichterstattung über JS-SEO-Best Practices, Test-Workflows und Framework-Überlegungen.
• Vercel — Rendering Strategies – Next.js-/Edge-Rendering-Dokumentation; nützlich bei der Wahl zwischen CSR, SSR, SSG, ISR und Streaming-SSR für ein reales Projekt.
• r/TechSEO – die Community zur Fehlersuche bei Render-/Index-Problemen.

Videos

• Google Search Central (YouTube) – Martin Splitts JavaScript SEO-Serie und die Rendering-Erklärungen sind die besten offiziellen Video-Walkthroughs dazu, wie der Web Rendering Service Ihr JS verarbeitet. Kanal

Statistiken, die sich zu zitieren lohnen

• Aktuelle offizielle Darstellung: keine feste Verzögerung. Googles Dokumentation besagt, dass eine gecrawlte Seite “may stay on this queue for a few seconds, but it can take longer than that” (Übersetzung) „möglicherweise einige Sekunden in dieser Warteschlange bleibt, aber es kann länger dauern“ — es gibt keine veröffentlichte feste Verzögerung oder Zeitüberschreitung für die Render-Warteschlange.
• Historischer Datenpunkt (veraltet) — ~5 Sekunden mediane Render-Verzögerung. In früheren Konferenzbemerkungen gaben Google-Mitarbeiter (Martin Splitt und Tom Greenaway) an, dass Seiten den Renderer mit einem Median von ~5 Sekunden erreichen, wobei das 90. Perzentil in Minuten liegt — nicht die „Wochen“, die die alte Zwei-Wellen-Befürchtung implizierte. Ich zitiere dies in meinem JavaScript-SEO-Leitfaden, behandle es jedoch als historischen Datenpunkt, nicht als aktuelle veröffentlichte Kennzahl — Google hat es nicht als laufende Zahl erneut veröffentlicht.
• Zwei Wellen der Indexierung verschwinden. Laut Martin Splitt spielt das Zwei-Wellen-Modell eine immer geringere Rolle, da Crawling, Rendering und Indexierung zusammenwachsen — Rendering findet jetzt im Wesentlichen für alle Seiten statt. Abdeckung
• Kein Render-Budget pro Seite. Google hat angedeutet, dass es nicht verfolgt, wie aufwendig eine einzelne Seite zu crawlen, zu rendern, zu indexieren oder auszuliefern ist — es gibt also kein „Render-Budget“, das man schonen müsste, so wie das Crawl-Budget diskutiert wird. Abdeckung

Testen Sie sich: Rendering

Fünf kurze Fragen dazu, wie Google Seiten rendert. Wählen Sie für jede eine Antwort und prüfen Sie dann.

Änderungsprotokoll