CSR, SSR, statische Generierung und Framework-Auswahl

Derselbe sichtbare Artikel kann auf unterschiedlichem abgerufenem Material beruhen

Damit Sonntagsöffnungszeiten erscheinen, müssen irgendwo Daten gelesen und HTML-Elemente erstellt werden. Übernimmt das der Browser, liefert der Server anfangs möglicherweise nur eine Ladeanzeige. Bei serverseitiger Erzeugung können Zeiten und Schließtage bereits im Antwortinhalt stehen. Für SEO, GEO und AEO ist das relevant, weil Such- und Antwortsysteme ihr Material aus dieser Antwort und der anschließenden Verarbeitung gewinnen.

Es folgen die Inhaltsbereiche zweier Varianten derselben Anleitung. Das CSR-Beispiel füllt den Inhalt im Browser mit JavaScript; das servergenerierte Beispiel enthält ihn durch SSR oder statische Generierung.

<!-- Erste Antwort bei Abruf des Inhalts im Browser --> <main id="guide">Die Anleitung wird geladen.</main> <script src="/guide.js" defer></script> <!-- Antwort mit serverseitig erzeugtem Inhalt --> <main><article> <h1>Sonntagsöffnungszeiten der Bibliothek</h1> <p>Sonntags 10–17 Uhr geöffnet. Am ersten Sonntag und an Feiertagen geschlossen.</p> <p>Gültig ab Oktober 2026.</p> <a href="/policies/opening-hours">Ursprüngliche Mitteilung zu den Öffnungszeiten</a> </article></main>

Die erste Antwort enthält keinen Schließtag. Er wird erst nach Ausführung von /guide.js und Abruf des Materials bekannt. Die zweite enthält bereits Antwort, Ausnahme, Gültigkeitsdatum und Beleglink. Ein HTML-lesendes Werkzeug erhält dies ohne weitere Bildschirmzusammensetzung. Prüfen Sie diesen Unterschied zuerst und entscheiden Sie dann über den Zeitpunkt der Inhaltserzeugung.

Vom Empfang des Inhalts zu Suchergebnissen und KI-Antworten

Suchsysteme verarbeiten abgerufene Dokumente für den Index und wählen Material zur Frage aus. Liefert eine Seite „am ersten Sonntag geschlossen“ nicht, lässt sich diese Bedingung nicht aus ihr entnehmen. Inhalt im Antwort-HTML verringert die ausschließliche Abhängigkeit von erfolgreicher JavaScript-Ausführung und zusätzlichen API-Anfragen.

Google führt JavaScript aus und kann auch CSR-Inhalte verarbeiten. Nach dem Crawling folgt Rendering; gesperrte Ressourcen oder fehlgeschlagene Anfragen können Inhalte auslassen. SSR und Prerendering liefern Kerninhalte mit der Antwort. Google erläutert auch, dass nicht alle Bots JavaScript ausführen können. Googles JavaScript-Verarbeitung

Auch generierte Antworten mit Webmaterial benötigen lesbare Dokumente. Indexierung und Berechtigung zur Snippet-Anzeige gehören zu den Teilnahmebedingungen der generativen Google-Suche. Eine korrigierte Inhaltsauslieferung hilft der Suche somit, mögliche Belegdokumente zu verarbeiten. Anschließend sind Fragebezug, ausreichende Fakten und Bedingungen sowie tatsächliche Quellenwahl zu prüfen. Anforderungen der generativen Google-Suche

Für „Kann ich am 1. November 2026 kommen?“ müssen Sonntagszeiten und Schließung am ersten Sonntag gemeinsam gelesen werden. Nur die Zeiten im Serverinhalt zu ergänzen verändert die Auslieferung, lässt aber unzureichendes Antwortmaterial zurück. Rendering löst die Übertragung, der Text liefert Entscheidungsfakten. Prüfen Sie Abrufmethoden externer KI-Dienste anhand ihrer Dokumentation und tatsächlichen Zitate.

CSR und SSR lesen Daten und erzeugen Inhalte an unterschiedlichen Orten

CSR (Client-Side Rendering) erstellt die Darstellung im Browser. Bei dortigem Inhaltsabruf lautet die Reihenfolge: HTML empfangen → JavaScript herunterladen und ausführen → API anfragen → Absätze erzeugen. Je nach Fehlerstelle bleiben Ladeanzeige oder unvollständige Informationen zurück.

SSR (Server-Side Rendering) lässt den angefragten Server Daten lesen und HTML erzeugen. Werden öffentliche Hinweise serverseitig abgefragt und als h1-, p- und a-Elemente ausgegeben, enthält die Antwort Titel, Bedingungen und Belege. Der Browser zeigt den Text und bindet erforderliche Schaltflächenfunktionen später an.

Bei SSR beeinflussen langsame Abfragen und Serverfehler die Antwort. Muss ein selten geänderter Hinweis nicht für jede Anfrage neu erstellt werden, sind statische Generierung oder Caching möglich. Entscheidend sind sowohl die Lesbarkeit des Materials als auch die notwendige Aktualisierungsgeschwindigkeit.

Statische Generierung erstellt HTML vor der Anfrage

SSG (Static Site Generation) erzeugt HTML pro Pfad, bevor Besucher anfragen. Beispielsweise liest der Build Vorstellungen und Nutzungshinweise, erstellt HTML für jede URL und lässt es über ein CDN ausliefern. Nicht jeder Zugriff muss die Datenbank abfragen und dieselbe Seite neu erstellen. Titel, Text und Links liegen im HTML; der wesentliche Crawling-Vorteil entspricht daher dem von SSR.

Auch statisch generierte Seiten können Schaltflächen und Suchfelder enthalten. React verbindet vorbereitete HTML-Ausgabe mit Interaktionen wie Ereignisverarbeitung; das heißt Hydration. Prüfen Sie gesondert, ob die statisch gehosteten Dateien den Inhalt je Pfad enthalten. Erhalten alle URLs dieselbe leere index.html und füllt erst der Browser den Inhalt, handelt es sich dafür weiterhin um CSR.

Die betriebliche Herausforderung von SSG ist Aktualisierung. Eine CMS-Änderung nach dem Build ändert vorhandenes HTML nicht automatisch. Erforderlich sind erneuter Build und Bereitstellung oder eine verbundene Pfadregenerierung in einer unterstützten Laufzeit. ISR (Incremental Static Regeneration) erzeugt vorbereitete Seiten nach Bedingungen oder Aktualisierungsanforderungen neu. Verbinden Sie Revalidierungs-APIs und Veröffentlichungsereignisse passend zu Next.js-Version und Cache-Konfiguration.

Zeitgesteuerte Aktualisierung kann bis dahin alte Inhalte belassen. Müssen Rücknahme oder Berechtigungsänderung sofort gelten, planen Sie Cache-Invalidierung und Veröffentlichungskontrolle bei Anfragen, statt nur Ablaufzeiten abzuwarten. Hintergrundgenerierung kann während der Erneuerung die alte Antwort liefern. Prüfen Sie deshalb auch die erste Anfrage unmittelbar nach Veröffentlichung oder Rücknahme.

Next.js-Builds bereiten pfadspezifisches HTML und Servercode vor

Ein Build verwandelt Quellcode in bereitstellbare Ergebnisse. Ein üblicher React-SPA-Build erzeugt JavaScript und einen HTML-Einstiegspunkt und kann das Füllen des Inhalts dem Browser überlassen. Next.js bereitet je nach Datenabfragen und Einstellungen vorab erzeugtes HTML und bei Anfragen auszuführenden Servercode vor. Beide Builds können erfolgreich sein; prüfen Sie daher, wann der Seiteninhalt in das Ergebnis gelangt.

In der späteren Next.js-Implementierungsübung erzeugt /archive/opening-2025 den festen historischen Hinweis beim Build, während /guides/[slug] bei jeder Anfrage die aktuelle veröffentlichte Revision liest. Der Produktionsserver liefert für den ersten Pfad fertiges HTML und für den zweiten eine durch Servercode erzeugte Antwort. Beide können Crawlern Inhalt liefern, aktualisieren sich aber zu unterschiedlichen Zeitpunkten.

Statische Pfade liefern weiter den beim Build verwendeten Text und müssen nach Änderungen neu generiert werden. Anfragegenerierte Pfade können neue Daten lesen; vorhandene Abfragecaches müssen jedoch ebenfalls aktualisiert werden. Nach dem Build sind erzeugte Pfade, tatsächliches HTML und Inhalt der ersten Antwort nach einer Änderung zu prüfen.

Mit output: export erstellt Next.js HTML, CSS und JavaScript im Verzeichnis out. Statische Server können diese Dateien ausliefern. Funktionen mit Servercode pro Anfrage und ISR werden in Bereitstellungen mit Serverlaufzeit eingerichtet. Statische Exporte mit Next.js

Datenabfrage und HTML-Ausgabe in Beispieldateien finden

React setzt Oberflächen aus Komponenten zusammen. Komponenten sind wiederverwendbare Einheiten wie Überschriften oder Artikellisten. JSX beschreibt Oberflächen innerhalb von JavaScript mit HTML-ähnlicher Syntax. TypeScript ergänzt JavaScript um Typen zur Prüfung von Datenformen. tsx-Dateien verwenden TypeScript und JSX gemeinsam.

Ein Build transformiert und bündelt Code für seine Ausführungsumgebung. Ein Bundle ist die zusammengefasste Codedatei. Der Entwicklungsserver zeigt Änderungen schnell; der Produktionsbuild erstellt das tatsächlich bereitzustellende Ergebnis. Die Runtime führt dieses aus, wobei Browser und Server ihren jeweiligen Code ausführen.

Der Next.js App Router verbindet URLs und Seiten über die Verzeichnisstruktur von app. page.tsx definiert die Seite, layout.tsx gemeinsame Strukturen und route.ts einen HTTP-Anfragehandler. [slug] ist der variable Adressteil. In /guides/opening-hours lautet er opening-hours. Manche Repositories verwenden src/app.

generateMetadata erzeugt Titel, Beschreibung und kanonische URL aus Seitendaten. Eine API (Application Programming Interface) ist eine festgelegte Schnittstelle, über die Programme Daten oder Aktionen anfordern. Serverfunktionen öffentlicher Seiten können die Datenbank direkt lesen oder interne APIs aufrufen. Veröffentlichungsbedingungen werden auf dem Server angewendet, ohne Datenbankzugangsdaten an den Browser zu senden.

import bindet Code anderer Dateien ein; await wartet auf asynchrone Ergebnisse. useEffect führt zusätzliche Arbeit aus, nachdem die Komponente im Browser übernommen wurde. Wird öffentlicher Inhalt nur dort abgefragt, kann die Antwort nur die vorherige Ladeanzeige enthalten. Liest die Server-page das Material und gibt es in JSX-p-Elementen aus, kann es im servergenerierten Inhalt enthalten sein.

Auch mit Next.js verfolgen, wo der Inhalt entsteht

App-Router-page und -layout sind standardmäßig Server Components. Sie können serverseitig Daten lesen; statische Generierung und Cache-Einstellungen bestimmen den Ausführungszeitpunkt. Server Component bezeichnet eine Ausführungsgrenze, SSR und SSG dagegen den Zeitpunkt der HTML-Erzeugung.

Auch eine mit use client markierte Komponente kann beim ersten Seitenaufruf serverseitig vorgerendertes HTML liefern. Prüfen Sie, ob Kerninhalte erst nach useEffect entstehen, durch browserspezifische Bedingungen verborgen werden oder Serverrendering für den Bereich deaktiviert ist. Die Erläuterung zu Server und Client Components hilft, den Zeitpunkt des Datenzugangs zu bestimmen.

Werden öffentliche Artikel nur im Effect geladen, verschieben Sie die Abfrage in die Server-page und rendern Titel, Inhalt und Quellen der aktuellen veröffentlichten Revision. Nur interaktive Teile wie Likes, Teilen und Filter werden zu kleinen Client Components. Prüfen Sie, ob ein leerer Browser-Anfangszustand Serverinhalt überschreibt, und ob serverseitig vorhandene Sätze nach Hydration verschwinden.

Trennen Sie Arbeitsentwurf und veröffentlichte Revision im CMS. Inhalt und Metadaten müssen dieselbe öffentliche Version lesen. Wer nur den Rendering-Ort verschiebt, dabei aber einen Zwischenentwurf abfragt, kann unbeabsichtigt private Texte veröffentlichen. Wählen Sie in der öffentlichen Abfragefunktion die aktuell veröffentlichte Revision und übergeben Sie sie an Inhalt und Metadaten.

Serverrendering in Vite und Next.js vergleichen

Vite ist Entwicklungsserver und Build-Werkzeug. Eine SPA (Single-Page Application) wechselt Ansichten per JavaScript innerhalb eines Dokuments. Eine übliche Vite-React-SPA erstellt Anwendungs-JavaScript und einen HTML-Einstiegspunkt. Ruft sie Artikel über useEffect ab, erzeugt der Browser den Inhalt je Seite. Für pfadspezifisches HTML, kanonische URLs und Sitemap müssen Serverrendering oder Vorabgenerierung sowie Metadatenerzeugung eingerichtet werden.

Auch Vite unterstützt SSR. Ein Servereinstiegspunkt kann Komponenten rendern und in HTML einsetzen; alternativ lässt sich ein Vite-basiertes SSR- oder SSG-Framework verwenden. Anfrageverarbeitung, Datenabruf, head pro Route, 404, Weiterleitungen, Caching und Updates müssen trotzdem gewählt werden. Vites SSR-Anleitung erklärt die dafür angebotenen Low-Level-APIs sowie Server- und Client-Einstiegspunkte.

Next.js bietet eine umfassendere Anwendungsstruktur. App-Router-page und -layout, Serverabfragen, statisches und dynamisches Rendering, Metadata API, robots- und sitemap-Dateikonventionen, Weiterleitungen und Bereitstellungslaufzeiten lassen sich gemeinsam verwalten. Nach dem Abruf einer CMS-Revision können etwa Inhalt, generateMetadata und JSON-LD dieselben Daten nutzen und zugehörige Caches bei Veröffentlichungsänderungen aktualisiert werden.

Diese Integration kann die Auswahl für Websites begründen, die Vorstellungen und Archive vorab erzeugen, bei neuen Artikeln die aktuelle Revision lesen und pro Detailseite Titel, kanonische URL und Quelle anbieten müssen. Auch nach Umbauten lassen sich Routen, Metadaten, Sitemap und Antworten innerhalb derselben Anwendung verfolgen. Das kann Lücken durch getrennte Implementierungen der Veröffentlichungsbedingungen reduzieren. Suchsysteme sammeln das dabei ausgegebene HTML, Links und Metadaten.

Vite-basierte Lösungen können dasselbe öffentliche HTML, dieselben Metadaten, Statuscodes und Aktualisierungen bereitstellen. Vergleichen Sie den selbst zu implementierenden Routing-, Abfrage- und Cache-Code, die Unterstützung der Bereitstellungsumgebung und die Wartungserfahrung des Teams. Prüfen Sie zuerst, ob eine vorhandene stabile Lösung die Anforderungen bereits erfüllt.

Entstehen Titel, Inhalte und canonicals hunderter CMS-Hinweise in getrennten Codepfaden, wird bei neuen Inhaltstypen leicht ein Pfad vergessen. Ein praktischer Grund für Next.js ist, Routenabfragen, Metadata API und Sitemap-Erzeugung mit denselben Daten und derselben Dateistruktur zu verwalten. Bewerten Sie, ob das tatsächliche Auslassungen und Widersprüche reduziert. Bestehende Vite-SSR- oder andere Serverlösungen mit gleichen Antworten und Updates erfüllen die Anforderung ebenfalls.

Erzeugungszeitpunkt und Aktualisierung je Seite bestimmen

Vorstellungen oder archivierte Hinweise, die zwischen Bereitstellungen unverändert bleiben, können statisch erzeugt werden. Regelmäßig im CMS veröffentlichte und zurückgezogene Detailartikel müssen bei Anfragen die aktuelle Revision lesen oder ihren Cache bei Veröffentlichungsereignissen aktualisieren. Personalisierte Verwaltungsseiten verarbeiten zuerst Authentifizierung und nutzerspezifische Daten.

Diese Verfahren können auf einer Website zusammen eingesetzt werden. Legen Sie pro URL-Typ Erzeugungszeitpunkt, erlaubte Dauer alter Inhalte und Fehlerantworten fest. Auch SSR-Seiten können gemeinsame Struktur zuerst und Daten später streamen.

Beginnt die Antwort erst nach der Serverabfrage, zählt diese Wartezeit zur Zeit bis zum ersten Byte. Wird zuerst das Grundgerüst gestreamt, kann der Inhaltsabruf erst danach enden. Messen Sie sowohl das erste Byte als auch die tatsächliche Inhaltsanzeige.

HTML vor und nach Änderungen, dann tatsächliche Suchverarbeitung vergleichen

Führen Sie nach den Installations- und Ausführungsschritten der Übung die folgenden Befehle aus und speichern Sie beide vollständigen Antworten. curl führt kein JavaScript aus und holt daher keine Artikel, die der Browser erst später anfordert und einfügt.

curl -sS -D current.headers -o current.html http://localhost:3027/guides/opening-hours curl -sS -D archive.headers -o archive.html http://localhost:3027/archive/opening-2025

Suchen Sie in current.html Öffnungszeiten, Schließung am ersten Sonntag und Gültigkeitsbeginn; in archive.html den Gültigkeitszeitraum 2025 und den Link zur aktuellen Anleitung. Die HTML-Parser-Prüfung erkennt Text, der nur in script-Daten steht, und vergleicht article-Inhalt, Links und Daten. Lesen Sie bei Streaming die gesamte Antwort und das fertige Browser-DOM gemeinsam.

Ändern Sie anschließend CMS-Daten oder den festen Übungstext und rufen Sie dieselben Adressen erneut ab. Statische Seiten müssen nach dem Neuaufbau den neuen Satz zeigen, anfragegenerierte nach einer neuen Anfrage und nötigen Cache-Updates. So prüfen Sie, ob das Verfahren die tatsächlichen Aktualisierungsanforderungen erfüllt.

Prüfen Sie nach der Produktionsumstellung Crawling- und Rendering-Ergebnisse sowie das letzte Abrufdatum in Search Console. Stellen Sie einer KI mit Websuche dieselbe Frage zum selben Stichtag und lesen Sie zitierte URL und Schließbedingungen. Vergleichen Sie nacheinander, ob die Serverantwort den neuen Satz enthält, die Suche das neue Dokument verarbeitet hat und die Antwort die Bedingung nutzt. Dadurch lässt sich die nächste Korrekturstelle eingrenzen.

Enthält SSR-HTML ein img, entdeckt der Browser die Adresse und fordert das Bild separat an. Öffnungszeiten können sofort im HTML stehen, doch bei einem 5MB-Original folgen Übertragung und Dekodierung des Fotos. Deshalb sind currentSrc und Antwortbytes von CMS-Fotos auch nach erfolgreichem Next.js-Build zu prüfen. Die Übung zur CMS-Bildauslieferung hält die HTML-Erzeugung konstant und vergleicht nur Anfragen nach Original und abgeleiteter Datei.