Dynamic Rendering war eine Zeit lang die übliche Antwort auf eine schwierige Frage: Wie bekommt man eine Website, die ihren Inhalt erst per JavaScript im Browser aufbaut, sauber in die Suche? Der Server erkannte Crawler und gab ihnen fertiges HTML, Besucher bekamen die normale Anwendung. Google hat seine Einschätzung inzwischen deutlich formuliert. Die Seite dazu heißt "Dynamisches Rendering als Behelfslösung", und dort steht: "Dynamisches Rendering war eine Behelfslösung und keine langfristige Lösung" [1]. Dieser Ratgeber erklärt, wie das Verfahren arbeitet, wo die Grenze zum Cloaking liegt und wie Sie eine bestehende Lösung ablösen.
So funktioniert die Weiche
Der Ablauf besteht aus zwei Teilen. Zuerst muss der Webserver Crawler erkennen, zum Beispiel am User-Agent einer Anfrage [1]. Anfragen von Bots, die möglicherweise Probleme mit per JavaScript erzeugten Inhalten haben, gehen dann an einen Rendering-Server. Der führt das JavaScript aus und antwortet mit einer für den Crawler geeigneten Fassung, etwa statischem HTML [1]. Besucher und Crawler ohne Schwierigkeiten mit JavaScript bekommen die normale Antwort [1].
Google beschreibt auch, für welche Fälle das Verfahren gedacht war: für indexierbare, öffentliche Inhalte, die per JavaScript entstehen und sich schnell ändern, und für JavaScript-Funktionen, die von bevorzugten Crawlern nicht unterstützt werden [1]. Den ersten Fall beschreibt Google inzwischen in der Vergangenheitsform.
Warum Google davon abrät
Google begründet die Abkehr knapp: Dynamisches Rendering sei keine empfohlene Lösung, "weil es zusätzliche Komplexitäten und Ressourcenanforderungen verursacht" [1]. In der Praxis bedeutet das: Sie betreiben zwei Auslieferungswege für dieselben Inhalte. Jede Änderung am Frontend muss in beiden ankommen, der Rendering-Server braucht Rechenleistung, und Fehler zeigen sich oft nur in der Fassung, die kein Mensch sieht.
Hinzu kommt, dass Google selbst JavaScript ausführt. Seiten werden mit einer aktuellen Chrome-Version gerendert [2]. Jede Seite mit dem Statuscode 200 geht in die Warteschlange für das Rendering, auch wenn der Abstand zwischen Abruf und Rendering länger sein kann [3]. Der ursprüngliche Grund für die Weiche, dass Google JavaScript nicht verarbeitet, trägt bei Google also nicht mehr. Für andere Crawler müssen Sie das im Einzelfall prüfen, Google macht dazu keine Angaben.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Die Grenze zum Cloaking
Wer Crawlern etwas anderes zeigt als Besuchern, bewegt sich nahe an einem Spamverstoß. Google zieht die Grenze bei der Ähnlichkeit der Inhalte: Erzeugt das dynamische Rendering ähnliche Inhalte, geht der Googlebot nicht von Cloaking aus [1]. Als Gegenbeispiel nennt Google eine Seite, die Besuchern Katzen und Crawlern Hunde zeigt. Das gilt als Cloaking [1]. Was Google darunter versteht, erklärt das Glossar unter Cloaking.
Eine Sonderregel betrifft Fehlerseiten. Entstehen beim Einrichten des dynamischen Renderings Fehlerseiten, behandelt der Googlebot sie wie jede andere Fehlerseite und wertet sie nicht als Cloaking [1]. Der Schaden bleibt trotzdem: Bekommt der Crawler eine Fehlerseite, fehlt die eigentliche Seite im Index.
Was Sie an einer bestehenden Lösung prüfen
Ob Ihre Website überhaupt eine Weiche nutzt, ist nicht immer bekannt, gerade wenn eine Agentur oder ein Plugin sie eingerichtet hat. Hinweise geben Regeln in der Serverkonfiguration, die Anfragen nach dem User-Agent umleiten, ein vorgeschalteter Dienst für das Vorrendern im Vertrag mit dem Hoster oder Abrufe in den Serverprotokollen, die nur bei Crawler-Anfragen auftreten. Fragen Sie im Zweifel beim Dienstleister nach, der das Frontend betreut. Wie Sie Crawler in den Protokollen zuverlässig erkennen, beschreibt der Ratgeber Server-Logs auswerten.
Viele Websites haben die Weiche vor Jahren eingerichtet und seitdem nicht mehr angefasst. Bevor Sie sie abbauen, sollten Sie wissen, was sie heute ausliefert. Das URL-Prüftool der Search Console hilft dabei. Ein Live-Test ruft die Adresse in Echtzeit ab und zeigt die HTTP-Antwort und den zurückgegebenen HTML-Code. Screenshots der gerenderten Seite gibt es nur im Live-Test [4]. Vergleichen Sie dieses Ergebnis mit dem, was Sie im Browser sehen.
Dabei lohnen vier Fragen. Stimmen Überschriften, Text und Produktdaten überein? Sind die Links in der Crawler-Fassung normale a-Elemente mit href-Attribut? Nur solche Links findet Google zuverlässig [3]. Liefert die Crawler-Fassung bei gelöschten Seiten einen echten Fehlercode, oder entsteht ein Soft 404? Und steht in einer der beiden Fassungen ein noindex, das in der anderen fehlt? Steht noindex im ursprünglichen Code, überspringt Google das Rendering möglicherweise ganz [3].
Die Alternativen, die Google empfiehlt
Google nennt drei Wege: serverseitiges Rendering, statisches Rendering und Hydration [1]. Allen gemeinsam ist, dass Besucher und Crawler dasselbe HTML bekommen und es keine Weiche mehr gibt.
| Verfahren | Wie es arbeitet | Passt zu |
|---|---|---|
| Serverseitiges Rendering | Der Server erzeugt das HTML bei jeder Anfrage. | Inhalten, die sich oft ändern oder personalisiert sind |
| Statisches Rendering | Das HTML entsteht vorab beim Bau der Website. | Inhalten, die sich selten ändern, etwa Ratgeber und Produktbeschreibungen |
| Hydration | Der Server liefert fertiges HTML, das JavaScript übernimmt danach die Interaktion im Browser. | Anwendungen, die schnell sichtbar und danach interaktiv sein sollen |
Auch in den allgemeinen Grundlagen zu JavaScript nennt Google serverseitiges Rendering oder Pre-Rendering eine sehr gute Option, weil die Website dadurch für Nutzer und Crawler schneller wird [3]. Die Unterschiede der Ansätze beschreibt der Ratgeber Client-Side oder Server-Side Rendering, den Begriff das Glossar unter Server-Side Rendering.
Den Abschied planen
Ein Umstieg ist ein Eingriff in die Auslieferung und sollte wie ein kleiner Relaunch behandelt werden. Bewährt hat sich bei uns dieses Vorgehen: Zuerst eine Liste typischer Adressen je Seitentyp anlegen und für jede die heutige Crawler-Fassung sichern. Dann das neue Rendering in einer Testumgebung aufbauen und dieselben Adressen vergleichen. Erst wenn Inhalte, Links, Statuscodes und Metaangaben übereinstimmen, wird die Weiche abgeschaltet.
Ein Punkt verdient beim Umstieg besondere Aufmerksamkeit: die Statuscodes in Anwendungen, die im Browser zwischen Seiten wechseln. Dort entsteht leicht ein Soft 404, also eine Fehlerseite mit dem Code 200. Google nennt zwei Auswege. Entweder leitet das JavaScript auf eine Adresse um, für die der Server mit 404 antwortet, oder es setzt auf Fehlerseiten ein robots-Meta-Tag mit noindex [3]. Prüfen Sie das besonders sorgfältig, wenn bisher der Rendering-Server die Fehlercodes für Crawler geliefert hat.
Danach beobachten Sie zwei Dinge. Im Bericht Crawling-Statistik der Search Console sollte die Reaktionszeit nicht sprunghaft steigen, denn serverseitiges Rendering kostet Rechenzeit bei jeder Anfrage. Und im Bericht zur Seitenindexierung sollten keine neuen Gruppen nicht indexierter Seiten auftauchen. Wie Sie den ersten Bericht lesen, steht im Ratgeber Crawling-Statistiken der Search Console lesen. Die Grundlagen zu JavaScript und Suche fasst der Ratgeber JavaScript SEO Grundlagen zusammen.
Wenn der Umbau größer wird, begleitet SEO NW ihn im Rahmen der Leistung Technisches SEO. Für die erste Einschätzung, ob Ihre Website die Weiche überhaupt noch braucht, stellen Sie die Frage in der gratis Sprechstunde.
- Organisation Dynamisches Rendering als Behelfslösung. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation Umfassender Leitfaden zur Funktionsweise der Google Suche. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation URL-Prüftool. Search Console-Hilfe. Stand laufend. abgerufen am 31.10.2026
Häufige Fragen
Ist dynamisches Rendering Cloaking?
Nicht, solange die Crawler-Fassung ähnliche Inhalte zeigt wie die Fassung für Besucher. Zeigt sie etwas ganz anderes, wertet Google das als Cloaking. Fehlerseiten, die beim Einrichten entstehen, gelten nicht als Cloaking.
Muss ich eine bestehende Lösung sofort abschalten?
Google nennt das Verfahren eine Behelfslösung und empfiehlt Alternativen, setzt aber keine Frist. Planen Sie den Umstieg und prüfen Sie bis dahin regelmäßig, ob beide Fassungen übereinstimmen.
Rendert Google JavaScript überhaupt selbst?
Ja. Google rendert Seiten mit einer aktuellen Chrome-Version. Zwischen Abruf und Rendering kann aber Zeit vergehen, und Inhalte im ausgelieferten HTML sind deshalb früher verfügbar.
Was ist besser: serverseitiges oder statisches Rendering?
Das hängt davon ab, wie oft sich Inhalte ändern. Statisch erzeugtes HTML passt zu Inhalten, die selten wechseln, serverseitiges Rendering zu Seiten, die bei jeder Anfrage aktuell sein müssen. Beide liefern Besuchern und Crawlern dasselbe.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
