Ein Kunde rief mich 2021 in Panik an. Sie hatten ihren E-Commerce-Katalog mit 4.200 Produktseiten auf einem headless Contentful Setup mit Next.js Frontend neu gestartet. Die Agentur hatte ihnen den Pitch verkauft: moderner Stack, blitzschnell, Google wird es lieben. Sechs Wochen nach dem Launch war der organische Traffic um 61% eingebrochen. Keine Crawl-Fehler. Keine manuellen Penalties. Einfach... weg.
Wichtiges Fazit: Headless zu gehen behebt dein SEO nicht automatisch – kaputte Crawls entstehen durch Client-Side-Rendering, fehlenden Metadaten-Transport und Preview-URLs, die in den Index lecken.
Ich habe dieses Muster mittlerweile viel zu oft gesehen. Und das Frustrierende? Das SSR funktionierte technisch gesehen. Seiten wurden auf dem Server gerendert. HTML wurde zurückgegeben. Aber es gab etwa sieben andere Stellen, an denen das Ganze leise auseinanderfiel, und niemand hatte daran gedacht zu überprüfen.
Dieser Post handelt nicht davon, ob headless gut oder schlecht ist, es ist eindeutig hervorragend möglich. Es geht um die spezifischen, lösbaren Wege, auf denen SSR auf einem headless Stack für SEO schiefgeht, und was du konkret dagegen tust.
---
Der Mythos, dass SSR Headless SEO automatisch behebt
Hier ist das Problem: Als Client-Side Rendering um 2016–2018 zum Mainstream wurde, hatte die SEO-Community einen kollektiven Zusammenbruch (zu Recht). Googles Crawler war inkonsistent bei der JavaScript-Ausführung, Inhalte würden nicht indexiert, und SPA-Seiten verloren Rankings. Also schwenkte die Branche hart auf SSR als Lösung um.
Und es ist besser als reines CSR. Aber „besser" bedeutet nicht „gelöst".
SSR löst das Rendering-Problem. Aber Caching-Strategien, Crawl Budget, kanonische URLs und die Metadaten-Pipeline zwischen CMS und HTML <head>? Das sind komplett andere Baustellen. In einer Headless-Architektur musst du mindestens zwei Systeme koordinieren: das CMS und das Frontend-Framework. Sie müssen sich einig sein, was zu tun ist.
Das tun sie oft nicht.
---
Wo SSR SEO in einem Headless Stack wirklich kaputtmacht
Das Time-to-First-Byte-Problem
SSR ist nur schnell, wenn dein Server schnell ist. Bei einem Headless-Setup muss dein Next.js- oder Nuxt-Server Inhalte von der CMS-API abrufen, bevor er antworten kann. Wenn Contentful (oder Sanity, oder Storyblok, oder welche auch immer) einen langsamen Moment hat, schießt dein TTFB in die Höhe. Ich habe gesehen, dass TTFB bei schlecht konfigurierten SSR-Setups während CMS-API-Kaltstarts über 3 Sekunden gestiegen ist.
Google nutzt TTFB als Signal für die Crawl-Planung. Langsame Antworten bedeuten, dass Googlebot weniger Seiten pro Session crawlt. Bei einer großen Katalog-Site führt das direkt dazu, dass Seiten tagelang in der Crawl-Warteschlange feststecken.
Kanonische Tags, die zur Laufzeit generiert werden
Das überrascht die meisten. In einem traditionellen CMS wie WordPress sind kanonische Tags im Theme oder einem SEO-Plugin eingebaut. In einem headless Setup lebt deine kanonische Logik in deinem Frontend-Code, vielleicht in einer Next.js <Head> Komponente, vielleicht in einem Layout Wrapper. Das CMS hat keine Ahnung, welches Canonical du renderst.
Was passiert also, wenn eine Produkt-URL Query-Parameter für Sortierung oder Filterung hat? Oder wenn dein CMS einen Page Slug zurückgibt, der sich leicht von deiner Routing-Logik unterscheidet? Du landest mit kanonischen Tags, die auf die falsche URL zeigen oder ganz fehlen. Ich bin auf das bei einem Seahawk Projekt für einen UK-Einzelhändler letztes Jahr gestoßen, 800 Seiten kanonisierten zu /?page=1, weil die Pagination-Logik den falschen Prop an die SEO-Komponente übergab. Hat zwei Tage gedauert, es zu finden. Drei Zeilen zum Beheben.
Metadaten-Pipelines ohne Fallbacks
Jedes headless CMS lässt dich SEO-Metadaten-Felder hinzufügen, Meta Title, Description, OG Tags. Toll. Aber was passiert, wenn ein Editor eine Seite veröffentlicht und vergisst, sie auszufüllen? In WordPress mit Yoast würdest du ein generiertes Fallback bekommen. In einem headless Setup, wenn deine Frontend-Komponente keine explizite Fallback-Logik hat, bekommst du ein leeres <title> Tag. Oder schlimmer, der rohe Feldname hallt in den HTML wider.
Baue die Fallback-Kette immer explizit auf: seoTitle ?? pageTitle ?? siteName. Jedes Feld. Ohne Ausnahmen.
Das ist der Punkt, an dem sich ein Schema-gesteuerten CMS bewährt. In Sanity sind die SEO-Felder (Meta-Titel, Canonical, Hreflang, strukturierte Daten) typisierte Eigenschaften des Content-Modells, nicht nachträglich an einen Page Editor angehängte Boxen. Die Fallback-Kette existiert einmal im Schema, statt in jeder Frontend-Komponente neu implementiert zu werden, und eine GROQ-Query gibt genau die Felder zurück, die das Template benötigt – ohne Over-Fetching und ohne das Parsing loser CMS-Antworten. Die Metadaten-Pipeline wird zuverlässiger, weil die Source of Truth das Content-Modell ist, nicht der Code, der es konsumiert. Ich habe das kürzlich für einen Kunden umgesetzt, und es hat eine ganze Klasse von Runtime-Bugs eliminiert, um die es in diesem Abschnitt geht.
---
Die Caching-Schicht, über die niemand genug nachdenkt
ISR, Incremental Static Regeneration in Next.js, ist wirklich clever. Du bekommst größtenteils statische Performance mit der Fähigkeit, nach Plan neu zu validieren. Aber für SEO ist das Revalidierungs-Fenster eine Entscheidung mit echten Konsequenzen.
Setze revalidate: 3600 (eine Stunde) und deine Content-Änderungen sind bis zu eine Stunde nach der Veröffentlichung nicht für Googlebot sichtbar. Das ist okay für einen Blog. Für eine News-Site oder eine Flash-Sale E-Commerce-Seite ist es ein Desaster. Ich hatte einen Kunden, der einen 4-Stunden-begrenzten Sale laufen ließ und 45 Minuten davon mit einer gecachten "ausverkauft"-Seite verbrachte, weil niemand das ISR-Fenster bedacht hatte, als die Discount-Kampagne geplant wurde.
Der Fix ist nicht immer „häufiger neu validieren." Häufigere Revalidierung bedeutet mehr Origin Load. Der echte Fix ist On-Demand-Revalidierung, löse eine Cache-Bereinigung von deinem CMS Webhook aus, wenn Content veröffentlicht wird. Next.js unterstützt On-Demand ISR seit v12.2. Contentful, Sanity und Storyblok unterstützen alle ausgehende Webhooks. Verdrahte sie miteinander. Es dauert etwa einen Nachmittag.
---
Crawl Budget und die Headless-URL-Oberfläche
Traditionelle CMS-Plattformen haben Jahre von Konvention um URLs, Taxonomien, Pagination, kanonische Handhabung für Archive. Headless Setups geben dir totale Freiheit, was bedeutet, du musst alle diese Entscheidungen selbst treffen, im Code.
Freiheit ist gefährlich, wenn du nicht aufpasst.
Ein Headless-Produktkatalog mit Facetten-Filterung kann leicht Zehntausende eindeutiger URLs generieren, /products?colour=red&size=M&sort=price-asc und jede erdenkliche Permutation davon. Wenn deine SSR-Schicht all diese mit eindeutigem HTML rendert und kein Canonical auf die Basis-URL zurückweist, hast du Googlebot gerade ein unendliches Labyrinth in die Hand gedrückt.
Ein paar Dinge, die ich bei jedem Headless-Build mache:
- Alle Query-Parameter-URLs in
robots.txtblockieren, die nicht SEO-relevant sind - Ein Single Canonical auf alle gefilterten/sortierten Varianten implementieren, das auf die saubere Basis-URL verweist
<meta name="robots" content="noindex, follow">auf paginierten Seiten jenseits von Seite 2 bei kleineren Sites nutzen- Prüfe die XML-Sitemap gegen das ab, was Googlebot tatsächlich crawlt (über den Coverage-Report der Google Search Console) – die beiden stimmen beim ersten Durchlauf selten überein.
Und bitte generiere deine Sitemap dynamisch aus deinem CMS, nicht statisch zur Build-Zeit. Eine Sitemap, die nur Inhalte aus deinem letzten Deploy widerspiegelt, ist nutzlos, wenn Editoren zwischen den Deployments 40 neue Seiten veröffentlichen.
---
Die Structured-Data-Lücke
Headless-CMS sind hervorragend für strukturierte Inhalte. Schemas, Feldtypen, Referenzen – Sanity und Contentful modellieren Daten wunderbar. Aber strukturierte Daten für SEO (JSON-LD-Schemas, Product, Article, BreadcrumbList etc.) sind etwas ganz anderes.
Die meisten Headless-Frontend-Setups, die ich prüfe, haben entweder gar kein JSON-LD oder ein einzelnes generisches WebSite-Schema, das dem Layout angeklebt ist. Das ist ein Fehler. Auf einer Produktseite möchtest du ein Product-Schema mit Preis-, Verfügbarkeits- und Review-Daten, die live aus deinem CMS gezogen werden. Auf einer Rezept- oder How-to-Seite kann das passende Schema Rich Results in Google direkt beeinflussen.
Die Implementierung ist nicht kompliziert. In Next.js packst du dein JSON-LD in einen <script type="application/ld+json">-Tag im <Head>, füllst ihn aus deinen Page-Props auf und testest ihn im Rich-Results-Test von Google. Kompliziert ist es, sicherzustellen, dass dein CMS-Content-Modell die richtigen Felder für das Frontend bereitstellt. Das ist ein Content-Architecture-Gespräch, keine Dev-Task.
---
Die Metadata-Pipeline von Anfang bis Ende reparieren
Hier ist die exakte Checkliste, die ich bei jedem Headless-SEO-Audit abarbeite. Nicht konzeptuell. Tatsächliche Schritte.
- Verifiziere das gerenderte HTML. Nutze curl -A "Googlebot" [deine URL] und inspiziere die rohe Response. Was enthält der
<head>tatsächlich? Nicht das, was dein Browser nach Hydration zeigt. Die rohe Server-Response. - Prüfe die Canonical-Genauigkeit auf 20 zufälligen Seiten, besonders bei Produkt-/Kategorieseiten mit Parametern. Schreibe ein kleines Script mit
node-fetch, um Canonicals in großem Maßstab zu pullen und zu parsen, falls die Seite groß ist. - Teste TTFB von drei Standorten. Ich nutze WebPageTest mit Googlebot UA von London, Frankfurt und Virginia. Falls irgendein Standort konsistent über 800ms liegt, kümmere dich zunächst um die API-Response-Zeiten deines CMS.
- Prüfe deine Sitemap gegen die GSC. Exportiere den Coverage-Report aus der Search Console. Vergleiche „Valid"-URLs mit deiner Sitemap. Jede URL in der Sitemap, die als „Excluded" auftaucht, braucht Nachforschungen.
- Prüfe auf doppelte `<title>` und `<meta description>` Tags. Kommt häufiger vor als man denkt, wenn Layout-Komponenten und Seiten-Komponenten beide versuchen, Metadaten zu schreiben.
- Teste On-Demand-Revalidation end-to-end. Veröffentliche eine Inhaltsänderung in deinem CMS. Wie lange dauert es, bis sie auf der Server-Rendered-Seite live ist? Falls es in Stunden gemessen wird, richte den Webhook ein.
- Validiere strukturierte Daten auf repräsentativen Seitentypen – mindestens Product, Article und FAQ. Nutze Google's Rich Results Test auf den Live-URLs, nicht nur lokal.
---
Die Tools, die ich tatsächlich verwende
Keine theoretische Liste. Das sind die Tools, die offen sind, wenn ich gerade an einem Headless-SEO-Fix arbeite.
- Screaming Frog, crawle die Live-Site im Rendering-Modus, um zu sehen, was Googlebot sieht. Stelle den Rendering-Modus zuerst auf "None", um die rohe SSR-Ausgabe zu sehen, dann vergleiche mit dem "JavaScript"-Modus.
- WebPageTest, TTFB, Server-Response-Waterfall, CDN-Edge-Hit/Miss-Header.
- Google Search Console, Coverage-Bericht, URL-Überprüfung für einzelne Seiten, Core Web Vitals nach Seitentyp.
- Postman oder `curl`, zum manuellen Abfragen von CMS-APIs, um zu prüfen, welche Daten tatsächlich an die SSR-Schicht zurückgegeben werden.
- Next.js integriertes Logging, oft übersehen. Das Aktivieren von ausführlichem Logging während eines Staging-Audits zeigt genau, wo dein Render wartet.
Ehrlich gesagt finde ich 80 % der Headless-SEO-Probleme allein mit Screaming Frog, wenn Sie wissen, worauf Sie achten müssen.
---
FAQ
Garantiert Next.js mit SSR gutes SEO?
Nein. SSR bedeutet, dass dein HTML auf dem Server gerendert wird, bevor es den Client erreicht – das ist notwendig, aber nicht ausreichend. Du brauchst trotzdem korrekte Canonical-Tags, eine sinnvolle Sitemap, richtige Metadaten, strukturierte Daten und schnelle Server-Response-Zeiten. SSR behebt das JavaScript-Rendering-Problem. Es behebt nicht die Architektur-Probleme.
Ist Contentful besser für SEO als Sanity?
Keines der beiden CMS beeinflusst direkt dein SEO, sie sind headless, haben also keine Meinung zu deinem gerendertem HTML. Die Frage ist, welches es einfacher macht, SEO-relevante Content-Felder zu modellieren. Beide haben SEO-Field-Plugins. Die GROQ-Abfragesprache von Sanity gibt dir mehr Flexibilität beim Formen der exakten Daten, die dein Front-End braucht, was es einfacher machen kann, eine saubere Metadaten-Pipeline zu bauen. Aber das ist ein Developer-Experience-Argument, kein SEO-Argument.
Wie handhabe ich hreflang in einem Headless-Setup?
Genauso wie du alle Metadaten handhaben würdest – generiere sie serverseitig aus deinen CMS-Daten und injiziere sie in <head> auf jeder Seite. Die Komplexität liegt darin, die Locale-zu-URL-Zuordnung in deinem CMS zu pflegen und sicherzustellen, dass das Front-End sie korrekt konsumiert. Wenn du auf Next.js bist, handhabt die i18n-Konfiguration einen Großteil der Routing-Seite; du musst trotzdem explizit die <link rel="alternate" hreflang="...">-Tags aus deinen Content-Daten rendern.
Sollte ich SSG statt SSR für bessere SEO nutzen?
Hängt von deiner Content-Update-Häufigkeit ab. Vollständige statische Generierung (SSG) gibt dir den schnellstmöglichen TTFB, alles wird zur Deploy-Zeit vorgebaut, bedeutet aber, dass Content-Updates nur bei neuem Deploy live gehen, es sei denn, du nutzt ISR. Für eine größtenteils statische Marketing-Website ist SSG mit On-Demand-ISR wahrscheinlich die richtige Wahl. Für einen großen Katalog mit häufigen Bestandsänderungen ist SSR mit aggressivem CDN-Caching und kurzfristigen Cache-Headern angemessen.
---
Die unbequeme Wahrheit ist, dass Headless Stacks mehr SEO-Verantwortung in die Hände von Entwicklern legen als jede bisherige CMS-Architektur. Es gibt kein Plugin, das man installieren und das sich darum kümmern kann. Jede Entscheidung, von der kanonischen Logik über die Sitemap-Generierung bis zur strukturierten Datenauszeichnung, ist eine Code-Entscheidung. Das bedeutet, dass jede dieser Entscheidungen falsch sein kann, und die meisten Teams überprüfen sie erst, wenn die Rankings bereits in die falsche Richtung gehen.
Sei schneller dran. Crawle deine eigene Site wie Googlebot es würde. Die Probleme sind fast immer auffindbar, bevor Google sie für dich findet.