Headless CMS: Wann lohnt sich der Umstieg von WordPress?

Was ist ein Headless CMS?

Ein klassisches CMS wie WordPress macht zwei Dinge in einem System: Es speichert deine Inhalte und baut daraus die fertige Seite, mit Theme, Templates und Plugins. Inhalt und Darstellung hängen fest zusammen. Man nennt das gekoppelt.

Ein Headless CMS macht nur den ersten Teil. Die Inhalte liegen strukturiert hinter einer API (einer Schnittstelle, über die andere Programme Daten abfragen). Deine Website, deine App oder dein Newsletter holen sich die Inhalte dort ab und stellen sie selbst dar. Das Frontend, also das, was Besucher sehen, ist ein eigenes Projekt.

Wann lohnt sich ein Headless CMS?

Mehrere Kanäle. Dieselben Produkttexte, FAQs oder Standortdaten erscheinen auf der Website, in einer App und im Newsletter. Mit einem Headless CMS pflegst du sie einmal, statt sie zu kopieren.

Eigenes Frontend. Dein Team baut ohnehin mit React, Next.js oder TanStack Start und will sich nicht an ein Theme-System anpassen. Oder du planst einen Relaunch und willst das Design später noch einmal ändern können, ohne die Inhalte neu zu migrieren.

Performance. Ein Frontend, das Seiten statisch oder auf dem Server rendert, lädt in der Regel schneller als ein WordPress mit vielen Plugins. Garantiert ist das nicht: Auch ein Headless-Frontend kann mit großen Bildern und zu viel JavaScript langsam sein. Bevor du deshalb umsteigst, schau in die Felddaten. Wie das geht, steht in Core Web Vitals verbessern. Oft ist die schnellere Lösung, das bestehende System zu optimieren.

Redaktioneller Ablauf. Mehrere Personen schreiben, prüfen und veröffentlichen, in mehreren Sprachen, mit Freigaben und geplanten Veröffentlichungen. Die großen Headless-Anbieter haben dafür Rollen, Vorschauen und Workflows eingebaut, allerdings oft erst in den bezahlten Plänen (siehe Vergleich unten).

Wann lohnt es sich nicht?

Kleine Firmenwebsite. Zehn Seiten, die sich ein paarmal im Jahr ändern: Hier zahlst du bei Headless für ein eigenes Frontend und dessen Wartung, ohne dass du den Vorteil mehrerer Kanäle nutzt. Ein gut gepflegtes WordPress oder ein Baukasten reicht.

Kein Zugriff auf Entwickler. Bei WordPress baust du eine neue Landingpage zur Not selbst mit einem Page-Builder. Bei Headless braucht ein neuer Seitentyp in der Regel eine Änderung am Frontend. Wenn niemand da ist, der das übernimmt, wird das CMS zum Engpass.

Das Problem liegt woanders. Eine langsame Seite wegen eines überladenen Themes, ein chaotischer Plugin-Bestand oder fehlende Updates sind Gründe, das bestehende System aufzuräumen. Ein Umstieg löst sie nur, wenn du ihn ohnehin planst.

Storyblok, Sanity, Contentful, Strapi und Payload im Vergleich

Die vier Kategorien, die beim Vergleich am meisten zählen: wo das System läuft, wie der Preis wächst, ob die Redaktion visuell bearbeiten kann und wo die Daten liegen. Preise wie auf den Preisseiten angezeigt (Stand: November 2026), ohne Steuern; Storyblok zeigt Besuchern aus Deutschland Euro-Preise, Sanity, Contentful und Strapi nennen ihre Preise in US-Dollar.

Quellen, abgerufen am 13. November 2026: Storyblok Preise, Storyblok Preis-FAQ, Storyblok Spaces, Sanity Preise, Sanity Unterauftragsverarbeiter, Contentful Preise, Contentful EU-Datenresidenz, Contentful Multi-Region-Infrastruktur, Strapi Preise (selbst gehostet), Strapi Cloud Preise, Strapi Cloud Deployment, Payload Live Preview, Payload Visual Editor, Payload auf GitHub. Preise und Pläne ändern sich; prüf sie vor der Entscheidung.

So liest du die Tabelle. Wenn deine Redaktion vor allem Seiten zusammenklickt und sehen will, was sie tut, sind Storyblok und Sanity mit visueller Bearbeitung in jedem Plan stark. Wenn Daten nachweisbar in der EU liegen müssen, hast du bei Strapi und Payload die volle Kontrolle, weil du sie selbst hostest; dafür kümmerst du dich um Server, Updates und Backups. Bei den Cloud-Anbietern lohnt der Blick ins Kleingedruckte: Ein EU-Standard ist nicht dasselbe wie ein vertraglich zugesicherter EU-Standort.

Meine Empfehlung. Will die Redaktion vor allem visuell arbeiten, nehme ich Storyblok. Braucht das Team flexible Inhaltsmodelle und eigene Oberflächen im Editor, Sanity. Müssen alle Daten bei dir liegen, Payload, selbst gehostet.

So läuft die Migration ab

1. Inhaltsmodell entwerfen

   Schau dir an, welche Arten von Inhalten es gibt (Seiten, Artikel, Produkte, Standorte, Personen) und welche Felder jede braucht. Modelliere nach Bedeutung, nicht nach Layout: ein Feld teaser statt „Text oben links“. So überlebt das Modell auch den nächsten Redesign.

2. Migrationsskript schreiben

   Exportiere die alten Inhalte (bei WordPress etwa über die REST-API oder den XML-Export), wandle sie in das neue Modell um und importiere sie über die Management-API des neuen CMS. Bilder, interne Links und Shortcodes brauchen eigene Regeln. Lass das Skript mehrfach laufen können, damit du bis zum Umstieg nachziehen kannst.

3. Vorschauen einrichten

   Die Redaktion muss sehen, wie ein Entwurf auf der echten Seite aussieht, bevor er live geht. Das heißt: Vorschau-Modus im Frontend, Zugriff auf unveröffentlichte Inhalte und, wo verfügbar, visuelle Bearbeitung. Teste das mit echten Entwürfen, nicht nur mit der Startseite.

4. Weiterleitungen und SEO sichern

   Erstelle eine Liste aller alten URLs (Sitemap, Search Console, Server-Logs) und ordne jeder eine neue zu. Jede geänderte URL bekommt eine 301-Weiterleitung. Übernimm Titel, Meta-Beschreibungen, Canonicals, strukturierte Daten und hreflang. Nach dem Umstieg: Sitemap neu einreichen und die Search Console auf 404-Fehler prüfen.

5. Redaktion schulen

   Zeig dem Team das neue Inhaltsmodell, die Vorschau und den Veröffentlichungsablauf an seinen eigenen Inhalten. Eine kurze Anleitung mit Screenshots für die häufigsten Aufgaben spart später viele Rückfragen.

Was kostet der Umstieg? Das hängt vor allem an drei Dingen: wie viele Inhaltstypen es gibt, wie viele Seiten umziehen und wie viele Sonderfälle im alten System stecken, etwa Shortcodes, Plugins oder mehrere Sprachen. Eine belastbare Zahl gibt es erst nach einem Blick auf deine Inhalte. Nach einem kostenlosen Erstgespräch bekommst du dafür einen Festpreis.

Typische Fehler beim Umstieg

URLs ändern sich ohne 301. Das ist der häufigste Grund für Ranking-Verluste nach einem Relaunch. Wenn /leistungen/webdesign/ plötzlich /services/webdesign heißt und keine Weiterleitung existiert, landen Besucher und Google auf einer 404-Seite. Die URL-Liste gehört an den Anfang des Projekts, nicht ans Ende.

Die Vorschau funktioniert nicht. Die Redaktion veröffentlicht blind, sieht Fehler erst live und verliert das Vertrauen ins neue System. Vorschauen hängen von Frontend, Caching und Zugriffsrechten ab; plane sie als eigene Aufgabe ein.

Das Inhaltsmodell ist zu kompliziert. Dutzende verschachtelte Bausteine mit jeweils zwanzig Feldern machen jede neue Seite zum Puzzle. Starte mit wenigen Inhaltstypen und erweitere, wenn die Redaktion etwas wirklich braucht.

API-Kosten werden unterschätzt. Die Preise der Cloud-Anbieter hängen an Nutzern, API-Aufrufen und Traffic. Contentful Free etwa erlaubt 100.000 API-Aufrufe im Monat ohne Überschreitung (Stand: November 2026), Sanity berechnet im Growth-Plan Aufrufe über dem Kontingent nach Verbrauch. Ein Frontend, das bei jedem Seitenaufruf frisch abfragt, statt zu cachen oder statisch zu bauen, verbraucht das Kontingent schnell.

Schon headless, aber unzufrieden?

Wenn du bereits ein Headless CMS nutzt, aber Builds langsam sind, die Vorschau hakt oder die API-Rechnung wächst, brauchst du keinen neuen Umstieg. Dann geht es um das bestehende Setup: Caching, Inhaltsmodell, Vorschau-Modus. Mehr dazu unter Headless CMS optimieren.

Was du jetzt tun solltest

• Du hast eine kleine Website ohne Entwickler: Bleib beim klassischen CMS und halte es aktuell.
• Deine Seite ist langsam: Prüf zuerst die Core Web Vitals, bevor du das System wechselst.
• Du willst mehrere Kanäle oder ein eigenes Frontend: Liste deine Inhaltstypen und alten URLs auf und vergleiche die Anbieter nach Datenstandort, Preismodell und Vorschau.