Die CMS-Auswahl beginnt bei den Menschen, die Inhalte pflegen, und den Kanälen, in denen diese Inhalte erscheinen sollen. Ein klassisches CMS verbindet Inhaltspflege und Seitenausgabe. Bei einer Headless-Architektur werden Inhalte über Schnittstellen an eine separate Oberfläche ausgeliefert. Beide Ansätze können sinnvoll sein; keiner ist automatisch schneller oder wartungsärmer.
Redaktionelle Aufgaben zuerst beschreiben
Vor einer Produktentscheidung mit der Redaktion klären:
- Welche Inhaltstypen und Beziehungen müssen gepflegt werden?
- Braucht die Redaktion freie Seitengestaltung oder klar begrenzte Inhaltsmodule?
- Wie funktionieren Vorschau, Prüfung, Freigabe und Veröffentlichung?
- Welche Sprachen, Rollen und weiteren Ausgabekanäle sind vorgesehen?
- Wer übernimmt Betrieb, Updates, Sicherungen und eine spätere Datenmigration?
WordPress: Redaktion und Website zusammen oder getrennt
WordPress kann Inhaltspflege und Ausgabe in einem System abdecken, etwa mit dem Block-Editor und einem passenden Theme. Für eine separate Oberfläche steht eine REST API bereit. GraphQL gehört nicht zum WordPress-Kern und benötigt eine zusätzliche Lösung. WordPress als Inhaltsquelle mit eigenem Frontend ist bereits eine Headless-Architektur.
Ein klassischer Aufbau kann gut passen, wenn Redakteure direkt an Seiten arbeiten und vorhandene Erweiterungen benötigt werden. Bei einer Trennung müssen Vorschau, Formulare, Suche und weitere Funktionen bewusst zwischen CMS und Frontend verbunden werden.
Sanity und Contentful: verwaltete Inhaltsdienste
Sanity trennt die konfigurierbare Redaktionsoberfläche Sanity Studio von der gehosteten Inhaltsplattform Content Lake. Ein selbst gehostetes Studio bedeutet nicht, dass auch die Datenhaltung selbst betrieben wird. Contentful stellt ebenfalls einen verwalteten Inhaltsdienst mit APIs bereit. Bei beiden gehören Datenmodell, Rollen, Nutzung und Vertragsbedingungen in die Entscheidung.
Verwaltete Dienste nehmen bestimmte Betriebsaufgaben ab. Die Verantwortung für eine passende Inhaltsstruktur, Zugangskonfiguration, Integration und spätere Exportierbarkeit bleibt Teil des Projekts. Welche Funktionen enthalten sind, wird am aktuellen Angebot und dem benötigten Umfang geprüft.
Strapi: Inhalts-API mit eigenem Betriebsanteil
Strapi lässt sich selbst betreiben und stellt Inhalte über eine REST API bereit. GraphQL wird über ein zusätzliches Plugin eingebunden. Eigenbetrieb erlaubt Einfluss auf die Infrastruktur, bedeutet aber auch Verantwortung für Updates, Datenbank, Sicherungen und Verfügbarkeit. Open Source beseitigt nicht den Aufwand einer späteren Migration.
Mit einer vollständigen redaktionellen Aufgabe vergleichen
Lassen Sie in einer kleinen Vorprüfung denselben Inhalt anlegen, in der Vorschau ansehen, ändern und veröffentlichen. Beziehen Sie dabei eine echte Rolle aus der späteren Redaktion ein. So werden Unterschiede bei Modellierung, Bedienung und Freigabe sichtbar, die eine reine Funktionsliste leicht verdeckt.
Die passende Entscheidung umfasst CMS, Frontend und Betrieb gemeinsam. Eine vertraute Redaktion, funktionierende Vorschau und klar betreute Schnittstellen sind oft wichtiger als eine lange Liste optionaler Funktionen.
Quellen und weiterführende Dokumentation
Themen
- Headless CMS
- Sanity
- Strapi
- Contentful
- WordPress
- JAMstack
- Hybrid