CMS-Auswahl: WordPress, Headless und Eigenentwicklung nach dem Betriebsmodell entscheiden

1. Anforderungen aus dem Content-Lebenszyklus ableiten, nicht aus einer Funktionsliste

Halten Sie zuerst fest, wer Inhalte produziert, wie häufig das geschieht und welche Freigaben dazugehören. Eine Autorin legt den Entwurf an, die Rechtsabteilung prüft, der lokale Markt passt an, die Redaktion terminiert, der Betrieb hält aktuell. Notieren Sie Rollen, Berechtigungen, den Bedarf an Rücknahme, Vorschau, Massenbearbeitung und den Weg für dringende Veröffentlichungen als konkrete Schritte. Ein Häkchen bei "Workflow vorhanden" belegt nicht, dass Ihr Freigabemodell tatsächlich funktioniert.

Trennen Sie Inhaltstypen von Seitenvorlagen. Bestimmen Sie Felder, Beziehungen und Lebenszyklen von Objekten wie Leistungen, Referenzen, Fachpersonen, Produkten, Standorten, Kampagnen und Meldungen. Wenn dieselben Inhalte auf der Website, in einer App, auf Displays, per E-Mail oder über einen Partnerkanal ausgespielt werden, gewinnt eine kanalunabhängige Struktur an Gewicht. In einem kleinen Team, das nur visuelle Seiten einer Marketing-Website pflegt, wiegen Redaktionsvorschau und schnelle Bearbeitung dagegen schwerer.

Machen Sie nicht-funktionale Anforderungen sichtbar: Lastspitzen, Datenstandort, Barrierefreiheit, Mehrsprachigkeit, Protokollierung, Identitätsverwaltung und Wiederherstellung. Halten Sie zu jedem Punkt fest, ob er "wünschenswert" oder "ohne ihn kein Livegang" ist, und dazu die entscheidende Person sowie die Prüfmethode.

2. Die Betriebslogik von WordPress, Headless und Eigenentwicklung unterscheiden

Der klassische WordPress-Ansatz hält Content-Verwaltung, Theme, Plugin-Ökosystem und Web-Ausgabe eng beieinander. Für gängige Marketing- und Publishing-Anforderungen liefert er eine der Redaktion vertraute Oberfläche, einen großen Fachkräftemarkt und einen schnellen Start. Der Preis dafür sind Plugin-Governance, Update-Disziplin, Theme-Abhängigkeit und wachsender Individualcode, sobald die Anforderungen komplexer werden. WordPress zu wählen bedeutet nicht "kein Code": Hosting, Sicherheit und Integration brauchen weiterhin eine verantwortliche Stelle.

Die offizielle Dokumentation der WordPress REST API beschreibt, dass Inhalte per JSON an Anwendungen und eigenständige Frontends außerhalb des Themes ausgeliefert werden können. WordPress ist damit nicht auf den integrierten Vorlagenansatz festgelegt, sondern lässt sich auch headless betreiben. Dieselbe Dokumentation weist zugleich darauf hin, dass kein Druck zur Nutzung der REST API bestehen sollte, wenn eine bestehende Website wie erwartet funktioniert. Eine Entkopplung der Architektur muss durch einen echten Bedarf begründet sein.WordPress Developer Resources — REST API Handbook

Ein Headless-CMS trennt die Inhaltsverwaltung von der Ausgabeschicht: Dieselbe Struktur lässt sich an verschiedene Clients verteilen, und die Frontend-Technologie wird frei wählbar. Im Gegenzug sind Vorschau, Routing, Personalisierung, Suche, Formulare, Identitätsverwaltung und Publishing-Orchestrierung oft weniger integriert als in einem fertigen Seitensystem. Eine Eigenentwicklung bietet die größte Kontrolle, verpflichtet Sie aber zur dauerhaften Pflege eines vollständigen Produkts, inklusive Redaktionserlebnis, Sicherheit, Versionierung, Medienverwaltung und Migrationswerkzeugen.

3. Die Entscheidungsmatrix mit Gewichtung, Nachweis und Ausschlussschwelle aufbauen

Alle Kriterien gleich zu gewichten erzeugt eine Scheingenauigkeit. Legen Sie zuerst die Ausschlussbedingungen fest: Werden ein vorgeschriebener Datenstandort, ein Identitätsstandard, eine barrierefreie Redaktionsoberfläche, der Export oder der Freigabeprozess nicht erfüllt, scheidet die Option trotz hoher Gesamtpunktzahl aus. Gewichten Sie die übrigen Kriterien nach ihrer Geschäftswirkung. Wer die Gewichte nach den Demos ändert, bekommt ein Ergebnis nach Sympathie; bestätigen Sie sie deshalb vor der Bewertung.

Neben jeder Bewertung muss ein Nachweis stehen: offizielle Dokumentation, ein lauffähiger Prototyp oder eine vertragliche Zusage. Werten Sie Unbekanntes nicht wohlwollend. "Es gibt eine API" belegt nicht, dass Berechtigungen, Vorschau und Fehlerbehandlung in Ihrem Szenario funktionieren. Führen Sie einen Proof of Concept mit den kritischen Inhalten und Integrationen durch.

Reduzieren Sie die Gesamtbetriebskosten nicht auf Lizenzen. Umsetzung, Design, Content-Migration, Plugin- oder App-Gebühren, Hosting, CDN, Suche, Monitoring, Sicherheit, Support, Versionswechsel, Redaktionsschulung und Ausstiegskosten gehören in die Rechnung. Setzen Sie die Zeit interner Teams nicht mit null an. Vergleichen Sie ein Dreijahresszenario mit niedriger, erwarteter und hoher Nutzung.

4. Modell, Vorschau und Migration an echten Inhalten proben

Wählen Sie für die Demo nicht den bequemen Blogbeitrag, sondern das schwierigste reale Beispiel: ein mehrsprachiges Produkt, eine bedingte Kampagne, ein verknüpftes Expertenprofil oder regelmäßig aktualisierte Regulierungsinhalte. Beobachten Sie, wie die Redaktion anlegt, wiederverwendet, lokalisiert, in der Vorschau prüft, zur Freigabe schickt, terminiert und zurücknimmt. Unterscheiden Sie eine Lernkurve, die sich durch Schulung schließen lässt, von dauerhafter Abhängigkeit von der Entwicklung.

Die offizielle Dokumentation zum Datenmodell von Contentful erklärt, dass Inhaltstypen aus Feldern und Metadaten bestehen, dass Inhalte als Einträge und Medien als Assets vorgehalten werden und dass sich Beziehungen über Verknüpfungen modellieren lassen. Das ist keine Begründung für einen bestimmten Anbieter, sondern eine Produktdokumentation, die konkret zeigt, wie ein strukturiertes Content-Modell bei der Headless-Bewertung zu behandeln ist.Contentful Documentation — Data model

Nehmen Sie URLs, Medien, Alternativtexte, Beziehungen, SEO-Felder, Weiterleitungen und den Veröffentlichungsstatus in die Migrationsprobe auf. Testen Sie den Export: Bleiben Beziehungen oder Asset-Lizenzen unklar, sind die Ausstiegskosten versteckt. Prüfen Sie außerdem, dass unveröffentlichte Daten in der öffentlichen API nicht sichtbar sind.

• Die drei komplexesten Inhaltstypen sind mit echten Beispielen modelliert.
• Die Redaktion hat Entwurf, Vorschau, Freigabe, Terminierung und Rücknahme durchlaufen.
• Mehrsprachigkeit und Markt-Fallback sind getestet.
• Medien, Beziehungen, SEO-Felder und Weiterleitungen sind Teil der Migrationsprobe.
• Berechtigungen für unveröffentlichte Inhalte und die Sicherheit der Vorschau sind geprüft.
• Export und Wiederaufbau von Inhalten samt Assets wurden erprobt.

5. Angenommenes Szenario: CMS-Auswahl für eine zweisprachige Dienstleistungswebsite

Dieses Szenario ist angenommen; es ist weder ein Kundenergebnis noch ein Kostenversprechen. Stellen Sie sich ein zweisprachiges Dienstleistungsunternehmen mit acht Redaktionsmitgliedern vor. Der Hauptkanal ist die Website, pro Jahr laufen einige Kampagnen, eine CRM-Formularintegration besteht, eine App ist nicht geplant. Das vorhandene Eigenbau-Backend bietet keine Vorschau, und jedes neue Seitenlayout erfordert die Entwicklung. Das Team schlägt vor, für die "Zukunftsfähigkeit" auf ein Headless-CMS zu wechseln.

Die Eingangsgrößen sind Kanalanzahl, Unabhängigkeit der Redaktion, Frequenz neuer Seiten, Integrationskomplexität, interne Entwicklungskapazität und die Wartungskosten über drei Jahre. Im Proof of Concept bietet die WordPress-Variante der Redaktion Vorschau und Terminierung über kontrollierte Blöcke. Die Headless-Variante überzeugt beim Content-Modell, verlangt aber zusätzliche Frontend-Arbeit für Live-Vorschau, Formulare und Weiterleitungen. Die Eigenentwicklung erfüllt alle Anforderungen, trägt jedoch den höchsten Wartungsaufwand und die stärkste Personenabhängigkeit.

Die Entscheidung fällt auf gemanagtes WordPress mit begrenzten individuellen Blöcken, statt heute für einen hypothetischen künftigen Kanal zu entkoppeln. Die REST API bleibt für eine spätere kontrollierte Inhaltsausspielung offen. Plugin-Updates, Rückkehr aus dem Backup, Sicherheitsverantwortung und Exportbedingungen kommen in den Vertrag. Sollte ein mobiler Kanal tatsächlich in die Roadmap gelangen, ist das als Auslöser für eine erneute Architekturbewertung festgehalten.

6. Die Wahl mit Vertrag, Pilot, Migration und Ausstiegsplan umsetzen

Im Entscheidungsdokument stehen Umfang, Gewichtung, Ausschlussgründe, Nachweise, offene Punkte und die Auslöser für eine Neubewertung. Servicelevel, Datenhoheit, Meldepflichten bei Sicherheitsvorfällen, Backups, Preise, Support, Barrierefreiheit, Export und der Zugriff nach Vertragsende gehören in die Verhandlung und sollten fachlich geprüft werden.

Führen Sie den Piloten mit risikoarmen, repräsentativen Inhalten durch. Testen Sie Modell, Frontend, Identitätsverwaltung, Formulare, Analytics, Vorschau und Veröffentlichungsstrecke durchgängig. Messen Sie die Performance für Besuchende, Redaktion und API. Stehen die Erfolgskriterien nicht von Anfang an fest, lässt sich auch ein schwaches Ergebnis zum Erfolg erklären.

Migrationswellen, Content-Freeze, URL-Zuordnung, Schulung und die Rückfallentscheidung gehören schriftlich festgehalten. Benennen Sie Verantwortliche für System, Content-Modell und Integrationen. Im Ausstiegsplan werden Export, Medien, Schema, Weiterleitungen und Betriebsdokumentation regelmäßig gepflegt, damit Portabilität nicht nur ein Vertragssatz bleibt.

• Entscheidungsmatrix, offene Punkte und Ausschlussgründe sind freigegeben.
• Für den repräsentativen Piloten gibt es messbare Erfolgs- und Abbruchkriterien.
• Daten, Sicherheit, Support, Preis und Ausstieg sind im Vertrag klar geregelt.
• Migrationswellen, URL-Zuordnung, Schulung und Rückfall sind geplant.
• Für CMS, Content-Modell und Integrationen sind Verantwortliche benannt.
• Export und Wiederherstellung werden regelmäßig getestet.

7. Grenzen und Fehlermuster: Die Plattform löst kein Organisationsproblem

Ein neues CMS behebt weder unklare Freigabebefugnisse noch eine schwache Strategie oder Seiten ohne Verantwortliche. Wer das alte Durcheinander in ein neues Modell überträgt, bekommt ein teureres Durcheinander. Vor der Migration muss jeder Inhalt die Entscheidung behalten, zusammenführen, aktualisieren oder löschen durchlaufen. Ohne Governance und Lebenszyklus zerfällt das System erneut.

Verbreitete Fehler sind, die Redaktion zu spät einzubinden, Headless mit Modernität gleichzusetzen, die Wartungskosten der Eigenentwicklung zu verschweigen und den Ausstieg nie zu testen. Sicherheit entsteht nicht durch das Plattformetikett: Versionen, Zugriffe, Plugins, Backups und Vorfallsreaktion müssen bei jedem Ansatz betrieben werden.

Dieser Rahmen spricht keine abschließende Produktempfehlung aus. Preise, Funktionsumfang, Hosting-Optionen und Regulierung ändern sich; in der Shortlist-Phase sind aktuelle offizielle Dokumente und Verträge zu prüfen. Das beste CMS ist nicht das mit den meisten Funktionen, sondern das System, das Content-Geschwindigkeit, Risiko und technische Kapazität des Unternehmens mit klarer Verantwortlichkeit ausbalanciert.