Dynamic Rendering: Was es auf einer JavaScript-Website löst (und was nicht)
Von Toy Wen Da, Mitgründer · Aktualisiert · 7 Min. Lesezeit
Übersetzt aus dem englischen Original. Auf Englisch lesen
Dynamic Rendering bedeutet: Ihr Server prüft, ob ein Besucher ein Browser oder ein Suchmaschinen-Bot ist. Bots erhalten dann eine vorgerenderte, statische HTML-Version der Seite, während Menschen das volle JavaScript-Erlebnis bekommen. Es hilft bei Websites, auf denen Googlebot Inhalte nicht lesen kann, die erst nach der Ausführung von Skripten erscheinen. Es löst aber nicht jedes Indexierungsproblem.
Bevor Sie Servercode anfassen, prüfen Sie, was Googlebot auf der betreffenden Seite sieht. Der kostenlose Googlebot Simulator ruft eine URL so ab wie der Crawler von Google und zeigt Ihnen das gerenderte HTML. So wissen Sie innerhalb einer Minute, ob Ihre JavaScript-Inhalte in dem fehlen, was der Bot erhält.
So funktioniert es
Den Besucher erkennen
Ihr Server oder eine CDN-Schicht davor prüft bei jeder Anfrage den User-Agent-Header. Entspricht der Header einem bekannten Crawler wie Googlebot oder Bingbot, oder zunehmend auch einem KI-Crawler, wird die Anfrage anders geleitet als die eines normalen Browsers.
Zwei Versionen derselben Seite ausliefern
Menschliche Besucher bekommen weiterhin Ihre React-, Vue- oder Angular-App mit der gesamten Interaktivität. Bots erhalten einen vorgerenderten HTML-Snapshot. Er wird von einem Headless-Browser-Tool wie Puppeteer oder Rendertron oder von einem Drittanbieter-Dienst wie Prerender.io erzeugt. Da der Snapshot statisch ist, muss kein Skript laufen, damit der Inhalt sichtbar wird.
Warum Websites das überhaupt brauchen
Googlebot kann JavaScript ausführen, doch das Rendern ist ressourcenintensiv und erfolgt zeitversetzt. Seiten werden deshalb oft einmal gecrawlt und erst später erneut gerendert, was die Indexierung verzögern kann. Die meisten KI-Antwortmaschinen führen JavaScript gar nicht erst aus. Eine Seite, die auf Client-seitiges Rendering angewiesen ist, ist für sie daher womöglich von Anfang an unsichtbar. Eine Seite, die nie indexiert wird, erzielt keinerlei Sichtbarkeit und überhaupt keine Klickrate, geschweige denn eine gute.
Das Problem in der eigenen Website beheben, Schritt für Schritt
- Stellen Sie sicher, dass es tatsächlich eine Lücke gibt: Rufen Sie die Seite als Bot ab und vergleichen Sie sie mit dem, was ein normaler Browser lädt. Stimmt der Inhalt überein, brauchen Sie nichts davon.
- Entscheiden Sie, ob das Problem ein Template, einen Bereich der Website oder alles betrifft. Dieser Umfang bestimmt, wie viel Infrastrukturarbeit auf Sie zukommt.
- Fügen Sie auf Server- oder CDN-Ebene eine User-Agent-Erkennung hinzu, zum Beispiel mit einem Cloudflare Worker oder einer Nginx-Regel, die eingehende Anfragen mit einer gepflegten Bot-Liste abgleicht.
- Leiten Sie den Bot-Traffic an einen Prerendering-Dienst weiter, der für jede URL statisches HTML erzeugt und zwischenspeichert, damit nicht bei jedem Bot-Besuch neu gerendert wird.
- Halten Sie die Inhalte gleichwertig: Die vorgerenderte Version muss dem entsprechen, was ein Mensch am Ende sieht, mit demselben Text, denselben Links und denselben strukturierten Daten.
- Testen Sie nach dem Launch und nach jedem Front-End-Deployment erneut, denn eine Änderung an der Oberfläche kann unbemerkt zerstören, was der Prerendering-Dienst erfasst.
- Überwachen Sie die Einrichtung laufend. Fällt der Rendering-Dienst aus, können Bots leere Seiten oder Fehler erhalten, was schnell zur Deindexierung führen kann.
Wann die eigenen Tools genügen und wann nicht
Eine einzelne Seite zu prüfen ist etwas anderes, als das Rendering einer ganzen Website zu reparieren.
| Situation | Was Sie prüfen | Passendes Tool | Reicht der kostenlose Weg? |
|---|---|---|---|
| Eine URL sieht für Sie gut aus, fehlt aber im Google-Index | Was Googlebot auf dieser Seite sieht | Googlebot Simulator | Ja, bestätigt oder widerlegt eine Rendering-Lücke in Minuten |
| Ganze Website auf React/Vue/Angular ohne Server-Rendering | Crawlbarkeit der gesamten Website | Ein vollständiger technischer Crawl plus ein Rendering-Audit | Nein, das ist eine Infrastrukturänderung und keine Prüfung einer einzelnen Seite |
| Das mobile Layout einer Seite wirkt neben dem Indexierungsproblem fehlerhaft | Mobiles Rendering, Viewport, Bedienbarkeit | Kostenloser Mobile-Friendly-Test | Ja, um den mobilen Teil des Problems zu diagnostizieren |
| Seiten waren problemlos indexiert und fielen nach einem Redesign heraus | Wiederkehrende Regression, kein Einzelfall | Laufendes Monitoring plus Überprüfung der Prerendering-Einrichtung | Nein, eine einzelne Prüfung erkennt kein Problem, das nach jedem Deployment erneut auftritt |
Eine einmalige Prüfung einer einzelnen URL ist genau das, wofür die kostenlosen Tools gemacht sind. Ein wiederkehrendes, websiteweites Muster deutet dagegen auf eine Infrastrukturlösung hin, meist mit einem Entwickler und einem Prerendering-Dienst.
Der Vergleich mit den Alternativen
| Ansatz | Funktionsweise | Geeignet für | Wartungsaufwand |
|---|---|---|---|
| Dynamic Rendering | Liefert statisches HTML an Bots, die JS-App an Menschen | JS-lastige Websites mit Crawl-Budget- oder KI-Sichtbarkeitsproblemen, die noch nicht komplett neu aufgebaut werden können | Hoch, eine separate Rendering-Pipeline muss gewartet werden |
| Server-Side Rendering (SSR) | Der Server rendert bei jeder Anfrage HTML, für alle | Neuentwicklungen oder Websites mit den Ressourcen, ihr Front End neu aufzubauen | Mittel, ein Rendering-Pfad für alle Besucher |
| Static Site Generation (SSG) | HTML wird im Voraus beim Deployment erzeugt | Inhalte, die sich nicht pro Anfrage ändern, etwa Blogs oder Marketingseiten | Niedrig, Neuaufbau bei Inhaltsänderung |
| Client-seitiges Rendering (keine Lösung) | Der Browser baut die Seite aus JavaScript auf, Bots erhalten dasselbe | Interne Tools, keine öffentlichen, für die Suche bestimmten Seiten | Geringer Aufwand, hohes Suchrisiko |
Googles eigene Empfehlung beschreibt die Technik als Notlösung und nicht als Ziel. SSR oder SSG sind die dauerhafteren Lösungen, sobald Sie sich den Neuaufbau leisten können.
Gilt es als Cloaking?
Nein, solange Sie es in gutem Glauben einsetzen. In der Dokumentation von Google Search Central heißt es, dass Googlebot es in der Regel nicht als Cloaking behandelt, sofern der an Bots ausgelieferte gerenderte Inhalt dem entspricht, was menschliche Besucher am Ende sehen. Der Verstoß liegt nicht darin, dass zwei Versionen existieren, sondern darin, dass Bots und Menschen wirklich unterschiedliche Inhalte sehen, etwa eine mit Keywords überladene Seite über Laufschuhe für Crawler, während Besucher eine Seite zu einem ganz anderen Thema sehen. Halten Sie den Inhalt in beiden Versionen gleich, und Sie bewegen sich innerhalb der Regeln.
Häufige Fehler
- Es als Dauerlösung zu behandeln, obwohl es ein Crawlbarkeitsproblem nur überdeckt und die irgendwann nötige, besser crawlbare Architektur nicht ersetzt.
- Den Prerendering-Dienst veralten zu lassen, sodass Bots eine überholte oder defekte Version der Seite sehen, sobald er eine Front-End-Änderung verpasst.
- Sich auf eine lückenhafte Bot-Liste zu verlassen: Die User-Agent-Erkennung funktioniert nur für Bots, die Sie aufgelistet haben, und ein neuer KI-Crawler, den Ihre Regeln nicht erkennen, bekommt die rohe JavaScript-Version, die er vermutlich nicht lesen kann.
- Nach Deployments nicht erneut zu testen, obwohl ein Front-End-Release, den niemand gegen die Bot-Version geprüft hat, der häufigste Grund dafür ist, dass eine solche Einrichtung unbemerkt kaputtgeht.
- Es auf einer Website einzusetzen, die es nicht braucht, denn kleine, überwiegend statische Websites haben selten ein Rendering-Problem, das so viel Infrastruktur rechtfertigt.
FAQ
Schadet Dynamic Rendering meinen Rankings?
Nicht von sich aus. Das Risiko liegt in einer falsch konfigurierten Version, die veraltete Seiten oder Fehler ausliefert und sich von dem entfernt, was menschliche Besucher sehen.
Ist Dynamic Rendering dasselbe wie Cloaking?
Nein. Cloaking bedeutet, Bots und Menschen inhaltlich unterschiedliche Inhalte auszuliefern. Dynamic Rendering liefert denselben Inhalt in einem anderen Format, was Suchmaschinen ausdrücklich erlauben.
Woran erkenne ich, ob meine Website Dynamic Rendering überhaupt braucht?
Rufen Sie eine Seite als Googlebot ab und vergleichen Sie sie mit der Browser-Version. Fehlen Ihre Hauptinhalte und Links in der Ansicht des Bots, haben Sie Ihr Signal.
Was ist die langfristige Alternative zu Dynamic Rendering?
Server-Side Rendering oder Static Site Generation. Beide liefern allen dasselbe gerenderte HTML aus, statt zwei getrennte Pfade zu pflegen.
Können kleine Unternehmenswebsites Dynamic Rendering komplett ignorieren?
In der Regel ja. Es ist vor allem für große, JavaScript-lastige Websites mit häufigen Inhaltsänderungen oder Crawl-Budget-Einschränkungen relevant, nicht für eine typische kleine Website mit Standard-Seitenvorlagen.
Prüfen Sie Ihre Seite, bevor Sie etwas bauen
Beginnen Sie nicht aus einem Bauchgefühl heraus mit dem Aufbau einer Prerendering-Pipeline. Rufen Sie die betreffende Seite ab, sehen Sie nach, was Googlebot erhält, und investieren Sie nur dann in die Infrastruktur, wenn es wirklich eine Lücke zwischen dem gibt, was Bots und Menschen sehen. Wenn Sie eine zweite Meinung dazu möchten, was Ihre Indexierung ausbremst, sprechen Sie mit dem Team und fordern Sie einen Beispiel-SEO-Report an.
Quellen
Über den Autor
SearchBlueprint hat diesen Artikel mit der Content-Pipeline recherchiert, geschrieben und bewertet, die unsere Kunden auf ihren eigenen Websites einsetzen. Die Bewertung in der Autorenzeile ist die, die unsere Content-Engine dieser Seite vor der Veröffentlichung gegeben hat. Nichts davon wird von Hand geprüft, und genau das ist der Punkt: Es ist das Ergebnis des Produkts, veröffentlicht dort, wo jeder es nachprüfen kann.