SSR erklärt — Server-Side Rendering und KI-Sichtbarkeit

Direkte Antwort

SSR: Server-Side Rendering heißt, dass der Server für jede Anfrage das komplette HTML einer Seite erzeugt und ausliefert, statt dem Browser ein leeres Gerüst zu schicken. Der Inhalt steht damit schon im ersten Response — für Besucher sichtbar, für Suchmaschinen und KI-Crawler lesbar. Praktisch heißt das: Wenn deine Seite von Nutzer, Cookies oder Live-Daten abhängt, ist SSR der saubere Weg; für gleichbleibende Inhalte reicht oft statisches Rendering.

Wichtigste Punkte

SSR liefert fertiges HTML pro Anfrage; der Browser macht es anschließend per Hydration interaktiv.
Besser als reines Client-Rendering für Crawling, KI-Extraktion und die erste Darstellung.
Kostet Serverleistung und braucht Caching; gleichbleibende Seiten sind per SSG günstiger.
SSR für Personalisierung und Live-Daten, SSG/ISR für gemeinsame Marketing-Inhalte.

— Steve Baka

Aktualisiert: 6. Oktober 2026 · Autor: Steve Baka

Was ist SSR?

Server-Side Rendering bezeichnet das Erzeugen von HTML auf dem Server. Wenn ein Browser eine URL anfragt, führt der Server die Anwendungslogik aus, lädt die benötigten Daten, setzt daraus das HTML zusammen und schickt das fertige Dokument zurück. Das ist keine neue Idee: Klassische PHP-, Ruby- oder Java-Seiten arbeiten seit jeher so. Neu ist die moderne Variante mit JavaScript-Frameworks, die denselben Komponentencode auf dem Server und im Browser verwenden können.

Dem gegenüber steht Client-Side Rendering (CSR). Dort liefert der Server ein fast leeres HTML-Dokument mit einem JavaScript-Bündel aus. Erst der Browser lädt das Skript, ruft Daten ab und baut die Oberfläche auf. Die Folge: Bis das Skript läuft, sieht der Nutzer nichts, und Crawler, die kein JavaScript ausführen, sehen auch nichts.

SSR löst dieses Problem. Das gelieferte HTML enthält Überschriften, Text, Links und strukturierte Daten bereits im Quelltext. Anschließend lädt der Browser das JavaScript nach und „hydriert“ die Seite, damit Buttons, Formulare und Menüs reagieren — dieser Schritt heißt Hydration.

Wie funktioniert SSR im Request-Pfad?

Der Browser oder Crawler fordert https://beispiel.de/leistung an.
Der Server startet das Rendering der passenden Route und holt Daten aus CMS, Datenbank oder API.
Er erzeugt das vollständige HTML samt Meta-Tags und JSON-LD.
Die Antwort geht mit dem passenden Statuscode — 200, 301 oder 404 — zurück.
Der Browser zeigt den Inhalt an und lädt nur das JavaScript nach, das für Interaktion nötig ist.

Weil jede Anfrage Rechenzeit kostet, ist Caching wichtig. Antworten, die für viele Nutzer identisch sind, lassen sich am Edge zwischenspeichern; sie werden dann wie statische Seiten ausgeliefert. Modelle wie Edge-Rendering und ISR verwischen die Grenze zwischen SSR und statischer Auslieferung bewusst. Hier ergänzt ein CDN die Rendering-Strategie.

Warum ist SSR für Suche und KI wichtig?

Googles Crawler kann JavaScript ausführen, tut das aber in einem zweiten, zeitversetzten Schritt und mit Ressourcengrenzen. Viele andere Bots — darunter ein großer Teil der KI-Crawler — führen JavaScript gar nicht aus. Sie lesen, was im ersten Response steht. Ohne serverseitiges HTML fehlen ihnen Texte, Preise, FAQ und Schema-Markup; deine Seite existiert für sie praktisch nicht. Darauf baut die Extrahierbarkeit auf: Antwortsysteme zitieren nur, was sie sauber aus dem Dokument ziehen können.

Dazu kommt der Performance-Effekt. Wenn der größte Inhaltsblock schon im HTML steht, verbessert sich der LCP, weil nicht erst Skripte laden und rendern müssen. Auch korrekte Statuscodes — echte 404 statt Soft-404 — gehören zu SSR.

Wann lohnt sich SSR, wann nicht?

Sinnvoll: Kundenbereiche, Seiten mit personalisierten Inhalten, Preise oder Verfügbarkeiten in Echtzeit, Inhalte mit Cookie- oder Geo-Abhängigkeit, Berichte, die pro Token anders aussehen.

Überdimensioniert: Klassische Marketing-, Themen- und Glossarseiten. Sie ändern sich selten und sehen für alle gleich aus. Hier ist SSG günstiger, schneller und robuster.

Gefährlich: Reines Client-Rendering für Inhalte, die gefunden und zitiert werden sollen.

Wie setzt Modern Stack SSR ein?

Wir kombinieren die Modelle pro Route mit Next.js. Öffentliche Inhaltsseiten sind statisch oder per ISR erzeugt, dynamische Bereiche laufen serverseitig. In beiden Fällen kommt vollständiges HTML an, inklusive JSON-LD, korrekter Canonicals und Statuscodes. Zusätzlich liefern Inhaltsseiten bei Accept: text/markdown eine Markdown-Variante aus, siehe Markdown-Negotiation. Wer von einer pagebuilder-lastigen WordPress-Webseite kommt, merkt den Unterschied vor allem an Ladezeit und an Seiten, die endlich auch ohne Skript lesbar sind. Die Entscheidungslogik dahinter beschreibt SSR/SSG-Stack; den Überblick gibt Webarchitektur im KI-Zeitalter.

Quellen

web.dev — Rendering on the Web — Google web.dev
Vergleicht Server-, statisches und Client-Rendering inklusive Trade-offs.
Google — JavaScript SEO basics — Google Search Central
Erläutert, wie Google JavaScript rendert und warum serverseitiges HTML robuster ist.
Next.js — Documentation — Next.js
Herstellerdokumentation zu Server Components, Rendering und Caching.
SSR/SSG-Stack — Modern Stack
Praxis, wie wir Rendering-Modelle für Marketing-Webseiten kombinieren.

Häufige Fragen

Wann nehme ich SSR, wann SSG?

Inhalte, die für alle gleich sind und sich selten ändern, rendern wir statisch (SSG) oder mit ISR. SSR nehmen wir, wenn das HTML vom Nutzer, von Cookies oder von Live-Daten abhängt. In beiden Fällen kommt fertiges HTML beim Client an.

Ist SSR gleichbedeutend mit Next.js?

Nein. Next.js ist ein Framework, das SSR bequem macht. Das Prinzip gibt es seit den Anfängen des Webs — klassische PHP-Seiten sind auch servergerendert. Entscheidend ist, dass das HTML fertig und sauber ankommt.

Reicht Google, JavaScript auszuführen — brauche ich SSR dann überhaupt?

Google rendert JavaScript, aber zeitversetzt und mit Grenzen. Viele KI-Crawler führen gar kein JavaScript aus. Wer Inhalte nur clientseitig erzeugt, riskiert Lücken in Index und KI-Antworten.

Weiterlesen

SSR/SSG-Stack
Warum servergerendertes und statisch generiertes HTML die Basis für Performance, Crawlability und KI-Extraktion ist — und warum eine reine React-SPA für Marketingseiten meist nicht reicht.
Webseite-Modernisierung
Was Webseite-Modernisierung bei Modern Stack bedeutet: bestehende WordPress- und Baukasten-Webseiten auf einen modernen Web-Stack bringen — Inhalte behalten, Technik erneuern, bereit für Google und KI-Suche.
SSG
SSG (Static Site Generation) erzeugt das fertige HTML jeder Seite einmal beim Build, nicht bei jedem Aufruf. Die Dateien lassen sich über ein CDN ausliefern — schnell, robust und für Crawler direkt lesbar.
Next.js
Next.js ist ein React-Framework von Vercel für Webanwendungen und Unternehmensseiten. Es rendert Seiten auf dem Server oder vorab (SSR, SSG, ISR) und liefert fertiges HTML — gut für Geschwindigkeit, Suche und KI.
Crawlability
Crawlability beschreibt, ob Suchmaschinen-Crawler und KI-Assistenten deine Inhalte erreichen und lesen dürfen und können. Gesperrte Bots, fehlerhafte Statuscodes, Soft-404 und leere JavaScript-Hüllen verhindern sie.
Hydration
Hydration ist der Schritt, in dem der Browser vorgerendertes HTML mit JavaScript verbindet und interaktiv macht. Zu viel Hydration bedeutet schweres JavaScript, träge Reaktion (INP) und unnötigen Ballast.
Edge Rendering
Edge-Rendering führt das Erzeugen von HTML oder API-Antworten auf Servern nah am Nutzer aus, statt zentral in einem Rechenzentrum. Es senkt Latenz für dynamische Antworten und ergänzt das CDN, das statische Dateien ausliefert.
Headless CMS
Ein Headless CMS verwaltet Inhalte ohne eigene Darstellungsschicht und liefert sie per API an beliebige Frontends wie Next.js. Das bringt Flexibilität und schlankes HTML, verlangt aber mehr Integrationsarbeit als ein klassisches CMS.
LCP
LCP (Largest Contentful Paint) ist eine der drei Core Web Vitals. Die Metrik misst die Zeit, bis das größte sichtbare Element im Viewport gerendert ist; gut sind höchstens 2,5 Sekunden.
Extrahierbarkeit
Extrahierbarkeit beschreibt, wie zuverlässig sich Fakten aus einer Webseite herauslösen lassen — durch Menschen, Crawler und KI-Modelle. Sauberes HTML, klare Überschriften und eigenständige Antwortabschnitte erhöhen sie; Layout-Ballast und JavaScript-Hüllen senken sie.
CDN
Ein CDN (Content Delivery Network) ist ein verteiltes Netz aus Cache-Servern (PoPs), das statische und oft auch gerenderte Dateien geografisch nah am Nutzer ausliefert — statt alles vom Origin-Server zu ziehen.
Core Web Vitals
Core Web Vitals sind Googles drei Nutzererlebnis-Kennzahlen: LCP (Ladezeit des größten Elements), INP (Reaktionszeit auf Eingaben) und CLS (visuelle Stabilität). Sie fließen in die Suche ein und zeigen Timeout- und Abbruchrisiken auch für KI-Crawler.
Markdown-Negotiation
Bei Markdown-Negotiation liefert ein Server unter derselben URL HTML oder Markdown, je nachdem, was der Client im Accept-Header anfordert. KI-Agenten erhalten so reinen Text mit Struktur, Menschen weiterhin die normale Seite.
WordPress im KI-Zeitalter — 10 Gründe, warum der Monolith nicht mehr zeitgemäß ist
WordPress und Baukästen wurden für Dokumente gebaut — nicht für Token-Streaming, Agenten, RAG und Generative UI. Zehn strukturelle Gründe und der Wechsel zu Next.js, Convex, SurrealDB und dem Vercel AI SDK.
Webarchitektur im KI-Zeitalter — vom CMS-Monolithen zum reaktiven Full-Stack
Warum WordPress, Wix, Jimdo und Squarespace an Streaming, RAG und agentischen Workflows scheitern — und wie Next.js, Convex, SurrealDB, Resend und Vercel ein KI-taugliches Ökosystem bilden.