SEO für React: So werden React-Websites bei Google sichtbar

React und gute Rankings passen zusammen. Es kommt darauf an, was Ihr Server beim ersten Abruf ausliefert: fertiges HTML mit Inhalt, Title, Meta-Description und Canonical oder eine fast leere Seite, die erst im Browser per JavaScript Inhalt bekommt. Für eine öffentliche Unternehmenswebsite auf React-Basis brauchen Sie deshalb vier Dinge: die passende Rendering-Strategie, Metadaten im Server-HTML, crawlbare URLs und Links sowie gute Core Web Vitals. Hier lesen Sie, wie das in der Praxis aussieht, wie Sie Ihre eigene Seite prüfen und womit Sie anfangen sollten.

TL;DR

• React ist nicht schlecht für SEO. Problematisch ist reines Client-Side Rendering (CSR) bei Seiten, die gefunden werden sollen.
• Für Marketing-, Produkt- und Blogseiten sind Server-Side Rendering (SSR) oder Static Site Generation (SSG) die richtige Wahl, am einfachsten über ein Framework wie Next.js oder React Router.
• Title, Meta-Description, Canonical und strukturierte Daten gehören ins ausgelieferte HTML und dürfen nicht erst per JavaScript gesetzt werden.
• Echte URLs, <a href>-Links und korrekte Statuscodes entscheiden darüber, ob Google Ihre Seiten überhaupt findet und richtig einordnet.
• SSR löst nicht alles: Hydration, Server-Antwortzeit und Caching bestimmen, ob die Core Web Vitals am Ende gut ausfallen.

Inhaltsverzeichnis

• Warum React-Seiten bei Google oft unsichtbar bleiben
• Rendering-Strategien im Vergleich
• Welche Strategie zu welcher Seite passt
• Title, Meta-Tags und Canonical gehören ins Server-HTML
• Routing, Links und Statuscodes
• Performance: Core Web Vitals in React-Projekten
• So prüfen Sie Ihre React-Website in sieben Schritten
• Unsere Sicht: Erst die Architektur, dann der Feinschliff
• Unterstützung für Ihr React-Projekt
• Häufige Fragen zu SEO mit React
• Quellen

Warum React-Seiten bei Google oft unsichtbar bleiben

Eine klassische React-Single-Page-Application (SPA) liefert beim ersten Abruf meist nur ein Gerüst aus. Im Quelltext steht dann etwa Folgendes:

<body>
  <div id="root"></div>
  <script src="/assets/index.js"></script>
</body>

Überschriften, Texte, interne Links und Meta-Tags entstehen erst, wenn der Browser das JavaScript-Bundle geladen und ausgeführt hat. Googlebot kann JavaScript rendern, aber das kostet Zeit und Rechenleistung, und nicht jeder Crawler führt JavaScript so zuverlässig aus wie Google. Wer auf das Rendern angewiesen ist, macht sich von einem zusätzlichen, fehleranfälligen Schritt abhängig.

Die Folgen lassen sich messen. Eine 2025 veröffentlichte Vergleichsstudie zu SPA, SSR und SSG kommt zu dem Ergebnis, dass reine Client-Side-Rendered-Anwendungen bei SEO-Sichtbarkeit und Ladezeiten (FCP und LCP) deutlich schlechter abschneiden als serverseitig oder statisch gerenderte Seiten. Bei SSR lag der First Contentful Paint dort oft bei rund 0,2 Sekunden, während reine SPAs ihre Inhalte deutlich später zeigen.

Für viele B2B-Unternehmen ist das mehr als ein Technikproblem. Leistungs-, Produkt- und Fachartikelseiten sind oft der erste Kontakt mit neuen Kunden. Wenn diese Seiten nur verzögert oder unvollständig indexiert werden, fehlen Anfragen im Vertrieb. Wie eng organische Sichtbarkeit und Umsatz zusammenhängen, zeigt dieser Beitrag darüber, wie SEO den Vertrieb zum Wachstumsmotor macht. Die technische Architektur Ihrer React-Website entscheidet mit darüber, ob dieser Kanal überhaupt funktioniert.

Rendering-Strategien im Vergleich

Die wichtigste SEO-Entscheidung in einem React-Projekt fällt, bevor die erste Meta-Description geschrieben ist: Wo und wann entsteht das HTML? Die folgende Übersicht ordnet die gängigen Strategien ein.

Die Richtung ist eindeutig. Das Chrome-Team empfiehlt in seinem Leitfaden zum Rendering im Web, serverseitiges oder statisches Rendering einem Ansatz mit vollständiger Rehydrierung vorzuziehen. Auch das React-Team selbst empfiehlt für neue Apps und Websites den Start mit einem Framework, etwa Next.js oder React Router, weil dort Routing, Datenabruf, SSR und SSG bereits eingebaut sind. Das frühere Starter-Tool Create React App wurde im Februar 2025 offiziell eingestellt, mit dem Hinweis, auf ein Framework zu migrieren.

Dass sich der Aufwand auch bei sehr großen Plattformen lohnt, zeigt eine Fallstudie über den Website-Baukasten Wix: Der Umstieg auf Server-Side Rendering brachte dort sowohl schnellere Sichtbarkeit der Seiten als auch eine bessere Indexierung. Gleichzeitig wurde die Infrastruktur komplexer. Diese Abwägung zwischen Umsetzungskosten und erwartetem Wachstum müssen auch Sie treffen.

Welche Strategie zu welcher Seite passt

In der Praxis braucht kaum eine Website nur eine einzige Strategie. Moderne Frameworks erlauben es, pro Route zu entscheiden. Diese Fragen helfen bei der Zuordnung:

• Soll die Seite in Google erscheinen? Wenn nein, etwa beim Kundenkonto oder einem internen Konfigurator, ist CSR völlig in Ordnung.
• Wie oft ändert sich der Inhalt? Selten geänderte Seiten wie Leistungsbeschreibungen, Über-uns oder Fachartikel sind ideal für SSG.
• Hängt der Inhalt vom Nutzer oder von Echtzeitdaten ab? Dann ist SSR sinnvoll, idealerweise mit einem Cache für den öffentlichen Teil.
• Wie viele Seiten gibt es? Bei Tausenden Produkt- oder Integrationsseiten verlängert reines SSG die Build-Zeiten stark. Inkrementelle Generierung ist hier oft der bessere Kompromiss.
• Welche Infrastruktur steht zur Verfügung? SSR braucht einen laufenden Server oder Edge-Funktionen, SSG kommt mit einem CDN aus.

Ein typisches Beispiel aus dem B2B-Umfeld: Ein SaaS-Anbieter betreibt Startseite, Leistungsseiten und Blog statisch generiert, die Preisseite serverseitig gerendert, damit aktuelle Konditionen sofort sichtbar sind, und die eigentliche Anwendung hinter dem Login als klassische SPA. Damit erhält jede Seitenart die Strategie, die zu ihr passt. Wie sich diese Architektur in Pipeline statt bloßem Traffic übersetzt, beschreiben wir im Beitrag zu B2B SaaS SEO.

Title, Meta-Tags und Canonical gehören ins Server-HTML

Jede indexierbare Route braucht eigene Metadaten. Dazu gehören mindestens:

• ein eindeutiger <title>, der Thema und Nutzen der Seite nennt,
• eine meta description, die zum Klick einlädt,
• ein Canonical-Tag mit der absoluten, bevorzugten URL,
• ein robots-Meta-Tag, wenn eine Seite bewusst nicht indexiert werden soll,
• Open-Graph-Tags für die Vorschau in LinkedIn, Slack oder Teams,
• bei mehrsprachigen Seiten hreflang-Angaben,
• strukturierte Daten als JSON-LD, etwa für Organisation, Artikel oder FAQ.

In einer reinen SPA setzen viele Teams diese Angaben mit Bibliotheken wie React Helmet. Das ändert den Dokumentkopf aber erst, nachdem das JavaScript gelaufen ist. Im ausgelieferten HTML steht dann für jede Route derselbe Standard-Title, oft der Name der App. Social-Media-Vorschauen, die kein JavaScript ausführen, zeigen entsprechend nichts Sinnvolles.

Besonders heikel ist das Canonical-Tag. Google beschreibt in seiner Dokumentation, wie Sie eine kanonische URL angeben, und nennt die Methoden nach der Stärke ihres Signals. Wird das Canonical erst per JavaScript eingefügt, sieht der Crawler beim ersten Abruf eine Version ohne Kanonisierung. Bei großen Websites mit Filtern, Parametern oder Tracking-URLs führt das schnell zu Duplikaten und falsch gewählten Hauptversionen. Die Regel lautet deshalb: Canonical immer im Server- oder Build-HTML ausgeben, nie erst durch Client-Logik setzen, und nie zwei widersprüchliche Canonicals in einer Seite.

In Next.js definieren Sie Metadaten pro Seite über die eingebaute Metadaten-Schnittstelle, React Router bietet pro Route einen eigenen Export für Meta-Angaben. Beide schreiben die Tags beim Rendern auf dem Server direkt in den <head>. Prüfen Sie danach im Quelltext, ob wirklich jede Seite ihren eigenen Title und ihr eigenes Canonical trägt.

Routing, Links und Statuscodes

Auch wenn das HTML stimmt, kann Google eine React-Website nur so gut erfassen, wie ihre Struktur es zulässt. Vier Punkte sehen wir in Audits immer wieder.

Echte URLs statt Hash-Routing

Adressen wie beispiel.de/#/leistungen stammen aus älteren SPA-Setups. Alles nach dem # ist für Suchmaschinen kein eigenständiger Pfad, solche Seiten lassen sich kaum sauber indexieren. Nutzen Sie echte Pfade wie beispiel.de/leistungen, die der Server bei direktem Aufruf auch selbst ausliefert.

Links als <a href>

Navigation über onClick-Handler auf div– oder button-Elementen ist für Crawler unsichtbar, weil sie Links über das href-Attribut finden. Die Link-Komponenten von Next.js und React Router rendern echte <a href>-Elemente, nutzen Sie sie konsequent, auch in Teasern, Karten und Mega-Menüs.

Korrekte Statuscodes

Eine SPA antwortet auf jede URL mit dem Code 200, auch wenn die Route nicht existiert und die App nur „Seite nicht gefunden“ anzeigt. Google bewertet solche Seiten als Soft-404. Mit SSR können Sie für fehlende Inhalte echte 404- oder 410-Codes und für umgezogene Seiten serverseitige 301-Weiterleitungen ausgeben. Weiterleitungen per JavaScript sind nur die Notlösung.

Crawling nicht versehentlich blockieren

Wenn die robots.txt Verzeichnisse mit JavaScript- oder CSS-Dateien sperrt, kann Google Ihre Seiten nicht vollständig rendern. Welche Regeln sinnvoll sind, lesen Sie in unserem Beitrag zur robots.txt für SEO. Ergänzen Sie eine XML-Sitemap, die automatisch aus Ihren Routen erzeugt wird und nur indexierbare, kanonische URLs enthält.

Performance: Core Web Vitals in React-Projekten

Google empfiehlt Website-Betreibern, gute Core Web Vitals zu erreichen. Die Zielwerte: Largest Contentful Paint (LCP) innerhalb von 2,5 Sekunden, Interaction to Next Paint (INP) unter 200 Millisekunden und Cumulative Layout Shift (CLS) höchstens 0,1. Gute Werte garantieren kein Top-Ranking, sind aber Teil der Ranking-Systeme, die Page Experience bewerten.

React-Projekte stolpern dabei über typische Stellen:

Hydration. Auch eine serverseitig gerenderte Seite muss im Browser „hydriert“ werden: React führt das JavaScript erneut aus und verbindet es mit dem HTML, damit Buttons und Formulare reagieren. Ist das Bundle groß, blockiert diese Phase den Hauptthread, und der INP leidet trotz sauberer Indexierung. Der web.dev-Leitfaden zum Rendering beschreibt Streaming und schrittweise Hydration als Wege, diese Last zu verteilen. In Next.js mit React Server Components gelangt Code, der keine Interaktivität braucht, gar nicht erst in den Browser.

Server-Antwortzeit. Eine SPA liegt meist statisch auf einem CDN. SSR dagegen erzeugt HTML bei jedem Request, was die Time to First Byte (TTFB) erhöhen kann. Als Faustregel nennt web.dev eine TTFB von 0,8 Sekunden oder weniger. Wer SSR ohne HTML-Caching betreibt, verschenkt den Geschwindigkeitsvorteil wieder. Cachen Sie öffentliche Seiten am CDN oder setzen Sie wo möglich auf statische oder inkrementelle Generierung.

Bundle und Medien. Laden Sie Komponenten unterhalb des sichtbaren Bereichs nachträglich (Code-Splitting, React.lazy), geben Sie Bildern feste Abmessungen gegen Layoutverschiebungen, liefern Sie moderne Bildformate aus und laden Sie das LCP-Bild nicht verzögert. Prüfen Sie Drittanbieter-Skripte für Chat, Tracking und Consent-Banner kritisch: Sie sind oft die größten INP-Bremsen.

Google selbst rät dazu, sich nicht nur auf ein oder zwei Aspekte der Page Experience zu konzentrieren. SSR und gute Messwerte sind die Voraussetzung, entscheidend bleibt, ob die Seite die Frage des Nutzers schnell und vollständig beantwortet.

So prüfen Sie Ihre React-Website in sieben Schritten

Ob Ihre Seite ein Problem hat, lässt sich in etwa einer Stunde feststellen:

1. Quelltext ansehen. Öffnen Sie eine wichtige Seite und drücken Sie Strg+U. Stehen Hauptüberschrift, Fließtext und Links im Quelltext, oder nur ein leeres div? Der Elemente-Tab der Entwicklertools zeigt das gerenderte DOM und ist dafür kein Ersatz.
2. JavaScript deaktivieren. Laden Sie die Seite mit abgeschaltetem JavaScript. Was dann fehlt, hängt vom Rendern ab.
3. URL-Prüfung in der Google Search Console. Der Live-Test zeigt den gerenderten HTML-Code und blockierte Ressourcen aus Sicht von Googlebot.
4. Bericht zur Seitenindexierung auswerten. Viele URLs mit „Gecrawlt – zurzeit nicht indexiert“ oder Soft-404 sind bei React-Seiten ein typisches Warnsignal.
5. Metadaten pro Route vergleichen. Prüfen Sie stichprobenartig, ob Title, Description und Canonical je Seite eindeutig sind und auf die richtige URL zeigen.
6. Felddaten der Core Web Vitals prüfen. Der Bericht in der Search Console und PageSpeed Insights zeigen echte Nutzerdaten. Labormessungen allein reichen nicht.
7. Crawl mit und ohne JavaScript-Rendering. Ein SEO-Crawler, der beide Modi beherrscht, zeigt, welche internen Links erst nach dem Rendern auftauchen.

Wenn Sie tiefer einsteigen möchten, finden Sie in unserem Leitfaden zu JavaScript SEO für dynamische Websites weitere Prüfmethoden. Einen Überblick über Indexierung, Crawling und Performance gibt unsere Seite zu Technical SEO.

Unsere Sicht: Erst die Architektur, dann der Feinschliff

Wir arbeiten an der Schnittstelle von technischem SEO und Softwareentwicklung, mit praktischer Erfahrung in React und Next.js. In React-Projekten sehen wir selten, dass es an Wissen über Meta-Tags fehlt. Es fehlt an der Reihenfolge. Teams optimieren Descriptions, während Google die Hälfte der Seiten nicht indexiert, oder sie investieren in Content, der in einem leeren HTML-Gerüst verschwindet.

Deshalb priorisieren wir konsequent statt eine lange To-do-Liste abzuliefern. Zuerst klären wir, ob die geschäftskritischen Seiten im ausgelieferten HTML vollständig sind und indexiert werden. Danach folgen Statuscodes, Canonicals und interne Verlinkung, dann Performance und Hydration, zuletzt der inhaltliche Feinschliff. Jede Maßnahme bekommt eine messbare Kennzahl, damit Sie sehen, was sie bewirkt hat.

Wichtig ist uns auch Ehrlichkeit beim Aufwand: Nicht jede SPA muss komplett neu gebaut werden. Oft reicht es, die öffentlichen Seiten in ein Framework mit SSR oder SSG zu überführen und die eigentliche Anwendung so zu lassen, wie sie ist. Weil Analyse und Umsetzung bei uns in einer Hand liegen, gehen zwischen SEO-Empfehlung und Entwicklerteam keine Details verloren. Wie wir dabei vorgehen, beschreibt unser SEO-Prozess von der Analyse bis zur Messung, mehr über unseren Hintergrund lesen Sie auf der Seite über Aliniyaz.

— Aliniyaz

Unterstützung für Ihr React-Projekt

Sie möchten wissen, wo Ihre React-Website konkret Sichtbarkeit verliert? Mit SEO Foundation ab 999 € einmalig bekommen Sie einen strukturierten Einstieg: eine technische Analyse und eine priorisierte Liste der Maßnahmen, mit denen Ihr Team sofort anfangen kann. Wenn Sie die Umsetzung dauerhaft begleitet haben möchten, gibt es laufende Betreuung ab 999 € pro Monat mit SEO Essentials. Ohne langwierige Bindungen und ohne leere Ranking-Garantien. Alle Pakete finden Sie in der Preisübersicht.

Häufige Fragen zu SEO mit React

Ist React schlecht für SEO?

Nein. React ist eine Bibliothek für Benutzeroberflächen und gibt keine Rendering-Strategie vor. Probleme entstehen, wenn öffentliche Seiten rein im Browser gerendert werden. Mit SSR oder SSG lassen sich React-Websites genauso gut indexieren wie klassische Websites.

Ist React ein Framework?

Streng genommen nicht. React ist eine JavaScript-Bibliothek, die sich um die Darstellung der Oberfläche kümmert. Routing, Datenabruf und serverseitiges Rendern liefern Frameworks wie Next.js oder React Router, die das React-Team für neue Projekte ausdrücklich empfiehlt.

Welche Programmiersprache nutzt React?

React basiert auf JavaScript, viele Teams verwenden TypeScript für mehr Typsicherheit. Komponenten werden meist in JSX geschrieben, einer Syntax, die HTML-ähnliche Strukturen direkt im JavaScript erlaubt. Für SEO zählt am Ende nicht die Sprache, sondern das HTML, das beim Nutzer und beim Crawler ankommt.

Brauche ich Next.js für gutes React-SEO?

Nicht zwingend, aber ein Framework mit SSR oder SSG ist der einfachste Weg. Next.js ist dafür weit verbreitet, React Router bietet ebenfalls serverseitiges Rendern. Eine eigene SSR-Lösung ist möglich, bedeutet aber deutlich mehr Wartungsaufwand.

Reicht React Helmet für Meta-Tags aus?

In einer reinen SPA setzt React Helmet die Tags erst nach dem Laden des JavaScripts. Für Google kann das funktionieren, ist aber unzuverlässig, und Social-Media-Vorschauen sehen die Tags oft gar nicht. Sicher sind Sie erst, wenn Title, Description und Canonical bereits im Server-HTML stehen.

Quellen

• Romanov et al.: Vergleichsstudie zu SPA, SSR und SSG (Aurora Journals)
• web.dev: Rendering on the Web
• web.dev: Zeit bis zum ersten Byte optimieren
• web.dev: Fallstudie Wix
• react.dev: Creating a React App
• react.dev: Sunsetting Create React App
• Google Search Central: Core Web Vitals
• Google Search Central: Page Experience
• Google Search Central: Kanonische URLs angeben

Empfehlungen

• Technical SEO: Technik, Indexierung & Performance
• JavaScript SEO: So werden dynamische Websites sichtbar
• SGE SEO: Wie Sie Ihre Sichtbarkeit in Googles KI-Suche sichern