Next.js 15 SEO-Architektur: SSR, PPR und Server Components

Die Wahl der Rendering-Architektur entscheidet in Next.js 15 darüber, ob eine Seite für klassische Suchmaschinen und für KI-Crawler gleichermaßen lesbar ist. Der App Router mit React Server Components und Partial Prerendering (PPR) verschiebt die Content-Erzeugung auf den Server. Das ist kein Detail für Performance-Enthusiasten, sondern die Grundlage dafür, dass Googlebot, ChatGPT, Claude und Perplexity überhaupt den vollständigen Inhalt einer Seite erfassen. Dieser Artikel ordnet die Rendering-Strategien ein und zeigt, welche Route welche Strategie braucht.

Warum die Rendering-Architektur über Sichtbarkeit entscheidet

Der entscheidende Befund kommt aus einer Analyse des Vercel-Crawler-Netzwerks: Keiner der sechs großen KI-Crawler (GPTBot, ClaudeBot, Meta-ExternalAgent, PerplexityBot, Bytespider) rendert JavaScript; ChatGPT ruft 11,50 % und Claude 23,84 % der JS-Dateien zwar ab, führt sie aber nicht aus. Nur Gemini (über die Googlebot-Infrastruktur) und AppleBot rendern vollwertig. Für jede Seite, deren Inhalt erst clientseitig per JavaScript entsteht, bedeutet das: KI-Crawler sehen eine leere Hülle.

Diese KI-Crawler sind kein Randphänomen mehr. GPTBot, Claude, AppleBot und PerplexityBot zusammen verursachen rund 1,3 Milliarden Fetches pro Monat, etwas mehr als 28 % von Googlebots 4,5 Milliarden Fetches im Vercel-Netzwerk. Wer im DACH-Raum in KI-Antworten zitiert werden will (Generative Engine Optimization, kurz GEO), muss seinen Content serverseitig als fertiges HTML ausliefern.

Auch der klassische Googlebot bestraft clientseitiges Rendering, wenn auch subtiler. Googlebot rendert JavaScript, aber in einer zweiten Welle: Seiten, die Rendering erfordern, landen zusätzlich zur Crawl-Queue in einer Rendering-Queue. Eine viel zitierte internationale Untersuchung quantifiziert die Folge: Google brauchte für JavaScript-gerenderte Seiten 313 Stunden gegenüber 36 Stunden für reines HTML, also rund neunmal so lange. Bei großen Sites verzögert das die Indexierung neuer und aktualisierter Inhalte erheblich.

Hinzu kommt eine harte technische Grenze. Googlebot crawlt nur noch die ersten 2 MB pro Ressource statt zuvor 15 MB, eine Reduktion um 86,7 %. Das Limit gilt pro Ressource, also für HTML, JavaScript-Bundle und CSS jeweils einzeln. Aufgeblähte Client-Bundles riskieren damit, dass entscheidende Skripte abgeschnitten werden.

Funktionsweise: SSG, SSR, ISR und PPR im SEO-Vergleich

Next.js 15 kennt vier Rendering-Strategien. Die Wahl pro Route folgt der Frage, wie dynamisch der Inhalt ist und wie schnell er aktuell sein muss.

• SSG (Static Site Generation): Die Seite wird beim Build als HTML erzeugt und vom CDN ausgeliefert. Bestmögliche TTFB und LCP, ideal für KI-Crawler, weil der vollständige Inhalt sofort im HTML steht. Geeignet für KB-Artikel, Leistungsseiten und Blogposts.
• ISR (Incremental Static Regeneration): Wie SSG, aber die Seite wird nach einem Zeitintervall (revalidate) oder per On-Demand-Trigger neu generiert. Verbindet statische Auslieferung mit redaktioneller Aktualität, etwa für Preislisten oder Bestandsanzeigen.
• SSR (Server-Side Rendering): Die Seite wird pro Anfrage auf dem Server gerendert. Notwendig bei nutzer- oder anfragespezifischem Inhalt (Geo-Targeting, A/B-Tests). Der Inhalt steht im HTML, die TTFB hängt aber von der Serverlaufzeit ab.
• PPR (Partial Prerendering, experimentell): Kombiniert statisch und dynamisch innerhalb einer Route. Eine statische Shell wird beim Build vorgerendert und vom CDN ausgeliefert, dynamische Teile streamen als HTML nach.

PPR ist der architektonisch interessanteste Ansatz für SEO. Die statische Shell (Header, Hauptinhalt, Footer) liegt sofort im initialen HTML-Response und sorgt für eine niedrige TTFB und ein schnelles LCP. Dynamische Fragmente, die in <Suspense>-Grenzen liegen, werden serverseitig nachgestreamt und ebenfalls als HTML in dieselbe Response eingefügt. Entscheidend für die Crawlbarkeit: Der gestreamte Content ist HTML, kein clientseitig nachgeladenes JavaScript. Ein Crawler ohne JS-Ausführung erhält den vollständigen Inhalt, sobald der Stream abgeschlossen ist.

Server Components sind das Fundament darunter. Sie rendern ausschließlich auf dem Server und senden null Client-JavaScript für ihre eigene Logik. Das reduziert das Hydration-Volumen drastisch, was direkt auf INP (Interaction to Next Paint) einzahlt, und es verkleinert die JS-Bundles relativ zum 2-MB-Limit. Interaktivität wird gezielt über Client Components ("use client") an den Rändern hinzugefügt, nicht pauschal über die gesamte Seite.

Best Practices für die Next.js-15-SEO-Architektur

Rendering-Strategie pro Route bewusst wählen

Die Standardregel: so statisch wie möglich, so dynamisch wie nötig. Inhaltsseiten (KB, Blog, Leistungen) gehören auf SSG oder ISR. Personalisierte oder echtzeitnahe Seiten nutzen SSR oder PPR mit eng gefassten <Suspense>-Grenzen, sodass die SEO-relevante Shell statisch bleibt und nur wirklich dynamische Teile streamen.

Metadata-API serverseitig vollständig nutzen

Der App Router erzeugt Metadaten serverseitig über das metadata-Objekt oder die generateMetadata-Funktion. Wichtig:

• metadataBase setzen: Ohne metadataBase werden Open-Graph- und Twitter-Bild-URLs relativ ausgegeben und von Crawlern oft nicht korrekt aufgelöst. Diese Basis-URL ist Pflicht für valide OG-Tags.
• Canonical pro Route: über alternates.canonical setzen, um Duplicate-Content durch Parameter- oder Pfadvarianten zu vermeiden.
• hreflang für den DACH-Raum: über alternates.languages mit de-AT, de-DE und x-default ausgeben. Das ist fehleranfällig: Eine internationale Studie fand, dass 31,02 % der mehrsprachigen Websites widersprüchliche hreflang-Direktiven enthalten und 16,04 % der hreflang-Cluster keine selbstreferenzierenden Tags haben. Jede Sprachvariante muss sich selbst und alle anderen referenzieren.
• JSON-LD serverseitig einbetten: als <script type="application/ld+json"> direkt im Server Component. Strukturierte Daten sind verbreitet: JSON-LD findet sich 2024 auf 41 % aller Seiten, plus 7 Prozentpunkte gegenüber 34 % im Jahr 2022. Serverseitig gerendert ist es auch für KI-Crawler ohne JS-Ausführung lesbar.

Pflicht-Dateien dynamisch generieren

Next.js 15 ersetzt Third-Party-SEO-Plugins durch konventionsbasierte Dateien:

• sitemap.ts: generiert die XML-Sitemap programmatisch, inklusive lastModified je URL für ein präzises lastmod-Signal.
• robots.ts: erzeugt die robots.txt dynamisch, inklusive sitemap-Verweis und gezielter Regeln für einzelne User-Agents.
• 301-Redirects: dauerhafte Weiterleitungen gehören in next.config (redirects()) oder bei dynamischer Logik in die Middleware. Statuscode 308/301 verwenden, damit Linkkraft und Indexierungssignale übertragen werden.

Edge, CDN und Caching für niedrige TTFB in Österreich

Statische und ISR-Seiten werden vom CDN aus einem Edge-Standort nahe am Nutzer ausgeliefert, was die TTFB für Besucher in Österreich und im DACH-Raum minimiert. Steuern lässt sich das über revalidate (Zeitintervall), cache-control-Header und On-Demand-Revalidation per revalidatePath oder revalidateTag. HTTP/3 reduziert zusätzlich den Verbindungsaufbau-Overhead. Da Google in Österreich im Mai 2026 einen Marktanteil von 81,87 % hält und Bing 9,01 %, bleibt die Optimierung für Googlebot prioritär, ohne Bing zu vernachlässigen.

IndexNow bei On-Demand-Revalidation anstoßen

Wenn ein redaktioneller Trigger eine Seite revalidiert, lässt sich im selben Route Handler ein IndexNow-Ping an Bing und Yandex senden. Das beschleunigt die Indexierung dort spürbar: IndexNow liefert 18 % aller geklickten neuen URLs in der Websuche, bei über 3,5 Milliarden täglich eingereichten URLs. Für Google ersetzt IndexNow das Crawling nicht, ergänzt die Sichtbarkeit im Bing-Ökosystem aber wirkungsvoll.

Core Web Vitals mit den Bordmitteln optimieren

Next.js 15 liefert die Werkzeuge gegen die drei CWV-Metriken mit:

• next/image gegen LCP und CLS: liefert moderne Formate, responsive Größen und reservierten Platz, der Layout-Verschiebungen verhindert.
• next/font gegen CLS: hostet Schriften selbst und vermeidet Layout-Shifts durch Font-Swaps.
• Streaming und Suspense gegen LCP: rendern den kritischen Inhalt zuerst und lagern langsame Datenquellen aus.
• Server Components und Code-Splitting gegen INP: reduzieren das Client-JS und damit die Verarbeitungszeit von Interaktionen.

KI-Crawler und GEO gezielt bedienen

Server-gerenderter Content ist die Grundvoraussetzung dafür, dass ChatGPT, Claude und Perplexity einen Text erfassen. Darüber hinaus: robots.txt (via robots.ts) steuert den Zugriff einzelner KI-Bots, eine optionale llms.txt kann zentrale Inhalte ausweisen. Für die Zitierbarkeit in KI-Antworten zählen konkrete Fakten, Zahlen mit Quellen und klar beantwortete Fragen direkt im serverseitigen HTML.

Häufige Fehler

• Inhalt clientseitig nachladen: Daten erst per useEffect/Fetch im Client zu holen, macht den Inhalt für alle sechs großen KI-Crawler unsichtbar und verzögert Googlebot über die Rendering-Queue.
• metadataBase vergessen: OG-Bild-URLs werden relativ und brechen Social- und teils KI-Vorschauen.
• hreflang unvollständig: fehlende Selbstreferenz oder fehlendes x-default führen zu den dokumentierten Cluster-Fehlern.
• Alles zur Client Component machen: ein pauschales "use client" an der Wurzel verschenkt die Vorteile der Server Components und bläht das Bundle in Richtung 2-MB-Limit.
• Zu weite Suspense-Grenzen unter PPR: wird zu viel als dynamisch markiert, schrumpft die statische Shell und der TTFB-Vorteil entfällt.
• Redirect-Ketten und Soft-Redirects: clientseitige Weiterleitungen statt 301/308 übertragen keine Indexierungssignale sauber.

Metriken und Messung

Die Wirkung der Architektur wird an konkreten Kennzahlen sichtbar:

• Core Web Vitals (Felddaten): LCP, INP und CLS aus der CrUX-/Search-Console-Realität messen. Zur Einordnung: International bestehen 48 % der mobilen und 56 % der Desktop-Origins alle drei Core Web Vitals; mobil sind LCP zu 62 %, INP zu 77 % und CLS zu 81 % im grünen Bereich. LCP ist damit mobil die limitierende Metrik, genau dort setzen SSG/PPR und Streaming an.
• INP statt FID beachten: Seit der Umstellung gilt die strengere Metrik. International hatten 2024 nur 43 % der mobilen Sites gute CWV unter INP gegenüber 48 % unter dem alten FID. Das macht die INP-Optimierung durch Server Components besonders relevant.
• Render-Differenz prüfen: den ausgelieferten HTML-Quelltext (View Source) mit dem gerenderten DOM vergleichen. Was nur im DOM steht, sehen KI-Crawler nicht.
• Indexierungs-Latenz: in der Google Search Console die Zeit von Veröffentlichung bis Indexierung verfolgen, als Indikator für die Crawl-Effizienz.
• Bundle-Größe gegen das 2-MB-Limit: JS- und CSS-Bundles pro Route überwachen.

Weiterführendes

Die Next.js-15-Architektur ist mächtig, aber komplex. Das spiegelt sich in der Entwicklerwahrnehmung: Laut der internationalen State-of-JavaScript-2025-Umfrage nutzen 59 % der Befragten Next.js, bei 21 % positiver gegenüber 17 % negativer Stimmung, wobei die steigende Komplexität wiederholt kritisiert wird. Die praktische Konsequenz: Rendering-Strategien bewusst pro Route wählen, PPR mit eng gefassten Suspense-Grenzen einsetzen und die SEO-Pflichtdateien (sitemap.ts, robots.ts, Metadata-API, Canonical, hreflang) konsequent serverseitig erzeugen. So entsteht eine Site, die für Googlebot schnell, für KI-Crawler vollständig lesbar und im DACH-Raum performant ausgeliefert ist. Als nächste Schritte empfehlen sich ein Render-Audit (HTML vs. DOM), eine CWV-Messung auf Feldebene und die Anbindung von IndexNow an den Revalidation-Flow.