Headless klingt modern, WordPress klingt bewährt – beides bringt dich bei der Entscheidung nicht weiter. Die nützlichere Frage ist, wer die Inhalte pflegt, wie viele Ausspielkanäle es gibt und wer das System im Alltag betreibt. Danach fällt die Entscheidung in vielen Fällen deutlich leichter.
Die kurze Antwort
Wenn dein Team Inhalte selbst pflegt, es einen Hauptkanal gibt (die Website) und niemand intern dauerhaft Entwicklungszeit einplant, ist ein klassisches Setup mit WordPress in der Regel die pragmatischere Wahl. Wenn Inhalte in mehrere Ausgabekanäle fließen (Website, App, Displays, Partnerportale), wenn es feste Entwicklungskapazität gibt und die Oberfläche stark individuell sein soll, spricht mehr für einen Headless-Ansatz. Alles dazwischen entscheidest du über den Betrieb: Wer übernimmt Updates, Deployments und Fehler nachts um elf?
Wichtig zur Einordnung: Das ist kein Entweder-oder auf technischer Ebene. WordPress bringt eine REST-API mit, über die Inhalte von anderen Anwendungen abgerufen werden können – WordPress lässt sich also auch headless betreiben. Die Entscheidung ist damit weniger „welches Produkt“ als „welches Betriebs- und Redaktionsmodell“.
Was „headless“ konkret bedeutet
In einem klassischen Setup liefert dasselbe System sowohl die Redaktionsoberfläche als auch die fertige HTML-Seite an den Browser. Vorlagen, Design und Inhalt hängen zusammen. Bei einem Headless-Ansatz trennst du beides: Das CMS verwaltet nur noch Inhalte und stellt sie über eine Schnittstelle bereit, das Frontend ist eine eigenständige Anwendung, die diese Inhalte abholt und darstellt. Der praktische Unterschied ist nicht die Ladezeit oder die Modernität, sondern die Arbeitsteilung. Getrennte Systeme heißen: mehr Freiheit im Frontend, mehr Abstimmung, mehr Teile, die betrieben und aktualisiert werden wollen.
Das wirkt sich direkt auf die Redaktion aus. In einem klassischen System sieht eine Redakteurin beim Bearbeiten meist unmittelbar, wie die Seite aussieht. In einem Headless-Setup ist diese Vorschau ein Feature, das gebaut werden muss – sie entsteht nicht von selbst. Wenn Menschen ohne technischen Hintergrund täglich Inhalte anlegen sollen, ist das ein Punkt, den du früh testen und nicht in die letzte Projektwoche schieben solltest. Was dabei auch immer zur Sprache kommt: Wer soll die Seite später eigentlich pflegen – eine Frage, die schon ins Website-Briefing gehört.
Die fünf Kriterien, die die Entscheidung tragen
Wir empfehlen, Kriterium 1 und 5 doppelt zu gewichten. Prüfe dabei nicht nur Funktionen, sondern auch, wer das System nach dem Start pflegt. Was dazugehört, steht in Website-Wartung: Was regelmäßig geprüft werden sollte.
Vergleich nach Situationen, nicht nach Feature-Listen
| Situation in deinem Team | Spricht eher für klassisches WordPress | Spricht eher für Headless |
|---|---|---|
| Inhalte werden von Marketing selbst gepflegt | Vertraute Oberfläche, direkte Vorschau | Nur mit eigens gebauter Vorschau sinnvoll |
| Ein Hauptkanal: die Website | Ja, geringerer Overhead | Aufwand ohne klaren Gegenwert |
| Inhalte für Website und App gleichzeitig | Möglich über die REST-API | Klarer Vorteil, dafür gedacht |
| Keine feste Entwicklungskapazität | Wartbar mit Agenturunterstützung | Riskant: Frontend braucht dauerhaft Pflege |
| Sehr individuelle Interaktionen geplant | Nur mit erheblichem Aufwand | Mehr Freiheit im Frontend |
| Viele Redaktionsrollen und Freigaben | Über Rollen und Plugins abbildbar | Abhängig vom gewählten CMS |
| Kurzer Zeitrahmen bis zum Start | Meist schneller startklar | Mehr Vorlauf für Konzeption und Aufbau |
| Bestehende WordPress-Inhalte vorhanden | Direkter Weiterbau möglich | Migration und Mapping nötig |
Hypothetisches Rechenbeispiel zum Betriebsaufwand
Die folgenden Zahlen sind frei angenommen und keine Marktpreise oder Erfahrungswerte – sie zeigen nur, wie du selbst rechnen kannst. Angenommen, ihr veranschlagt für ein klassisches Setup pro Monat zwei Stunden Betrieb (Updates, Prüfung, kleine Anpassungen). Für ein Headless-Setup nehmt ihr an, dass CMS und Frontend getrennt aktualisiert werden und ein Deployment-Prozess dazukommt, also drei bis vier Stunden. Über zwölf Monate wären das 24 gegenüber 36 bis 48 Stunden. Multipliziere das mit dem Stundensatz, den du selbst einsetzt, und vergleiche das Ergebnis mit dem Nutzen der Mehrkanal-Ausspielung. Wenn es diesen Nutzen nicht gibt, ist die Rechnung schnell fertig.
Setz denselben Denkweg auch beim Startaufwand an: Wie viele Vorlagen braucht ihr, wie viele davon existieren im gewählten Ansatz schon, was muss von Grund auf gebaut werden. Die eigentliche Kostenfrage liegt häufig im Frontend, nicht im CMS.
Fiktives Beispiel: der Hersteller mit zwei Portalen
Frei erfundenes Beispiel: Ein mittelständischer Hersteller pflegt Produktbeschreibungen bisher in Word und kopiert sie in die Website und in ein Händlerportal. Zwei Personen im Marketing aktualisieren die Inhalte, keine davon programmiert. Es gibt keine interne Entwicklungsabteilung, aber der Wunsch, künftig auch eine Servicetechniker-App mit denselben Texten zu versorgen.
Hier ist die Antwort nicht „Headless, weil mehrere Kanäle“. Sinnvoller ist der Zwischenschritt: Inhalte einmal sauber strukturieren, im bestehenden System als Datenquelle verfügbar machen und die App später über die Schnittstelle anbinden. Damit gewinnt das Team die Mehrfachnutzung, ohne gleichzeitig ein zweites Frontend betreiben zu müssen. Wichtig ist dabei, dass die Website weiter sauber crawlbar bleibt – die Grundlagen dazu stehen in Technisches SEO: Crawling, Indexierung und saubere URLs. Wenn du das bestehende System ausbauen willst, ist das typische Arbeit für eine WordPress-Agentur; geht es um eine eigenständige Anwendung mit individueller Logik, fällt das eher in die Webentwicklung.
Grenzen und häufige Missverständnisse
Headless macht eine Seite nicht automatisch schnell. Geschwindigkeit entsteht durch Bildgrößen, Skriptmenge, Caching und Hosting – das gilt in beiden Ansätzen. Umgekehrt ist WordPress nicht automatisch unsicher oder unflexibel; problematisch werden Installationen, die über Jahre mit Plugins vollgeladen und nicht aktualisiert wurden. Auch die Vorstellung, man könne später „einfach das Frontend austauschen“, stimmt nur, wenn die Inhalte von Anfang an sauber strukturiert sind und nicht als HTML-Blöcke in Textfeldern liegen.
Und: Diese Entscheidung ist reversibel, aber nicht kostenlos. Ein Wechsel bedeutet Inhaltsmigration und neue Vorlagen; ob sich die URLs ändern, ist eine eigene Entscheidung – bleiben sie gleich, entfallen Weiterleitungen. Deshalb ist es besser, die Frage einmal ehrlich anhand deines Teams zu beantworten, als dem allgemeinen Trend zu folgen.
Dein nächster Schritt
Setz dich für 30 Minuten mit der Person zusammen, die die Inhalte tatsächlich pflegt, und lass sie beschreiben, was sie in einer typischen Woche an der Website ändert. Danach beantwortest du die fünf Kriterien oben schriftlich mit je einem Satz. Oft zeigt sich dabei eine Richtung – und wenn nicht, ist das ein Hinweis, dass die technische Frage gerade nicht die wichtigste ist.
Unsicher, welcher Ansatz trägt?
Wir schauen uns dein Redaktions- und Betriebsmodell an und leiten daraus eine Empfehlung ab, statt mit dem System anzufangen.
Zur Webdesign-Agentur
Wissen
