Dynamic Rendering
Dynamic Rendering ist eine Technik, bei der eine Website zwei Versionen jeder Seite ausliefert: einen vorgerenderten, statischen HTML-Schnappschuss für Suchmaschinen-Crawler und ein vollständiges JavaScript-Single-Page-App-Erlebnis für menschliche Nutzer. Google empfahl es 2018 öffentlich als Notlösung für JS-lastige Websites und stufte es bis 2024 still und leise zu einer "veralteten Notlösung" herab, als das JS-Rendering des Googlebot ausgereift war.
Dynamic Rendering ist eine Technik, bei der eine Website zwei Versionen jeder Seite ausliefert: einen vorgerenderten, statischen HTML-Schnappschuss für Suchmaschinen-Crawler und ein vollständiges JavaScript-Single-Page-App-Erlebnis für menschliche Nutzer. Google empfahl es 2018 öffentlich als Notlösung für JS-lastige Websites und stufte es bis 2024 still und leise zu einer "veralteten Notlösung" herab, als das JS-Rendering des Googlebot ausgereift war.
Warum es wichtig ist
JavaScript-lastige Websites lieferten früher leere HTML-Gerüste aus und vertrauten darauf, dass der Crawler das JS ausführt und den echten Inhalt sieht. Der Googlebot kam schließlich dorthin, aber langsam, oft erst Tage nach dem ersten HTML-Abruf, und andere Crawler (Bing, KI-Bots, Facebook-Vorschau) waren schlechter. Dynamic Rendering ermöglichte es SEO-Teams zu garantieren, dass Crawler sofort vollständig gerendertes HTML sehen, ohne die App neu zu schreiben. Für E-Commerce-Kataloge, JS-Dashboards und SPAs mit kritischen SEO-Anforderungen war es eine pragmatische Brücke. Es zu verstehen ist nach wie vor wichtig, da viele Websites heute noch mit Dynamic Rendering laufen und umsteigen müssen.
So funktioniert es
1. Anfrage trifft ein: Der Edge oder Server prüft den User-Agent.
2. Crawler-Erkennung: Wenn der User-Agent mit einem bekannten Suchbot übereinstimmt (Googlebot, Bingbot, Twitterbot, LinkedInBot, KI-Crawler), wird die Anfrage an einen Pre-Render-Dienst weitergeleitet. Andernfalls landet sie bei der normalen SPA.
3. Pre-Render-Dienst: Ein Headless-Chrome (oft über prerender.io, Rendertron, Puppeteer oder Playwright) ruft die Seite ab, wartet, bis das JS fertig ist, erfasst das DOM und liefert statisches HTML zurück.
4. Cache: Das gerenderte HTML wird zwischengespeichert, damit nachfolgende Crawler-Aufrufe kein erneutes Rendern auslösen.
5. Bot sieht HTML, Nutzer sieht SPA: Dieselbe URL, zwei Erlebnisse.
Warum es heute eine "veraltete Notlösung" ist
Googles Leitlinien von 2024 verschoben Dynamic Rendering von "empfohlen" zu "eine Notlösung und keine langfristige Lösung". Die Gründe:
Der Googlebot rendert JS inzwischen gut: Google betreibt ein aktuelles Headless-Chrome und verarbeitet JS auf den meisten Seiten schnell. Der ursprüngliche Grund für Dynamic Rendering ist für Google weitgehend entfallen.
Wartungsaufwand: Eine zweite Render-Pipeline parallel zu betreiben bedeutet einen betrieblichen Aufwand, der den Nutzen meist übersteigt.
Risiko der Abweichung: Wenn der Pre-Render-Dienst ausfällt oder veraltet, sehen Bots alten Inhalt und Nutzer neuen Inhalt, ein klassisches Cloaking-Signal.
Keine Cloaking-Strafe, aber nahe dran: Google sagt ausdrücklich, dass Dynamic Rendering kein Cloaking ist, doch eine Abweichung zwischen Bot- und Nutzeransicht kann eine manuelle Prüfung auslösen.
Modernes SSR/SSG ist besser: Next.js, Nuxt, SvelteKit, Astro und Remix liefern standardmäßig serverseitig gerenderte oder statisch generierte Seiten aus. Kein Dynamic Rendering nötig.
Wann (falls überhaupt) es noch sinnvoll ist
Veraltete SPAs, die Sie nicht neu schreiben können: Eine ausgereifte, JS-lastige App ohne Budget für eine SSR-Migration. Dynamic Rendering ist als Übergangslösung weiterhin tragfähig.
Nicht-Google-Crawler: KI-Crawler, Bing, Baidu und Nischen-Bots rendern JS nach wie vor schlechter als Google. Wenn diese für Ihren Traffic wichtig sind, kann Dynamic Rendering helfen.
Widgets und Einbettungen: Inhalte, die nach dem ersten HTML über JS geladen werden, manchmal die einzige Möglichkeit, sie für Crawler sichtbar zu machen.
Edge-Render-Notlösungen: Ein schlankes dynamisches Rendern am CDN-Edge, das die SPA im laufenden Betrieb in HTML umwandelt, ohne separaten Pre-Render-Dienst.
So steigen Sie vom Dynamic Rendering um
1. Prüfen Sie, was im JS tatsächlich fehlschlägt: Nutzen Sie die URL-Prüfung der Search Console und Rendering-Vergleiche. Viele "JS-SEO-Probleme" sind lediglich fehlendes SSR auf kritischen Seiten.
2. Verlagern Sie kritische Seiten auf SSR oder SSG: Startseite, Landingpages, Produkt- und Artikelseiten zuerst. Behalten Sie Dashboards und angemeldete Bereiche als SPA bei.
3. Verwenden Sie ein modernes Framework: Next.js, Nuxt und SvelteKit beherrschen hybrides Rendering von Haus aus.
4. Prüfen Sie die Übereinstimmung: Crawlen Sie nach der Migration die neue Website mit Screaming Frog und bestätigen Sie, dass das HTML dem entspricht, was der alte Pre-Render erzeugt hat.
5. Stellen Sie den Pre-Render-Dienst ein: Erst nach mehreren Wochen sauberer Abdeckungsberichte in der Search Console.
Häufige Fehler
Absichtlich unterschiedlichen Inhalt ausliefern: Dynamic Rendering bedeutet "gleicher Inhalt, andere Form". Unterschiedlicher Inhalt ist Cloaking und wird abgestraft.
Den Pre-Render-Cache nicht aktualisieren: Veraltete Pre-Renders liefern Bots alten Inhalt und ranken für das Produkt von gestern.
Sich für alles auf den Pre-Render verlassen: Einen Pre-Render vor eine Website ohne SSR-Strategie zu stellen bedeutet, dass Sie immer nur einen Ausfall von der Crawler-Blindheit entfernt sind.
Nicht-Googlebot-UA-Listen ignorieren: Bing, Yandex, Baidu und KI-Crawler haben alle unterschiedliche UAs. Wenn Sie einen vergessen, cloaken Sie sich vor diesem Bot.
Dynamic Rendering für neue Projekte verwenden: Tun Sie das nicht. Setzen Sie stattdessen auf SSR/SSG in einem modernen Framework.
Sources: