Headless CMS vs. traditionelles CMS: Was passt zu Ihrer Website?
Ein traditionelles CMS speichert Inhalte und rendert die Seiten. Ein Headless CMS speichert Inhalte und gibt sie über eine API weiter, das Rendern überlässt es vollständig Ihnen. Dieser eine Unterschied wirkt sich auf alles aus: Vorschau, Kosten, Teamstruktur und wie schnell jemand aus dem Marketing eine Seite ändern kann.
Dieser Leitfaden behandelt, was Sie gewinnen, was Sie verlieren, und wo der Mittelweg liegt.
Der eigentliche Unterschied#
Alles andere folgt daraus, wo gerendert wird.
| Traditionell | Headless | |
|---|---|---|
| Rendern | Das CMS erzeugt das HTML | Ihr Frontend |
| Templates | Im CMS | In Ihrer Codebasis |
| Vorschau | Eingebaut und genau | Müssen Sie bauen |
| Kanäle | Eine Website | Website, App, Kiosk, alles, was eine API aufrufen kann |
| Frontend-Freiheit | Vom CMS begrenzt | Vollständig |
| Zeit bis zur ersten Seite | Schnell | Langsam — nichts rendert, bevor Sie es bauen |
| Wer für eine Layoutänderung gebraucht wird | Oft die Redaktion | Die Entwicklung |
Was Sie mit headless aufgeben#
Die Funktionen, die ein traditionelles CMS gratis mitbringt, sind die, die man vermisst — und man entdeckt sie meist nach der Entscheidung.
- Vorschau. Redaktionen erwarten, die Seite vor dem Veröffentlichen zu sehen. Bei headless ist das eine Funktion, die Sie bauen und pflegen.
- Seitenkomposition. Blöcke auf einer Seite anzuordnen ist in traditionellen Systemen gelöst und in headless ein Bauvorhaben.
- Menüs und Navigation. Ebenfalls etwas, das Sie nun selbst modellieren und bauen.
- Formulare. Mit der API kommt kein Formularbaukasten.
- Weiterleitungen und URL-Verwaltung. Ihre Aufgabe.
- Plugin-Ökosystem. SEO-Felder, Sitemaps, Weiterleitungen — alles wird Eigenentwicklung.
- Tempo kleiner Änderungen. „Diesen Abschnitt nach oben" ist keine Redaktionsaufgabe mehr.
Das wiederkehrende Muster enttäuschender Headless-Projekte ist ein Marketingteam, das früher selbst eine Seite ändern konnte und jetzt Tickets schreibt.
Wann headless die richtige Wahl ist#
Es passt zu einer bestimmten Problemform, und außerhalb davon ist es teure Flexibilität.
| Situation | Passung |
|---|---|
| Inhalte in Website und mobiler App | Stark — das ist der Kernfall |
| Mehrere Websites mit einer Inhaltsquelle | Stark |
| Frontend-Anforderungen, die das CMS nicht erfüllen kann | Stark |
| Ein eigenes Frontend-Team existiert bereits | Gut |
| Marketing-Website mit kleinem Team | Schlecht — Sie verlieren Tempo und gewinnen Tickets |
| Inhaltsgetriebene Website mit häufigen Layoutänderungen | Schlecht |
| „Es ist der moderne Ansatz" | Kein Grund |
Der Mittelweg#
Den meisten Websites ist mit etwas zwischen den Extremen besser gedient.
- Traditionelles CMS mit eigenem Theme. Volle Frontend-Kontrolle, und Vorschau und Komposition funktionieren weiter.
- Traditionelles CMS, headless genutzt für eine Oberfläche. Die Website bleibt vom CMS gerendert; die App nutzt eine API.
- Headless CMS mit statischem Generator. Die Redaktion bekommt eine gute Oberfläche, die Website ist statisch und schnell; die Vorschau braucht Arbeit.
- Hybrides CMS. Systeme, die gerenderte Seiten und eine API bieten — oft die pragmatische Antwort.
- Statischer Generator mit git-basiertem Editor. Sehr niedrige Kosten und sehr niedriges Risiko für Inhalte, die überwiegend Dokumente sind.
Ein eigenes Theme auf einem traditionellen CMS gibt Ihnen den größten Teil der Frontend-Freiheit, wegen der Menschen headless gehen — ohne Vorschau, Komposition und Ökosystem aufzugeben.
Häufige Fragen
Ist headless besser für die Performance?
Es kann sein, weil Sie genau kontrollieren, was gesendet wird — aber der Gewinn kommt von statischer Generierung und einem schlanken Frontend, nicht von der API. Ein gut gebautes traditionelles CMS mit ordentlichem Caching und eigenem Theme ist ebenfalls schnell. Performance ist eine Folge der Bauweise, nicht des Speicherorts der Inhalte.
Ist headless besser für SEO?
Bestenfalls neutral und schlechter, wenn Seiten nur im Browser rendern. Alles, was technisches SEO braucht — serverseitig gerendertes HTML, Canonicals, Sitemaps, strukturierte Daten, Weiterleitungen —, müssen Sie bei headless selbst umsetzen, während traditionelle Systeme reife Plugins dafür haben. Headless ist mit Disziplin in Ordnung und ohne sie enttäuschend.
Können Redaktionen bei headless eine Vorschau sehen?
Ja, aber Sie bauen sie: einen Vorschaumodus im Frontend, der Entwurfsinhalte holt und rendert. Planen Sie das ausdrücklich ein. Projekte, die die Vorschau auslassen, enden damit, dass Redaktionen in die Produktion veröffentlichen, um zu sehen, wie etwas aussieht — genau das, was ein CMS verhindern soll.
Was kostet headless im Vergleich zu traditionell?
Die Erstumsetzung ist typischerweise höher, weil Sie das Frontend plus die Funktionen bauen, die ein traditionelles CMS enthielt. Die laufenden Kosten können niedriger sein, besonders mit statischer Generierung. Der größere langfristige Unterschied ist, dass mehr Routineänderungen Entwicklungszeit brauchen — ein fortlaufender Posten, der im Angebot nicht auftaucht.
headless cmstraditionelles cmsheadless vs traditionelljamstackapi first cmscms architektur
