Millionen von Websites werden mit React, Vue oder Angular gebaut – Frameworks die standardmäßig Client-Side Rendering (CSR) verwenden. Das bedeutet: Der Browser erhält zunächst leeres HTML und baut die Seite erst nach der JavaScript-Ausführung auf. Für Nutzer kaum merklich, für Suchmaschinen-Crawler eine erhebliche Herausforderung. Dieser Artikel erklärt, warum CSR SEO-Probleme verursacht und welche Rendering-Strategien die Lösung sind.

Das Grundproblem: Client-Side Rendering und Crawler

Wenn Googlebot eine normale HTML-Seite lädt, sieht er den vollständigen Inhalt sofort. Bei einer reinen React/Vue/Angular-App sieht er zunächst nur:

<!DOCTYPE html>
<html>
  <head>
    <title>My App</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/static/js/main.bundle.js"></script>
  </body>
</html>

Der eigentliche Seiteninhalt existiert zu diesem Zeitpunkt nicht. Er wird erst erzeugt, wenn der Browser JavaScript ausführt – ein Prozess den nicht alle Crawler vollständig oder zuverlässig durchführen.

Googles Umgang mit JavaScript: Google kann JavaScript rendern, aber mit Einschränkungen. Die Verarbeitung erfolgt in einer zweistufigen Pipeline: Erst wird die Seite gecrawlt, dann später (Stunden bis Tage) gerendert. Während dieser Zeit fehlt der Inhalt für das Ranking.

Seiten mit Client-Side Rendering werden von Google im Schnitt 3–7 Tage später vollständig indexiert als SSR-Seiten – ein kritischer Nachteil für neue Inhalte die schnell ranken sollen.

Die vier Rendering-Strategien im Überblick

Client-Side Rendering (CSR)

Ablauf: Server liefert leeres HTML + JS-Bundle. Browser führt JS aus, rendert Inhalt.

SEO-Bewertung: Problematisch. Langsame Indexierung, schlechtere Core Web Vitals (LCP), Crawl-Budget-Probleme bei großen Sites.

Geeignet für: Web-Apps hinter Login, Dashboards, Tools ohne organischen Traffic-Anspruch.

Server-Side Rendering (SSR)

Ablauf: Server rendert vollständiges HTML für jede Anfrage, liefert es direkt aus.

SEO-Bewertung: Sehr gut. Crawler sehen sofort vollständigen Inhalt.

Nachteil: Serverauslastung bei hohem Traffic, jede Anfrage braucht einen Render-Prozess.

Frameworks: Next.js (React), Nuxt.js (Vue), Angular Universal

Static Site Generation (SSG)

Ablauf: HTML wird zum Build-Zeitpunkt vorab gerendert und als statische Dateien ausgeliefert.

SEO-Bewertung: Ausgezeichnet. Vollständiges HTML, maximale Performance, minimale TTFB.

Nachteil: Bei häufig wechselnden Inhalten muss der Build neu ausgelöst werden.

Frameworks: Next.js, Nuxt.js, Astro, Gatsby

Incremental Static Regeneration (ISR)

Ablauf: Seiten werden statisch generiert, aber im Hintergrund nach einem definierten Intervall neu gebaut.

SEO-Bewertung: Sehr gut – kombiniert Performance von SSG mit Aktualität von SSR.

Verfügbar in: Next.js (nativ), Nuxt.js (experimentell)

React SEO: Next.js als Lösung

Reines React (Create React App) ist für SEO-relevante Seiten nicht geeignet. Next.js ist die Standard-Lösung um React SEO-tauglich zu machen.

Next.js SEO-Grundkonfiguration:

// pages/index.js – SSG (Standard)
export async function getStaticProps() {
  const data = await fetchData();
  return {
    props: { data },
    revalidate: 3600, // ISR: Seite nach 1 Stunde neu bauen
  };
}

// Für dynamische Seiten
export async function getStaticPaths() {
  return {
    paths: [{ params: { slug: 'artikel-1' } }],
    fallback: 'blocking', // SSR für unbekannte Pfade
  };
}

Meta-Tags mit next/head:

import Head from 'next/head';

export default function Page({ title, description }) {
  return (
    <>
      <Head>
        <title>{title}</title>
        <meta name="description" content={description} />
        <link rel="canonical" href="https://example.de/seite/" />
        <meta property="og:title" content={title} />
        <meta property="og:description" content={description} />
      </Head>
      {/* Seiteninhalt */}
    </>
  );
}

Ab Next.js 13 wird das App Router-System mit der Metadata API bevorzugt:

// app/page.tsx
export const metadata = {
  title: 'Seitentitel',
  description: 'Meta-Beschreibung',
  alternates: {
    canonical: 'https://example.de/seite/',
  },
};

Vue SEO: Nuxt.js als Standard

Vue.js ist ähnlich wie React ohne Server-Rendering für SEO problematisch. Nuxt.js ist das Vue-Äquivalent zu Next.js.

<!-- Nuxt 3: useHead() für Meta-Tags -->
<script setup>
useHead({
  title: 'Seitentitel',
  meta: [
    { name: 'description', content: 'Meta-Beschreibung' },
    { property: 'og:title', content: 'Seitentitel' },
  ],
  link: [
    { rel: 'canonical', href: 'https://example.de/seite/' },
  ],
})
</script>

Nuxt 3 nutzt standardmäßig Hybrid-Rendering: SSG für statische Seiten, SSR für dynamische, Client-Side für interaktive Elemente. Das ist eine ausgezeichnete Konfiguration für SEO.

Angular SEO: Angular Universal

Angular ist das am schwierigsten zu optimierende Framework für SEO, da es ursprünglich ausschließlich für SPAs konzipiert wurde.

Angular Universal fügt SSR zu Angular hinzu:

// In server.ts
const app = express();
app.engine('html', ngExpressEngine({
  bootstrap: AppServerModule,
}));

// Pre-rendering für statische Routen
const routes = [
  { path: '/startseite' },
  { path: '/ueber-uns' },
];

Praxistipp: Wenn Sie ein neues Projekt mit SEO-Anforderungen starten, wählen Sie Next.js (React) oder Nuxt.js (Vue) von Anfang an – diese Frameworks haben SSR/SSG eingebaut und sind produktionserprobt. Reines React/Vue/Angular für öffentlich sichtbare Seiten ist eine technische Schuld die Sie früher oder später zurückzahlen müssen.

Häufige JavaScript-SEO-Probleme und Lösungen

Problem: Lazy Loading verzögert Inhalt JavaScript-geladene Inhalte die erst nach einem User-Trigger erscheinen (Tabs, Akkordeons) werden von Google möglicherweise nicht vollständig indexiert.

Lösung: Wichtigen Content initial im HTML bereitstellen, nicht hinter Klick-Triggern verstecken.

Problem: Dynamic Meta-Tags funktionieren nicht Bei CSR ändert sich der <title>-Tag oft erst nach JS-Ausführung.

Lösung: SSR/SSG für alle öffentlichen Seiten. Alternativ: react-helmet oder vue-meta mit SSR kombinieren.

Problem: Infinite Scroll und Paginierung Googlebots Render-Budget ist begrenzt – bei Infinite Scroll werden spätere Inhalte möglicherweise nicht gecrawlt.

Lösung: Klassische Paginierung mit URL-Wechsel (oder rel=next/prev) beibehalten. Infinite Scroll nur für eingeloggte Nutzer.

Problem: JavaScript-Fehler blockieren Rendering Ein einzelner JS-Fehler kann verhindern, dass Googlebot die gesamte Seite rendert.

Lösung: Error Boundaries in React, Fehlerüberwachung mit Sentry. Regelmäßige Crawl-Tests mit puppeteer oder Screaming Frog.

JavaScript-Fehler auf kritischen Seiten blockieren in 100 % der Fälle das Rendering für Googlebot – eine in Search Console oft unsichtbare Ursache für schlechte Rankings.

Testing: Wie sieht Googlebot Ihre Seite?

Google Search Console – URL-Inspektion: Zeigt gerendertes HTML + Screenshot wie Googlebot die Seite sieht. Unverzichtbar für JavaScript-Debugging.

Screaming Frog (Spider → JS Rendering): Crawlt mit Chrome-Engine, kann Unterschiede zwischen gecrawltem und gerenderten HTML identifizieren.

Puppeteer / Playwright: Programmatisches Testing des gerenderten Inhalts für automatisierte Qualitätssicherung.

# Schneller Test: Seiteninhalt mit curl (kein JS) vs. browser
curl -s https://example.de/ | grep -i "hauptinhalt"
# Wenn leer: CSR ohne SSR

Bing und andere Suchmaschinen: Während Google JavaScript rendern kann (wenn auch verzögert), haben andere Suchmaschinen wie Bing, DuckDuckGo oder Yandex deutlich eingeschränktere JavaScript-Fähigkeiten. Für maximale Indexierbarkeit über alle Suchmaschinen hinweg ist SSR/SSG die einzige zuverlässige Lösung.

JavaScript Frameworks und SEO: React, Vue, Angular