SEO für React-Anwendungen: So bringst du dein SPA in die Top 10

Lass mich mit einer kleinen Wahrheit anfangen, die viele Frontend-Entwickler*innen seit Jahren umtreibt: React ist nicht das Problem. Das Rendering ist es. Während Tech-Giganten wie Instagram, Airbnb und Netflix React seit über einem Jahrzehnt produktiv einsetzen und Google weiterhin massiv in das Verständnis von JavaScript investiert, hält sich hartnäckig das Gerücht: „SPAs sind unsichtbar für Google.“ Falsch – aber es steckt ein Kern Wahrheit darin. Und genau die schauen wir uns heute an.

Und weil wir Montag haben und ich versprochen habe, euch aktuell zu halten: In den letzten Tagen ist die Diskussion um die „Zwei-Wellen-Indexierung“ von Google wieder richtig Fahrt aufgenommen. Die Community analysiert gerade, warum manche JavaScript-Seiten Wochen brauchen, bis sie in den Index wandern, während statische Seiten nach Stunden da sind. Dazu kommt, dass immer mehr KI-Crawler wie GPTBot, ClaudeBot oder PerplexityBot durch eure Server strömen – und die meisten davon führen keinerlei JavaScript aus. Wer also nur auf Client-Side-Rendering setzt, zeigt diesen Bots wortwörtlich eine leere Seite. Grund genug, dem Thema heute auf den Grund zu gehen.

Warum Google bei React-Anwendungen eigentlich in die Bredouille kommt

Der Standardweg einer klassischen React-App: Der Server schickt ein fast leeres HTML-Skelett, in dem nur ein <div id="root"></div> wartet. Der komplette Content entsteht erst im Browser, nachdem das JavaScript-Bundle geladen, geparst und ausgeführt wurde. Für euch als User ist das okay – für Suchmaschinen bedeutet es die berüchtigte zweite Welle:

Erste Welle: Googlebot crawlt das HTML und findet nur leere Hülsen. Die Seite wird in die Render-Queue geschoben – je nach Kapazität kann das Stunden, Tage oder sogar Wochen dauern.
Zweite Welle: Googlebot rendert die Seite mit einer Chromium-Instanz, führt JavaScript aus und indexiert endlich den echten Content.

Das klingt erstmal harmlos, hat aber drei fiese Konsequenzen: Latenz (euer neuer Blogpost ist erst morgen oder übermorgen im Index), Ressourcenverschwendung (Crawl-Budget verpufft an leeren Seiten) und Risiko (jeder Rendering-Fehler, jedes abgelehnte Script von Drittanbietern und jede API-Auszeit macht eure Seite für den Index unsichtbar). Und dann ist da noch die Tatsache, dass Googlebot eurem Code nicht vertraut, ohne Limit zu raten: Abhängige Ressourcen wie Fonts, CSS oder Datenendpunkte, die mit bis zu 60 Sekunden Timeout laden, dürfen gerne gecacht werden.

Google selbst ist da übrigens bemerkenswert transparent. In den JavaScript-SEO-Grundlagen aus Search Central steht wörtlich, dass Googlebot Seiten zum Crawlen und Rendern in separaten Queues ablegt – und dass das Rendern „nicht sofort“ passiert. Wer das einmal gelesen hat, versteht, warum die Empfehlung der Branche inzwischen einstimmig ist: Liefert euren Content schon im ersten HTML aus.

Die Zauberwörter: SSR, SSG und Streaming

Die gute Nachricht: Ihr müsst euer React nicht wegwerfen, um im Ranking zu landen. Ihr müsst nur euer Rendering-Modell anpassen. Die drei üblichen Verdächtigen:

SSR (Server-Side Rendering): Jeder Request rendert die Seite auf dem Server und liefert fertiges HTML aus. Der User bekommt sofort Inhalte, Google ebenfalls. Kostenpunkt: mehr Serverlast.
SSG (Static Site Generation): Die Seiten werden beim Build einmalig erzeugt und als statische Dateien ausgeliefert. Maximal schnell, maximal crawlbar – aber bei sehr dynamischen Inhalten unpraktisch.
ISR (Incremental Static Regeneration): Der Kompromiss: Statische Seiten, die im Hintergrund regelmäßig neu gebaut werden.

In der Praxis läuft das heute fast immer über ein Meta-Framework. Wer React produktiv betreibt, nutzt in 2026 in überwältigender Mehrheit Next.js – oder bewusst das neue Kind im Block, Remix. In Next.js wählt ihr das Rendering pro Seite, ganz nach Bedarf:

// app/products/[slug]/page.tsx
import { notFound } from "next/navigation";

export const revalidate = 3600; // ISR: stündlich neu generieren

export default async function ProductPage({ params }) {
  const { slug } = await params;
  const product = await getProduct(slug);

  if (!product) notFound();

  return (
    <main>
      <h1>{product.title}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Der Clou: Mit dem App Router von Next.js 14+ sind Server Components standardmäßig Server-seitig. Euer SEO-relevanter Content landet im ersten HTML, die Hydration auf dem Client passiert im Hintergrund. Genau das ist der Sweet Spot für Suchmaschinen.

React Server Components: Das SEO-Update, das keiner bemerkt hat

Hier wird es spannend, denn React 19 hat mit den Server Components die Spielregeln geändert. RSCs laufen komplett auf dem Server, streamen ihr Ergebnis als fertiges HTML zum Client und schicken nicht einmal mehr JavaScript-Bundle-Code für die Komponente selbst. Für SEO bedeutet das im Klartext: kein leerer Content mehr, keine Rendering-Welle, kein verlorenes Crawl-Budget. Google kriegt den kompletten Text direkt beim ersten Zugriff.

Das Beste daran: Ihr entscheidet Komponente für Komponente. Die produktbeschreibende Textzeile wird ein Server Component, der interaktive Warenkorb-Button bleibt ein Client Component. Ihr müsst also nicht euer ganzes Architektur-Hirn umbauen, sondern nur euren Content-Teil konsequent serverseitig halten. Ein simples Beispiel:

// Server Component (Standard)
export default async function BlogPost() {
  const post = await fetchPostFromCMS();
  return <article>{post.content}</article>;
}

// Client Component (nur für Interaktivität)
"use client";
export function LikeButton() {
  const [liked, setLiked] = useState(false);
  return (
    <button onClick={() => setLiked(true)}>
      {liked ? "Gefällt mir ❤️" : "Like"}
    </button>
  );
}

Ein Wort der Vorsicht: Gerade wer noch auf dem App Router unterwegs ist und "use client" großzügig streut, verschenkt das Potenzial. Je mehr von eurer Seite in Client Components wandert, desto mehr nähert ihr euch wieder dem alten SPA-Problem an.

Metadata: Das kleine SEO-Goldstück, das alle vergessen

Selbst wenn eure Seite perfekt serverseitig gerendert wird: Ohne korrekte Metadaten bleibt Google beim Kaltstart ratlos. In Next.js erledigt ihr Title, Description und Open Graph elegant über die zentrale Metadata-API – ihr könnt sie sogar in Server Components definieren, damit jede Route ihre eigenen Werte bekommt:

import type { Metadata } from "next";

export async function generateMetadata({ params }): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPost(slug);

  return {
    title: post.title,
    description: post.excerpt,
    openGraph: {
      title: post.title,
      images: [{ url: post.coverImage }],
    },
  };
}

Für alle, die lieber beim klassischen React bleiben: Der moderne Weg ist react-helmet-async – aber ehrlich gesagt rate ich jedem mit ambitionierten SEO-Zielen zum Framework-Wechsel auf Next.js. Der App Router macht das, wofür ich früher drei Libraries und ein Build-Script brauchte, jetzt out of the box.

Structured Data: Maschinen freundlich machen

Rich Results sind das i-Tüpfelchen – und sie funktionieren in React genauso gut wie in jeder statischen Seite, weil sie einfach als JSON-LD im HTML landen. Ein Must-Have für jeden eCommerce- oder Blog-Auftritt. Next.js unterstützt das schick über die jsonLd-Property im Metadata-Objekt, aber auch ein klassisches Script-Tag mit type="application/ld+json" tut’s:

import Script from "next/script";

export default function ProductPage({ product }) {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Product",
    name: product.title,
    description: product.description,
    offers: {
      "@type": "Offer",
      price: product.price,
      priceCurrency: "EUR",
    },
  };

  return (
    <main>
      <Script
        id="product-jsonld"
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <h1>{product.title}</h1>
    </main>
  );
}

Profi-Tipp: Testet euer Markup regelmäßig im Rich Results Test und im Schema Validator – beide liefern euch Feedback, ob Google die Daten wirklich versteht oder ob euer JSON nur euch selbst glücklich macht.

Routing: Saubere URLs statt Client-Router-Gefummel

Ein Klassiker bei handgebauten React-SPAs: Der gute alte BrowserRouter aus React Router macht auf den ersten Blick alles richtig, erzeugt aber oft URLs, die nur mit JavaScript funktionieren. Wenn ihr bei einem Router mit einer index.html für alles landen wollt, müsst ihr den Server konfigurieren, damit er für eure Route-Dateien statt eines 404 das richtige HTML ausliefert. Das sieht dann so aus:

// Nginx für ein React-SPA
server {
  listen 80;
  server_name example.com;
  root /var/www/my-spa;

  # Alle Routen auf die index.html umleiten
  location / {
    try_files $uri /index.html;
  }

  # Aber statische Assets direkt ausliefern
  location /_next/static/ {
    alias /var/www/my-spa/.next/static/;
  }
}

Und weil wir gerade beim Thema sind: Egal ob SPA oder Next.js – vermeidet Abhängigkeit von #-Fragmente-URLs. Google behandelt sie zwar, aber sie sind ein schlechter Freund fürs Teilen und fürs Crawling. Setzt auf echte, sprechende Pfade wie /produkte/lederschuhe statt /#/produkt?id=42.

Core Web Vitals: Wo React euch das Leben schwermacht

Jetzt wird’s praktisch. Selbst wenn Google euren Content rendert: Die Core Web Vitals bleiben ein Ranking-Faktor, und hier haben SPAs ein strukturelles Problem. LCP, INP und CLS sind bei schweren React-Bundles oft mangelhaft, weil der Client so viel arbeiten muss. Die üblichen Übeltäter:

Code-Splitting ist Pflicht. Teilt euer Bundle mit React.lazy() und Suspense, damit nur das lädt, was gerade gebraucht wird.
Bilder: next/image oder loading="lazy", width und height immer setzen – sonst springt das Layout und der CLS-Score explodiert.
Fonts: font-display: swap nicht vergessen, damit Text sofort erscheint.

import { lazy, Suspense } from "react";

const HeavyChart = lazy(() => import("./HeavyChart"));

export default function Dashboard() {
  return (
    <Suspense fallback={<div>Lade Diagramm…</div>}>
      <HeavyChart />
    </Suspense>
  );
}

Wer sein SPA nicht auf SSR/SSG umbaut, kann zumindest mit Code-Splitting und Bild-Optimierung LCP und INP deutlich verbessern. Und ganz wichtig: Testet nicht nur im Lighthouse, sondern im echten Feld – mit echten Nutzern und echten Geräten, denn die sind das, was Google wertet.

Und die KI-Crawler? GPTBot & Co. wollen euer HTML

Der Elefant im Raum, der 2026 nicht mehr ignoriert werden kann: Die KI-Bots von OpenAI, Anthropic und Perplexity durchforsten das Web in Massen – und die allermeisten davon führen kein JavaScript aus. Für eine reine Client-Side-React-App bedeutet das: Sie sehen euer leeres <div id="root"> und ziehen weiter. Kein Wunder, dass sich das Buzzword „LLM-Optimierung“ etabliert hat.

Der beste Schutz gegen unsichtbares Content-Rendern ist auch hier dasselbe Rezept: Server-seitiges Rendering oder SSG, damit das komplette HTML ausgeliefert wird. Und wer mag, kann sich per robots.txt sogar überlegen, welche Bots er überhaupt reinlässt – aber das ist eine Strategiefrage, die ihr je nach Business entscheidet.

Euer SEO-Playbook für React: Die 7-Punkte-Checkliste

Rendert serverseitig. SSR oder SSG über Next.js ist 2026 der Standard – nicht die Ausnahme.
Setzt auf Server Components für alles, was Content ist; Client Components nur für Interaktivität.
Pflegt eure Metadaten pro Route über die Metadata-API.
Deklariert strukturierte Daten (JSON-LD) für Produkte, Artikel und FAQs.
Nutzt saubere URLs und konfiguriert euren Server (Nginx, Vercel, Cloudflare) korrekt für Routing und Redirects.
Optimiert Core Web Vitals: Code-Splitting, Bilder, Fonts – gemessen im Feld, nicht nur im Lab.
Prüft mit echten Tools: Google Search Console (Rendern von URLs!), Mobile-Friendly-Test, Rich Results Test.

Fazit: React und SEO sind 2026 ein Liebespaar – wenn ihr es richtig angeht

Die gute Nachricht zum Schluss: Ihr müsst euer React nicht verbannen, um im Google-Index zu glänzen. Die schlechte: Wer weiter auf reines Client-Side-Rendering setzt, lebt gefährlich – nicht nur wegen Googles Zwei-Wellen-Indexierung, sondern zunehmend auch wegen der KI-Crawler, die euer leeres HTML-Getrüst nie zu sehen bekommen.

Mit Next.js, React Server Components und einem konsequenten Fokus auf SSR/SSG, saubere Metadaten und Core Web Vitals stellt ihr euer SPA auf die Gewinnerseite. Die Technik dafür ist da, sie ist ausgereift, und Google belohnt euch dafür mit schnellerer Indexierung und – im Zweifel – besseren Rankings. Also: Weg vom <div id="root"> und hin zum Server-Side-Rendering. Euer Content hat es verdient, gesehen zu werden. Und jetzt: Ab in die Search Console, die Render-Queue wartet!

SEO für React-Anwendungen