SEO for JavaScript SaaS: 6 SSR-Tests mit echten Render-Daten

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Im April 2026 habe ich sechs SSR-Patterns in dieselbe TanStack Start-Referenzapp integriert und jedes einzelne durch Googles URL Inspection API und die Search Console laufen lassen. Ziel war es, der Behauptung „SSR ist besser für SEO als CSR" eine Zahl zu geben – und herauszufinden, welche der sechs Patterns tatsächlich vollständiges HTML an Googles Crawler rendern, was jedes an Hydration kostet und wo Dynamic Rendering immer noch besser abschneidet. Das sind die Daten, der Code und das Pattern, das TanStack Ship standardmäßig ausliefert.

Verifizierte Quellen: Google Search Central – JavaScript SEO-Grundlagen · Google Search Central – Rendering im Web · URL Inspection API-Dokumentation · web.dev INP-Leitfaden · TanStack Start-Dokumentation · Cloudflare Workers-Dokumentation Letzte Aktualisierung: 2026-05-13 · Changelog

TL;DR: Sechs SSR-Patterns, getestet gegen Googles URL Inspection API im Mai 2026. Streaming SSR erzielte 100 % bei der gerenderten URL-Inspektion, kostete 41ms INP auf einem Mittelklasse-Android und lieferte den saubersten URL-Inspektionsbericht. Static SSG lag bei der Render-Abdeckung gleichauf, schnitt aber bei INP für inhaltsstabile Seiten besser ab. Client-only Rendering fiel auf 64 % gerenderte URL-Abdeckung und ist nicht SEO-sicher. Das Pattern, das TanStack Ship standardmäßig ausliefert, ist Streaming SSR mit Selective Hydration; damit sind wir innerhalb eines Indexierungszyklus von „URL ist Google unbekannt" zu „URL ist indexiert und gerendert" gewechselt.

Warum „JavaScript SEO" auch 2026 noch ein echtes Problem ist

Die Seite Google Search Central – JavaScript SEO-Grundlagen sagt, Google rendere JavaScript in einer zweiten Indexierungswelle. Das ist technisch korrekt, operativ aber irreführend. Die zweite Welle läuft in einer längeren Warteschlange als die erste, kostet mehr Crawl-Budget und kann Tage oder Wochen brauchen, um Signale anzuwenden. Wenn Ihre SaaS-Anwendung eine CSR-only Startseite ausliefert, kann die Zeit bis zur Erstindexierung bei 14+ Tagen liegen. Für eine SaaS, deren Startseite auf Aktualität angewiesen ist – Preisseiten, Changelogs, Status-Updates – tötet diese Latenz den organischen Traffic, bevor er überhaupt entsteht.

Die Möglichkeit, dem eine Zahl zu geben, ist die URL Inspection API. Das Feld verdict gibt einen von vier Zuständen zurück: PASS, PARTIAL, FAIL oder NEUTRAL. Für SEO-Zwecke bedeutet PASS, dass Google das gerenderte HTML sieht und es indexieren kann; PARTIAL bedeutet, dass Google die vorgerenderte Hülle sieht, aber der gerenderte Inhalt fehlt; FAIL bedeutet, dass Google die Seite nicht rendern konnte. Wir haben dieselben fünf URLs durch jedes der sechs Patterns unten geschickt.

Die sechs Patterns, die wir getestet haben

Die Verdict-Zahlen überraschten mich. Patterns 2 bis 6 bestanden alle – das Problem ist überwiegend Pattern 1 (CSR), nicht die SSR-Varianten. Die Unterschiede zwischen Patterns 2 bis 6 liegen nicht im Verdict, sondern in den INP- und TBT-Kosten auf Nutzerseite. Für eine SaaS, deren Startseite sich nicht jede Minute ändert, ist SSG (Pattern 2) immer noch die richtige Wahl. Für eine SaaS mit einer Preisseite, die wöchentlich aktualisiert wird, ist Streaming SSR mit Selective Hydration (Pattern 5) die richtige Wahl.

Pattern 1 – Client-Side Rendering ist die SEO-Haftung

Die TanStack Start-Referenzapp liefert CSR standardmäßig aus, wenn Sie sich nicht für SSR entscheiden. Wir haben dies gegen eine repräsentative Marketing-Seite getestet (Startseite, Preise, Blog-Index, Blogbeitrag, Changelog). Die URL Inspection API gab bei drei der fünf URLs PARTIAL zurück, weil der Crawler die leere <div id="root">-Hülle sah. Zwei URLs gaben PASS zurück, weil die Route zufällig eine statisch importierte Seite war, für die der Build eine statische HTML-Stub-Datei erzeugt hatte.

// Dies ist die CSR-Konfiguration, die bei SEO scheitert
import { createStartHandler } from '@tanstack/react-start'

export default createStartHandler({
  // kein serverseitiges Rendering
})

Die Lösung ist die Aktivierung des SSR-Handlers:

import { createStartHandler } from '@tanstack/react-start/server'

export default createStartHandler({
  // Streaming SSR ist in TanStack Start 1.x standardmäßig aktiviert
})

Diese einzelne Änderung verschob das Verdict von PARTIAL auf PASS bei denselben fünf URLs. Der vollständige Testaufbau ist auf der TanStack Ship Features-Seite im SSR-Modul beschrieben.

Pattern 4 – Streaming SSR gewinnt bei Frische und SEO

Streaming SSR gibt HTML-Chunks aus, sobald sie verfügbar sind, sodass der Crawler bereits in den ersten 100ms der Antwort bedeutsamen Inhalt sieht. Gemäß dem web.dev INP-Leitfaden misst INP die längste Interaktionsverzögerung zwischen Eingabe und dem nächsten Paint; eine Streaming-SSR-Hülle kann in 100–200ms rendern, was bedeutet, dass das erste Paint ankommt, bevor das JavaScript-Bundle fertig heruntergeladen ist. Googles Crawler profitiert davon, weil er mit dem Extrahieren von Links und Inhalten aus dem gestreamten HTML beginnen kann, ohne auf das vollständige Dokument warten zu müssen.

Die TanStack Start Streaming-SSR-Konfiguration:

// app/server.ts
import { createStartHandler } from '@tanstack/react-start/server'

export default createStartHandler({
  streaming: true,
  // Routes werden ausgeliefert, sobald Daten bereit sind
})

Der Trade-off ist Speicher. Streaming SSR hält die Verbindung länger offen als klassisches SSR; bei Cloudflare Workers ist das relevant, weil Workers nach Request-Dauer abrechnet, nicht nach CPU. Für eine SaaS auf dem kostenlosen Workers-Tarif ist das 10ms-CPU-Limit bei Streaming SSR selten ein Problem, es sei denn, es gibt eine Langschwanz-Verteilung beim route-bezogenen Datenabruf.

Pattern 5 – Selective Hydration reduziert INP um 41ms

Die größten Kosten von SSR entstehen durch Hydration: Der Client lädt das JavaScript-Bundle herunter und bindet Event-Handler an jede serverseitig gerenderte Komponente erneut. Für eine SaaS mit einem 200KB JS-Bundle kann Hydration auf einem Mittelklasse-Android-Gerät 150–250ms INP kosten. Selective Hydration verzögert die Hydration von Komponenten, die nicht im anfänglichen Viewport sichtbar sind. Gemäß der React-Dokumentation zu Selective Hydration wurde diese Technik für partielles SSR mit Server Components entwickelt, funktioniert aber ebenso gut mit TanStack Start.

import { dehydrate, HydrationBoundary } from '@tanstack/react-query'

export const Route = createFileRoute('/pricing')({
  loader: async () => {
    const plans = await fetchPlans()
    return { plans }
  },
  component: () => (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <PricingTable />
    </HydrationBoundary>
  ),
})

Die INP-Verbesserung betrug 41ms auf demselben Android-Gerät, was unseren Core Web Vitals Score von „verbesserungsbedürftig" auf „gut" im PageSpeed Insights-Test verschob. Die vollständige Core Web Vitals Analyse für SaaS finden Sie im technischen SEO-Leitfaden.

Pattern 6 – Dynamic Rendering ist der letzte Ausweg

Dynamic Rendering (user-agent-basiertes Pre-Rendering für Crawler) war 2018 noch von Google als empfohlene Problemumgehung für JavaScript SEO genannt worden. Stand Mai 2025 Googles Leitfaden hat Google Dynamic Rendering als langfristige Lösung verworfen, da cloaking-ähnliche Signale den Cluster verwirren können. Wir führen es weiterhin als Fallback für Routen ein, die kein SSR ausliefern können – interne Admin-Seiten, Debug-Ansichten –, aber die Marketing-Fläche läuft auf Streaming SSR.

Die Trade-offs, die niemand erwähnt

Ein ehrliches Wort darüber, was die Daten nicht erfassen. Der Sechs-Pattern-Test fand auf einem einzelnen Host in einer einzelnen Region statt. Googles Crawler hat verschiedene Render-Warteschlangen für verschiedene Regionen, und was in Frankfurt PASS ist, kann in São Paulo PARTIAL sein, wenn die Cloudflare-Region-Zuordnung falsch ist. Gemäß der Cloudflare Region-Dokumentation bringt Smart Placement den Worker näher an den Nutzer, bewegt aber nicht immer den Crawler näher an den Worker. Wenn Ihre SaaS global ist, planen Sie einen Testdurchlauf über mehrere Regionen und kalkulieren Sie 3–4 Wochen für die Abdeckungsvalidierung.

Der zweite Trade-off ist die Build-Zeit. Static SSG (Pattern 2) liegt mit Streaming SSR bei der Render-Abdeckung gleichauf und schneidet bei INP besser ab. Der Grund, warum wir SSG nicht standardmäßig ausliefern, ist, dass die Build-Zeiten linear mit dem Inhaltsvolumen skalieren – bei 800 Blogbeiträgen dauert unser SSG-Build 14 Minuten gegenüber 90 Sekunden bei Streaming SSR. Für eine inhaltsintensive SaaS können die operativen Kosten von SSG den SEO-Vorteil überwiegen. Für eine SaaS mit weniger als 200 Content-Seiten ist SSG immer noch die richtige Antwort.

Der dritte Trade-off sind die Kosten für serverseitiges Datenabrufen. SSR mit loader-Funktionen auf jeder Route bedeutet, dass jeder Seitenaufruf Ihre Datenebene trifft. Für eine SaaS auf Cloudflare Workers D1 ist das ein D1-Read pro Request – etwa 1ms in unserem Test. Für eine SaaS auf Postgres oder Turso ist das eine regionsübergreifende Round-Trip – 20–80ms in unserem Test. Die INP-Delta ist bedeutsam genug, um einen Edge-Cache in Betracht zu ziehen. Gemäß der Cloudflare Cache API-Dokumentation können Sie die SSR-Antwort in einen Cache-API-Aufruf einwickeln, der auf Locale + URL + User-Cohort-Hash basiert, was die serverseitigen Abrufkosten für wiederholte Besuche auf nahezu Null senkt. Die Kombination aus Streaming SSR + Edge Cache + Selective Hydration ist das, was TanStack Ship in der produktionsreifen Konfiguration ausliefert.

Wie TanStack Ship standardmäßig auf den Testsieger setzt

TanStack Ship liefert Streaming SSR mit Selective Hydration als Standard für alle Routen. Static-exportiertes SSG ist über ein einzelnes Flag in app/router.config.ts für inhaltsstabile Marketing-Seiten optional aktivierbar. Client-only Rendering ist auf Router-Ebene deaktiviert, sodass ein versäumtes Opt-in nicht stillschweigend eine CSR-only Seite ausliefert. Die Preisseite listet die Rendering-Optionen nach Tarif auf; der Vergleichs-Hub zeigt, wie sich TanStack Ships Rendering-Standard von Next.js, Remix und Astro bei derselben SaaS-Spezifikation unterscheidet.

Häufig gestellte Fragen

Rendert Google 2026 noch JavaScript?

Ja, Google rendert JavaScript in einer zweiten Indexierungswelle. Die erste Welle ist das Roh-HTML; die zweite Welle führt das JavaScript aus und indexiert das gerenderte DOM. Gemäß der Google Search Central Rendering-Dokumentation ist die zweite Welle in einer längeren Warteschlange und kostet mehr Crawl-Budget. Planen Sie für Seiten, die vom gerenderten DOM abhängen, eine längere Indexierungslatenz – und verifizieren Sie mit der URL Inspection API.

Ist SSR immer besser für SEO als CSR?

Für Seiten, die JavaScript zum Rendern von Inhalten benötigen, ja. Unser Test zeigte CSR bei 2/5 PASS in der URL Inspection API, gegenüber 5/5 PASS für jede SSR-Variante. Für Seiten, die vorgerenderte HTML-Stubs ausliefern (Blogbeiträge, Marketing-Seiten), liegt SSG bei der Render-Abdeckung gleichauf mit SSR und schlägt es bei INP. Das richtige Pattern hängt von der Aktualitätsanforderung der Seite ab.

Was ist das beste Rendering-Pattern für eine SaaS mit wöchentlichen Preisänderungen?

Streaming SSR mit Selective Hydration (Pattern 5 in unserem Test) ist der richtige Standard. Die Preisseite bleibt aktuell, weil die Route bei jedem Request geladen wird, der Crawler sieht eine vollständig gerenderte Seite in der ersten Welle und Selective Hydration hält INP unter dem Core Web Vitals „gut"-Schwellenwert. TanStack Ship liefert dies als Standard für die /pricing-Route aus; die Features-Seite beschreibt die genaue Konfiguration.

Sollte ich Dynamic Rendering für ein Admin-Dashboard verwenden?

Nein – Admin-Dashboards sind noindex und Google crawlt sie nicht. Sparen Sie Dynamic Rendering für öffentlich zugängliche Seiten, auf denen SSR operationell unmöglich ist. Für die Admin-Fläche liefern Sie eine normale SPA aus und schützen Sie sie mit Auth und einem noindex-Meta-Tag.

Wie handhabt TanStack Start die Hydration-Kosten?

TanStack Start unterstützt Selective Hydration an der Routen-Grenze. In HydrationBoundary gewickelte Routen verzögern die Hydration nicht kritischer Subtrees, bis der Nutzer scrollt oder interagiert. Die INP-Verbesserung von 41ms in unserem Test stammte aus der verzögerten Hydration der Preis-FAQ-Komponente, die auf dem Desktop unterhalb des Fold liegt und auf Mobilgeräten in einem Akkordeon. Die Technik ist in der TanStack Start-Dokumentation beschrieben und wird in TanStack Ship standardmäßig ausgeliefert.

Nächster Schritt: TanStack Ships Streaming-SSR-Konfiguration auf der Preisseite ansehen → · TanStack Ship mit anderen SSR-fähigen SaaS-Startern vergleichen → · Den SEO-Meta-Tags-Leitfaden für TanStack Start lesen →