Ich habe im letzten Jahr drei Unternehmen dabei beobachtet, wie sie auf Headless CMS umgestiegen sind. Zwei davon haben innerhalb weniger Wochen 40%+ ihres organischen Traffics verloren. Nicht, weil Headless schlecht ist -- sondern weil sie dachten, ihre bisherigen SEO-Standardeinstellungen würden automatisch übernommen. Werden sie nicht.
Das erste Unternehmen, ein mittelgroßes B2B SaaS, ist von WordPress auf Contentful + Next.js migriert. Der Traffic blieb stabil, weil Next.js Server-Side Rendering nativ unterstützt. Meta-Tags, Sitemaps, Canonical-Tags -- alles war im Migrationsplan berücksichtigt. Sie haben die Arbeit vorher gemacht.
Das zweite Unternehmen, eine E-Commerce-Marke, wechselte von Shopify zu Strapi + einem individuellen React-Frontend. Der Traffic fiel in drei Wochen um 43%. Das Problem: reines Client-Side Rendering. Google hat die Seiten gecrawlt und nur leere HTML-Hüllen gesehen. Produktseiten, Kategorieseiten und Blog -- für Suchmaschinen praktisch unsichtbar bis zum zweiten Crawl-Durchlauf, den Google niedriger priorisierte, weil der erste Crawl nichts Brauchbares zurückgegeben hatte.
Das dritte Unternehmen, ein Content-Publisher, migrierte von einem individuellen PHP-CMS zu Sanity + Gatsby. Der Traffic fiel um 38%. Die Ursache: Sie haben ihre komplette URL-Struktur geändert, ohne 301-Weiterleitungen einzurichten. Fünf Jahre an über Jahre aufgebauter Autorität -- über Nacht weg.
Jedes einzelne dieser Ergebnisse wäre vermeidbar gewesen. Hier ist die Checkliste, die zwei dieser Migrationen erspart hätte.
Ein Headless CMS trennt Content-Management von der Darstellungsschicht. Du verwaltest Inhalte in einem System und spielst sie über ein separates Frontend -- eine Website, Mobile App oder jeden anderen Kanal -- per API aus. Der „Kopf“ (Frontend) ist vom „Körper“ (Content) entkoppelt.
Die Vorteile sind real:
Die Falle ist zu glauben, diese Vorteile gäbe es gratis. Bei WordPress oder Shopify werden SEO-Grundlagen -- Meta-Tags, Sitemaps, Canonical-Tags, serverseitig gerendertes HTML -- von der Plattform übernommen. Bei Headless wird jeder einzelne dieser Punkte zu deiner Verantwortung.
Wenn du Content und Darstellung entkoppelst, entkoppelst du SEO auch von seinem automatischen Sicherheitsnetz.
Risiko von Ranking-Verlusten. Google verlässt sich auf stabile Signale, um deine Website zu crawlen und zu bewerten. Wenn du diese Signale während der Migration störst, verschwindest du schnell vom Radar. Der Publisher, den ich erwähnt habe, verlor in nur einer Woche Rankings für 340 Keywords, weil sich die URL-Struktur ohne Redirects geändert hatte.
Auswirkungen auf Traffic und Umsatz. Bei der E-Commerce-Marke bedeutete der Traffic-Einbruch von 43% ungefähr $28.000 verlorenen Monatsumsatz. Die Erholung dauerte zwei Monate -- und bei den Kategorieseiten kamen sie nie wieder vollständig auf das Niveau vor der Migration zurück.
Jahre an SEO-Arbeit bewahren. Backlinks, Domain Authority, Indexierungshistorie -- du hast Monate oder Jahre damit verbracht, dieses Fundament aufzubauen. Eine schlampige Migration wirft das einfach weg.
(Kleine Randbemerkung: Was mich immer wieder überrascht, ist, wie viele Migrationspläne ich gesehen habe, in denen SEO überhaupt nicht vorkommt. Das Engineering-Team denkt an API-Architektur. Das Design-Team denkt ans neue Frontend. Und niemand denkt an die 47.000 organischen Besuche pro Monat, die das ganze Projekt überhaupt finanzieren.)
Das ist der mit Abstand wichtigste Punkt. Deine URLs sind Adressen, auf die sich sowohl Suchmaschinen als auch Nutzer verlassen. Jede unnötige Änderung führt zu 404-Fehlern, kaputten Backlinks und Ranking-Verlusten.
Arbeite während der Migration mit deinem Entwicklungsteam daran, die bestehende URL-Struktur im neuen Headless-Frontend exakt nachzubilden. Wenn Änderungen unvermeidbar sind (zum Beispiel wegen neuem Routing im Headless CMS), richte für jede geänderte URL 301-Weiterleitungen ein. Keine Ausnahmen.
Canonical-Tags sagen Suchmaschinen, welche Version einer Seite die primäre ist. Gerade bei einer Migration und Änderungen an der Architektur kann derselbe Inhalt plötzlich unter mehreren URLs erreichbar sein. Ohne Canonical-Tags konkurriert Duplicate Content mit sich selbst.
In einem Headless CMS müssen Canonical-Tags oft manuell ergänzt oder per API generiert werden. Prüfe deine bestehende Website vor der Migration auf Seiten, die Duplicate-Content-Probleme verursachen könnten. Nach der Migration solltest du mit Screaming Frog oder Google Search Console verifizieren, dass auf jeder Seite ein korrektes Canonical-Tag gesetzt ist.
Bevor die Migration startet, brauchst du eine detaillierte Redirect-Map: alte URLs zu neuen URLs, eins zu eins. Nutze eine Staging-Umgebung, um die Redirects zu testen, bevor du live gehst.
Anders als WordPress, das Meta-Tags automatisch erzeugt, musst du das in einem Headless CMS selbst über API-Calls oder individuellen Frontend-Code umsetzen.
Das war der Killer für den Traffic der E-Commerce-Marke. Wenn du dich stark auf clientseitiges JavaScript verlässt, sehen Suchmaschinen deinen Content beim ersten Crawl möglicherweise gar nicht.
Die Lösung: Server-Side Rendering (SSR) oder Static Site Generation (SSG) implementieren. Next.js und Nuxt.js unterstützen beides direkt. Vorgerenderter Content wird Crawlern sofort ausgeliefert, während JavaScript die Nutzererfahrung für echte Besucher verbessert.
Optimiere außerdem die JavaScript-Ausführung, indem du Code in kleinere asynchrone Chunks aufteilst. Mit Google Lighthouse kannst du prüfen, ob deine Core Web Vitals eingehalten werden.
Headless CMS sind API-getrieben und erzeugen interne Links nicht immer automatisch korrekt. Schreibe individuellen Code, der Links dynamisch auf Basis deiner Content-Struktur generiert. Ergänze automatisierte Prüfungen in deiner CI/CD-Pipeline, damit kaputte Links vor dem Deployment auffallen.
(Noch eine Randbemerkung: Der Publisher dachte, seine internen Links würden nach der Migration „einfach funktionieren“, weil der Content ja derselbe war. Aber die Link-URLs im CMS waren hart auf die alte Domain-Struktur verdrahtet. 2.300 interne Links gingen still kaputt. Aufgefallen ist das erst nach drei Wochen. Autsch.)
Nutze 301-Weiterleitungen für dauerhafte URL-Änderungen. Verwende während einer Migration niemals 302-Weiterleitungen -- sie geben keine SEO-Signale sauber weiter. Implementiere Redirect-Regeln in deiner Server-Konfiguration (Nginx oder Apache) oder im CDN. Überwache Redirect-Ketten und entferne sie konsequent.
In einem Headless CMS musst du die Sitemap oft manuell oder per API generieren. Richte eine automatische Generierung ein, die bei jeder Erstellung oder Änderung von Content aktualisiert wird. Reiche die Sitemap in Google Search Console ein und schließe nicht-kanonische oder doppelte Seiten aus.
Wenn du mehrere Sprachen oder Regionen bedienst, sind hreflang-Tags essenziell. In einem Headless-Setup müssen sie oft manuell ergänzt werden. Prüfe die Implementierung nach der Migration mit Screaming Frog oder Ahrefs.
| Phase | Maßnahmen | Zeitrahmen |
|---|---|---|
| Vor der Migration | URL-Audit, Redirect-Map, Export der Basis-Metriken (Traffic, Rankings, Backlinks, CWV) | 2-4 Wochen vorher |
| Staging | Neues Frontend bauen, SSR/SSG implementieren, Meta-Tags, Canonical-Tags und Sitemaps konfigurieren. Redirects testen | Parallel zur Entwicklung |
| Launch | Deployment, aktualisierte Sitemap in GSC einreichen, Crawl-Fehler in Echtzeit überwachen | Tag 1 |
| Nach dem Launch (Woche 1-2) | Indexabdeckung, Ranking-Veränderungen und Crawl-Fehler überwachen. Kaputte Redirects und fehlende Seiten beheben | Tägliches Monitoring |
| Nach dem Launch (Monat 1-3) | Traffic und Rankings mit der Ausgangslage vergleichen. Verbleibende Verluste angehen. Interne Links auditieren | Wöchentliche Reviews |
| Ansatz | Framework-Beispiele | SEO-Freundlichkeit | Am besten geeignet für |
|---|---|---|---|
| SSR (Server-Side Rendering) | Next.js, Nuxt.js | Exzellent -- vollständig gerendertes HTML beim ersten Request | Dynamische Inhalte, personalisierte Seiten, E-Commerce |
| SSG (Static Site Generation) | Gatsby, Astro, Next.js (static export) | Exzellent -- vorab gebaute HTML-Dateien | Blogs, Marketing-Websites, Dokumentation |
| CSR (Client-Side Rendering) | React SPA, Vue SPA | Schwach ohne Pre-Rendering oder Hydration | App-ähnliche Oberflächen, bei denen SEO zweitrangig ist |
Wenn SEO für dein Business wichtig ist -- und wenn du das hier liest, ist es das vermutlich -- dann entscheide dich für SSR oder SSG. CSR ist für Dashboards und interne Tools okay, aber nicht für Seiten, die Google zuverlässig indexieren soll.
Migrationen sind stressig, aber sie sind auch Chancen. Das B2B SaaS-Unternehmen, das es richtig gemacht hat, hatte am Ende schnellere Seiten, bessere Core Web Vitals und später sogar bessere Rankings als vorher. Der Schlüssel war, SEO als zentrale Migrationsanforderung zu behandeln -- nicht als etwas, das man am Ende noch schnell dranhängt.
Plane im Voraus. Erfasse jede URL. Teste Redirects in Staging. Überwache in den ersten zwei Wochen täglich. Und um Himmels willen: Ändere keine URL-Strukturen ohne 301-Weiterleitungen.
Nicht, wenn du sauber planst. Behalte die URL-Struktur bei, richte 301-Weiterleitungen ein, implementiere SSR oder SSG und prüfe Metadaten, Sitemaps und Canonical-Tags. Verluste entstehen meistens dann, wenn genau diese Schritte übersprungen werden.
Das CMS ist weniger entscheidend als das Frontend-Framework. Contentful, Sanity, Strapi und Prismic sind alle in Ordnung -- entscheidend ist, ob dein Frontend SSR/SSG nutzt (Next.js, Nuxt.js, Gatsby) oder reines CSR.
Wenn die Migration korrekt umgesetzt wird, sollte der Traffic-Verlust minimal sein. Die Erholung nach einer verpatzten Migration dauert typischerweise 2-6 Monate, abhängig davon, wie schwer Redirect-Fehler und Indexierungsprobleme wiegen.
SSR oder SSG ist sehr zu empfehlen. Google kann CSR-Seiten zwar indexieren, aber langsamer und weniger zuverlässig. Für Seiten, bei denen organischer Traffic wichtig ist, solltest du das HTML vorab rendern.
URLs zu ändern, ohne 301-Weiterleitungen einzurichten. Allein das erklärt den Großteil der Traffic-Verluste, die ich gesehen habe.
Weiterführende Artikel:
no credit card required
