Sanity als Headless CMS: Redaktion ohne Plugin-Chaos

Eine Marketing-Verantwortliche will einen Blogbeitrag veröffentlichen. Sie loggt sich ins WordPress-Backend ein, wartet 14 Sekunden auf den Seitenaufbau, klickt auf 'Beitrag erstellen' und sieht eine Update-Warnung: drei Plugins fordern Aktualisierungen, eines davon ist sicherheitskritisch. Sie aktualisiert, das Kontaktformular-Plugin kollidiert mit dem Page-Builder, die Vorschau zeigt zerschossene Spalten. Statt Content zu publizieren, schreibt sie ein Ticket an die Agentur. Dieses Szenario ist kein Einzelfall. Es ist der Alltag auf Webseiten, deren Redaktionssystem und Darstellungsschicht in einem monolithischen Block verschmolzen sind.

Warum der Monolith zum Problem wird

WordPress betreibt laut W3Techs rund 43 Prozent aller Webseiten weltweit. Das ist eine beeindruckende Zahl, und WordPress hat diese Position verdient: Es hat das Web demokratisiert und Millionen von Unternehmen online gebracht. Doch mit zunehmender Komplexität der Anforderungen stößt die monolithische Architektur an Grenzen. Eine durchschnittliche WordPress-Installation nutzt 20 bis 30 aktive Plugins. Jedes Plugin bringt eigenen Code, eigene Datenbanktabellen und eigene Update-Zyklen mit. Das Ergebnis: ein fragiles System, in dem ein einziges Update eine Kettenreaktion auslösen kann.

Das Problem ist strukturell, nicht individuell. In einem monolithischen CMS sind Inhalt, Darstellung und Funktionalität untrennbar verzahnt. Wer das Design ändert, riskiert den Content. Wer ein Plugin aktualisiert, riskiert das Design. Wer das Frontend modernisieren will, muss das gesamte System anfassen. Für Unternehmen, die ihre Webseite als geschäftskritische Infrastruktur betrachten, ist das ein untragbares Risiko.

Die Headless-Architektur: Inhalt und Darstellung getrennt

Headless CMS lösen dieses Problem durch eine konsequente Trennung: Das Content-Management-System verwaltet ausschließlich Inhalte. Es kennt kein Theme, keinen Page-Builder, keine Darstellungslogik. Das Frontend, also die sichtbare Webseite, wird unabhängig entwickelt und bezieht seine Inhalte über eine API. Diese Entkopplung klingt abstrakt, hat aber sehr konkrete Auswirkungen auf den Redaktionsalltag.

Sanity ist ein solches Headless CMS und bildet zusammen mit Next.js und Vercel den Tech-Stack, den wir in einem früheren Artikel als Alternative zu WordPress vorgestellt haben. Während jener Artikel die Frontend-Perspektive beleuchtet, geht es hier um die andere Seite: das Redaktionserlebnis.

Sanity Studio: Wie sich Redaktion anfühlen sollte

Sanity Studio ist die Oberfläche, in der Redakteure arbeiten. Es läuft im Browser, lädt in unter zwei Sekunden und zeigt exakt die Felder, die der jeweilige Inhaltstyp benötigt. Keine Sidebar mit Widget-Optionen, keine Plugin-Einstellungen, keine Theme-Konfiguration. Ein Blogbeitrag hat Titel, Slug, Excerpt, Inhalt und SEO-Felder. Eine Teamseite hat Name, Rolle, Foto und Kontaktdaten. Nichts mehr, nichts weniger.

Das Studio wird für jeden Kunden individuell konfiguriert. Wir definieren die Inhaltsstruktur so, dass sie exakt zu den Geschäftsprozessen passt. Der Redakteur bearbeitet Content, nicht Technik. Wenn er etwas ändert, sieht er die Änderung in Echtzeit, auch wenn ein Kollege gleichzeitig am selben Dokument arbeitet. Sanity nennt das 'Echtzeit-Kollaboration', und es funktioniert wie Google Docs, nur für strukturierten Website-Content.

Der entscheidende Unterschied zum WordPress-Backend: Es gibt keine Updates, die der Redakteur ausführen muss. Keine Plugin-Warnungen, keine PHP-Versionshinweise, keine Datenbank-Optimierungen. Das Studio ist eine gehostete Anwendung, die Sanity bereitstellt und wartet. Der Redakteur öffnet es, arbeitet, schließt es.

Structured Content: Warum Ihr Inhalt mehr wert ist als das Design

In einem klassischen CMS ist Content an ein Theme gebunden. Die Texte, Bilder und Layouts leben in einer Datenbank, die nur das installierte Theme interpretieren kann. Wechselt man das Theme, bricht der Content auseinander. Wechselt man das CMS, beginnt eine aufwändige Migration. Der Inhalt, den Unternehmen über Jahre erstellt haben, ist de facto gefangen.

Sanity verfolgt das Konzept 'Structured Content': Jeder Inhalt wird in einer definierten Struktur gespeichert, unabhängig von jeder Darstellung. Ein Blogartikel ist nicht eine HTML-Seite, sondern ein strukturiertes Dokument mit Titel, Absätzen, Zwischenüberschriften und Metadaten. Dieses Dokument kann über die API abgerufen und in jeder beliebigen Form ausgespielt werden: als Webseite, als App-Inhalt, als Newsletter, als Digital-Signage-Anzeige. Der Content überlebt jedes Frontend-Redesign, weil er nie an ein Frontend gebunden war.

Das ist kein theoretischer Vorteil. Es bedeutet konkret: Wenn wir in drei Jahren das Frontend einer Kunden-Webseite komplett neu bauen, bleibt der gesamte Content bestehen. Keine Migration, kein Datenverlust, kein Einfrieren der Redaktion während des Umbaus. Das Frontend wird ausgetauscht, der Content-Layer bleibt.

Keine Plugins, keine Konflikte, keine Angst vor Updates

Das Plugin-Modell klassischer CMS ist ein Kompromiss: Weil das Kernsystem nicht alles kann, werden Funktionen nachgerüstet. Kontaktformulare, SEO-Optimierung, Bildkomprimierung, Caching, Sicherheit, jede Funktion ist ein separates Plugin mit eigenem Wartungszyklus. Bei 25 aktiven Plugins ergeben sich 25 potenzielle Konfliktquellen, die bei jedem Update neu evaluiert werden müssen.

In der Headless-Architektur existiert dieses Problem nicht. Das CMS hat genau eine Aufgabe: Content verwalten. Kontaktformulare werden im Frontend gelöst. SEO-Tags generiert der Build-Prozess. Bildoptimierung übernimmt der Hosting-Provider. Caching ist eine Eigenschaft des Frameworks, nicht ein nachgerüstetes Plugin. Sicherheit wird durch die Architektur selbst gewährleistet, weil es keine öffentlich erreichbare Datenbank gibt, die angegriffen werden könnte.

Für Unternehmen, die gesetzliche Anforderungen wie das Barrierefreiheitsstärkungsgesetz erfüllen müssen, ist das ein relevanter Punkt: Barrierefreiheit wird im Frontend-Code sauber implementiert, nicht durch ein Overlay-Plugin simuliert, das beim nächsten Update ausfallen kann.

Der SK-Stack in der Praxis

Wir setzen Sanity als CMS für alle neuen Projekte ein. Unsere eigene Webseite sk-online-marketing.de läuft auf diesem Stack: Next.js als Frontend-Framework, Sanity als CMS, Vercel als Hosting-Plattform. Die Erfahrung aus dem täglichen Einsatz fließt direkt in die Kundenprojekte zurück.

Die Philosophie dahinter ist einfach: Der Kunde editiert Content, nicht Struktur. Für alles andere ruft er an. Das bedeutet nicht, dass wir den Kunden einschränken. Es bedeutet, dass wir ihm ein Werkzeug geben, das genau das tut, was er braucht, ohne ihn mit technischer Komplexität zu belasten. Ein Redakteur, der einen neuen Blogartikel schreibt, sollte sich auf den Inhalt konzentrieren können, nicht auf die Frage, ob das Yoast-Plugin mit dem neuen Gutenberg-Update kompatibel ist.

Sanity bietet darüber hinaus eine eigene Abfragesprache namens GROQ, mit der Entwickler Inhalte präzise abfragen können. Das ist ein Vorteil gegenüber REST-APIs, die oft entweder zu viele oder zu wenige Daten liefern. Für den Redakteur ist das unsichtbar, für die Performance der Webseite relevant: Jede Seite bekommt exakt die Daten, die sie braucht.

Wann Headless der richtige Weg ist

Headless CMS sind nicht für jedes Projekt die richtige Wahl. Eine einfache Visitenkarten-Webseite mit fünf Seiten, die selten aktualisiert wird, kann mit WordPress effizient betrieben werden. Die Vorteile der Headless-Architektur entfalten sich dort, wo Content lebt: wo regelmäßig publiziert wird, wo mehrere Personen redaktionell arbeiten, wo Performance und Sicherheit geschäftskritisch sind, wo der Content langfristig erhalten und wiederverwendet werden soll.

• Redaktionseffizienz: Ein aufgeräumtes Studio ohne Plugin-Warnungen, das in unter zwei Sekunden lädt und Echtzeit-Kollaboration ermöglicht.
• Zukunftssicherheit: Content überlebt jedes Frontend-Redesign, weil er strukturiert und API-basiert gespeichert ist.
• Sicherheit: Keine öffentlich erreichbare Datenbank, keine Plugin-Schwachstellen, keine PHP-Angriffsvektoren.
• Performance: Statisch gerenderte Seiten mit sauberem Code laden schneller als dynamisch generierte WordPress-Seiten mit Caching-Plugin.
• Unabhängigkeit: Der Content gehört dem Kunden. Er liegt strukturiert im Content Lake und kann jederzeit exportiert werden.

Fazit: Content verdient ein besseres Werkzeug

Die Frage ist nicht, ob WordPress schlecht ist. WordPress hat das Web verändert und Millionen von Unternehmen den Zugang zum Internet ermöglicht. Die Frage ist, ob ein monolithisches System aus 2003 das richtige Werkzeug für Premium-Webprojekte in 2026 ist. Für Unternehmen, die ihre Webseite als geschäftskritische Infrastruktur betreiben, redaktionelle Effizienz erwarten und ihren Content langfristig als Asset betrachten, bietet die Headless-Architektur mit Sanity eine Redaktionsumgebung, die sich auf das Wesentliche konzentriert: guten Content, schnell veröffentlicht, sicher gespeichert.