Ein Kunde rief mich 2021 in Panik an. Sie hatten ihren E-Commerce-Katalog neu aufgelegt – 4.200 Produktseiten – auf einem Contentful-Setup ohne Koppelung an ein Next.js-Frontend. Die Agentur hatte ihnen das verkauft: moderner Stack, blitzschnell, Google wird es lieben. Sechs Wochen nach dem Launch war der organische Traffic um 61% eingebrochen. Nicht Crawl-Fehler. Nicht manuelle Strafen. Einfach... weg.modern stack, lightning fast, Google will love it. Six weeks post-launch, organic traffic was down 61%. Not crawl errors. Not manual penalties. Just... gone.
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.Going headless does not sort your SEO by default: broken crawls come from client-side rendering, missing metadata transport, and preview URLs leaking into the index.
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.
Das ist kein Beitrag darüber, ob Headless gut oder schlecht ist – es kann eindeutig ausgezeichnet sein. Es geht um die spezifischen, lösbaren Wege, auf denen SSR bei einer Headless-Architektur für SEO schiefgeht und was du wirklich 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".is better than pure CSR. But "better" doesn't mean "sorted."
SSR löst das Rendering-Problem. Es macht fast nichts für Caching-Strategie, Crawl-Budget, kanonische Verwirrung oder die Metadaten-Pipeline zwischen deinem CMS und deinem HTML <head>. Das sind völlig getrennte Ausfallmodi. Und in einer Headless-Architektur sind alle davon in mindestens zwei Systemen – dem CMS und dem Frontend-Framework – anfällig, die sich einig sein müssen.<head>. Those are entirely separate failure modes. And in a headless architecture, every single one of them involves at least two systems -- the CMS and the front-end framework -- that need to agree on what to do.
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.before it can respond. If Contentful (or Sanity, or Storyblok, or whichever) is having a slow moment, your TTFB balloons. I've seen TTFB spike past 3 seconds on poorly configured SSR setups during CMS API cold starts.
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. Slow responses mean Googlebot crawls fewer pages per session. On a large catalogue site, that directly translates to pages stuck in the crawl queue for weeks.
Kanonische Tags, die zur Laufzeit generiert werden
Das überrascht viele. In einem klassischen CMS wie WordPress sind kanonische Tags in das Theme oder ein SEO-Plugin eingebettet. Bei Headless 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, welchen kanonischen Tag du renderst.WordPress, canonical tags are baked into the theme or an SEO plugin. In a headless setup, your canonical logic lives in your front-end code -- maybe in a Next.js <Head> component, maybe in a layout wrapper. The CMS has no idea what canonical you're rendering.
Was passiert also, wenn eine Produkt-URL Query-Parameter für Sortierung oder Filterung hat? Oder wenn dein CMS einen Seiten-Slug zurückgibt, der sich leicht von deiner Routing-Logik unterscheidet? Du landest bei kanonischen Tags, die entweder auf die falsche URL zeigen oder ganz fehlen. Das bin ich bei einem Seahawk-Projekt für einen britischen Einzelhändler letztes Jahr auf die Spur gekommen – 800 Seiten kanonisierten zu /?page=1, weil die Paginierungslogik das falsche Prop an die SEO-Komponente übergab. Zwei Tage zum Finden. Drei Zeilen zum Fixen./?page=1 because the pagination logic was passing the wrong prop to the SEO component. Took two days to find. Three lines to fix.
Metadaten-Pipelines ohne Fallbacks
Jedes Headless-CMS lässt dich SEO-Metadaten-Felder hinzufügen – Meta-Titel, Beschreibung, OG-Tags. Großartig. Aber was passiert, wenn ein Redakteur eine Seite veröffentlicht und vergisst, sie auszufüllen? Bei WordPress mit Yoast würdest du einen generierten Fallback bekommen. Bei Headless bekommst du, wenn deine Frontend-Komponente keine explizite Fallback-Logik hat, einen leeren <title>-Tag. Oder schlimmer – der rohe Feldname echot ins HTML.<title> tag. Or worse -- you get the raw field name echoing into the HTML.
Baue die Fallback-Kette immer explizit auf: seoTitle ?? pageTitle ?? siteName. Jedes Feld. Ohne Ausnahmen.seoTitle ?? pageTitle ?? siteName. Every field. No exceptions.
---
Die Caching-Schicht, über die niemand genug nachdenkt
ISR – Incremental Static Regeneration in Next.js – ist wirklich clever. Du kriegst fast-statische Performance mit der Möglichkeit, nach Plan neu zu validieren. Aber für SEO ist das Validierungsfenster 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.revalidate: 3600 (one hour) and your content edits won't be seen by Googlebot for up to an hour after publish. That's fine for a blog. For a news site or a flash-sale e-commerce page, it's a disaster. I had a client who ran a 4-hour limited sale and spent 45 minutes of it with a cached "sold out" page because nobody had thought about the ISR window when the discount campaign was planned.
Der Fix ist nicht immer „aggressiver neu validieren." Häufigere Neubewertung bedeutet mehr Origin-Last. Der echte Fix ist On-Demand-Revalidation – triggere eine Cache-Bereinigung von deinem CMS-Webhook, wenn Content veröffentlicht wird. Next.js unterstützt On-Demand ISR seit v12.2. Contentful, Sanity und Storyblok unterstützen alle ausgehende Webhooks. Verkabel sie zusammen. Es dauert etwa einen Nachmittag.on-demand revalidation -- trigger a cache purge from your CMS webhook when content is published. Next.js has supported on-demand ISR since v12.2. Contentful, Sanity, and Storyblok all support outgoing webhooks. Wire them together. It takes about an afternoon.
---
Crawl Budget und die Headless-URL-Oberfläche
Traditionelle CMS-Plattformen haben jahrelange Konventionen rund um URLs -- Taxonomien, Paginierung, kanonische Behandlung für Archive. Headless-Setups geben dir totale Freiheit, was bedeutet, dass du all diese Entscheidungen selbst im Code treffen musst.
Freiheit ist gefährlich, wenn du nicht aufpasst.
Ein Headless-Produktkatalog mit facettierter Filterung kann leicht zehntausende eindeutige URLs generieren -- /products?colour=red&size=M&sort=price-asc und jede Permutation davon. Wenn deine SSR-Schicht all diese mit eindeutiger HTML rendert und kein Canonical zurück zur Basis-URL zeigt, hast du Googlebot gerade ein unendliches Labyrinth in die Hand gegeben./products?colour=red&size=M&sort=price-asc and every permutation thereof. If your SSR layer is rendering all of those with unique HTML and no canonical pointing back to the base URL, you've just handed Googlebot an infinite maze.
Ein paar Dinge, die ich bei jedem Headless-Build mache:
- Alle Query-Parameter-URLs in robots.txt blockieren, die nicht SEO-relevant sind
robots.txtthat aren't SEO-significant - 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
<meta name="robots" content="noindex, follow">on paginated pages beyond page 2 for smaller sites - Vergleiche die XML-Sitemap mit dem, was Googlebot tatsächlich crawlt (über den Coverage-Bericht der Google Search Console) -- die beiden sind beim ersten Durchlauf selten identisch.
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 Redakteure zwischen Deployments 40 neue Seiten veröffentlichen.
---
Die Structured-Data-Lücke
Headless CMSs sind brillant bei strukturiertem Inhalt. Schemas, Feldtypen, Referenzen -- Sanity und Contentful modellieren Daten wunderbar. Aber strukturierte Daten für SEO (JSON-LD Schemas -- Product, Article, BreadcrumbList, etc.) sind etwas völlig 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.WebSite schema bolted onto the layout. That's a miss. On a product page, you want Product schema with price, availability, and review data pulled live from your CMS. On a recipe or how-to page, the appropriate schema can directly influence rich results in Google.
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.<script type="application/ld+json"> tag inside <Head>, populate it from your page props, and test it in Google's Rich Results Test. What is complicated is making sure your CMS content model surfaces the right fields for the front-end to consume. That's a content architecture conversation, not a dev ticket.
---
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.
- Überprüfe das gerenderte HTML -- Nutze curl -A "Googlebot" [deine URL] und inspiziere die rohe Antwort. Was enthält der <head> tatsächlich? Nicht das, was dein Browser nach Hydration zeigt. Die rohe Server-Antwort. -- Use
curl -A "Googlebot" [your URL]and inspect the raw response. What does the<head>actually contain? Not what your browser shows after hydration. The raw server response. - Überprüfe kanonische Genauigkeit auf 20 zufälligen Seiten -- Besonders Produkt-/Kategorieseiten mit Parametern. Baue ein kleines Script mit node-fetch, um Canonicals in großem Maßstab zu ziehen und zu parsen, wenn die Website groß ist. -- Especially product/category pages with parameters. Build a small script with
node-fetchto pull and parse canonicals at scale if the site is large. - Teste TTFB von drei Standorten -- Ich nutze WebPageTest mit Googlebot UA von London, Frankfurt und Virginia. Wenn ein Standort durchgehend über 800ms liegt, untersuche zuerst deine CMS-API-Antwortzeiten vor allem anderen. -- I use WebPageTest with Googlebot UA from London, Frankfurt, and Virginia. If any location is above 800ms consistently, dig into your CMS API response times before anything else.
- Prüfe deine Sitemap gegen GSC -- Exportiere den Coverage-Bericht aus der Search Console. Vergleiche "Valid"-URLs mit deiner Sitemap. Jede URL in der Sitemap, die als "Excluded" gekennzeichnet ist, braucht Untersuchung. -- Export the Coverage report from Search Console. Compare "Valid" URLs to your sitemap. Any URL in the sitemap that's "Excluded" needs investigation.
- Überprüfe auf doppelte `<title>` und `<meta description>` Tags -- Passiert häufiger als man denkt, wenn Layout-Komponenten und Seiten-Level-Komponenten beide versuchen, Metadaten zu schreiben. -- Happens more than you'd think when layout components and page-level components both try to write metadata.
- Testen Sie die On-Demand-Revalidierung end-to-end – Veröffentlichen Sie eine Inhaltsänderung in Ihrem CMS. Wie lange dauert es, bis sie auf der server-gerenderten Seite live ist? Falls es in Stunden gemessen wird, richten Sie den Webhook ein. -- Publish a content change in your CMS. How long before it's live on the server-rendered page? If it's measured in hours, wire up the webhook.
- Validieren Sie strukturierte Daten auf repräsentativen Seitentypen – Produkt, Artikel, FAQ mindestens. Nutzen Sie Googles Rich Results Test auf den Live-URLs, nicht nur lokal. -- Product, Article, FAQ at minimum. Use Google's Rich Results Test on the live URLs, not just locally.
---
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 – Crawlen Sie die Live-Site im Rendering-Modus, um zu sehen, was Googlebot sieht. Stellen Sie den Rendering-Modus zuerst auf „None", um die rohe SSR-Ausgabe zu sehen, vergleichen Sie dann mit dem „JavaScript"-Modus. -- Crawl the live site in rendering mode to see what Googlebot sees. Set the rendering mode to "None" first to see raw SSR output, then compare to "JavaScript" mode.
- WebPageTest – TTFB, Server-Response-Waterfall, CDN-Edge-Hit/Miss-Header. -- TTFB, server response waterfall, CDN edge hit/miss headers.
- Google Search Console – Coverage-Bericht, URL-Inspektion für einzelne Seiten, Core Web Vitals nach Seitentyp. -- Coverage report, URL Inspection for specific pages, Core Web Vitals by page type.
- Postman oder `curl` – Zum manuellen Abfragen von CMS-APIs, um zu überprüfen, welche Daten tatsächlich an die SSR-Schicht zurückgegeben werden. -- For manually querying CMS APIs to check what data is actually being returned to the SSR layer.
- Next.js integriertes Logging – Oft übersehen. Wenn Sie während eines Staging-Audits ausführliches Logging aktivieren, werden Sie sehen, genau wo Ihr Render wartet. -- Often overlooked. Turning on verbose logging during a staging audit will surface exactly where your render is waiting.
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 Ihr HTML auf dem Server gerendert wird, bevor es den Client erreicht – das ist notwendig, aber nicht ausreichend. Sie benötigen immer noch 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?
Weder das eine noch das andere CMS wirkt sich direkt auf Ihr SEO aus – sie sind headless, also haben sie keine Meinung zu Ihrem gerendertem HTML. Die Frage ist, welches es leichter macht, SEO-relevante Content-Felder zu modellieren. Beide haben SEO-Field-Plugins. Sanitys GROQ-Abfragesprache gibt Ihnen mehr Flexibilität beim Formen der exakten Daten, die Ihr Front-End benötigt, was es einfacher machen kann, eine saubere Metadata-Pipeline zu bauen. Aber das ist ein Developer-Experience-Argument, kein SEO-Argument.GROQ query language gives you more flexibility in shaping the exact data your front-end needs, which can make it easier to build a clean metadata pipeline. But that's a developer experience argument, not an SEO argument.
Wie handhabe ich hreflang in einem Headless-Setup?
Genauso wie Sie jedes andere Metadatum handhaben würden – generieren Sie es Server-seitig aus Ihren CMS-Daten und injizieren Sie es in den <head> auf jeder Seite. Die Komplexität liegt darin, die Locale-zu-URL-Zuordnung in Ihrem CMS zu pflegen und sicherzustellen, dass das Front-End sie korrekt konsumiert. Falls Sie Next.js verwenden, erledigt die i18n-Config viel auf der Routing-Seite; Sie müssen immer noch explizit die <link rel="alternate" hreflang="...">-Tags aus Ihren Content-Daten rendern.<head> on every page. The complexity is in maintaining the locale-to-URL mapping in your CMS and making sure the front-end consumes it correctly. If you're on Next.js, the i18n config handles a lot of the routing side; you still need to explicitly render the <link rel="alternate" hreflang="..."> tags from your content data.
Sollte ich SSG statt SSR für bessere SEO nutzen?
Das hängt von deiner Content-Update-Häufigkeit ab. Vollständige statische Generierung (SSG) gibt dir die schnellstmögliche TTFB – alles wird zum Zeitpunkt des Deployments vorgebaut – bedeutet aber, dass Content-Updates nur bei einer erneuten Bereitstellung 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 kurzlebigen Cache-Headern angemessener.
---
Die unbequeme Wahrheit ist, dass Headless-Stacks mehr SEO-Verantwortung in die Hände von Entwicklern legen als jede vorherige CMS-Architektur. Es gibt kein Plugin, das man installiert und das sich darum kümmert. Jede Entscheidung – von der Canonical-Logik über die Sitemap-Generierung bis zur strukturierten Datenerfassung – 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.