Inhaltssystem und Auslieferung unterscheiden
Ein gekoppeltes System ist sinnvoll, wenn die Redaktion hauptsächlich eine Website betreut und ihre Abläufe funktionieren. Eine getrennte Auslieferung lohnt sich, wenn eigenständige Anwendungen dieselben strukturierten Inhalte benötigen. Das Wort headless allein begründet keinen Wechsel.
WordPress und Headless sind keine Gegensätze. Über die WordPress REST API lassen sich Inhalte in unabhängigen Anwendungen verwenden. WordPress kann also redaktionelles Backend bleiben, während eine andere Anwendung die öffentliche Oberfläche liefert. Zuerst steht die Architekturfrage, danach die Anbieterauswahl.
Clodron betrachtet diesen Vergleich aus der Produktentwicklung. Entscheidend ist ein dauerhaft brauchbarer Veröffentlichungsprozess, nicht eine möglichst umfangreiche Sammlung von Diensten.
Die tatsächliche Redaktionsarbeit betrachten
Ein gekoppelter Aufbau passt, wenn Seiten, Artikel und wiederverwendbare Blöcke eng mit dem Erscheinungsbild der Website verbunden sind. Vorschau und Veröffentlichung lassen sich innerhalb desselben Systems beurteilen. Ein eingespielter redaktioneller Ablauf ist zunächst ein Wert, keine technische Altlast.
Headless wird interessanter, wenn Inhalte unabhängig von einzelnen Seiten gebraucht werden: Produktwissen in mehreren Oberflächen, Hilfetexte innerhalb einer Anwendung oder gemeinsame Datensätze für unterschiedliche Kanäle. Wiederverwendbare Bedeutung ist dabei wichtiger als formatierten Text durch eine API zu schicken.
Geht es bei jeder Diskussion über das Inhaltsmodell letztlich um die Position einer Überschrift, wird möglicherweise ein visueller Seitenbaukasten benötigt. Das ist legitim, aber eine andere Anforderung als unabhängige Inhaltsauslieferung.
Den Veröffentlichungsprozess mitkalkulieren
Ein separates Frontend übernimmt die bisherige Redaktionserfahrung nicht automatisch. Geschützte Vorschau, Entwurfszugriff, Weiterleitungen, Bilder, Cache-Aktualisierung und Fehlerbehandlung brauchen eine Umsetzung. Ein gespeicherter Datensatz ist noch keine korrekt veröffentlichte Seite.
Die WordPress-API unterscheidet öffentliche Inhalte von authentifizierungspflichtigen Daten. Diese Grenze muss auch im individuellen Frontend gelten. Ein bequem gebauter Vorschau-Endpunkt darf sie nicht aufheben. Das ist eine konkrete Implementierungsaufgabe, kein pauschales Argument für oder gegen Headless.
Ebenso wenig darf angenommen werden, dass jedes bisherige Plugin in einem fremden Frontend weiterwirkt. Ein zusätzliches Metadatenfeld lässt sich möglicherweise übertragen. Die Ausgabe, Prüfung und Vorschau dieses Feldes müssen dennoch umgesetzt werden.
Änderungsaufwand statt Mode vergleichen
Kopplung hilft, wenn Inhalte und Darstellung gemeinsam verändert werden sollen. Trennung kann helfen, wenn verschiedene Teams unabhängig veröffentlichen müssen. Dafür entstehen Schnittstellenverträge und zusätzliche Abstimmung. Beide Ansätze haben einen Preis.
Unser Beitrag über ungenutzte Designsysteme beschreibt eine verwandte Grenze: Eine elegante gemeinsame Grundlage verliert ihren Nutzen, wenn Menschen täglich um sie herumarbeiten müssen. Ein Inhaltsmodell sollte Veröffentlichungen vereinfachen.
Bei einer individuellen Webplattform gehören die Zuständigkeiten für Redaktion und Frontend deshalb gemeinsam auf den Tisch. Eine CMS-Auswahl ohne diese Verantwortung lässt das Betriebsmodell unvollständig.
Vor dem Umzug eine Veröffentlichung proben
Diese Woche reichen echte, schwierige Beispiele als Entscheidungsgrundlage: ungewöhnlich formatierter Inhalt, ein unveröffentlichter Entwurf und eine geänderte URL. In jedem Ansatz werden Bearbeitung, Vorschau, Freigabe, Veröffentlichung und Rücknahme durchgespielt. Auch eine ausgefallene Aktualisierungsnachricht gehört dazu.
Bleibt der gekoppelte Aufbau für die tatsächlichen Zielgruppen und Arbeitsweisen passend, sollte er nicht vorschnell ersetzt werden. Headless lohnt sich bei einem belegten Bedarf nach unabhängiger Auslieferung und klarer Verantwortung für die Zusatzarbeit. WordPress kann dabei weiterhin das passende Backend sein.