„Und dann kann ich nichts mehr selbst ändern?“ — diese Frage hören wir in fast jedem Migrationsgespräch, sobald das Wort „Headless“ fällt. Sie kommt selten von der Geschäftsleitung, fast immer von den Menschen, die täglich publizieren: der Redaktion. Die gute Nachricht vorweg: Die Sorge ist in den allermeisten Fällen unbegründet. Bei einem Headless-Wechsel bleibt das WordPress-Backend — mit dem die Redaktion arbeitet — vollständig erhalten; was wechselt, ist nur das Frontend, also die Schicht, die Redaktionen ohnehin selten anfassen. Wer heute mit WordPress arbeitet, arbeitet morgen mit demselben Backend weiter. Genau dieses Backend ist der Grund, warum WordPress laut W3Techs im Juni 2026 noch immer rund 41,5 % aller Websites und etwa 59,3 % aller CMS-gestützten Sites antreibt (W3Techs CMS-Marktanteile) — ein Editor, den Millionen Redakteure kennen, geht bei Headless nicht verloren. Wenn Sie zuerst verstehen wollen, was Headless überhaupt bedeutet, liefert der Beitrag was Headless WordPress genau ist die Grundlage; die Übersicht zu Headless WordPress bündelt das gesamte Thema.
Dieser Beitrag betrachtet den Wechsel ausschliesslich aus Redaktionssicht. Nicht die Architektur, nicht das Hosting, nicht die API — sondern die konkrete Frage: Wie fühlt sich das tägliche Arbeiten an, wenn das Frontend nicht mehr WordPress ist? Er ergänzt unsere Analyse der Migrations-Stolperfallen, die den technischen Umzug beschreibt — hier geht es um die Menschen, die danach im System arbeiten.
Was bleibt für die Redaktion gleich?
Bei Headless WordPress bleibt für die Redaktion praktisch der gesamte Arbeitsalltag unverändert: dasselbe Backend, derselbe Gutenberg-Editor, dieselbe Mediathek, dieselben Rollen, Entwürfe und Veröffentlichungs-Workflows. Headless trennt das Frontend vom Backend — und das Backend ist genau das, womit die Redaktion arbeitet. Es bleibt das vertraute WordPress.
Konkret heisst das: Sie melden sich an derselben Adresse mit denselben Zugangsdaten an. Sie sehen dasselbe Dashboard. Sie schreiben im Gutenberg-Editor mit denselben Blöcken — Überschrift, Absatz, Bild, Galerie, Spalten, alles wie gewohnt. Die Mediathek funktioniert unverändert: Bilder hochladen, zuschneiden, Alt-Texte vergeben, wiederverwenden. Entwürfe speichern, später weiterschreiben, geplant veröffentlichen — alles bleibt. Genau dieser Editor ist heute der Standard: Der Gutenberg-Block-Editor wird mittlerweile von über 60 % der WordPress-Installationen aktiv genutzt — gegenüber rund 37 % im Jahr 2020 (Adoptionsdaten zum Gutenberg-Editor 2026). Wer ihn kennt, kennt ihn auch nach dem Headless-Wechsel.
Auch das, was Teams über die reine Texterfassung hinaus brauchen, bleibt erhalten:
- Rollen und Rechte: Administrator, Redakteur, Autor, Mitarbeiter — das gesamte Berechtigungssystem ist Teil des Backends und läuft unverändert. Wer bisher nur eigene Beiträge bearbeiten durfte, darf das auch weiter.
- Freigabe-Workflows: Mehrstufige Reviews, Entwurf-zur-Freigabe-Status, redaktionelle Kommentare — die Plugins und Mechanismen, die das steuern, funktionieren im Backend wie bisher.
- Geplante Veröffentlichung: Beiträge auf ein Datum vorplanen, Embargos setzen, zurückdatieren — unverändert.
- Versionierung: Die Revisions-Historie von WordPress bleibt vollständig erhalten. Frühere Stände lassen sich wie immer wiederherstellen.
Für eine Redaktion, die heute produktiv in WordPress arbeitet, ist das die wichtigste Botschaft: Das Werkzeug bleibt. Es bekommt nur ein neues Schaufenster.
Was ändert sich für die Redaktion wirklich?
Bei Headless WordPress ändern sich für die Redaktion genau drei Dinge: die Live-Vorschau, das Block-Rendering im Frontend und einzelne Customizer-Optionen. Nur die Vorschau verdient echte Aufmerksamkeit — die beiden anderen Punkte merkt ein Team im Tagesgeschäft kaum. Alles, was die eigentliche Inhaltserfassung betrifft, bleibt unverändert.
Ehrlichkeit gehört dazu: Diese drei Dinge ändern sich. Zwei davon merkt die Redaktion im Alltag kaum, eines verdient echte Aufmerksamkeit.
Erstens — die Live-Vorschau. Im klassischen WordPress zeigt der „Vorschau“-Button sofort die fertige Seite im aktiven Theme. Bei Headless gibt es dieses Theme nicht mehr; ein separates Frontend rendert die Inhalte. Damit der Vorschau-Button trotzdem funktioniert, muss er einmalig mit diesem Frontend verbunden werden. Das ist die eigentliche Stolperfalle — dazu gleich mehr.
Zweitens — das Block-Rendering im Frontend. Ein Gutenberg-Block sieht im Editor so aus, wie WordPress ihn standardmässig darstellt. Im Headless-Frontend wird derselbe Block durch eigene Komponenten gerendert, die zum Design der Site passen. Inhaltlich identisch, optisch zum finalen Layout gehörend. Für die Redaktion bedeutet das: Was Sie eingeben, erscheint zuverlässig — die exakte Pixel-Darstellung übernimmt das Frontend, nicht der Editor.
Drittens — eingeschränkte Customizer-Optionen. Theme-Customizer-Einstellungen (Farben, Schriften, Header-Varianten über das WordPress-Menü „Design“) greifen je nach Setup in der Regel nicht, weil das Design im Frontend liegt. Manche Headless-Stacks führen einzelne globale Design-Tokens bewusst wieder aus WordPress heraus; das ist aber eine Architekturentscheidung, kein Automatismus. Für Redaktionen ist das selten relevant — diese Einstellungen werden ohnehin meist beim Aufbau gesetzt und nicht im Tagesgeschäft verändert. Wer regelmässig globale Designparameter selbst anpassen möchte, sollte diesen Bedarf vor dem Wechsel ansprechen.
Headless ändert nicht, wie Sie schreiben — sondern nur, wie Sie das Ergebnis vorab sehen.
Warum ist die Vorschau die eigentliche Stolperfalle?
Die Vorschau ist der einzige Punkt, an dem ein Headless-Projekt aus Redaktionssicht wirklich scheitern kann. Weil der Editor vom Frontend entkoppelt ist, gilt die gewohnte „What You See Is What You Get“-Annahme zunächst nicht mehr. Ein eingerichteter Preview-Modus löst das vollständig — fehlt er, entsteht der schlechte Ruf, den Headless bei manchen Content-Teams hat.
Wenn ein Headless-Projekt aus Redaktionssicht scheitert, dann fast immer an diesem einen Punkt: Die Vorschau wurde nicht eingerichtet — oder schlecht. Das ist die Stelle, an der die Sorge „ich kann nichts mehr selbst kontrollieren“ tatsächlich berechtigt wird, wenn man sie ignoriert.
Der Grund ist eine Erwartungslücke. Viele Redaktionen sind „What You See Is What You Get“ gewohnt: Was im Editor steht, ist exakt das, was später online steht. Bei Headless ist der Editor entkoppelt vom Frontend, also stimmt diese Eins-zu-eins-Annahme zunächst nicht mehr. Ohne Gegenmassnahme heisst das: schreiben, publizieren, auf die Live-Seite wechseln, um das Ergebnis zu sehen — ein Bruch im Arbeitsfluss, der schnell frustriert.
Die Lösung ist Standard und gehört in jedes seriöse Headless-Projekt: ein eingerichteter Preview-Modus. Das moderne Frontend (etwa Next.js) bietet dafür einen Draft- beziehungsweise Preview-Mechanismus, der die unveröffentlichten Inhalte direkt aus WordPress zieht und im echten Design rendert (Next.js Draft Mode Dokumentation). Konkret bedeutet das für die Redaktion: Ein Klick auf „Vorschau“ öffnet die Seite im finalen Layout — inklusive ungespeicherter Entwürfe, ohne dass etwas live geht.
Wie das technisch verdrahtet wird, folgt in unseren Projekten einem wiederkehrenden Muster: Der „Vorschau“-Button in WordPress zeigt nicht mehr auf das Theme, sondern auf eine Draft-Route im Frontend (etwa /api/draft). Diese Route prüft einen geheimen Token — bekannt nur dem Frontend und WordPress, damit niemand ohne Backend-Zugang Entwürfe aufruft —, schaltet den Draft-Modus frei und rendert den Beitrag samt unveröffentlichter Änderungen im echten Design. Für die Redaktion bleibt davon genau ein Klick sichtbar; der Token-Abgleich läuft unbemerkt im Hintergrund.
Richtig umgesetzt verschwindet der Unterschied im Alltag fast vollständig. Die Redaktion klickt auf „Vorschau“ und sieht die fertige Seite — genau wie vorher, nur dass dahinter ein schnelleres, besser strukturiertes Frontend steht. Wo dieser Schritt übersprungen wird, entsteht der schlechte Ruf, den Headless bei manchen Content-Teams hat. Es ist kein Problem der Architektur, sondern eines der Umsetzung.
Klassisch vs. Headless: Was ändert sich pro Aufgabe?
Im direkten Vergleich bleiben bei Headless WordPress alle täglichen Redaktionsaufgaben — schreiben, bebildern, planen, freigeben — identisch zum klassischen Setup. Spürbar verschieben sich nur Vorschau und finale Darstellung, und auch das nur gering, sofern der Preview-Modus sauber eingerichtet ist. Die folgende Übersicht zeigt jede Aufgabe im Seitenvergleich.
| Redaktions-Aufgabe | Klassisch | Headless | Spürbar im Alltag? |
|---|---|---|---|
| Beitrag schreiben (Gutenberg) | Im Backend-Editor | Identisch im Backend-Editor | Nein |
| Bilder verwalten (Mediathek) | Im Backend | Identisch im Backend | Nein |
| Entwürfe und geplante Beiträge | Standard-Workflow | Identischer Workflow | Nein |
| Rollen und Freigaben | Backend-Berechtigungen | Identische Berechtigungen | Nein |
| Live-Vorschau | Sofort im Theme | Über eingerichteten Preview-Modus | Gering, wenn sauber eingerichtet |
| 1:1-Darstellung im Editor | Theme rendert direkt | Frontend rendert die Vorschau | Gering |
| Globale Design-Einstellungen (Customizer) | Im „Design“-Menü | Im Frontend, nicht im Backend | Nur bei Eigen-Anpassung relevant |
Das Muster ist deutlich: Die Aufgaben, die eine Redaktion täglich macht — schreiben, bebildern, planen, freigeben — bleiben gleich. Was sich verschiebt, betrifft allein Vorschau und Darstellung, wie es die rechte Spalte zeigt.
Wie aufwendig ist die Umstellung für das Team?
Für die meisten Redaktionen ist die Umstellung auf Headless WordPress minimal: Wer Gutenberg routiniert bedient, kommt erfahrungsgemäss mit einer Einführung von unter einer Stunde aus. Spürbar wird sie nur in einem Szenario — wenn das Team zuvor mit einem reinen visuellen Page-Builder gearbeitet hat. Dann steht eine andere Denkweise an, kein höherer Schwierigkeitsgrad.
Aus eigenen Schweizer Headless-Projekten 2024–2026 fällt diese Einführung fast immer in dieselbe Stunde: Sie dreht sich um die neue Vorschau-Funktion und um die Frage, wo globale Einstellungen jetzt liegen. Workflow-Plugins, die Teams mitbringen — etwa PublishPress für mehrstufige Freigaben oder Yoast SEO für die redaktionelle Metadaten-Pflege —, laufen im Backend unverändert weiter und müssen nicht neu erlernt werden.
Spürbarer wird die Umstellung in genau einem Szenario: wenn das Team vorher mit einem reinen visuellen Page-Builder gearbeitet hat (etwa Elementor oder Divi), bei dem man Layouts per Drag-and-drop direkt auf der Seite zieht. Headless setzt auf strukturierte Inhalte statt frei platzierte Design-Elemente — das ist eine andere Denkweise, kein anderer Schwierigkeitsgrad. Ein Beispiel macht den Unterschied greifbar: Im Page-Builder baut die Redaktion eine Team-Sektion, indem sie drei Spalten zieht, in jede ein Bild legt, darunter ein Textfeld setzt und Abstände von Hand justiert. Im strukturierten Modell pflegt sie stattdessen pro Person einen Eintrag mit den Feldern Foto, Name und Funktion — die Anordnung als gleichmässiges Raster übernimmt das Frontend. Wer aus der Page-Builder-Welt kommt, gewinnt so Struktur und Konsistenz, gibt aber das freie Pixel-Schieben auf. Das ist eine bewusste Entscheidung, die vor dem Projekt geklärt gehört.
Für die ehrliche Einordnung hilft eine einfache Profil-Tabelle:
| Profil | Umstellung | Warum |
|---|---|---|
| Team arbeitet mit Standard-Gutenberg | Praktisch keine | Editor, Mediathek, Workflow bleiben identisch |
| Team nutzt Custom-Blöcke und Templates | Gering | Vertraute Logik, nur die Vorschau ist neu |
| Team kommt von einem visuellen Page-Builder | Mittel | Wechsel von freiem Layout zu strukturierten Inhalten |
| Einzelne Person publiziert selten | Keine bis gering | Wenig Berührung, kurze Einführung genügt |
Die Botschaft hinter der Tabelle: Für die grosse Mehrheit der WordPress-Redaktionen ist Headless keine Umstellung, sondern Kontinuität mit besserem Frontend. Nur das Page-Builder-Profil verlangt eine echte Anpassung der Arbeitsweise — und auch die ist gut planbar, wenn man sie früh anspricht. Wer abwägen will, ob der Wechsel sich für die eigene Konstellation lohnt, findet im Vergleich von Headless und klassischem WordPress die strategische Einordnung.
Nächster Schritt
Die Redaktions-Frage entscheidet ein Headless-Projekt oft mit — und sie lässt sich vorab klären. Wenn Sie wissen wollen, wie Ihre aktuelle Site beim Thema Performance und Technik dasteht, gibt der kostenlose Website-Check in unter einer Minute eine erste Orientierung, ganz ohne dass Sie Daten preisgeben. Wer tiefer in die Materie einsteigen will, findet in der Themenübersicht zur Headless-Praxis weitere Beiträge aus echten Projekten.
Wenn Sie konkret prüfen möchten, was ein Wechsel für Ihr Redaktionsteam bedeuten würde, besprechen wir das gerne direkt. Vereinbaren Sie ein Erstgespräch — 15 Minuten, kostenlos. Wir klären Ausgangslage, Team-Profil und Vorschau-Anforderungen — und Sie wissen am Ende, ob und wie sich Ihr Redaktionsalltag verändern würde.