REDAXO ist seit Jahren das schlanke, hochflexible PHP-CMS für mittelständische Projekte in der DACH-Region. Klassisch wird es als monolithisches System genutzt: Templates rendern die Seiten serverseitig, der Browser bekommt fertiges HTML. Das funktioniert hervorragend für klassische Websites – stößt aber an Grenzen, sobald moderne Anwendungen wie SPAs (Single Page Applications), mobile Apps oder Multi-Channel-Publishing ins Spiel kommen. Hier kann REDAXO als Headless CMS die Antwort sein. In diesem Artikel erklären wir, was Headless CMS überhaupt bedeutet, wann sich der Schritt mit REDAXO lohnt und wie eine saubere Umsetzung in der Praxis aussieht.
Headless CMS – was bedeutet das eigentlich?
Ein klassisches CMS hat zwei Teile: Backend (Redaktion, Inhalte pflegen) und Frontend (Templates, die Inhalte als HTML ausgeben). Beide sind eng miteinander verzahnt. Ein Headless CMS löst diese Kopplung auf: Das Backend bleibt, der Frontend-Teil wird durch eine API ersetzt. Inhalte werden über REST oder GraphQL angefragt, das Frontend ist frei wählbar – React, Vue, Svelte, native Mobile App, beliebige andere Anwendung.
Klassisches CMS: Inhalte → Templates → HTML. Headless CMS: Inhalte → API → beliebige Endpunkte. "Headless" weil der Kopf (= das Frontend) abgenommen wurde – das Backend liefert nur noch strukturierte Daten.
Wann lohnt sich der Headless-Ansatz?
Headless ist kein Selbstzweck. Es lohnt sich nur in bestimmten Szenarien – sonst handelt man sich Komplexität ohne Mehrwert ein.
Single Page Application (SPA)
Sie wollen eine Anwendung mit React, Vue oder Svelte bauen, aber Inhalte sollen weiterhin von Redakteuren gepflegt werden. REDAXO als Headless-Backend liefert die Inhalte, das Frontend rendert sie clientseitig.
Mobile App + Website mit gleichen Inhalten
Eine native iOS-/Android-App und die Website sollen denselben Inhalts-Stand zeigen. Ein Headless-CMS liefert beide aus derselben Quelle.
Multi-Channel-Publishing
Inhalte sollen nicht nur auf einer Website erscheinen, sondern auch in Apps, auf Partner-Portalen, in Newslettern, in Digital Signage. Headless macht das technisch sauber.
Komplexe Frontend-Logik
Wenn das Frontend Animationen, Echtzeit-Updates, komplexe Interaktionen braucht – das ist in serverseitigem Templating schwer, in einem JavaScript-Frontend natürlich.
Klare Trennung Frontend / Backend
In Teams, in denen Frontend-Entwickler und Backend-Entwickler getrennt arbeiten, ist eine API-Trennung sinnvoll. Beide Teams können unabhängig releasen.
Wann Headless eher schadet als nützt
- Klassische Inhaltsseiten (Über uns, Kontakt, Impressum, Blog) – kein Mehrwert durch Headless
- Kleine Teams ohne Frontend-Spezialisten – die zusätzliche Komplexität lohnt sich nicht
- SEO ist Priorität und es gibt keine SSR-Strategie für das Frontend – Client-seitig gerendertes JS ist SEO-schwierig
- Low-Budget-Projekte – Headless braucht typisch 30-50 % mehr Initialaufwand
- Wenn Redaktion Live-Vorschau braucht – Headless-Vorschau ist machbar, aber aufwändiger
- Wartung soll an Kunden mit wenig technischem Verständnis übergeben werden
Wenn Sie keinen klaren Use-Case für ein JavaScript-Frontend oder eine Mehrkanal-Strategie haben, ist klassisches REDAXO meist die bessere Wahl. Headless lohnt sich erst, wenn die Anforderungen klassisches Templating überfordern.
REDAXO als Headless-CMS: Wie es technisch funktioniert
REDAXO bringt von Haus aus keine vollständige Headless-API mit – aber alles Nötige, um sie zu bauen. Drei bewährte Wege:
Eigene API-Endpunkte über Module oder Addons
Klassischer REDAXO-Ansatz: Pro Inhaltstyp eine eigene URL, die JSON statt HTML ausgibt. Vorteil: maximale Kontrolle, kein zusätzliches Addon nötig. Nachteil: Bei vielen Inhaltstypen wird es viel manuelle Arbeit.
YForm als Datenquelle + eigene API
YForm ist das CRUD-Addon von REDAXO. Eigene Tabellen lassen sich darüber pflegen, und über eigene PHP-Endpunkte als JSON ausliefern. Sehr flexibel für strukturierte Daten.
Fremd-Addons für Headless-Funktionalität
Es gibt Community-Addons, die REDAXO-Inhalte automatisch als REST-API bereitstellen – mit unterschiedlichem Reifegrad. Lohnt sich zu prüfen, statt alles selbst zu bauen.
Für die meisten Projekte ist die Kombination YForm + eigene API-Endpunkte der pragmatischste Weg. YForm bietet das Backend-UI für strukturierte Daten, eigene PHP-Skripte liefern die JSON-Antworten.
Architektur einer REDAXO-Headless-Lösung
Eine typische Headless-Architektur mit REDAXO sieht so aus:
- Backend: REDAXO mit YForm-Tabellen für strukturierte Daten, klassische Artikel-Struktur für CMS-Inhalte
- API-Schicht: PHP-Endpunkte, die Anfragen entgegennehmen, prüfen, Daten laden und als JSON zurückgeben
- Authentifizierung: Token-basierte Auth (Bearer-Token, JWT) für geschützte Endpunkte
- Caching: Redis oder File-Cache vor den API-Endpunkten – minimiert Datenbank-Last
- CORS-Konfiguration: damit das Frontend von einer anderen Domain zugreifen kann
- Frontend: React, Vue, Svelte oder Astro – läuft als separates Deployment
- Server-Side-Rendering oder Static Site Generation, falls SEO wichtig
Authentifizierung der API: Sicherheit ist Pflicht
Eine offene API ohne Authentifizierung ist eine Einladung an Crawler, Bots und Konkurrenz. Selbst bei rein öffentlichen Inhalten gehört Authentifizierung als Grundsicherung dazu:
| Methode | Anwendungsfall | Implementierung |
|---|---|---|
| API-Key | Frontend-Anwendung, vertrauenswürdige Clients | Statischer Token im Header, einfach |
| JWT | Anwender-bezogene Authentifizierung | Token nach Login, mit Ablaufzeit |
| OAuth 2.0 | Drittanbieter-Zugriff | Komplexer, aber Standard für offene APIs |
| IP-Whitelist | Server-zu-Server | Einfach, aber nur ergänzend |
| Rate-Limiting | Generelle Sicherheit | Immer einsetzen, unabhängig von Auth |
⚠️ Wichtig: API-Keys gehören niemals in Frontend-Quellcode – sie sind dort öffentlich sichtbar. Sensible Tokens müssen über einen Backend-Proxy laufen oder über kurze, anwender-bezogene Sessions ausgegeben werden.
Caching: Performance der API
Ein Headless-Setup steht und fällt mit der API-Performance. Bei jedem Frontend-Seitenaufruf können mehrere API-Calls anfallen – ohne Caching wird das schnell langsam.
Caching-Schichten
- REDAXO-Cache (klassisch): Inhalte werden in der bestehenden Cache-Logik gehalten
- File-Cache für API-Antworten: JSON-Antworten als Datei zwischenspeichern, mit Versionsmarker
- Redis / Memcached: Für höher belastete APIs, sub-Millisekunden-Zugriff
- CDN vor der API: Cloudflare, Bunny oder eigenes CDN – cacht GETs effizient
- Client-seitiges Caching im Frontend: Anfragen wiederholen, nicht jeden Klick neu laden
- ETag-Header und Conditional Requests: Anwender bekommt nur Updates, keine ganze Antwort
Setzen Sie HTTP-Cache-Header (Cache-Control, ETag) immer korrekt. Auch ohne externes CDN profitiert jeder Browser davon – und sie sind die Grundlage für späteres CDN-Cache-Tuning.
Versionierung der API
Sobald die API von externen Clients (z.B. Mobile App) verwendet wird, ist Versionierung Pflicht. Sonst legt jede API-Änderung Clients lahm, die nicht mit-aktualisiert werden können.
- URL-Versionierung:
/api/v1/products– einfach, klar, gängig - Header-Versionierung:
Accept: application/vnd.mimann.v1+json– sauberer, aber schwerer testbar - Feature-Flags pro Client: granular, aber komplex
- Deprecation-Hinweise im Header: Clients erfahren, dass eine Version ausläuft
Live-Vorschau – die größte Herausforderung
Klassisches REDAXO bietet eine selbstverständliche Vorschau für Redakteure – "speichern und im Frontend ansehen". Headless macht das aufwändiger:
Preview-Modus im Frontend
Frontend lädt im Preview-Modus Entwurfs-Daten statt Live-Daten. Token-basiert geschützt.
Serverseitiges Rendering auf Knopfdruck
Static Site Generators wie Next.js können einzelne Seiten on-demand neu rendern, wenn ein Redakteur einen Inhalt speichert.
Incremental Static Regeneration (ISR)
Statische Seiten werden bei Inhaltsänderungen automatisch im Hintergrund neu generiert. Frontend zeigt schnell den neuen Stand.
Webhook bei Speichern
REDAXO ruft beim Speichern eines Inhalts einen Webhook auf, der das Frontend zur Aktualisierung triggert.
Wann lohnt sich der Schritt – konkrete Beispiele
Beispiel 1: Mitarbeiter-Portal
Eine Webapp, die Mitarbeitenden Zugriff auf interne Ressourcen, Workflows und Daten gibt. REDAXO im Hintergrund pflegt Inhalte und Stammdaten, ein React-Frontend bietet die Anwendung. Klare Trennung Frontend/Backend, redaktionelle Inhalte aus REDAXO, dynamische Logik im Frontend.
Beispiel 2: Konfigurator
Anwender konfigurieren ein Produkt schrittweise. Backend liefert Optionen, Preise, Verfügbarkeiten als JSON. Frontend (Vue) rendert die Auswahl, prüft Abhängigkeiten, berechnet Preise. Inhaltsverwaltung der Produkte durch Vertrieb über REDAXO.
Beispiel 3: Mobile App + Website
Eine Vereins-Website und eine Mitglieder-App teilen sich denselben Inhalts-Backend. Veranstaltungen, News und Mitgliederinfos werden zentral in REDAXO gepflegt und über die API in beide Kanäle ausgespielt.
Beispiel 4: B2B-Portal mit Selfservice
Kunden können ihre Daten ändern, Aufträge einsehen, Tickets eröffnen. Frontend in Svelte für saubere User Experience, Backend in REDAXO mit YForm für strukturierte Daten. CRM-Integration über zusätzliche API-Aufrufe.
Was eine Headless-Lösung mit REDAXO kostet
Die Kosten hängen stark vom Umfang ab. Realistische Größenordnungen:
- Kleine Lösung (REDAXO bleibt, zusätzlich 5-10 API-Endpunkte + einfaches React-Frontend): 12.000-25.000 €
- Mittlere Lösung (Headless-Architektur mit Auth, Caching, mehreren Inhaltstypen): 30.000-70.000 €
- Größere Lösung (Multi-Channel, mobile App, SSR-Frontend, vollständiger Workflow): 80.000-200.000 €
- Wartung und Erweiterung: 20-30 % der Erstellungskosten pro Jahr
5 typische Fehler in Headless-REDAXO-Projekten
Headless wählen, wo klassisches REDAXO ausgereicht hätte
Mehr Komplexität, mehr Wartungsaufwand, kein Mehrwert. Vorher ehrlich prüfen, ob ein JS-Frontend wirklich nötig ist.
Kein Caching von Anfang an
API ist schnell, solange nur wenige Anfragen kommen. Mit Wachstum bricht die Performance. Caching gehört von Tag eins ins Setup.
Authentifizierung als Nachgedanke
Erst die API bauen, dann "später Auth einbauen" – führt zu unsicheren Endpunkten und unsauberen Nachrüstungen.
Keine API-Versionierung
Erste Version geht live, dann Änderungen "in place" – Clients brechen. Versionierung von Anfang an mit einplanen.
Live-Vorschau vergessen
Redakteure merken erst nach Go-Live, dass sie keine Vorschau haben. Sehr schmerzhaft, weil nachträglich aufwändig.
Fazit: Headless ist ein Werkzeug, kein Trend
REDAXO als Headless CMS ist ein mächtiges Werkzeug – für die richtigen Projekte. Wer eine moderne Webanwendung mit eigenem Frontend, mehrere Ausgabekanäle oder eine Mobile App im Mix hat, profitiert deutlich. Wer eine klassische Website mit Redaktion bauen will, ist mit dem traditionellen REDAXO-Setup besser bedient – einfacher, günstiger, schneller im Aufbau und langfristig pflegeleichter.
Wenn Sie eine Webanwendung mit REDAXO als Headless-Backend planen oder eine bestehende Anwendung in diese Richtung weiterentwickeln möchten – melden Sie sich. Wir entwickeln Headless-Architekturen mit REDAXO für mittelständische Unternehmen in Freiburg und der Region, inklusive API-Design, Authentifizierung und Frontend-Anbindung.