React und SEO

TL;DR — React ist nicht schlecht für SEO – aber die Art, wie die meisten React-Apps gebaut sind, ist es. Standardmäßig baut React die Seite im Browser des Besuchers auf. Wenn eine Suchmaschine also zuerst Ihre URL abruft, erhält sie eine fast leere Seite. Google kann die Lücken normalerweise füllen, indem es Ihr JavaScript ausführt, aber das ist langsamer und riskanter, als einfach fertiges HTML zu liefern. Die Lösung besteht darin, Ihre Seiten auf einem Server oder zur Build-Zeit zu rendern – normalerweise mit einem Framework wie Next.js.

Warum React anders ist

Die meisten Websites – zum Beispiel ein WordPress-Blog – senden der Suchmaschine eine vollständige Seite: Der Server erstellt das HTML und liefert es, inklusive Überschrift. Eine Standard-React-App macht das Gegenteil. Der Server sendet eine fast leere Hülle (im Grunde ein leeres <div>), und dann läuft JavaScript im Browser, um die eigentliche Seite zu erstellen.

Das ist großartig für flüssige, app-ähnliche Erlebnisse. Für SEO ist es ein Problem, denn das Erste, was ein Crawler herunterlädt, ist diese leere Hülle. Ihr Inhalt ist noch nicht da – er erscheint erst, nachdem das JavaScript ausgeführt wurde.

Kann Google nicht einfach das JavaScript ausführen?

Ja – Google führt im Hintergrund eine echte, aktuelle Version von Chrome aus und kann Ihr JavaScript ausführen, um die fertige Seite zu sehen. React-Inhalte können also indexiert werden. Evidence for this claim Googlebot uses an evergreen Chromium rendering engine and can execute JavaScript. Scope: Google Search; successful execution still depends on accessible resources and application behavior. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Aber es gibt Haken:

• Es ist verzögert. Google führt das Rendering später durch, in einem separaten Schritt, der in die Warteschlange gestellt wird. Ihr Inhalt kann also länger brauchen, um in der Suche zu erscheinen.
• Es kann fehlschlagen. Wenn Ihre Seite langsam lädt, kann der Renderer von Google aufgeben, bevor der Inhalt erscheint – und eine fast leere Seite indexieren.
• Andere Crawler sind unterschiedlich. Bing verarbeitet JavaScript weniger zuverlässig, und KI-Anbieter veröffentlichen keinen gemeinsamen Rendering-Vertrag. Jeder Crawler, der nur das anfängliche HTML abruft, sieht eine Standard-React-App als leer an.

Die einfache Lösung

Bringen Sie Ihren Inhalt in das HTML, bevor er den Browser erreicht. Zwei Möglichkeiten:

• Server-side Rendering (SSR) – ein Server erstellt die vollständige Seite für jede Anfrage.
• Static Site Generation (SSG) – Seiten werden im Voraus zu fertigem HTML erstellt. Evidence for this claim React supports server rendering APIs and can be used by frameworks that generate HTML outside the browser. Scope: React server APIs; build-time generation is a framework/build-system capability rather than a React mode by itself. Confidence: high · Verified: 2026-07-14 React: Server APIs

Der einfachste Weg zu beidem ist Next.js, ein Framework, das auf React basiert und dies für Sie erledigt. (Remix ist eine weitere gute Option.) Mit SSR oder SSG übergibt Ihre React-Site Crawlern eine vollständige Seite – und sie ist so suchmaschinenfreundlich wie jede normale Website.

Ein paar andere Dinge, die Sie richtig machen sollten

• Verwenden Sie normale URLs (/products), keine Hash-URLs (/#/products) – Google kann die Hash-URLs nicht zuverlässig indexieren.
• Machen Sie Ihre Links zu echten Links (<a href>), nicht zu klickbaren <div>s.
• Geben Sie jeder Seite einen eigenen Titel und eine eigene Beschreibung, die sich aktualisieren, wenn sich die Seite ändert.

Möchten Sie die tiefergehende Version – wie der Renderer von Google tatsächlich funktioniert, die Render-Timeout-Falle, die doppelte Seiten erzeugt, den Vergleich der Rendering-Strategien und wie Sie testen können, was Google sieht? Wechseln Sie zum Erweitert-Tab.

TL;DR — Reacts SEO-Problem ist nicht React selbst, sondern das standardmäßige clientseitige Rendering. CRA und Vite + React liefern eine leere Hülle und bauen das DOM im Browser auf, sodass das rohe HTML, das ein Crawler abruft, keinen Inhalt enthält. Google kann es über den Web Rendering Service (evergreen Chromium) rendern, aber das Rendering wird separat in die Warteschlange gestellt, kann verzögert werden und kann zeitlich auslaufen — Gary Illyes hat dokumentiert, dass Render-Timeouts nur Boilerplate-Seiten hinterlassen, die dann als Duplikate markiert werden. Bing rendert JS weniger zuverlässig; das Rendering durch KI-Crawler variiert je nach Anbieter. Die Lösung ist die Rendering-Strategie: SSR oder SSG (am einfachsten mit Next.js oder Remix) bringt Inhalte in das initiale HTML — und wenn Sie servergerendertes Markup hydratisieren, verwenden Sie hydrateRoot (nicht createRoot) und behandeln Sie jede Server/Client-Diskrepanz als Bug, nicht als Warnung, die Sie unterdrücken. Verwenden Sie dann History-API- Routing (nicht Hash-URLs) und echte <a href>-Links. Für <head>-Metadaten: React 19 hebt <title>/<meta>/<link> nativ hervor; bei React 18 oder für fortgeschrittene Anforderungen verwenden Sie react-helmet-async (niemals das nicht mehr gewartete Original react-helmet). Setzen Sie korrekte HTTP- Statuscodes. Es gibt keinen Ranking-Bonus für SSR — es macht Inhalte nur zuverlässig indexierbar. Für die allgemeinen Rendering-Mechanismen siehe die Themen JavaScript-SEO und Headless-CMS.

Was React für SEO tatsächlich schwierig macht

React ist eine komponentenbasierte JavaScript-Bibliothek, und standardmäßig — Create React App, Vite + React — läuft sie clientseitig. Der Server liefert ein nahezu leeres Dokument (bekanntlich nur ein <div id="root"></div>) plus ein JavaScript-Bundle, und der Browser führt dieses JavaScript aus, um das DOM zu konstruieren. Vergleichen Sie das mit einer servergerenderten Seite (WordPress, eine Rails-App), bei der das vollständige HTML — Inhalt, Überschriften, Links — in der allerersten Antwort ankommt.

Die entscheidende Frage ist also: Was steht im rohen HTML, bevor irgendein JavaScript läuft? Bei einer Standard-React-App lautet die Antwort „fast nichts“. Rechtsklick → Seitenquelltext anzeigen bei einer CRA-App zeigt die Hülle, nicht den Inhalt. Genau das bekommt ein Crawler bei seinem ersten Abruf.

Um genau zu sein, wo die Verantwortung tatsächlich liegt: Die React-Bibliothek ist nicht nur CSR. React DOM bietet Client-Rendering (createRoot), Server-Rendering (Streaming- und statische APIs) sowie Hydration-APIs — die Bibliothek unterstützt all das. Das Problem der leeren Hülle ist eine Eigenschaft der Standard-Toolchain (Create React App, Vite + React ohne Server), die nur die Client-APIs verdrahtet und nichts, das auf dem Server HTML rendert. Tauschen Sie die Toolchain — Next.js, Remix oder Reacts eigene Server-Rendering-APIs — und dieselbe Bibliothek liefert vollständiges HTML in der ersten Antwort.

Dies ist die React-spezifische Anwendung des breiteren JavaScript-SEO-Problems — gehen Sie dort für die allgemeinen Fehlermodi hin (Parität, Interaktion, Zustand, Timing). Hier werde ich mich auf das konzentrieren, was spezifisch für React ist und wie man es behebt.

Wie Google eine React-App tatsächlich verarbeitet

Google verarbeitet JavaScript in drei Phasen: Crawlen → Rendern → Indexieren. Googlebot ruft die URL ab, das gerenderte DOM wird später vom Web Rendering Service (WRS) aufgebaut — einer Evergreen-Version von Chromium, derselben Engine wie Chrome — und dann wird die gerenderte Ausgabe indexiert und ihre Links extrahiert. Evidence for this claim Google processes JavaScript pages through crawling, rendering, and indexing using its Web Rendering Service. Scope: Google Search rendering behavior. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Die wichtige Nuance ist, wann das Rendering passiert. Rendering ist ressourcenintensiv, daher wird es getrennt vom initialen Crawl in die Warteschlange gestellt. Martin Splitt beschrieb den Ablauf klar: “we do an HTTP request, and we get something back … some barebone HTML and all it does is load the JavaScript and run the JavaScript. Then, this HTML … goes into rendering. Rendering runs JavaScript — boom!, a lot of content happens that wasn’t there before.” (Übersetzung) „Wir machen eine HTTP-Anfrage und bekommen etwas zurück … etwas nacktes HTML, und alles, was es tut, ist, das JavaScript zu laden und auszuführen. Dann geht dieses HTML … ins Rendering. Rendering führt JavaScript aus — boom!, eine Menge Inhalt entsteht, der vorher nicht da war.“ Für eine CSR-React-Seite ist das „Boom“ Ihre gesamte Seite — nichts davon existiert, bis dieser Rendering-Schritt läuft.

Ein Hinweis, den man mitnehmen sollte: Verlassen Sie sich nicht zu sehr auf das alte Modell der „zwei Indexierungswellen“. Splitt selbst ist davon abgerückt und nannte die Welle „eine Vereinfachung“. Die praktische Erkenntnis ist nicht „es gibt eine formale Welle 2 mit festgelegtem Timing“ – sondern dass Rendering ein eigener, aufschiebbarer, fehleranfälliger Schritt ist und CSR 100 % Ihres Inhalts auf die falsche Seite davon stellt.

Zwei weitere Fakten über den Renderer, die React-Apps besonders treffen:

• Er ist zustandslos. Googlebot speichert localStorage, sessionStorage oder Cookies nicht zwischen Seitenaufrufen. Inhalte oder Routing, die von clientseitigem Zustand abhängen, sind für den Crawler unsichtbar.
• Er kann aufgeben. Der Renderer erzwingt ein Timeout. Wenn Ihre Hauptinhalte langsam laden – große Bundles, Wasserfälle von API-Aufrufen – kann das Rendering abgeschlossen sein, bevor Ihre Inhalte eintreffen, und Google indexiert die unvollständige Seite.

Die Render-Timeout-Falle (und warum sie Duplikate erzeugt)

Dieser Fehlermodus wird selten gut erklärt und ist für React-Apps der schädlichste. Gary Illyes beschrieb ihn direkt: „Ich habe eine Reihe von E-Mails in meinem Posteingang, bei denen das Problem ist, dass das Herzstück ewig zum Laden brauchte, sodass das Rendering ein Timeout hatte … und wir blieben mit einer Reihe von Seiten zurück, die nur das Grundgerüst hatten. Mit nur dem Grundgerüst sind diese Seiten Duplikate.“ (Übersetzung) „Ich habe eine Reihe von E-Mails in meinem Posteingang, bei denen das Problem ist, dass das Herzstück ewig zum Laden brauchte, sodass das Rendering ein Timeout hatte … und wir blieben mit einer Reihe von Seiten zurück, die nur das Grundgerüst hatten. Mit nur dem Grundgerüst sind diese Seiten Duplikate.“

Gehen Sie durch, was das für eine CSR-React-App bedeutet. Ihr Header, die Navigation und der Footer sind Grundgerüst, das schnell lädt. Ihr eigentlicher Seiteninhalt – der Teil, der jede URL einzigartig macht – wird von JavaScript abgerufen und gerendert und lädt langsam. Das Rendering läuft in ein Timeout. Google bleibt auf jeder URL mit Header + Navigation + Footer zurück. Jetzt sieht jede Seite identisch aus, und Google markiert sie in der Google Search Console als Duplikate voneinander.

Illyes’ eigener Fix ist der umsetzbare Teil: „Versuchen Sie, die JS-Aufrufe so umzustrukturieren, dass der Inhalt (einschließlich des marginalen Grundgerüsts) zuerst lädt, und sehen Sie, ob das hilft.“ (Übersetzung) „Versuchen Sie, die JS-Aufrufe so umzustrukturieren, dass der Inhalt (einschließlich des marginalen Grundgerüsts) zuerst lädt, und sehen Sie, ob das hilft.“ Aber die dauerhaftere Antwort ist, für Ihre Hauptinhalte überhaupt nicht vom Rendering-Schritt abzuhängen – das bedeutet SSR oder SSG.

Rendering-Strategien für React

Dies ist die mit Abstand wirkungsvollste Entscheidung. Die Optionen, grob von schlechtester zu bester für SEO:

• CSR (Standard-React). Der Server sendet die Hülle; der Browser baut alles. Inhalte werden durch die Rendering-Warteschlange verzögert und sind dem Timeout ausgesetzt. Am schlechtesten für SEO. Gut für authentifizierte Dashboards, die Sie ohnehin nicht indexiert haben möchten. Evidence for this claim Client-only React rendering constructs UI in the browser; server rendering APIs produce HTML before browser hydration. Scope: React rendering mechanics; SEO impact depends on what the initial response contains. Confidence: high · Verified: 2026-07-14 React: hydrateRoot React: Server APIs
• Pre-Rendering. Rendering zur Build-Zeit ohne vollständiges SSR-Framework – Tools wie react-snap oder ein Prerender-Dienst crawlen Ihre App und speichern statisches HTML. Leichtgewichtiger; funktioniert für einfachere, weitgehend statische Websites.
• SSG (Static Site Generation). HTML wird einmal zur Bereitstellungszeit erstellt und als statische Dateien ausgeliefert. Am schnellsten, Inhalte sind immer im rohen HTML vorhanden. Eingeschränkt für stark dynamische oder benutzerspezifische Inhalte; große Websites haben langsame Builds.
• SSR (Server-Side Rendering). Der Server führt React pro Anfrage aus und sendet vollständiges HTML. Inhalte sind für Crawler sofort verfügbar; immer aktuell. Kostet einen Node.js-Server und eine etwas höhere TTFB.
• Hybrid / ISR (Incremental Static Regeneration). Eine Next.js-Funktion, die statische Seiten im Hintergrund neu generiert – statische Geschwindigkeit mit regelmäßiger Aktualität.

Und eine Strategie, die Sie bei neuen Builds überspringen sollten: dynamisches Rendering – Erkennen des Crawler-User-Agents und Ausliefern einer vorgerenderten Version an diesen, während Benutzer CSR erhalten. Google nennt das inzwischen “einen Workaround und keine langfristige Lösung”, das “zusätzliche Komplexität und Ressourcenanforderungen schafft”, und empfiehlt stattdessen Server-Side Rendering, Static Rendering oder Hydration. (Bing empfahl dynamisches Rendering bereits 2018, aber diese Empfehlung ist veraltet – seit 2019 rendert Bingbot über Microsoft Edge / Chromium, und SSR/SSG ist auch dort der richtige Ansatz.)

Hier lohnt es sich, einen Mythos zu widerlegen: SSR ist kein Ranking-Boost. Wie John Mueller es formulierte: “there are no SEO ranking bonuses for implementing it one way or another” – die verschiedenen Rendering-Methoden sind “just different ways of making the content indexable.” (Übersetzung) „Es gibt keine SEO-Ranking-Boni, wenn man es auf die eine oder andere Weise implementiert“ – die verschiedenen Rendering-Methoden sind „nur verschiedene Möglichkeiten, den Inhalt indexierbar zu machen.“ Der Wert von SSR liegt in zuverlässiger Indexierbarkeit (und oft besseren Core Web Vitals durch ein schnelleres First Contentful Paint), nicht in einem magischen Ranking-Hebel.

Hydration muss exakt übereinstimmen – das ist eine Bug-Grenze, keine SEO-Technik

SSR und SSG liefern dem Browser beide HTML aus, das Ihren Inhalt bereits enthält. React muss dann im Client an dieses Markup andocken, und das ist eine andere API als ein reines Client-Rendering:

• createRoot rendert React von Grund auf in einen DOM-Knoten – ohne vorhandenes Markup. Verwenden Sie es nur für CSR-Apps.
• hydrateRoot dockt React an HTML an, das react-dom/server bereits generiert hat, und erwartet, dass das erste Rendering des Clients eine Ausgabe erzeugt, die mit dem identisch ist, was der Server gesendet hat. Wenn Sie SSR/SSG verwenden, benötigen Sie hydrateRoot, nicht createRoot – der Aufruf von createRoot auf servergerendertem Markup führt dazu, dass React es verwirft und von Grund auf neu rendert, wodurch der genaue SEO-Vorteil verloren geht, den Sie mit SSR/SSG erzielen wollten.

Abweichungen zwischen Server- und Client-Ausgabe sind ein echtes Risiko in React-Apps, die SEO-Fixes durchführen – ein Date.now() in einem Titel, ein localesabhängiges Format, ein if (typeof window !== 'undefined')-Zweig. Reacts eigene Dokumentation ist unmissverständlich darüber, was dann passiert: Sie warnt in der Entwicklung vor Abweichungen, aber “there are no guarantees that attribute differences will be patched up in case of mismatches.” (Übersetzung) „Es gibt keine Garantien, dass Attributunterschiede bei Abweichungen behoben werden.“ Die Anleitung lautet, Abweichungen als Bugs zu behandeln und zu beheben – nicht die Warnung zu unterdrücken und von Inhaltsgleichheit auszugehen. Speziell für SEO: Gehen Sie nicht davon aus, dass Ihre gerenderten Inhalte und Metadaten mit dem übereinstimmen, was der Server gesendet hat, nur weil die Seite im Browser korrekt aussieht. Vergleichen Sie das Server-HTML direkt mit dem DOM nach der Hydration (der View Source vs. Inspect Element-Check aus dem Testabschnitt unten ist die schnelle Version davon), anstatt einer sauberen Konsole zu vertrauen.

React Router und URL-Struktur

React Router übernimmt die Navigation im Browser ohne Server-Roundtrips, was für SEO in Ordnung ist, wenn es korrekt konfiguriert ist:

• Verwenden Sie die History API, nicht Hash-Routing. BrowserRouter verwendet pushState und erzeugt saubere, crawlbare URLs (/products). HashRouter erzeugt /#/products, und Google kann Hash-basierte URLs nicht zuverlässig auflösen – das alte AJAX-Crawling-Schema, das sie funktionsfähig machte, ist veraltet. Verwenden Sie die History API.
• Der Server muss diese URLs ebenfalls verarbeiten. Mit History-API-Routing benötigt jede “Seite” eine echte URL, auf die der Server antworten kann – entscheidend für SSR und notwendig, damit ein direkter Zugriff oder ein Refresh auf /products nicht zu einem 404 führt.
• <Link> rendert einen echten Anker. Die <Link>-Komponente von React Router gibt ein <a href> aus, das crawlbar ist. Navigation, die auf onClick-Handlern ohne Anker basiert, ist nicht crawlbar – Google folgt nur echten <a href>-Links.

Metadaten verwalten: react-helmet, react-helmet-async und die nativen Tags von React 19

Durch React 18 hat React bei Routenwechseln nie nativ das <head>-Element des Dokuments aktualisiert – jede <title>-, Meta-Description-, Canonical- und Open-Graph-/Twitter-Tag einer Route musste von einer Bibliothek gesetzt werden. React 19 hat das geändert: Komponenten können <title>, <meta>- und <link>-Tags direkt rendern, und React hebt sie von selbst in den <head>-Bereich – funktioniert sowohl mit Client-only-Apps, Streaming-SSR als auch Server Components. React 19.2 ist Stand Mitte 2026 die aktuelle stabile Version, das gilt also für jede App mit einer aktuellen React-Version.

Das bedeutet, die richtige Antwort hängt von Ihrer React-Version und Ihren tatsächlichen Anforderungen ab:

• React 19, eigenständige App, nur grundlegende Tags. Rendern Sie <title>/<meta>/<link> direkt in Ihren Komponenten – keine Bibliothek nötig.
• React 19, aber Sie benötigen htmlAttributes/bodyAttributes, SSR-context-Serialisierung, onChangeClientState, prioritizeSeoTags oder titleTemplate. Natives Hoisting deckt diese nicht ab – verwenden Sie react-helmet-async. Deren eigene Dokumentation weist direkt darauf hin: ohne diese spezifischen Anforderungen benötigen Sie das Paket unter React 19 möglicherweise gar nicht.
• React 18 oder früher, eigenständige App. Natives Hoisting existiert noch nicht – verwenden Sie react-helmet-async. Es wird aktiv gepflegt (Hauptversion 3 und erkennt Ihre React-Version zur Laufzeit) und unterstützt SSR.
• Das ursprüngliche react-helmet. Verwenden Sie es nicht, auf keiner React-Version. Es ist ungepflegt – keine Veröffentlichung seit 2020 – und hat bekannte Fehler unter React 18s Concurrent Rendering.
• Next.js-Apps. Verwenden Sie Nexts eigene Metadata-API (den metadata-Export / generateMetadata im App Router) unabhängig von der React-Version – setzen Sie nicht auf Helmet und verlassen Sie sich auch nicht auf natives React-Tag-Hoisting. Das Framework besitzt das Dokument in einer Next.js-App.

Eine Zuverlässigkeitsregel gilt allgemein für JavaScript-SEO und trifft unabhängig davon zu, welche der oben genannten Optionen Sie verwenden: HTML-Ebene-Metadaten schlagen JS-injizierte Metadaten. Ein Canonical-Tag, das durch clientseitiges JavaScript injiziert wird, ist weit weniger zuverlässig als eines, das im serverseitig gerenderten HTML vorhanden ist – ein weiteres Argument für SSR/SSG.

KI-Crawler machen das dringend

Die Besonderheit 2026: Das Rendering-Verhalten für GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot und andere Agenten ist anbieter- und versionsspezifisch. Eine CSR-React-App liefert jedem Crawler dieselbe leere Hülle, die der erste Googlebot-Fetch sieht, und die aktuelle Anbieterdokumentation etabliert keinen gemeinsamen Rendering-Schritt, der sie füllen würde. Da generative Engines zu einer größeren Discovery-Oberfläche werden, ist SSR/SSG kein reines Google-Thema mehr: Rohes HTML maximiert die Abdeckung, ohne eine universelle Crawler-Einschränkung anzunehmen. (Das Headless-CMS-Thema behandelt diese KI-Crawler-Realität ausführlicher.)

Testen, was Google tatsächlich sieht

Vertrauen Sie nicht Ihrem Browser – Ihr DevTools-Inspektor zeigt das gerenderte DOM (nach JavaScript), was genau das ist, was ein Crawler ohne JS nicht sieht. Verwenden Sie die richtigen Tools:

• View Source vs. Inspect Element. View Source ist das rohe HTML (was Crawler vor JS erhalten). Inspect Element ist das gerenderte DOM. Wenn Inhalte in Inspect, aber nicht in View Source vorhanden sind, sind sie JavaScript-abhängig.
• URL Inspection Tool (Search Console) – die maßgeblichste Prüfung. Führen Sie einen Live-Test durch und betrachten Sie das gerenderte HTML, den Screenshot und die Seitenressourcen / Konsolenmeldungen, um zu sehen, was Google tatsächlich gerendert hat und was nicht geladen werden konnte.
• Rich Results Test – eine schnelle Prüfung des gerenderten HTML ohne Verifizierung der Website.
• Deaktivieren Sie JavaScript in DevTools und laden Sie neu – eine schnelle Simulation eines Crawlers, der kein JS ausführt (und ein brauchbarer Proxy für das, was KI-Crawler sehen).
• Search Console Coverage-Bericht – „Discovered, currently not indexed“ kann einen Render-Queue-Rückstau signalisieren; Cluster doppelter Seiten können die Render-Timeout-Boilerplate-Falle signalisieren.
• JS-rendering-Crawler – Ahrefs Site Audit und Screaming Frog (JS-Rendering-Modus) rendern Seiten in großem Maßstab, sodass Sie rohes vs. gerendertes HTML über die gesamte Website vergleichen können.

Next.js und Remix (die praktische Antwort)

Wenn SEO wichtig ist und Sie reines CSR-React verwenden, ist der Wechsel zu einem Framework, das auf dem Server rendert, in der Regel der richtige Schritt. Next.js ist genau dafür gebaut – SSR und SSG out of the box, ISR, der App Router, eine eingebaute Metadata-API, automatisches Code-Splitting und Bildoptimierung. Remix ist die Web-Standards-Alternative, basierend auf fetch/Request/Response mit SSR standardmäßig und einer starken Progressive-Enhancement-Geschichte. Next.js bekommt einen eigenen Deep Dive – ich halte es hier bewusst kurz. Der Punkt für React-SEO ist enger gefasst: Das Framework existiert, um Ihre Inhalte aus dem reinen Browser-Rendering-Schritt in das initiale HTML zu verschieben.

React ist gut für SEO, wenn Sie Rendering als Architekturentscheidung behandeln und nicht als nachträglichen Einfall. Wählen Sie SSR oder SSG für alles, was ranken soll, halten Sie Links und Routing ehrlich, verwalten Sie Metadaten pro Route und lassen Sie Googles eigene Tools – nicht Ihren Browser – Ihnen sagen, was tatsächlich gerendert wurde.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• React ist nicht schlecht für SEO – CSR standardmäßig schon. Die React-Bibliothek unterstützt Client-, Server-, statisches und Streaming-Rendering; es ist die Standard-CRA/Vite-Toolchain (ohne Server), die eine leere <div id="root">-Hülle ausliefert und das DOM im Browser aufbaut, sodass das rohe HTML, das ein Crawler abruft, keinen Inhalt enthält.
• Google kann React rendern über den Web Rendering Service (Evergreen-Chromium), aber das Rendering wird separat in die Warteschlange gestellt, kann verzögert werden und ist zustandslos (keine Cookies/localStorage/sessionStorage zwischen den Ladevorgängen).
• Die Render-Timeout-Falle: Wenn der Hauptinhalt langsam lädt, läuft das Rendering in einen Timeout und Google indexiert eine nur-Boilerplate-Seite. Über viele URLs hinweg sehen diese identisch aus und werden als Duplikate markiert (das dokumentierte Fehlermuster von Gary Illyes). Lösung: Laden Sie zuerst den Inhalt – oder besser, verlassen Sie sich nicht auf den Rendering-Schritt (SSR/SSG).
• Rendering-Strategien, beste→schlechteste für SEO: SSG (geringstes Risiko) ≈ SSR ≈ Pre-Rendering > ISR/hybrid > CSR (höchstes Risiko). Dynamisches Rendering ist veraltet – Google empfiehlt SSR, statisches Rendering oder Hydration.
• Kein Ranking-Bonus für SSR – Mueller: “no SEO ranking bonuses for implementing it one way or another.” (Übersetzung) „Keine SEO-Ranking-Boni, egal wie Sie es implementieren.“ Es macht Inhalte nur zuverlässig indexierbar.
• Hydration ist eine Bug-Grenze, keine Technik: SSR/SSG-Apps hydratisieren mit hydrateRoot (nicht createRoot), was erwartet, dass das erste Rendering des Clients exakt mit dem des Servers übereinstimmt. React warnt bei Abweichungen in der Entwicklung, garantiert aber nicht, dass sie behoben werden – behandeln Sie Abweichungen als Bugs und überprüfen Sie das Server- vs. Post-Hydration-DOM direkt.
• React Router: Verwenden Sie die History-API (BrowserRouter), nicht Hash-Routing; der Server muss diese URLs verarbeiten; <Link> rendert crawlbar <a href> – nur-onClick-Navigation tut das nicht.
• Metadaten: React 19 hebt <title>/<meta>/<link> nativ in den <head> für eigenständige Apps, die nur die Grundlagen benötigen. Auf React 18 oder für fortgeschrittene Anforderungen (SSR-Kontext, titleTemplate) verwenden Sie react-helmet-async – niemals das ursprüngliche react-helmet, das seit 2020 nicht mehr gewartet wird. In Next.js verwenden Sie die Metadata-API unabhängig von der React-Version. HTML-Ebene schlägt JS-injiziert.
• AI-Crawler-Rendering ist anbieterabhängig – CSR-React hängt von der Client-Ausführung ab, die jeder Crawler unterstützen kann oder nicht. SSR/SSG platziert Inhalte im initialen HTML und maximiert die Abdeckung.
• Testen Sie mit View Source vs. Inspect, URL Inspection (gerendertes HTML + Screenshot + Konsole), Rich Results Test, Neuladen mit deaktiviertem JS und einem JS-rendernden Crawler.
• Next.js / Remix sind die praktische Lösung – sie verschieben Inhalte in das initiale HTML.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• JavaScript-SEO-Grundlagen verstehen — die Crawl-→-Render-→-Index-Pipeline, SPAs, die History API, kanonische URLs mit JavaScript und aussagekräftige HTTP-Statuscodes.
• Suchbezogene JavaScript-Probleme beheben — Soft-404-Behandlung in SPAs, der zustandslose Renderer (keine Cookies/localStorage) und Tests mit URL Inspection.
• Dynamic Rendering (veralteter Workaround) — warum Google es als veraltet eingestuft hat und was stattdessen verwendet werden sollte (SSR, statisches Rendering, Hydration).
• Vorstellung einer neuen JavaScript-SEO-Videoreihe — Martin Splitts Reihe, die sich speziell mit React, Angular und Vue befasst.
• Ausführlicher Leitfaden zur Funktionsweise der Google-Suche — wo das Rendering im Ablauf Crawl → Index → Auslieferung steht.

Bing / Microsoft

• Der neue evergreen Bingbot (Microsoft Edge) — Bingbot rendert JavaScript über dieselbe Chromium-Plattform wie Googlebot.
• bingbot-Serie: JavaScript, Dynamic Rendering und Cloaking — Bings ältere (2018) Einschätzung; nützlich für die historische Dynamic-Rendering-Empfehlung.

Technische Referenz

• React v19 (Versionshinweise) — native Unterstützung für das Rendern von <title>, <meta>- und <link>-Tags in Komponenten, die automatisch in <head> angehoben werden.
• createRoot / hydrateRoot (React-Dokumentation) — die Trennung zwischen Client-Rendering und Hydration-API sowie der Hinweis, dass Abweichungen nicht garantiert korrigiert werden.
• react-helmet-async (npm) — der gepflegte Fork für die Verwaltung von <head> in eigenständigen React-Apps, für React 18 oder erweiterte React-19-Anforderungen.

Zitate aus der Quelle

Aussagen aus dem Google-Suchteam, die öffentlich dokumentiert sind. Jeder Suchmaschinen-Deep-Link springt direkt zur zitierten Passage auf der Quellseite; die Zitate von Mitarbeitern unten sind mit der Berichterstattung verlinkt, die sie wiedergegeben hat.

Google-Dokumentation — SPAs und Dynamic Rendering

• “Single-page applications (SPA) are websites that load an HTML document once and fetch any additional content using JavaScript APIs.” (Übersetzung) „Single-Page-Anwendungen (SPA) sind Websites, die ein HTML-Dokument einmal laden und zusätzliche Inhalte über JavaScript-APIs abrufen.“ — Google Search Central-Dokumentation. Zur Quelle springen
• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (Übersetzung) „Dynamic Rendering war ein Workaround und keine langfristige Lösung für Probleme mit JavaScript-generierten Inhalten in Suchmaschinen.“ — Google Search Central-Dokumentation. Zur Quelle springen

Martin Splitt, Google — wie JavaScript-Seiten indexiert werden

• “What we do is we do an HTTP request, and we get something back, right — some HTML, maybe it’s a barebone HTML and all it does is load the JavaScript and run the JavaScript. Then, this HTML that we got from the original HTTP GET request from the crawl, goes into rendering. Rendering runs JavaScript — boom!, a lot of content happens that wasn’t there before.” (Übersetzung) „Was wir tun, ist, dass wir eine HTTP-Anfrage stellen und etwas zurückbekommen, richtig — etwas HTML, vielleicht ist es ein minimalistisches HTML und alles, was es tut, ist, das JavaScript zu laden und das JavaScript auszuführen. Dann geht dieses HTML, das wir von der ursprünglichen HTTP-GET-Anfrage aus dem Crawl erhalten haben, in das Rendering. Das Rendering führt JavaScript aus — boom!, es passiert eine Menge Inhalt, der vorher nicht da war.“ Lesen Sie die Berichterstattung (Search Engine Journal)
• Zum unpräzisen Zwei-Wellen-Modell: “there’s no such thing as the second wave of crawling-ish. The wave is an oversimplification.” (Übersetzung) „Es gibt so etwas wie die zweite Welle des Crawlens nicht. Die Welle ist eine Vereinfachung.“ Lesen Sie die Berichterstattung (Search Engine Roundtable)

Gary Illyes, Google — die Falle doppelter Inhalte bei Rendering-Timeout

• “I have a bunch of emails in my inbox where the issue is that the centerpiece took forever to load, so rendering timed out (my most likely explanation) and we were left with a bunch of pages that only had the boilerplate. With only the boilerplate, those pages are dups.” (Übersetzung) „Ich habe eine Reihe von E-Mails in meinem Posteingang, bei denen das Problem ist, dass das Herzstück ewig zum Laden brauchte, sodass das Rendering eine Zeitüberschreitung hatte (meine wahrscheinlichste Erklärung) und wir mit einer Reihe von Seiten zurückblieben, die nur das Grundgerüst hatten. Mit nur dem Grundgerüst sind diese Seiten Duplikate.“
• “Do you have a JavaScript-heavy site and you see lots of dups reported in Search Console? Try to restructure the js calls such that the content (including marginal boilerplate) loads first and see if that helps.” (Übersetzung) „Haben Sie eine JavaScript-lastige Website und sehen viele Duplikate in der Search Console gemeldet? Versuchen Sie, die JS-Aufrufe so umzustrukturieren, dass der Inhalt (einschließlich des marginalen Grundgerüsts) zuerst lädt, und sehen Sie, ob das hilft.“ Lesen Sie den Beitrag (LinkedIn)

John Mueller, Google — kein Ranking-Bonus für die Wahl des Renderings

• “There are no SEO ranking bonuses for implementing it one way or another.” They’re “just different ways of making the content indexable (as is client side rendering).” (Übersetzung) „Es gibt keine SEO-Ranking-Boni, wenn man es auf die eine oder andere Weise implementiert.“ Sie sind “nur verschiedene Möglichkeiten, den Inhalt indexierbar zu machen (wie auch Client-Side-Rendering).” Lesen Sie die Berichterstattung (Search Engine Roundtable)

React-SEO-Checkliste

Ein Durchgang, um zu bestätigen, dass Crawler Ihre React-App sehen und indexieren können:

• Wichtige Inhalte erscheinen in View Source (rohes HTML), nicht nur im gerenderten DOM — wenn sie fehlen, sind Sie von CSR abhängig.
• Seiten, die ranken sollen, verwenden SSR oder SSG (Next.js, Remix oder einen Pre-Render-Schritt), nicht reines Client-Side-Rendering.
• Hauptinhalte laden schnell und zuerst — keine langsamen API-Waterfalls, die den Render-Timeout zu einer Nur-Boilerplate-Seite führen könnten.
• Routing verwendet die History API (BrowserRouter), nicht HashRouter / #/-URLs.
• Der Server kann auf jede Client-Route antworten (kein 404 bei direktem Aufruf oder Refresh).
• Navigation verwendet echte <a href>-Links (React Router <Link>), nicht nur onClick-Handler auf <div>/<button>.
• Jede Route setzt einen eindeutigen <title>, Meta-Description, Canonical und OG-Tags, die bei der Navigation aktualisiert werden.
• Metadaten entsprechen Ihrer Version: React 19 native <title>/<meta>/<link>-Tags für die Grundlagen, react-helmet-async für React 18 oder erweiterte Anforderungen (niemals das veraltete react-helmet), oder die Next.js Metadata API, falls Sie Next.js verwenden.
• Wenn serverseitig gerendert, hydratisieren Sie mit hydrateRoot (nicht createRoot), und jede Dev-Mode-Hydrations-Mismatch-Warnung wird als zu behebender Bug behandelt.
• Clientseitige “Not Found”-Routen geben einen echten 404 (oder ein noindex) zurück, keinen Soft-404 mit einem 200-Status.
• JavaScript und CSS sind nicht blockiert in robots.txt (Google rendert nicht aus blockierten Dateien).
• Keine kritischen Inhalte hängen von Cookies / localStorage / sessionStorage ab (der Renderer ist zustandslos).
• Verifiziert in URL Inspection: Das gerenderte HTML und der Screenshot zeigen Ihre echten Inhalte.
• Coverage-Bericht geprüft auf “Entdeckt, derzeit nicht indexiert” (Render-Backlog) und Duplikat-Cluster (Render-Timeout-Falle).

Die mentalen Modelle

1. Die einzige Frage, die zählt: Was steht im rohen HTML? View Source, bevor JavaScript ausgeführt wird, ist das, was ein First-Fetch-Crawler — und die meisten KI-Crawler, für immer — sehen. Wenn Ihre Inhalte nicht dort sind, haben Sie ein React-SEO-Problem, egal wie gut die Seite in Ihrem Browser aussieht.

2. Rendering ist ein separater, fehleranfälliger Schritt. Crawl → Render → Index. CSR legt 100 % Ihrer Inhalte auf die ferne Seite des Render-Schritts, der in der Warteschlange steht, verzögert, zustandslos ist und auslaufen kann. SSR/SSG verschieben Ihre Inhalte vor diesen Schritt. Vertrauen Sie dem “Zwei-Wellen”-Modell nicht zu sehr — Splitt selbst nannte es eine Vereinfachung.

3. Der Boilerplate-Duplikat-Fehlermodus. Langsame Inhalte + Render-Timeout = jede URL rendert nur Header/Nav/Footer = Google sieht Duplikate. Die Lösung ist strukturell: Inhalte zuerst laden oder nicht mehr vom Render-Schritt abhängen.

4. Der Rendering-Entscheidungsbaum.

• Öffentliche Inhalte, die ranken oder von KI zitiert werden müssen → SSG (statisch) oder SSR (frisch).
• Überwiegend statisch (Blog, Doku, Marketing) → SSG, oder ISR mit Timer.
• Häufig wechselnd, muss frisch sein → SSR.
• Eingeloggtes Dashboard, nicht zur Indexierung gedacht → CSR ist in Ordnung.
• Neuer Build, der SEO braucht → greifen Sie zu Next.js / Remix, nicht zu dynamischem Rendering.

5. HTML-first, JS-second für jedes SEO-Signal. Inhalte, Links, Canonicals, Titel, strukturierte Daten — bringen Sie sie in das serverseitig gerenderte HTML. Behandeln Sie JS-injizierte SEO-Signale (einschließlich JS-Canonical-Tags und react-helmet bei CSR) als Fallback, nicht als Plan: Google sieht sie spät, und KI-Crawler gar nicht.

React SEO — Spickzettel

Rendering-Modi auf einen Blick

Häufige React-SEO-Fehler → Lösungen

Schnelle Regeln

• Der Renderer ist Evergreen-Chromium, in der Warteschlange, zustandslos und mit Timeout.
• Kein Ranking-Bonus für SSR – es geht um zuverlässige Indexierbarkeit (Mueller).
• KI-Crawler-Rendering variiert je nach Anbieter → rohes HTML ist die sicherste Abdeckungsbasis.
• In Next.js die Metadata API verwenden – nicht React Helmet.
• Bing rendert JS (über Edge), aber weniger zuverlässig; SSR/SSG ist auch dort die sichere Wahl.

Prüfen, was der Server sendet, bevor React läuft

Repräsentative indexierbare Routen in urls.txt eintragen. Das findet CSR-Shells und fehlendes serverseitig gerendertes Head-Markup in der Rohantwort:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sS -o "$html" -w '%{http_code}' "$url")
  bytes=$(wc -c < "$html" | tr -d ' ')
  title_count=$(grep -Eio '<title>[^<]*</title>' "$html" | wc -l | tr -d ' ')
  canonical_count=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | wc -l | tr -d ' ')
  printf '%s\t%s\tbytes=%s\ttitles=%s\tcanonicals=%s\n' "$status" "$url" "$bytes" "$title_count" "$canonical_count"
  rm -f "$html"
done < urls.txt

Kleine Bytegröße ist nur ein Prüfsignal, kein Fehler an sich. Markierte Rohantworten mit dem gerenderten HTML vergleichen und bestätigen, dass Primärtext und crawlbare Links vorhanden sind.

Tools zur Prüfung von React-SEO

• View Source vs. Inspect Element – der schnellste erste Check. View Source ist das rohe HTML (was ein Crawler vor JS erhält); Inspect Element ist das gerenderte DOM. Inhalt in Inspect, aber nicht in View Source ist JavaScript-abhängig.
• URL Inspection (Google Search Console) – die Quelle der Wahrheit. Einen Live-Test ausführen, dann das gerenderte HTML, den Screenshot, die Seitenressourcen (was geladen vs. blockiert wurde) und Konsolenmeldungen ansehen, um genau zu sehen, was Google gerendert hat.
• Rich Results Test – eine schnelle Prüfung von gerendertem HTML und strukturierten Daten für eine einzelne URL ohne Site-Verifizierung.
• Chrome DevTools – JavaScript deaktivieren (Befehlsmenü → „Disable JavaScript“) und neu laden, um zu prüfen, was ein HTML-only-Fetcher erhält. Das ist ein Abdeckungscheck, kein Beweis für das aktuelle Rendering-Verhalten eines bestimmten KI-Crawlers.
• Search Console Coverage-Bericht – auf „Discovered, currently not indexed“ (Render-Backlog) und Duplikat-Cluster achten (die Render-Timeout-Boilerplate-Falle).
• JS-rendernde Crawler – Ahrefs Site Audit und Screaming Frog SEO Spider (JS-Rendering-Modus) führen JavaScript aus, sodass Sie rohes vs. gerendertes HTML siteweit vergleichen können.

Fehler, die React-Teams tatsächlich machen

Konkrete Muster, die ich immer wieder in ausgelieferten CSR-React-Apps sehe, keine hypothetischen. Jedes ist eine Präventionsmaßnahme – erkennen, bevor es Sie Indexierung kostet.

Rohes CRA/Vite-CSR für Seiten ausliefern, die ranken müssen

Teams bringen Create React App oder Vite + React direkt in Produktion für Marketingseiten, Blogbeiträge oder Produktseiten – genau den Inhalt, der in der Suche erscheinen muss. Warum es falsch ist: Der Server sendet eine fast leere <div id="root">-Shell; Ihr echter Inhalt existiert erst nach JavaScript-Ausführung, daher wird er durch die Render-Warteschlange von Google verzögert und kann für jeden KI-Crawler unsichtbar sein, der initiales HTML ohne Client-Ausführung abruft. Was stattdessen tun: Alles, was ranken oder zitiert werden muss, auf SSR oder SSG umstellen – Next.js oder Remix sind die einfachsten Wege – und rohes CSR für eingeloggte, nicht indexierte Oberflächen wie Dashboards reservieren.

Routing auf Hash-URLs (HashRouter)

Zu React Routers HashRouter zu greifen, weil es der Weg des geringsten Widerstands ist – keine Serverkonfiguration nötig, funktioniert auf jedem statischen Host. Warum es falsch ist: Google kann /#/products-artige URLs nicht zuverlässig auflösen; das alte AJAX-Crawling-Schema, das Hash-Fragmente crawlbar machte, ist veraltet. Was stattdessen zu tun ist: Verwenden Sie BrowserRouter (die History API) und stellen Sie sicher, dass der Server auf jede Route reagiert, die es erzeugt, einschließlich eines direkten Treffers oder Aktualisierens auf einem Deep Link.

Navigation auf onClick statt echten Ankern aufbauen

Navigation mit onClick-Handlern auf einem <div> oder <button> verdrahten, oft weil es leichter zu stylen war oder das Standard-Linkverhalten vermieden werden sollte. Warum es falsch ist: Google folgt nur echten <a href>-Links – ein <div> mit einem Klick-Handler ist für das Crawling unsichtbar, egal wie es sich für eine Maus verhält. Was stattdessen zu tun ist: Verwenden Sie die <Link>-Komponente von React Router, die unter der Haube ein echtes <a href> rendert, oder einen einfachen Anker-Tag für externe Navigation.

Hauptinhalt hinter einem langsamen API-Wasserfall laden

Header und Navigation schnell abrufen, dann mehrere API-Aufrufe verketten, bevor der eigentliche Seiteninhalt – der Teil, der jede URL einzigartig macht – erscheint. Warum es falsch ist: Der Web-Rendering-Dienst von Google erzwingt ein Timeout; wenn Ihr zentraler Inhalt langsam lädt, ist das Rendering abgeschlossen, bevor er ankommt, und Google indiziert nur Boilerplate-Seiten, die dann als Duplikate voneinander markiert werden – genau das Versagensmuster, das Gary Illyes beschrieben hat. Was stattdessen zu tun ist: Strukturieren Sie Anfragen so um, dass Hauptinhalte zuerst laden, oder entfernen Sie die Abhängigkeit vom clientseitigen Rendering vollständig mit SSR/SSG.

Immer noch das ursprüngliche react-helmet verwenden

Zu react-helmet für <title> und Meta-Tags pro Route greifen, weil es die Bibliothek ist, die jedes ältere Tutorial empfiehlt. Warum es falsch ist: Das ursprüngliche Paket ist nicht mehr gewartet – keine Veröffentlichung seit 2020 – und hat bekannte Probleme unter React 18s konkurrierendem Rendering und SSR. Was stattdessen zu tun ist: Auf React 19 <title>/<meta>/<link> direkt in Ihren Komponenten rendern und React sie hochziehen lassen (keine Bibliothek für die Grundlagen nötig). Auf React 18 oder für fortgeschrittene Bedürfnisse wie SSR-Kontextserialisierung oder titleTemplate verwenden Sie react-helmet-async, den gewarteten Fork. Auf Next.js verwenden Sie dessen eingebaute Metadata-API und setzen Sie Helmet nicht darauf auf.

JavaScript oder CSS in robots.txt blockieren

/static/js/ oder den Asset-Ordner eines Bundlers in robots.txt blockieren, manchmal übrig einer alten Crawl-Budget-Sorge oder von der Konfiguration einer anderen Site kopiert. Warum es falsch ist: Google kann nicht rendern, was es nicht abrufen darf – ein blockiertes Bundle bedeutet, dass der Web-Rendering-Dienst ein unvollständiges (oder leeres) DOM aufbaut, auch wenn Ihr Quellcode in Ordnung ist. Was stattdessen zu tun ist: Erlauben Sie Crawlern, Ihr JS und CSS abzurufen, und bestätigen Sie es mit der Seitenressourcen-Prüfung des URL-Inspektionstools, um zu sehen, dass nichts Kritisches blockiert ist.

Testen Sie sich: React SEO

Fünf kurze Fragen, um React-Apps crawlbar und indexierbar zu machen. Wählen Sie für jede eine Antwort, dann prüfen Sie.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• React SEO: Best Practices to Make It SEO-Friendly (Ahrefs) – der React-SEO-Leitfaden auf Ahrefs, den ich überprüft habe; dieser Artikel ist die tiefere, quellenverlinkte Behandlung.
• JavaScript SEO: A Definitive Guide (Ahrefs) – mein vollständiger Leitfaden zu den zugrunde liegenden Rendering-Mechaniken: DOM-Parität, die Regel der restriktivsten Direktive, kanonische und Meta-Tag-Behandlung sowie Rendering-Optionen. Lesen Sie dies für den allgemeinen Fall hinter React-spezifischen Korrekturen.
• The Beginner’s Guide to Technical SEO (Ahrefs) – wo React/JavaScript-SEO in das größere Bild passt.

Meine Vorträge

• How Search Works (SlideShare) – meine Erläuterung von Crawling, Rendering, Indexierung und Ranking. (Mein üblicher Haftungsausschluss gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis von Systemen … es wird nicht zu 100 % vollständig oder genau sein.“)

Aus der Branche

• JavaScript-SEO-Grundlagen verstehen (Google) – Primärquellen-Dokumentation zu SPAs, der History API sowie Canonical- und Statuscode-Behandlung.
• Dynamic Rendering (veraltet) (Google) – warum Dynamic Rendering eine Notlösung und keine langfristige Lösung ist.
• Martin Splitt erklärt, wie JavaScript-Seiten indexiert werden (Search Engine Journal) – die Erklärung des Crawl → Render → Index-Ablaufs als „barebone HTML … boom“.
• Gary Illyes über JS-lastige Seiten und Duplicate Content (LinkedIn) – der Fehlermodus Render-Timeout bis Duplikate, in seinen eigenen Worten.
• So beheben Sie technische SEO-Probleme in clientseitigen React-Apps (Search Engine Land) – eine praxisnahe Fallstudie zur Prüfung und Behebung einer CSR-React-App.
• SSR vs. Dynamic Rendering – kein Ranking-Unterschied (Search Engine Roundtable) – Muellers Aussage „keine SEO-Ranking-Boni“.
• react-helmet-async (npm) – die gepflegte Head-Management-Bibliothek für eigenständiges React.
• Der neue Evergreen-Bingbot (Microsoft Edge) (Bing) – Bingbot rendert JS über Chromium, wie Googlebot.

Videos

• Google Search Central – JavaScript-SEO-Serie (YouTube) – Martin Splitts offizielle Videoserie behandelt SEO für React, Angular und Vue speziell und führt durch den Crawl → Render → Index-Prozess sowie die üblichen Korrekturen. Serienankündigung · Kanal

Änderungsprotokoll