Was Headless konkret verändert
Ein Headless CMS verwaltet Inhalte getrennt von ihrer Darstellung. Eine Programmierschnittstelle, kurz API, liefert sie an Websites und Apps, die getrennt vom CMS entwickelt werden.
Die Redaktion pflegt Inhalte, die in mehreren Oberflächen erscheinen können. Dafür müssen diese Inhalte entsprechend aufgebaut sein: Ein Artikel braucht etwa getrennte Felder für Titel, Kurzfassung, Text und Bild. Wie daraus eine Seite wird, entscheidet die jeweilige Anwendung.
Storyblok, Payload oder das vorhandene CMS?
Die Wahl des CMS bestimmt, wie die Redaktion arbeitet und was das Entwicklungsteam selbst betreuen muss.
Storyblok: visuelle Redaktion als Cloud-Dienst
Die Redaktion bearbeitet Bausteine in einer angebundenen Seitenvorschau. Storyblok betreibt das CMS; die Website, ihre Vorschau und die Anbindung entwickeln und betreuen wir mit Ihrem Team.
Payload: Inhalte und individuelle Anwendungslogik
Payload kommt infrage, wenn Inhalte mit eigenen Datenmodellen und Zugriffsregeln zusammenhängen. Es wird Teil einer Next.js- und TypeScript-Anwendung. Damit liegen auch Updates, Datenhaltung und Betrieb in der Verantwortung des betreuenden Teams.
TYPO3, Craft CMS und Neos: das vorhandene System einbeziehen
Seitenstruktur, Mehrsprachigkeit und individuelle Erweiterungen können gute Gründe sein, ein bestehendes CMS weiterzuverwenden. Wir prüfen, welche Inhalte es anderen Anwendungen bereitstellen kann und welche Funktionen bei einer Trennung neu entwickelt werden müssten.
Integriert, Headless oder hybrid?
Mehrere Websites allein sind noch kein Grund für Headless. Entscheidend ist, ob sie dieselben Inhalte nutzen und ob ihre Oberflächen unabhängig voneinander weiterentwickelt werden sollen.
Inhalte und Website im selben CMS: integriert
Ein CMS verwaltet Inhalte und erzeugt die Website. Wenn Seitenstruktur, Formulare und Erweiterungen dort bereits gut zusammenspielen, halten wir diese Funktionen zusammen.
Gemeinsame Inhalte für Website und App: Headless
Eine Produktbeschreibung wird auf der Website und in einer App benötigt. Beide beziehen sie aus demselben CMS und stellen sie jeweils passend dar. Die Redaktion ändert den Text an einer Stelle, während Website und App eigene Entwicklungszyklen haben können.
Neuer Inhaltsbereich in bestehender Plattform: hybrid
Ein neues CMS liefert ausgewählte Inhalte an die vorhandene Website. Bestehende Formulare, Benutzerkonten und Erweiterungen bleiben im bisherigen System. Wir legen fest, welches System welche Inhalte führt und wie Änderungen übertragen werden.
Von der Inhaltspflege bis zur Veröffentlichung
An einem repräsentativen Inhalt prüfen Redaktion und Entwicklung den vollständigen Ablauf: Datenfelder befüllen, Vorschau aufrufen, freigeben, veröffentlichen und Änderungen übertragen.
- Inhaltsmodell: Felder, Übersetzungen, Verweise und wiederverwendbare Bausteine, etwa Artikel, Autoren und Teaser.
- Redaktion: Rollen, Freigaben und geschützte Vorschau. Entwürfe dürfen nicht über die öffentliche Schnittstelle erreichbar sein.
- Veröffentlichung: neue Inhalte, Änderungen und Rücknahmen zuverlässig übertragen; zwischengespeicherte Inhalte gezielt aktualisieren.
- Migration: alte Inhalte den neuen Feldern zuordnen, Medien und Links übernehmen und bestehende URLs erhalten oder gezielt weiterleiten.
- Suchmaschinen: lesbare Inhalte im ausgelieferten HTML, Seitentitel, Sprachversionen, Canonical-URLs und Weiterleitungen.
- Betrieb: Zuständigkeiten, Fehlerprotokolle, Updates und Wiederherstellung festlegen. Ladezeiten und Barrierefreiheit der fertigen Oberfläche prüfen.
Der erste Schritt: Ihre Inhalte und Abläufe prüfen
Bringen Sie Ihre bestehende Website, die geplanten Ausgabekanäle und ein Beispiel aus dem Redaktionsalltag mit. Wir erfassen, wo Inhalte entstehen, wer sie freigibt und welche Anwendungen darauf zugreifen. Bestehende Schnittstellen und Erweiterungen beziehen wir ein.
Daraus leiten wir ab, welche Aufgaben im bestehenden CMS bleiben und wo eine Trennung sinnvoll ist. Technisch offene Fragen prüfen wir an einem abgegrenzten Beispiel, bevor wir eine Migration planen. Auch Zuständigkeiten und laufende Kosten gehören in diese Entscheidung.
Praxis: Storyblok und TYPO3 auf lotterien.at
Bei lotterien.at pflegt die Redaktion Artikel in Storyblok; TYPO3 stellt sie auf der bestehenden Website dar. Wir haben die Anbindung entwickelt, die Artikel, Bilder und SEO-Angaben überträgt und Veröffentlichungen, Änderungen und Rücknahmen verarbeitet. Bestehende Seiten und individuelle TYPO3-Extensions bleiben erhalten. So kann die Redaktion Storyblok nutzen, ohne diese Funktionen neu entwickeln zu lassen.
Weitere Leistungen
- StoryblokVisuelle Redaktion und Integration
- Payload CMSEigene Datenmodelle und Anwendungsfunktionen
- Craft CMSFlexible Inhaltsbausteine und Seitenvorschau
- Neos CMSInhalte direkt in der Seitenansicht bearbeiten
- TYPO3Websites, Erweiterungen und redaktionelle Abläufe
- BarrierefreiheitNavigation, Formulare und zugängliche Webanwendungen
Fragen vor einem Headless-Projekt
Was wird durch Headless aufwendiger?
Neben dem CMS wird mindestens eine separate Oberfläche entwickelt und betreut. Funktionen wie Suche oder Formulare müssen dort eingebunden werden. Auch Änderungen am Inhaltsmodell sind mit den angebundenen Anwendungen abzustimmen.
Wie frei kann die Redaktion Seiten gestalten?
Mit den eingerichteten Bausteinen kann sie Seiten zusammenstellen, Inhalte ändern und veröffentlichen. Welche Anordnungen und Varianten möglich sind, wird bei der Entwicklung festgelegt. Eine neue Darstellungsform oder Funktion kann deshalb Anpassungen am CMS und an der Website erfordern.
Wie prüfen wir Inhalte, bevor sie veröffentlicht werden?
Die Vorschau zeigt einen Entwurf so, wie er auf der Website oder in der App erscheint. Nutzt derselbe Inhalt mehrere Oberflächen, muss er auch dort beurteilt werden können. Wir richten geschützte Vorschauen ein und prüfen mit der Redaktion, ob Texte, Bilder, Links und Sprachversionen vor der Freigabe richtig zusammenspielen.
Können wir das CMS später wechseln?
Ja, aber ein Wechsel bleibt ein Migrationsprojekt. Neben Texten und Bildern müssen Inhaltsmodelle, Verweise, Übersetzungen und die Anbindung der Anwendungen übernommen oder angepasst werden. Wir prüfen deshalb schon bei der Auswahl, wie sich Inhalte einschließlich ihrer Beziehungen exportieren lassen und wo CMS-spezifische Funktionen einen späteren Wechsel erschweren.