Google kann JavaScript ausführen und clientseitig erzeugte Inhalte indexieren. Daraus folgt aber nicht, dass die Rendering-Strategie für SEO egal ist. Inhalt kann nur zuverlässig verarbeitet werden, wenn Googlebot die URL findet, Ressourcen abrufen darf, JavaScript fehlerfrei läuft und der gerenderte DOM den erwarteten Content, Links und Metadaten enthält.
Für öffentlich indexierbare Seiten ist deshalb eine robuste Grundregel sinnvoll:
Wichtiger Inhalt, Navigation und Metadaten sollten bereits in der HTML-Antwort oder im zuverlässig vorgerenderten Ergebnis verfügbar sein. Client-JavaScript ergänzt Interaktivität, statt den gesamten Seiteninhalt erst herstellen zu müssen.
Das bedeutet nicht „SSR für alles“. Next.js bietet statische Generierung, dynamisches Server-Rendering, Streaming, Server Components und Client Components. Entscheidend ist, welche Teile bei der ersten Antwort vorhanden sind und welche Abhängigkeiten zwischen Googlebot und dem vollständigen Inhalt liegen.
Wie Google JavaScript-Seiten verarbeitet
Google beschreibt drei Phasen: Crawling, Rendering und Indexing. Beim ersten Abruf analysiert Googlebot die HTTP-Antwort und kann Links aus klassischen <a href="…">-Elementen direkt entdecken. URLs mit 200-Status werden grundsätzlich zur Rendering-Warteschlange hinzugefügt, sofern keine Indexierungsanweisung dagegenspricht.
Beim Rendering führt Googles Web Rendering Service JavaScript aus. Danach analysiert Google das gerenderte HTML erneut und verwendet es für Indexierung und weitere Linkentdeckung. Die offizielle Dokumentation zu JavaScript SEO weist darauf hin, dass das Rendering wenige Sekunden, aber auch länger dauern kann.
Wichtig sind drei Konsequenzen:
- Google ist leistungsfähiger als viele vereinfachte SEO-Regeln behaupten.
- Server- oder Pre-Rendering bleibt sinnvoll, weil Nutzer und Crawler Inhalt früher erhalten und nicht jeder Bot JavaScript ausführt.
- Ein technischer Fehler im clientseitigen Ablauf kann den indexierbaren Inhalt reduzieren, obwohl die Seite im Browser eines Entwicklers funktioniert.
Rendering-Begriffe in Next.js sauber trennen
Static Site Generation und statisches Rendering
Statische Seiten werden vorab oder beim ersten Bedarf erzeugt und anschließend wiederverwendet. Sie eignen sich für Inhalte, die nicht bei jedem Request individuell berechnet werden müssen, etwa Artikel, Wissensseiten und viele Service-Landingpages.
Vorteile:
- vollständige HTML-Antwort,
- gute Cachebarkeit,
- geringe Serverarbeit pro Request,
- wenig Abhängigkeit von Laufzeit-APIs.
Statisch bedeutet nicht unveränderlich. Revalidierung oder ein neuer Build können Inhalte aktualisieren.
Dynamisches Server-Rendering
Beim dynamischen Rendering entsteht die Antwort zur Anfragezeit. Das ist sinnvoll, wenn Inhalte von Request-Daten, nicht cachebaren Quellen oder aktueller Berechtigung abhängen.
SSR liefert nicht automatisch gute Performance oder SEO. Langsame Datenquellen, Fehler, Timeouts und ein unnötig großes Client-Bundle können weiterhin Probleme verursachen. Der Nutzen liegt darin, dass der Server den relevanten Seitenzustand in die erste Antwort aufnehmen kann.
Client-Side Rendering
Bei reinem CSR liefert der Server häufig eine App-Shell; der eigentliche Inhalt entsteht nach Download und Ausführung von JavaScript sowie möglicherweise nach weiteren API-Requests.
Google kann diesen Ablauf rendern. Zusätzliche Fehlerquellen sind jedoch:
- geblockte JavaScript- oder API-Ressourcen,
- Timeout oder Fehler im Datenabruf,
- Inhalt erst nach Klick, Scroll oder Browser-API,
- Client-Routing ohne crawlbare Links und Statuscodes,
- leere Fehlerzustände mit
200-Status, - abweichende Metadaten oder Canonicals vor und nach Hydration.
Für private Dashboards ist CSR oft passend. Bei öffentlichen Landingpages sollte sein Mehrwert gegen diese Abhängigkeiten abgewogen werden.
Server und Client Components im App Router
Server Components sind im Next.js App Router der Standard. Sie können Daten auf dem Server laden und erhöhen das Client-JavaScript nicht. Client Components werden für State, Event Handler, Lifecycle-Logik oder Browser-APIs verwendet.
Eine wichtige Nuance: Client Component bedeutet beim ersten Seitenaufruf nicht automatisch „leere HTML-Hülle“. Next.js kann Client Components zusammen mit dem React Server Component Payload zu HTML vor-rendern und anschließend hydratisieren. Die Grenze bestimmt vor allem, welcher Code an den Browser ausgeliefert wird und dort laufen muss.
Die aktuelle Next.js-Dokumentation zu Server und Client Components empfiehlt, Client-Grenzen so tief wie sinnvoll zu setzen. Statischer Content muss nicht clientseitig werden, nur weil ein benachbarter Button interaktiv ist.
Welche Inhalte in die erste Antwort gehören
Für SEO-relevante URLs sollten nach Möglichkeit ohne Nutzeraktion vorhanden sein:
- H1 und Hauptinhalt,
- interne Navigationslinks als echte
<a href>-Links, - eindeutiger Title und Meta Description,
- Canonical und hreflang,
- strukturierte Daten, sofern sie den sichtbaren Inhalt korrekt abbilden,
- sinnvoller HTTP-Status,
- sichtbarer Fehler- oder Nicht-gefunden-Zustand.
Tabs und Akkordeons sind nicht grundsätzlich problematisch. Kritisch wird es, wenn ihr Inhalt erst nach einer Interaktion vom Server geladen oder überhaupt in den DOM eingefügt wird. Googlebot führt keine beliebige Nutzerreise aus, um versteckte API-Daten freizuschalten.
Häufige Next.js-Fehler
SEO-Content in useEffect
Ein Client Component lädt im Effekt erst nach der Hydration den Haupttext. Damit hängt der indexierbare Zustand von JavaScript und API-Verfügbarkeit ab. Wenn der Inhalt öffentlich und nicht personalisiert ist, kann er meist in einer Server Component geladen und als HTML ausgegeben werden.
Links ohne href
Ein klickbares <div> mit Router-Handler ist kein verlässlicher crawlbarer Link. Google empfiehlt klassische Anchor-Elemente mit auflösbarem href. Next.js <Link> erzeugt dafür die passende Grundlage.
Soft 404 in Single-Page-Flows
Eine nicht existente Ressource zeigt „Nicht gefunden“, antwortet aber mit 200. Das erschwert Suchmaschinen die Einordnung. Der Server sollte, wo möglich, einen echten 404 liefern. Google dokumentiert für reine SPAs Ersatzstrategien, doch korrekte Statuscodes sind robuster.
Robots oder Ressourcen blockieren
Wenn robots.txt notwendige JavaScript-, CSS- oder API-Ressourcen blockiert, kann Google die Seite nicht wie ein Nutzer rendern. Ein noindex im initialen HTML sollte nicht per JavaScript entfernt werden: Google kann bei erkanntem noindex auf das Rendering verzichten.
Unterschiedliche Canonicals
Ein Canonical in der HTML-Antwort und ein anderer nach Client-Ausführung senden widersprüchliche Signale. Google empfiehlt, Canonicals direkt im HTML und konsistent auszugeben.
Fehler nur im Produktionsbot
Feature Flags, Geo-Logik, Consent, Auth-Checks oder Bot-Erkennung können Googlebot einen anderen Zustand liefern als Entwicklern. Cloaking ist zu vermeiden; auch unbeabsichtigte Abweichungen sollten mit Googles Testwerkzeugen und Serverlogs untersucht werden.
Entscheidungslogik für neue Seiten
Statisch rendern, wenn …
- der Inhalt für alle Besucher gleich oder cachebar ist,
- Aktualisierungen über Build oder Revalidierung ausreichen,
- schnelle, robuste Auslieferung wichtiger ist als Request-Personalisierung.
Dynamisch auf dem Server rendern, wenn …
- der öffentliche Inhalt zur Anfragezeit aktuell sein muss,
- Request-Daten den Seitenzustand bestimmen,
- Caching bewusst eingeschränkt werden muss.
Clientseitig rendern, wenn …
- der Bereich nicht indexiert werden soll, etwa ein internes Dashboard,
- Inhalt stark interaktiv und nutzerspezifisch ist,
- ein serverseitiger Grundzustand keinen sinnvollen Mehrwert liefert.
Hybride Lösungen sind normal: statischer oder serverseitiger Hauptinhalt, kleine Client Components für Filter, Formulare und Interaktion.
So prüfen Sie, was Google wirklich sieht
- Quelltext ansehen: Sind Hauptinhalt, Links, Canonical und Metadaten in der Antwort vorhanden?
- JavaScript deaktivieren: Welche Nutzeraufgabe und welcher Inhalt bleiben zugänglich? Das ist ein Robustheitstest, keine exakte Google-Simulation.
- URL-Prüfung in der Search Console: Live-Test und gerendertes HTML auf fehlende Inhalte oder Ressourcenfehler prüfen.
- Rich Results Test: Bei strukturierten Daten den gerenderten Zustand kontrollieren.
- Serverlogs: Googlebot-Requests, Statuscodes, Fehler und Antwortzeiten untersuchen.
- Clean Browser Test: Direktaufruf, Reload, Client-Navigation und 404-Fälle in einem neuen Profil testen.
Rendering und Performance gemeinsam betrachten
Server-Rendering kann Inhalt früh verfügbar machen, garantiert aber keine guten Core Web Vitals. Ein langsamer Server verschlechtert die Antwortzeit. Ein großes Hydration-Bundle kann INP belasten. Ein nachträglich ersetzter Platzhalter kann CLS erzeugen.
Umgekehrt ist weniger Client-JavaScript oft ein doppelter Gewinn: weniger Ausführungsarbeit für Nutzer und weniger Abhängigkeit für Crawler. Die Rendering-Entscheidung sollte deshalb Content-Verfügbarkeit, Cache-Strategie, Serverlatenz und Client-Kosten gemeinsam betrachten.
Audit-Checkliste
- Hauptinhalt und interne Links sind ohne Nutzeraktion verfügbar.
- Jede indexierbare URL liefert einen passenden HTTP-Status.
- Title, Canonical, hreflang und Robots sind im HTML konsistent.
- Notwendige JS-, CSS- und API-Ressourcen sind crawlbar.
- SEO-Content hängt nicht unnötig von
useEffectab. - Client Components sind auf echte Interaktivität begrenzt.
- Direktaufruf und Client-Navigation erzeugen denselben kanonischen Zustand.
- Fehler-, Leer- und Nicht-gefunden-Zustände wurden getestet.
- Der gerenderte Zustand wurde mit Search-Console-Werkzeugen geprüft.
Fazit
Google kann CSR indexieren, aber jede zusätzliche Client-Abhängigkeit ist eine weitere Stelle, an der Inhalt, Links oder Metadaten verloren gehen können. Für öffentliche, suchrelevante Seiten sind statisches oder serverseitiges Rendering meist die robustere Grundlage. Client Components ergänzen gezielt die Interaktion.
Die beste Next.js-Strategie ist nicht „SSR überall“, sondern: wichtigen Inhalt früh liefern, korrekte Status- und Metadaten senden, Client-JavaScript klein halten und den tatsächlich gerenderten Zustand prüfen.