Headless Workflow mit Kirby CMS und Nuxt

Jedes Kundenprojekt startet bei mir mit denselben zwei Entscheidungen: Kirby CMS im Backend, Nuxt als Frontend. Diese Kombination hat sich über mehrere Jahre und viele Projekte bewährt, nicht weil sie auf dem Papier gut klingt, sondern weil sie in der Praxis funktioniert. Websites, die schnell laden, die ein Kunde eigenständig pflegen kann, und die sich ohne Grundsanierung erweitern lassen, wenn das Unternehmen wächst.

Warum Nuxt und nicht React

Wer heute ein Frontend-Framework wählt, landet schnell bei React. Die Community ist groß, die Jobangebote auch. Ich nutze trotzdem Nuxt, ein Vue-basiertes Framework, und das seit Jahren.

Der Unterschied liegt nicht im Können, sondern in der Struktur. React ist bewusst minimal gehalten, es gibt kaum Vorgaben, wie ein Projekt aufgebaut sein soll. Das ist für große Teams mit eigenen Konventionen kein Problem. Für jemanden, der schnell und verlässlich Kundenprojekte liefert, ist es anders: Zwei React-Projekte können sich strukturell komplett unterscheiden, selbst wenn sie das gleiche Ziel verfolgen.

Nuxt macht das anders. Pages liegen in pages/, Komponenten in components/, Serverlogik in server/. Diese Struktur ist keine Einschränkung, sondern eine Entscheidung, die ich jeden Tag schätze. Bestehende Projekte lassen sich nach Monaten schnell wieder aufgreifen. Neue Projekte starten auf einer bekannten Grundlage.

Dazu kommt jahrelange Erfahrung mit dem Framework. Ich kenne die Eigenheiten beim Server-Side-Rendering, die sinnvolle Nutzung der Composables und wo man aufpassen muss, wenn ein Projekt größer wird. Diese Erfahrung ist durch ein anderes Framework nicht einfach zu ersetzen, egal wie viele neue Releases erscheinen.

Warum Kirby CMS als Headless-Backend

Kirby ist ein CMS aus München mit einer ungewöhnlichen Architekturentscheidung: Inhalte werden nicht in einer Datenbank gespeichert, sondern als einfache Textdateien direkt auf dem Server. Eine Seite entspricht einem Ordner, jedes Inhaltsfeld einem lesbaren Eintrag darin.

Headless bedeutet in diesem Kontext: Kirby verwaltet die Inhalte, baut aber kein eigenes Frontend. Nuxt holt sich die Daten über eine API und baut daraus das sichtbare Ergebnis. Inhalt und Darstellung sind konsequent getrennt.

Das hat konkrete Auswirkungen im Projektalltag.

Backups brauchen kein spezielles Plugin und keinen Datenbankexport. Den Projektordner kopieren reicht. Versionierung lässt sich mit Git einrichten, was bedeutet: Inhaltsänderungen lassen sich genauso zurückrollen wie Code-Änderungen. Kein CMS-Export, kein Diff-Problem.

Sicherheit ist ein weiterer Punkt. Kirby hat keine Datenbank, und damit entfällt eine der häufigsten Angriffsflächen klassischer Systeme. SQL-Injection, das Einschleusen von schadhaftem Code über Datenbankabfragen, ist bei Kirby schlicht nicht möglich. Kein Plugin-Wirrwarr, keine veralteten Abhängigkeiten, die zur Schwachstelle werden.

Die Performance ist das natürliche Ergebnis der Architektur. Weil Nuxt das Frontend aufbaut und Kirby nur Daten liefert, entstehen statisch generierte oder server-seitig gerenderte Seiten mit soliden Core-Web-Vitals-Werten, ohne aufwändiges Caching-Setup.

Wie sich Kirby dabei konkret gegen WordPress schlägt, habe ich im Beitrag Kirby CMS vs. WordPress ausführlicher verglichen.

Das Cacao Kit: Strukturierter Startpunkt für jedes Projekt

Für beide Seiten des Stacks nutze ich Starter-Pakete von Johann Schopplich: das Cacao Kit Frontend für Nuxt und das Cacao Kit Backend für Kirby. Beide Pakete sind aufeinander abgestimmt und bilden zusammen eine vollständige, sofort einsatzbereite Grundlage.

Das Frontend-Kit bringt die Nuxt-Konfiguration mit, die KQL-Integration (Kirbys Query Language, mit der Inhalte strukturiert aus dem Backend abgefragt werden), SEO-Defaults und sinnvolle Performance-Einstellungen. Man startet nicht bei null, sondern auf einer stabilen, getesteten Basis.

Das Backend-Kit liefert eine passende Kirby-Instanz mit Beispiel-Blueprints, vorkonfiguriertem API-Endpoint und der CORS-Konfiguration für ein Headless-Setup. Beide Kits spielen von Anfang an reibungslos zusammen, das ist kein Zufall, sondern die Absicht hinter den Paketen.

Was das in der Praxis bedeutet: Der Start eines neuen Projekts dauert keine zwei Tage bis zur ersten lauffähigen Version mit echten Inhalten aus dem CMS. Die Energie geht in das, was das Projekt wirklich unterscheidet: Struktur, Inhalt, Design.

Blueprints: Das CMS entsteht nach Anforderung

Ein zentrales Konzept in Kirby sind Blueprints. Das sind Konfigurationsdateien, die festlegen, welche Felder und Inhaltstypen im Backend-Panel existieren. Ein Blueprint für eine Projektseite sieht anders aus als einer für einen Blogbeitrag, eine Landingpage oder eine Kategorieübersicht.

Der Effekt ist direkt spürbar: Das CMS, das der Kunde sieht, ist genau das CMS, das für sein Projekt gebaut wurde. Keine ungenutzten Felder, keine Optionen, die verwirren, weil sie für ein anderes Projekt gedacht waren. Ein Architekturbüro sieht andere Eingabemasken als ein Finanzdienstleister.

Das erste Gespräch über den Inhalt ist gleichzeitig das erste Gespräch über die Blueprint-Struktur. Welche Seitentypen gibt es? Welche Felder braucht jede Seite? Welche Inhalte pflegt der Kunde selbst, welche werden einmalig festgelegt? Diese Fragen führen direkt zur Panel-Konfiguration, und die Panel-Konfiguration führt direkt zur Frontend-Datenstruktur. Beides entsteht aus denselben Anforderungen.

Kirby, KI und Textdateien: Ein unerwarteter Vorteil

Dass Kirby Inhalte als Textdateien speichert, war eine Entscheidung für Einfachheit und Wartbarkeit. Als Nebeneffekt ergibt sich daraus heute ein konkreter Vorteil im Umgang mit KI-Werkzeugen.

Sprachmodelle wie Claude oder ChatGPT arbeiten gut mit Textdateien. Kirby-Inhalte lassen sich direkt lesen, bearbeiten und strukturieren. Wer Inhalte für ein Kirby-Projekt anlegen will, kann dem Modell die Blueprint-Struktur übergeben, also welche Felder existieren und in welchem Format, und bekommt fertige Kirby-Dateien zurück, die direkt ins Projekt eingespielt werden können.

Keine Datenbankverbindung, keine Import-Skripte, keine manuellen Umwege. Für strukturierten Content, zum Beispiel Kategorieseiten, Produktbeschreibungen oder mehrsprachige Texte, ist das ein echter Zeitvorteil.

Das ist kein Ersatz für durchdachte Inhalte. Qualität muss stimmen, egal wer schreibt. Aber für den Teil der Arbeit, bei dem Struktur und Volumen wichtiger sind als Originalität, passt dieser Workflow gut. Und weil das Inhaltsmodell in Blueprints klar definiert ist, kann das Modell zuverlässig in der richtigen Struktur schreiben, ohne zu raten.

Wie ein Projekt in der Praxis entsteht

Nach dem Briefing beginnt die Struktur: Welche Seitentypen gibt es, welche Felder braucht jede Seite, was soll der Kunde später selbst ändern können? Dieses Inhaltsmodell definiert die Blueprints in Kirby und gleichzeitig, wie das Nuxt-Frontend die Daten verarbeitet.

Das Cacao Kit kommt als Basis, wird auf das Projekt zugeschnitten und um projektspezifische Komponenten erweitert. Das Panel entsteht parallel so, dass der Kunde nach Projektabschluss eigenständig Inhalte pflegen kann, ohne Entwicklerkenntnisse.

Das Ergebnis ist eine Website, bei der Code und Inhalt sauber getrennt sind, die Pflege unkompliziert ist und die technische Basis stabil genug, um mit dem Projekt zu wachsen, ohne bei der nächsten Erweiterung von vorne anfangen zu müssen. Das klingt nach dem Mindestanspruch, ist in der Praxis aber öfter die Ausnahme als erwartet.

Dieser Beitrag wurde mit Unterstützung von KI ausformuliert und übersetzt.