SSR vs. CSR (Server-/Client-Side Rendering)

SSR vs. CSR — ausführlicher erklärt

Bei Server-Side Rendering liefert der Server bei jedem Request bereits vollständiges HTML aus — Suchmaschinen-Crawler und Nutzer sehen sofort den Inhalt, JavaScript ist optional zum Aufwerten. Bei Client-Side Rendering schickt der Server eine fast leere HTML-Hülle plus JavaScript-Bundle; der Browser holt Daten per API und rendert die Seite erst clientseitig zusammen. Klassisches CSR-Beispiel: Single-Page-Apps in React/Vue ohne SSR-Layer.

Für SEO ist SSR meist die sicherere Wahl: Inhalt steht direkt im initialen HTML, LCP ist niedriger, kein Risiko, dass JS-Rendering bei Bots fehlschlägt. CSR ist trotzdem berechtigt für stark interaktive Apps hinter Login.

Beispiel / Praxisbezug

Astro, Next.js und Nuxt produzieren standardmäßig SSR oder Static-Output — Inhalte sind beim ersten Byte da. Eine reine React-SPA ohne SSR-Layer braucht dagegen mehrere Sekunden, bis Crawler sinnvolle Inhalte sehen.

Abgrenzung zu ähnlichen Begriffen

SSG (Static Site Generation) ist SSR-Variante: HTML wird beim Build vorgeneriert statt pro Request. Hydration ist die Ergänzung zu SSR: das ausgelieferte statische HTML wird im Browser nachträglich „lebendig” gemacht.

Entdecke mehr

Glossar

Hydration

Der Prozess, bei dem ein vom Server gerendertes statisches HTML im Browser nachträglich mit JavaScript-Interaktivität versehen wird — aus „totem" Markup wird eine reaktive App.

Lexikon

Technisches SEO — was Google wirklich crawlen, rendern und indexieren muss

Wie Crawl-Budget, Robots, Sitemap, JS-Rendering, Indexierung, Canonical und Core Web Vitals zusammenspielen — der vollständige Bogen für produktive Sites.

News

Google Search Central Live Toronto 2026 — was Google offiziell zur Zukunft der Suche sagt

Information Gain als neues Leitbild, Google-Extended klar eingeordnet, AI Mode mit 93 % Zero-Click. Die wichtigsten Aussagen aus Toronto.

Themenuebersicht

Technisches SEOJavaScript SEO