SSR/SSG-Stack — SSG, SSR, ISR für KMU

Rendering ist keine Geschmacksfrage, sondern die Weichenstellung zwischen Origin-Last, Cache-Hit-Rate und Maschinenlesbarkeit. Klassische KMU-Webseiten — Leistungen, Standort, Referenzen, FAQ, Anfrage — brauchen selten personalisiertes HTML pro Besucher. Solche Seiten brauchen deterministisches Markup, das in Millisekunden vom Edge kommt und ohne JavaScript-Boot lesbar ist. Dieser Beitrag liefert die Entscheidungsarchitektur: SSG vs. SSR vs. ISR, den Unterschied zu PHP-pro-Request, Edge-Caching, Anti-Patterns und den Bezug zu LCP sowie GEO-Crawl-Timeouts — eingebettet in Webseite-Modernisierung und den typischen Cutover über WordPress-Migration.

Was bedeutet SSR/SSG-Stack konkret — und was nicht?

Antwort zuerst: SSR/SSG-Stack heißt HTML-first Delivery mit klarer Routing-Strategie — nicht „wir nutzen React“ und nicht „alles muss serverseitig neu berechnet werden“.

Static Site Generation (SSG) erzeugt HTML zur Build-Zeit. Der CDN-/Edge-Knoten liefert Dateien oder gecachte Responses; der Origin bleibt für Marketingrouten oft unberührt. Server-Side Rendering (SSR) berechnet HTML beim Request (Node/Edge-Runtime), wenn Cookies, Auth, A/B oder Live-Daten den Markup-Inhalt binden. Incremental Static Regeneration und On-Demand-Revalidation halten eine statische Basis und invalidieren gezielt — siehe Next.js Caching & Revalidating.

Was der Stack nicht ist: Ersatz für Inhalte, Schema oder Conversion. Er ist die Auslieferungsschicht. Ohne answer-first Texte und strukturierte Daten bleibt die Maschinenschicht dünn — der Stack verhindert nur, dass Crawler und Extraktoren vor leeren Shells stehen.

Entscheidungsmatrix: SSG vs. SSR vs. ISR für KMU-Webseiten

Antwort zuerst: Wähle pro Route nach Änderungsfrequenz und Request-Bindung — nicht ein globales Dogma für die Domain.

Praxisregel bei Modern Stack: öffentliche Marketingrouten defaulten auf SSG; Redaktionsflächen mit mittlerer Frequenz auf ISR; SSR nur mit dokumentiertem Request-Grund. Next.js erlaubt diese Mischung pro Route — du musst die Domain nicht in ein einziges Rendering-Modell zwingen (Server & Client Components).

Mini-Entscheidungsbaum

1. Muss der HTML-Text vom aktuellen Request (Cookie, Rolle, Live-DB-Zeile) abhängen? → SSR (oder personalisierte Client-Insel).
2. Ändert sich der Inhalt nur bei Deploy/Redaktion? → SSG.
3. Ändert sich der Inhalt öfter als Deploys, aber nicht pro Besucher? → ISR / On-Demand-Revalidation.
4. Braucht nur ein Widget Live-Daten? → SSG-Shell + hydrierte Insel, nicht SSR der ganzen Seite.

Warum unterscheidet sich PHP-pro-Request fundamental?

Antwort zuerst: PHP-pro-Request rekonstruiert die Seite auf dem Origin; SSG/ISR liefern vorberechnetes oder invalidierbares HTML vom Edge — Caching kaschiert PHP, ersetzt die Architektur aber nicht.

Klassisches WordPress (und viele PHP-CMS) führen pro Treffer Bootstrap, Plugin-Hooks, Theme-Templates und MySQL-Queries aus, bevor HTML entsteht. Page-Cache-Plugins und Reverse Proxies können den HTML-Snapshot speichern — dann ähnelt das Ergebnis oberflächlich SSG. Der Unterschied bleibt strukturell:

• Schuld und Angriffsfläche: PHP, Themes und Plugins bleiben öffentlich erreichbar; Cache-Misses treffen wieder den vollen Stack.
• Determinismus: Plugin-Reihenfolge, Conditional Tags und Shortcodes erzeugen Markup-Varianz; Extraktoren sehen Rauschen.
• Invalidierung: Cache-Purges sind oft grob oder plugin-abhängig; Next.js-Revalidation adressiert Routen und Tags gezielt.
• Skalierung: Spitzenlast skaliert PHP-Worker und DB vertikal; Edge-HTML skaliert horizontal über CDN.

Deshalb ist „WordPress mit starkem Cache“ kein Äquivalent zu einem SSR/SSG-Stack. Es ist ein Monolith mit Pflaster. Der Migrationspfad — Inhalte behalten, fragile Schicht tauschen — ist in WordPress-Migration beschrieben. PHP-pro-Request erklärt auch, warum typische LCP-Werte trotz Optimierungsplugins im Bereich 2,5–4,0 s bleiben: der Origin-Pfad und das Asset-Chaos der Themes bleiben dominant.

Wie funktioniert Edge-Caching mit SSR, SSG und Revalidation?

Antwort zuerst: Edge-Caching speichert fertige Responses nah am Nutzer; SSG ist „immer cachebar“, ISR invalidiert gezielt, SSR ist nur cachebar, wenn du bewusst Cache-Control und Varianten setzt.

Bei SSG liegt der Idealfall vor: unveränderliche HTML-Responses mit langer TTL, global repliziert. ISR speichert dieselbe Art Response, hängt aber eine Revalidate-Semantik an — nach Zeit oder On-Demand-Tag wird die Route neu gebaut und der Edge aktualisiert (Next.js Caching). SSR ohne Cache-Header trifft den Origin bei jedem Request; mit sorgfältigen Cache-Control- und Vary-Regeln kannst du öffentlich cachebare SSR-Responses erzeugen — das nähert sich ISR an und sollte bewusst als solche modelliert werden, nicht als Zufall.

Edge-Rendering verkürzt Latenz für den Rest, der wirklich berechnet werden muss (Auth-Gates, Geo-Flags, A/B). Es ersetzt nicht die Entscheidung „HTML zuerst“. Betrieb und Plattformwahl nach Cutover: Hosting nach Migration.

Anti-Pattern: SSR „für Frische“, dann aggressives CDN davor — ohne Invalidierungsmodell. Dann liefern Edge-Knoten veraltete personalisierte oder halb-dynamische Seiten. Besser: klare Trennung von öffentlichen, lang cachebaren Routen und privaten, nie geteilten Responses.

Wann solltest du nicht alles per SSR ausliefern?

Antwort zuerst: SSR ohne Request-Bindung ist teure Default-Faulheit — sie senkt Cache-Hits, erhöht TTFB-Risiko und skaliert schlechter als SSG/ISR für KMU-Marketing.

Gründe gegen „SSR everywhere“:

1. Jeder Hit kostet Origin-Zeit, auch wenn der Content seit Wochen identisch ist.
2. CDN-Hit-Raten sinken, wenn Responses als dynamisch markiert sind.
3. Fehlerflächen wachsen: Origin-Outages treffen sofort alle Marketingseiten statt nur APIs.
4. GEO/Crawler brauchen keine Personalisierung — sie brauchen schnelles, stabiles HTML.
5. INP/Hydration: SSR allein verhindert nicht, dass du ein riesiges Client-Bundle nachlädst; Insel-Architektur bleibt Pflicht.

Wann SSR sinnvoll ist: Session-HTML, Checkout-Schritte mit serverseitigem Preis-/Bestandskontext, stark personalisierte Dashboards, Preview mit Draft-Auth. Wann SSR Falschfreund ist: Startseite, Leistungsseiten, Blogartikel, lokale Landings, FAQ — genau die URLs, die Ranking und GEO tragen.

Modern-Stack-Default für öffentliche Dienstleister-Webseiten: SSG/ISR für Content, API-Routen für Formulare (Conversion & Anfragen / Convex), minimale Hydration nur für Interaktion.

Wie hängen LCP-Benchmarks und GEO-Crawl-Timeouts zusammen?

Antwort zuerst: Langsamer LCP und hoher TTFB erhöhen das Risiko, dass Crawler und Answer-Pipelines abbrechen oder dünne Snapshots speichern — schnelles HTML ist Extraktionsvoraussetzung, nicht Ranking-Garantie.

Core Web Vitals definieren LCP als Ladequalität des größten sichtbaren Elements. Im internen Vergleich Next.js vs WordPress liegen typische WordPress/PHP-LCP-Werte bei 2,5–4,0 s, während SSG/Edge-Next.js oft bei ~0,8 s landet. Für Nutzer ist das Conversion; für Bots ist es Deadline-Druck: viele Pipelines budgetieren Fetch+Parse eng und führen kein volles Chromium aus.

GEO-Bezug (Princeton / Aggarwal et al., arXiv:2311.09735): generative Engines gewichten zitierfähige, früh extrahierbare Passagen. Wenn der erste HTML-Response leer ist oder der Fetch timeoutet, existiert dein Inhalt für die Pipeline nicht — unabhängig von Client-Schönheit. SSR/SSG adressiert die technische Extraktionsbasis; inhaltliche GEO-Taktiken (Statistiken, Quellen, Entities) kommen danach über GEO & AI-Sichtbarkeit und optional llms.txt.

Wichtig: LCP-~0,8-s-Werte sind Orientierung aus Stack-Vergleichen, keine Garantie für jede Domain. Bilder, Third-Party-Scripts und Cookie-Banner können SSG-Vorteile wieder auffressen — Rendering-Wahl ist notwendig, aber nicht hinreichend. Vertiefung: Core Web Vitals Modernisierung.

Warum scheitern reine SPAs an GEO und Crawlability?

Antwort zuerst: Viele Bot-Pipelines rendern kein volles Browser-JS; sehen sie nur <div id="root"></div>, fehlt Zitierstoff trotz funktionierender SPA im Chrome.

Marketing-SPAs booten oft erst Client-seitig Daten und Texte. Google kann JS rendern — mit Budget und Verzögerung; Answer-Engine- und RAG-Fetcher sind oft strenger. Crawlability und Extrahierbarkeit setzen voraus, dass Leistungen, Preise, FAQ und NAP im initialen Markup stehen.

SSR/SSG stellt genau das sicher. Optional ergänzt du Markdown-Negotiation und llms.txt; HTML bleibt die Quelle der Wahrheit. SPA-Muster bleiben legitim hinter Auth oder für stark interaktive Apps — nicht als öffentliche Marketing-Origin.

Was der Census zum SSR/SSG-Stack sagt

Antwort zuerst: Der Stack entfernt den Legacy-Bottleneck; AI-Readiness braucht danach Maschinen-Layer — Migration ohne Schema/llms bleibt halb fertig.

In der AI-Readiness-Studie (6.675 Audits) laufen 69,4 % der Sites auf Legacy-CMS. Agent-Ready Ø 25/100; llms.txt 15,6 %; JSON-LD 41,9 %; Markdown-Negotiation 0,3 %. Legacy-CMS korreliert mit PHP-pro-Request und Pagebuilder-Rauschen — genau dem Gegenteil von HTML-first.

SSR/SSG verbessert die technische Extraktionsbasis. Referenzen nach Stack-Wechsel: Mallorca Expats, Alexandre Liard. Der Census zeigt zugleich: ohne strukturierte Daten und answer-first Content bleibt die Sichtbarkeit in KI-Antworten begrenzt — Stack zuerst, Content-Taktiken parallel oder unmittelbar danach.

Hydration, Inseln und Interaktivität ohne SPA-Steuer

Antwort zuerst: Formulare und Widgets brauchen JS — die ganze Marketingseite nicht; hydriere Inseln, nicht das Dokument.

Mit SSR/SSG renderst du Text serverseitig und hydratisierst nur Slider, Karten, Consent oder Formularlogik. So sinkt Hydration-Last und INP, weil der Main Thread kein Megabyte-Bundle booten muss, bevor Buttons reagieren. Pagebuilder laden oft alles global — ein Hauptgrund, warum Legacy-CMS und schwache CWV zusammenpassen.

Trennung bei Modern Stack: statische/routenweise gerenderte Seiten + klar begrenzte API-Routen (z. B. Convex für Anfragen). Die Webseite wird nicht zur SPA, nur weil ein Formular asynchron absendet.

Redaktion, Catalog und Betrieb nach dem Stack-Wechsel

Antwort zuerst: Inhalte liegen versionierbar (MDX/Catalog oder Headless); Deploys und Revalidation ersetzen Live-Editing im Pagebuilder als Wahrheitsquelle für HTML.

Redaktion gewinnt nachvollziehbare Diffs und Staging; Technik gewinnt vorhersagbares Rendering und Tests vor Go-Live. Preview-Deploys, Env-Trennung und Monitoring gehören zum Betrieb — siehe Hosting nach Migration. Content-Updates laufen über Pipeline: Merge → Build/Revalidate → Edge. So bleiben HTML, Schema und Canonicals konsistent; Rollbacks sind möglich, wenn ein Release CWV oder Markup bricht.

Architekturkontext im KI-Zeitalter: Webarchitektur im KI-Zeitalter und WordPress im KI-Zeitalter.

Wann lohnt der SSR/SSG-Stack — und wann nicht allein?

Antwort zuerst: Sinnvoll, wenn öffentliche Seiten langsam, schlecht crawlbar oder SPA-dünn sind — nicht als Ersatz für eine kaputte Informationsarchitektur.

Sinnvoll bei: WordPress/PHP mit schwachen CWV trotz Cache, Elementor/Divi-Ballast, Client-only Marketing-SPAs, fragiler Extrahierbarkeit, geplanter GEO-Schicht.

Allein zu wenig, wenn: Texte, Angebote und Conversion unklar sind — dann Stack + Modernisierung/Redesign + Conversion. Shop-Logik und starke Personalisierung brauchen eigene SSR-/Insel-Grenzen und sprengen oft das „zehn Marketingseiten“-Muster.

Wie mapst du bestehende WordPress-/PHP-Routen auf SSG, ISR und SSR?

Antwort zuerst: Inventarisiere URLs nach Änderungsfrequenz und Personalisierung — dann weist du jeder Route genau ein Rendering-Muster zu, bevor du migrierst.

Ein praktisches Mapping für typische Dienstleister-Webseiten:

1. Statische Marketing-Cluster (Start, Leistungen, Team, Kontakt, Legal): SSG. Texte ändern sich mit Releases; 301-Matrix und Canonicals sitzen im Code.
2. Content-Cluster (Blog, Themen, Fallstudien): ISR oder On-Demand nach Publish-Webhook. Listen und Detailseiten teilen Revalidate-Tags, damit ein neuer Artikel die Übersicht mitzieht.
3. Lokale Landings (Stadt, Ortsteil): SSG, sofern NAP und Copy nicht personalisiert sind — hohe GEO-Priorität, deshalb besonders striktes HTML-first.
4. Formulare und Termine: SSG-Shell; Submit und Slot-Abfragen über API. Kein SSR der ganzen Landing nur wegen eines Datumsfelds.
5. Kundenlogin / Portal: SSR oder authentifizierte App-Route — bewusst außerhalb der öffentlichen Cache-Policy.

Dieses Mapping verhindert den häufigsten Cutover-Fehler: alles auf SSR „weil dynamisch“ und danach verwundert über schlechtere TTFB als beim alten Full-Page-Cache. Die technische SEO-Basis (Technical SEO, modernes Technical SEO) hängt an stabilen Canonicals, Sitemap und Schema im gerenderten HTML — nicht an Request-Zeit-Zufall.

Praktischer Einstieg und Checkliste

Antwort zuerst: Audit der aktuellen Delivery (erster HTML-Response, LCP, Bot-Fetch) → Routing-Matrix SSG/ISR/SSR → Migration/Rebuild → CWV- und Extraktions-Check → optional llms/Schema/Graph.

Checkliste vor dem Umbau:

• Top-20-URLs: enthält der erste HTML-Response Kerntext ohne JS?
• Pro Route: Request-Bindung ja/nein dokumentieren.
• Default SSG; ISR nur wo Redaktion schneller als Deploys ist; SSR nur mit Begründung.
• Edge-Cache- und Revalidate-Tags planen (nicht „SSR + Hoffnung“).
• Third-Party-Scripts und Banner auf LCP-Budget prüfen.
• Nach Go-Live: Mobile-LCP-Stichprobe, robots/sitemap, AI-Bot-Allowlist.
• Smoke-Test mit curl/Accept-Checks: Kernaussagen müssen ohne Browser-JS sichtbar sein.

Kurz: SSR/SSG-Stack ist die Auslieferungsentscheidung für maschinen- und menschenlesbare KMU-Webseiten — HTML zuerst, Frische gezielt, SSR sparsam. Start: Webseite-Modernisierung oder direkt WordPress-Migration. Anfrage stellen