Sanity vs. WordPress: Unterschiede bei Headless CMS, Architektur und Betrieb

Sanity und WordPress können beide Inhalte verwalten. Technisch verfolgen sie dabei unterschiedliche Ansätze.

WordPress kann CMS und Frontend in einem System verbinden. Sanity ist darauf ausgelegt, strukturierte Inhalte unabhängig vom sichtbaren Frontend bereitzustellen. Eine Anwendung mit Next.js, Astro oder Nuxt holt die benötigten Daten und entscheidet selbst über die Ausgabe.

Sanity und WordPress sind nur zwei Beispiele. Der CMS-Markt umfasst Systeme wie Joomla und Drupal ebenso wie Headless- und API-first-Lösungen wie Contentful, Storyblok, Strapi oder Directus. Einige davon können gekoppelt und Headless betrieben werden, andere setzen stärker auf getrennte Frontends.

Für diesen Vergleich sind zwei Fragen wichtig:

Sanity oder WordPress ist eine CMS-Entscheidung.

Gekoppelt oder Headless ist eine Architekturentscheidung.

WordPress kann ebenfalls Headless betrieben werden.

Sanity vs. WordPress im direkten Vergleich

Punkt	Sanity + separates Frontend	Klassisches WordPress
Architektur	Headless	normalerweise gekoppelt
Frontend	frei wählbar	meist WordPress-Theme
Strukturierte Inhalte	zentraler Teil des Systems	möglich, oft zusätzliche Modellierung
Mehrere Ausgabekanäle	sehr gut geeignet	möglich, besonders Headless
Entwicklungsaufwand	meist höher	bei Standardseiten geringer
Erweiterungen	Studio-Plugins, Frontend-Pakete, externe Dienste	großes WordPress-Plugin-Ökosystem
Redaktionsoberfläche	schema-basiert und stark anpassbar	umfangreich vorkonfiguriert
Visuelle Bearbeitung	Visual Editing integrierbar	Site Editor bei Block Themes
Content-Aktualisierung	technisch zu planen	klassisch direkt gekoppelt
Content-Backend / Hosting	Content Lake als Sanity-Dienst; Studio und Frontend separat hostbar	CMS, Datenbank und Frontend selbst oder managed hostbar
Plattformabhängigkeit	höher	geringer
Implementierungsabhängigkeit	kann durch Content-Modell, Queries und Frontend entstehen	kann durch Themes, Builder und Plugins hoch sein
Wartung	Framework, Pakete, APIs, Deployment	Core, Themes, Plugins, Hosting
Einstiegskosten	bei individuellen Projekten meist höher	bei Standardseiten meist niedriger

Was ist ein Headless CMS?

Bei einem Headless CMS sind Inhaltsverwaltung und Frontend getrennt.

Das CMS speichert und organisiert die Inhalte. Wie sie später aussehen, bestimmt eine andere Anwendung.

Eine Website für ein fiktives Musikprojekt könnte eigene Daten für Künstler, Veröffentlichungen, Veranstaltungen und Veranstaltungsorte speichern.

Ein Konzert liegt dann nicht als großer Textblock vor, in dem Datum, Ort und Ticketlink irgendwo zwischen zwei Absätzen herumstehen.

Titel: Signal North Live
Datum: 18.10.2026
Veranstaltungsort: Studiohalle 8
Ticketlink: URL zum Ticketanbieter
Status: verfügbar

Dieser Datensatz kann auf der Startseite, im Veranstaltungskalender und auf einer Detailseite verwendet werden.

Sobald dieselben Informationen an mehreren Stellen oder in verschiedenen Anwendungen gebraucht werden, wird diese Struktur interessant.

Wie Sanity strukturierte Inhalte verwaltet

Sanity speichert strukturierte Inhalte im Content Lake.

Sanity ist dabei API-first aufgebaut. Inhalte werden über APIs bereitgestellt und sind nicht an ein festes Theme oder eine bestimmte Ausgabe gebunden.

Eine technische Besonderheit: Der Content Lake selbst ist schemalos.

Im Sanity Studio definieren Entwickler Schemata für Inhaltstypen, Felder und Beziehungen. Das Studio erzeugt daraus die entsprechenden Formulare und Eingabefelder.

Eine Veröffentlichung könnte zum Beispiel Felder für Titel, Datum, Cover, Genre und Streaminglinks besitzen.

Validierungen im Studio können prüfen, ob Pflichtfelder vorhanden sind oder Werte zum erwarteten Format passen. Bei normalen API-Mutationen werden diese Studio-Schemata jedoch nicht automatisch serverseitig als Datenbankschema erzwungen.

Für Redakteure ist das meistens unsichtbar. Für Entwickler gehört es zum technischen Modell.

Visual Editing

Sanity unterstützt Visual Editing mit Live Preview und Click-to-edit. Bei entsprechend aufgebauten Array-Inhalten können Bereiche auch per Drag-and-drop verschoben werden.

Das Content-Modell und die Integration im Frontend müssen dafür passend aufgebaut sein.

Damit lässt sich Headless inzwischen deutlich visueller bearbeiten als noch vor einigen Jahren. Ein klassischer Page Builder wird daraus trotzdem nicht.

WordPress funktioniert klassisch anders

WordPress wurde als integriertes CMS entwickelt.

Inhalte, Medien, Benutzer, Datenbank und Frontend können innerhalb einer Installation liegen. Bei Block Themes erlaubt der Site Editor auch die Bearbeitung von Templates, Navigation und größeren Teilen der Website-Struktur.

Für viele Unternehmensseiten passt dieses Modell sehr gut.

Eine Seite mit Startseite, Leistungen, Referenzen, Kontakt und vielleicht einem Blog braucht keine zusätzliche Content-Plattform, nur damit am Ende dieselben fünf Seiten ausgeliefert werden.

Man kann dafür natürlich eine komplette Headless-Infrastruktur bauen. Die Öffnungszeiten werden durch den Deployment-Prozess allerdings nicht interessanter.

Kann WordPress als Headless CMS eingesetzt werden?

Ja.

Die WordPress REST API stellt Beiträge, Seiten, Medien, Taxonomien und weitere Daten für externe Anwendungen bereit.

Ein mögliches Setup sieht dann so aus:

WordPress: Inhaltsverwaltung
Next.js: Frontend

Das WordPress-Theme rendert die öffentliche Website in diesem Modell nicht mehr.

Bei Headless-WordPress-Projekten wird auch WPGraphQL eingesetzt. Das Plugin ergänzt WordPress um eine GraphQL-API und gehört nicht zum WordPress Core.

Interessant ist Headless WordPress vor allem dann, wenn eine bestehende Redaktion bei WordPress bleiben soll, das Frontend aber unabhängig entwickelt wird.

Wo Headless WordPress schwierig wird

Gutenberg basiert auf Blocks. Je nach Block werden Daten und Markup gespeichert oder Teile der Ausgabe serverseitig erzeugt. Ein separates Frontend muss diese Inhalte passend verarbeiten.

Auch andere WordPress-Funktionen brauchen im Headless-Betrieb häufig zusätzliche Arbeit:

• Vorschau von Entwürfen
• Navigation
• SEO-Metadaten
• Weiterleitungen
• Suche
• Formulare
• Authentifizierung
• Plugin-Ausgaben

Ein Plugin funktioniert nicht automatisch im Next.js-Frontend, nur weil WordPress weiterhin das Backend stellt.

Besonders bei Websites, die stark auf Gutenberg-Layouts oder viele Plugins angewiesen sind, kann Headless WordPress deutlich aufwendiger werden als erwartet.

Bei klar strukturierten Custom Post Types funktioniert die Trennung besser. Für ein neues Projekt mit konsequent strukturierten Daten würde ich trotzdem eher ein CMS wählen, das für diesen Ansatz entwickelt wurde.

Wo Sanity tatsächlich stärker ist

Sanity legt früh nahe, Inhalte als Content-Modell zu planen.

Bei einem Veranstaltungsort stellt sich zum Beispiel die Frage, ob er nur ein Textfeld oder ein eigener Datensatz ist.

Als eigener Datensatz kann er Adresse, Website und weitere Informationen besitzen und mit beliebig vielen Veranstaltungen verbunden werden.

Dasselbe funktioniert mit Künstlern, Produkten, Autoren, Kategorien oder Veröffentlichungen.

WordPress kann solche Modelle mit Custom Post Types, Custom Fields und Beziehungen ebenfalls abbilden. Bei Sanity gehört diese Denkweise stärker zum Grundaufbau.

Für viele strukturierte und miteinander verknüpfte Daten würde ich deshalb Sanity bevorzugen.

Ein Beispiel aus meiner eigenen Arbeit

Bei einem aktuell entstehenden Künstlerprojekt arbeite ich mit Next.js und Sanity.

Das Frontend wird individuell entwickelt. Veröffentlichungen, Musik und weitere redaktionelle Inhalte liegen getrennt davon im CMS und können dort gepflegt werden.

Für dieses Projekt ist die Trennung sinnvoll, weil Content-Modell und Frontend unterschiedliche Aufgaben haben.

Bei einer normalen Firmenwebsite mit wenigen Seitentypen würde ich denselben Aufbau nicht wählen.

Bei CoreWeb Studio setze ich deshalb je nach Projekt auf WordPress oder individuelle Webentwicklung mit React und Next.js.

Redaktionsworkflow: WordPress oder Sanity?

WordPress bringt Entwürfe, Revisionen, Benutzerrollen und zeitgesteuerte Veröffentlichungen bereits lange mit.

Sanity bietet ebenfalls Drafts und Rollen. Welche Rollen und feineren Berechtigungsmodelle verfügbar sind, hängt vom Tarif ab.

Scheduled Drafts erlauben die zeitgesteuerte Veröffentlichung einzelner Dokumente und sind Stand August 2026 im Growth-Plan verfügbar.

Mit Content Releases können mehrere Änderungen gemeinsam vorbereitet, geprüft, geplant und veröffentlicht werden. Diese Funktion ist Stand August 2026 bestimmten Enterprise-Plänen vorbehalten.

Bei einem einzelnen Redakteur ist das selten ausschlaggebend. Für größere Teams kann der Workflow dagegen direkt über die CMS-Wahl entscheiden.

Ist Sanity mit Next.js schneller als WordPress?

Nicht grundsätzlich.

Next.js kann Inhalte vorab oder zur Request-Zeit rendern. Seit Next.js 16 stehen mit Cache Components zusätzliche Möglichkeiten zur Verfügung, gecachte und dynamische Bereiche innerhalb einer Anwendung zu kombinieren. Die Funktion wird über cacheComponents: true aktiviert.

Gecachte Inhalte können zeitbasiert oder gezielt nach Änderungen aktualisiert werden.

WordPress kann ebenfalls schnell sein. Caching, CDN, gutes Hosting, optimierte Bilder und ein sauber gebautes Theme reichen für viele Projekte aus.

Langsame WordPress-Seiten haben meistens konkretere Ursachen: schwere Themes, unnötige Skripte, riesige Bilder oder Plugins, die deutlich mehr laden als gebraucht wird.

35 Plugins sind nicht automatisch ein Problem. Sie sind allerdings auch kein Sammelalbum.

Performance ist deshalb kein sinnvoller Grund, pauschal eines der beiden CMS auszuschließen.

Sanity, WordPress und SEO

Das CMS selbst erzeugt keinen Rankingbonus.

Für Google zählt nicht der Name des CMS, sondern was die Website technisch und inhaltlich ausliefert.

Google kann JavaScript rendern und daraus Inhalte indexieren. Server- oder Pre-Rendering kann trotzdem sinnvoll sein, weil wesentliche Inhalte bereits im initialen HTML verfügbar sind und die Auslieferung weniger vom nachgelagerten JavaScript-Rendering abhängt.

Interne Links sollten crawlbar sein. Titles, Canonicals, Weiterleitungen und strukturierte Daten müssen technisch sauber umgesetzt werden. Meta-Descriptions beeinflussen zusätzlich, wie Suchergebnisse dargestellt werden können.

Bei einem individuellen Frontend liegt mehr davon direkt in der Hand der Entwicklung. WordPress nimmt bei klassischen Projekten viele Standardaufgaben ab.

Mehr zu Seitenstruktur, Metadaten und interner Verlinkung steht auf meiner Seite zu On-Page-SEO. Wie diese Grundlagen inzwischen auch mit KI-Suche und Quellenfähigkeit zusammenhängen, behandle ich ausführlicher in SEO, GEO und KI-Sichtbarkeit 2026.

Wie kommen neue CMS-Inhalte ins Frontend?

Bei klassischem WordPress liegen CMS und Ausgabe eng zusammen. Ein veröffentlichter Beitrag kann direkt über WordPress gerendert werden.

Bei einem Headless-Frontend muss der Aktualisierungsweg festgelegt werden.

Daten können bei jedem Request geladen, gecacht oder vorab erzeugt werden. Webhooks können Aktualisierungen oder Builds anstoßen.

Sanity bietet dafür zusätzlich die Live Content API. In Next.js lässt sie sich über next-sanity und SanityLive anbinden, sodass Inhaltsänderungen automatisch in die Cache-Aktualisierung einbezogen werden können.

Je nach gewünschter Aktualisierungsgarantie können weitere Invalidierungsmechanismen nötig sein.

Bei Nachrichten, Veranstaltungen oder anderen zeitkritischen Inhalten muss dieser Prozess sauber passen.

Sonst klickt jemand im CMS auf „Veröffentlichen“ und eröffnet fünf Minuten später ein Ticket, weil die Website noch den alten Stand zeigt. Dann wird Architektur plötzlich erstaunlich wenig abstrakt.

Sanity oder WordPress: Wie stark ist die Abhängigkeit?

Hier lohnt es sich, Plattform- und Implementierungsabhängigkeit zu trennen.

Plattformabhängigkeit

Sanitys Content Lake und die dazugehörigen APIs laufen über Sanitys Plattform. Studio und Frontend können separat gehostet werden, das Content-Backend bleibt mit Sanity verbunden.

Sanity unterstützt Dataset-Exporte. Ein Wechsel auf ein anderes CMS bleibt trotzdem eine Migration.

Bei der Open-Source-Software WordPress können CMS, Datenbank und Frontend selbst betrieben oder über Managed Hosting bereitgestellt werden.

Auf Infrastrukturebene ist WordPress unabhängiger von einem einzelnen Plattformanbieter.

Implementierungsabhängigkeit

Sie kann bei beiden Systemen erheblich sein.

Bei WordPress entsteht sie beispielsweise durch Themes, Page Builder und proprietäre Plugins.

Bei Sanity können Content-Modell, Queries, APIs und die Frontend-Implementierung einen späteren Wechsel aufwendig machen.

Eine offene Lizenz oder ein möglicher Datenexport beseitigt diese Arbeit nicht.

Wartung und laufender Betrieb

Bei WordPress betrifft die laufende Pflege vor allem Core, Themes, Plugins, PHP und Hosting.

Bei Next.js und Sanity verschiebt sich der Aufwand zu Framework-Versionen, npm-Abhängigkeiten, Sanity Studio, APIs, Builds und Deployments.

Für WordPress-Projekte habe ich die typischen Aufgaben unter Website-Wartung und Content-Pflege ausführlicher beschrieben.

Bei Headless-Projekten gehört ein sauberer Entwicklungs- und Deployment-Prozess direkt zum Betrieb.

Was kostet Sanity im Vergleich zu WordPress?

Der Hostingpreis allein reicht für einen sinnvollen Vergleich nicht.

Bei WordPress können Hosting, Premium-Plugins, Lizenzen, Wartung und Entwicklungsarbeit Kosten verursachen.

Bei einer Headless-Architektur kommen je nach Projekt CMS-Tarif, Frontend-Hosting, externe Dienste, Build- oder Compute-Nutzung und Entwicklerzeit hinzu.

Gerade die Entwicklung macht häufig den größten Unterschied.

Für einen realistischen Vergleich zählen deshalb die Gesamtkosten über den Betrieb der Website.

Welche Posten bei Website-Projekten typischerweise entstehen, habe ich im Artikel Was kostet eine Website? Preise und Beispiele 2026 ausführlicher aufgeschlüsselt.

Welche Lösung passt wann?

WordPress würde ich wählen, wenn Inhalte hauptsächlich aus normalen Seiten und Beiträgen bestehen, viele Standardfunktionen gebraucht werden und der Betreiber möglichst viel direkt im CMS bearbeiten möchte.

Sanity würde ich bevorzugen, wenn Inhalte stark strukturiert und miteinander verbunden sind, mehrere Ausgabekanäle geplant sind oder ein individuell entwickeltes Frontend unabhängig vom CMS arbeiten soll.

Headless WordPress bleibt eine sinnvolle dritte Möglichkeit, besonders bei bestehenden WordPress-Projekten.

Die Technik sollte ein konkretes Problem lösen. Wenn man erst nach dem Problem suchen muss, damit der Stack sinnvoll aussieht, war wahrscheinlich der Stack zuerst da.