Für Fachleute
Headless CMS mit visuellem Editor: so sind unsere Websites gebaut
Ein Headless CMS trennt Inhalte von der Darstellung. Wir nutzen das Prinzip, ohne Redakteurinnen und Redakteure in Formularfelder zu zwingen: Inhalte liegen als strukturierte Daten in einer Datenbank in Frankfurt, die Website rendert sie mit Next.js, und der Editor zeigt beim Bearbeiten die echte Seite. Diese Seite beschreibt Aufbau, Auslieferung, Performance und die Grenzen des Ansatzes.
Was ist ein Headless CMS?
Ein Headless CMS speichert Inhalte getrennt vom Frontend und liefert sie über eine Schnittstelle aus; wie die Inhalte aussehen, entscheidet allein die Website. Das Gegenmodell ist ein klassisches CMS wie WordPress, in dem Inhalt, Theme und Plugins in einer Anwendung laufen und jede Seite bei Aufruf aus der Datenbank zusammengesetzt wird.
Viele Headless-Systeme bezahlen die Trennung mit Bedienkomfort: Redakteure pflegen Felder in einer Maske und sehen das Ergebnis erst in einer Vorschau. Unser CMS speichert jede Seite als Folge typisierter Blöcke (JSON) und rendert im Editor dieselben React-Komponenten wie die Website. Bearbeitet wird also die Seite selbst, gespeichert werden strukturierte Daten.
Wie ist eine APOLLOBASE-Website aufgebaut?
Eine APOLLOBASE-Website besteht aus drei Teilen: dem Frontend in Next.js, den Inhalten in PostgreSQL und dem visuellen Editor dazwischen. Die Teile sind lose gekoppelt; das Frontend läuft auch ohne erreichbare Datenbank mit den zuletzt veröffentlichten Inhalten weiter.
- Frontend: Next.js (App Router) mit React Server Components. Interaktive Teile wie Formulare laden als kleine Client-Komponenten nach; der Rest kommt als fertiges HTML.
- Inhalte: PostgreSQL bei Supabase in Frankfurt. Jede Seite hat einen Entwurf und eine veröffentlichte Fassung; die Website liest nur die veröffentlichte.
- Editor: visueller Seiteneditor auf Basis von Puck, angemeldet über Supabase Auth. Zugriff hat nur, wer für die jeweilige Website als Mitglied eingetragen ist; die Datenbank prüft das per Row Level Security.
- Veröffentlichen: Die Website wird beim Build statisch erzeugt. Wer im Editor veröffentlicht, erneuert gezielt den Cache der betroffenen Seite (On-Demand-Revalidierung über Cache-Tags), ohne neuen Build.
Warum statisch ausliefern statt bei jedem Aufruf rendern?
Weil eine vorab erzeugte Seite ohne Datenbankabfrage und ohne Anwendungscode pro Aufruf ausgeliefert wird. Das macht sie schnell und verkleinert die Angriffsfläche: Auf der öffentlichen Website laufen kein PHP, keine Plugins von Drittanbietern und kein Login.
Der Preis dafür: Neue Bausteine oder ein anderes Layout sind Entwicklungsarbeit und kein Klick im Backend. Redakteure ändern Texte, Bilder, Reihenfolge und Inhalte innerhalb der Bausteine, die wir für die Website definiert haben. Für die meisten Unternehmenswebsites ist das ein Vorteil, weil das Design nicht über die Jahre zerfällt.
Wie erreichen wir gute Core Web Vitals?
Wir planen jede Seite auf die drei Grenzwerte hin, die Google als „gut“ einstuft: Largest Contentful Paint bis 2,5 Sekunden, Interaction to Next Paint bis 200 Millisekunden und Cumulative Layout Shift bis 0,1. Vor dem Go-Live prüfen wir die Werte auf dem Handy-Profil von Lighthouse.
- Die H1 ist das größte Element im ersten Bild (LCP-Ziel). Bilder darunter laden verzögert und mit fester Größe, damit nichts springt.
- Schriften liegen auf unserem eigenen Server (next/font), ohne Anfragen an Google Fonts.
- Animationen nutzen nur transform und opacity und entfallen bei „Bewegung reduzieren“.
- Schwere Bibliotheken, etwa für 3D, laden erst nach einem Klick und nie beim ersten Aufruf.
- Kein Tag-Manager und keine Werbe-Skripte vor einer Einwilligung; die Reichweitenmessung läuft cookielos.
Was passiert mit den Inhalten, wenn Sie wechseln?
Die Inhalte gehören Ihnen und lassen sich exportieren. Weil jede Seite als strukturierte Blöcke in einer eigenen Datenbank liegt, bleiben Texte, Bildverweise und Gliederung maschinenlesbar und lassen sich in ein anderes System übertragen. Ihre Domain bleibt ohnehin bei Ihnen.
Den Editor buchen Sie monatlich ab 29 € netto und können ihn monatlich kündigen.
Für welche Projekte passt der Ansatz nicht?
Für Projekte, deren Kern ein großes Plugin-Ökosystem oder ein komplexer Shop ist, passt er nicht. Online-Shops bauen wir auf Shopify oder Shopware, bestehende WordPress- und TYPO3-Installationen betreuen wir weiter oder migrieren sie.
Gut passt er für Unternehmenswebsites, Kanzleien, Praxen, Handwerk und Gastronomie: Seiten mit klarer Struktur, bei denen ein kleines Team Inhalte pflegt und Geschwindigkeit, Sicherheit und Datenhaltung in Deutschland wichtiger sind als beliebige Erweiterbarkeit.
Technisches Gespräch
Beschreiben Sie kurz Ihr Vorhaben oder Ihre Vorgaben. Wir antworten persönlich.
- Sie schicken uns Ihre Anfrage, gern mit Vorgaben zu Datenhaltung, Rollen oder Technik.
- Der Gründer meldet sich persönlich bei Ihnen.
- Im Gespräch klären wir, ob und wie wir Ihre Anforderungen umsetzen und was das kostet.
Lieber direkt sprechen? +49 711 490 949 88
Direkt mit dem Gründer
Burkhard Wagner
Gründer, APOLLOBASE GmbH, Stuttgart
Bei uns sprechen Sie direkt mit dem Gründer. Rufen Sie an, schreiben Sie per WhatsApp oder wählen Sie einen Termin.
Gespeichert in Frankfurt
Alle Inhalte Ihrer Website werden in Frankfurt am Main gespeichert.
Persönliche Einweisung
Nach dem Start zeigen wir Ihnen persönlich, wie Sie Texte und Bilder ändern.
Preise offen
Unsere Preise stehen auf der Website, nicht erst im Angebot.