Headless WordPress: Entwürfe live vorschauen (Draft Mode)

Es gibt einen Satz, der in fast jedem Erstgespräch über Headless WordPress fällt, sobald die Redaktion mit am Tisch sitzt: «Wenn wir headless gehen, sehen wir unsere Entwürfe nicht mehr, bevor sie live sind.» Es ist der häufigste Einwand gegen den Architektur-Wechsel – und einer der wenigen, der schlicht nicht stimmt. Der Vorschau-Button in wp-admin funktioniert auch headless weiter. Er zeigt nur nicht mehr auf das alte WordPress-Theme, sondern auf eine geschützte Draft-Route im Next.js-Frontend, die den Entwurf im echten, produktiven Design rendert.

Dieser Beitrag erklärt, wie diese Brücke konkret gebaut wird – vom Klick in wp-admin bis zur gerenderten Vorschau im Headless-Layout. Es geht weniger um die generische Next.js-Funktion (die ist gut dokumentiert) als um den WordPress-spezifischen Teil: URL-Umschreibung, Token-Übergabe und die authentifizierte Abfrage unveröffentlichter Inhalte. Wer das grössere Bild sucht – also wie sich der gesamte Redaktionsalltag headless anfühlt –, findet das in unserem Beitrag zu Redaktion und Editor-UX bei Headless WordPress. Wie diese Bausteine ins Gesamtsystem passen, zeigt das Themen-Pillar Headless WordPress.

Verliert die Redaktion bei Headless WordPress die Live-Vorschau?

Nein. Die Vorschau bleibt erhalten – sie wird nur umgeleitet. Der native Vorschau-Button in wp-admin zeigt statt auf das WordPress-Theme auf eine geschützte Route im Next.js-Frontend, die den Entwurf zur Request-Zeit rendert. Editoren merken im Workflow keinen Unterschied, sehen aber das echte Headless-Layout statt des alten Themes.

Der psychologische Effekt ist nicht zu unterschätzen: Der am häufigsten geäusserte Einwand gegen Headless ist zugleich der am leichtesten zu entkräftende. Technisch passiert Folgendes: Ein kleines WordPress-Plugin schreibt die native Preview-URL auf die Frontend-Domain um und hängt die Post-ID sowie einen Token an. Klickt die Redaktion auf «Vorschau», landet sie nicht auf example.com/?p=123&preview=true, sondern auf frontend.example.com/api/draft?id=123&token=….

Wichtig für die Akzeptanz: Das funktioniert nicht nur für neue Entwürfe, sondern auch für ausstehende Beiträge und Revisionen bereits veröffentlichter Seiten. Eine Redakteurin kann also eine Korrektur an einer Live-Seite vorbereiten und sie im produktiven Design prüfen, bevor sie veröffentlicht wird – exakt der Workflow, den sie aus dem klassischen WordPress kennt.

Der häufigste Einwand gegen Headless WordPress ist auch der am leichtesten zu widerlegende: Die Live-Vorschau verschwindet nicht, sie zeigt nur auf eine andere Stelle.

Wie Next.js Draft Mode technisch funktioniert

Draft Mode ist eine offizielle Next.js-Funktion, kein Plugin und kein Hack. Eine Route Handler ruft draftMode().enable() auf und setzt damit das Cookie __prerender_bypass. Solange dieses Cookie gesetzt ist, rendert Next.js die Seite dynamisch zur Request-Zeit statt aus dem Build-Cache – so erscheinen unveröffentlichte Inhalte sofort, ohne einen erneuten Build.

Die API ist schlank. Aus next/headers importiert man draftMode() und arbeitet mit drei Methoden: isEnabled prüft den Zustand, enable() setzt das Cookie, disable() löscht es wieder. Seit Next.js 15 ist draftMode() eine asynchrone Funktion und muss awaited werden; eingeführt wurde die Funktion bereits in Version 13.4.0 (Next.js-Dokumentation, draftMode). In der Seite selbst schaltet man dann anhand von draftMode().isEnabled zwischen der Live-Query und der Draft-Query um – derselbe Seiten-Code, zwei Datenquellen.

Der entscheidende Mechanismus für die Frische der Vorschau: Bei aktivem Draft Mode werden gecachte Funktionen und Komponenten frisch ausgeführt statt aus dem Cache bedient, und die Antworten tragen nicht-cachebare Header (private, no-cache, no-store, max-age=0, must-revalidate) (Next.js-Dokumentation, Draft Mode Guide). Genau deshalb sieht die Redaktion jede Änderung am Entwurf sofort – und genau deshalb landet kein Entwurf versehentlich im CDN-Cache.

Ebenso wichtig wie das Aktivieren ist das saubere Beenden der Vorschau. Eine zweite Route ruft disable() auf und löscht das Cookie wieder; standardmässig endet die Draft-Sitzung ohnehin, sobald der Browser geschlossen wird. Eine praktische Stolperstelle aus der Dokumentation: Verlinkt man die Exit-Route mit der Next.js-<Link>-Komponente, muss prefetch={false} gesetzt sein – sonst löscht ein automatischer Prefetch das Cookie und beendet die Vorschau, bevor die Redakteurin überhaupt klickt (Next.js-Dokumentation, draftMode). Solche Details entscheiden darüber, ob sich die Vorschau im Alltag verlässlich anfühlt oder nicht.

Der WordPress-spezifische Teil: vom Vorschau-Button zur Draft-Route

Der eigentliche Aufwand liegt nicht im Draft Mode selbst, sondern in der Brücke zwischen wp-admin und Next.js. Ein Plugin schreibt die WordPress-Vorschau-URL auf die Frontend-Domain um und hängt einen Token plus die Post-ID an. Die Next.js-Route prüft den Token, aktiviert Draft Mode und leitet auf den richtigen Slug weiter.

Im Detail sendet WordPress Post-ID und Post-Type sowie ein Secret oder einen kurzlebigen Token an die Route. Die Route validiert das Secret, ruft enable() auf und führt einen redirect() auf den Post-Slug aus. Ein Punkt verdient besondere Aufmerksamkeit, weil er eine reale Sicherheitslücke ist: Niemals direkt auf searchParams.slug redirecten. Die offizielle Next.js-Dokumentation empfiehlt ausdrücklich, das Secret zu validieren, den Post anhand des Slugs zu verifizieren und dann auf post.slug zu redirecten – nicht auf den rohen Query-Parameter, sonst entsteht eine Open-Redirect-Schwachstelle (Next.js-Dokumentation, Draft Mode Guide).

Hier liegt auch die ehrliche Positionierung dieses Themas: Das generische Stichwort «Draft Mode» gehört nextjs.org, und ein weiteres Tutorial dazu braucht niemand. Der Mehrwert für ein Headless-WordPress-Projekt ist genau diese WordPress-Glue-Schicht – die Verbindung vom Preview-Button im Backend zur Draft-Route im Frontend. Eine praktische Hürde dabei: Entwürfe haben oft noch keinen sauberen Permalink. Das HeadstartWP-Framework von 10up löst das, indem es serverseitig ein REST-Feld _headless_wp_preview_link ergänzt, das den korrekten Vorschau-Pfad liefert (HeadstartWP-Dokumentation, Previews).

Authentifizierung: unveröffentlichte Inhalte aus WordPress laden

Entwürfe sind nicht öffentlich – WPGraphQL liefert Inhalte mit Status DRAFT nur an authentifizierte Anfragen aus. Die Draft-Route muss sich also als berechtigter Nutzer ausweisen, typisch per JWT oder Headless-Secret. Erst dann gibt WordPress den unveröffentlichten Inhalt oder die Revision für die Vorschau frei.

Das ist kein Sonderfall, sondern Standardverhalten: WPGraphQL behandelt private und unveröffentlichte Inhalte wie das WordPress-Backend selbst – sie sind nur mit Authentifizierung abrufbar. Als Optionen nennt die offizielle Dokumentation das WPGraphQL-JWT-Authentication-Plugin sowie die Cookie-plus-Nonce-Variante; WPGraphQL respektiert dabei die WordPress-Rollen und -Rechte (WPGraphQL-Dokumentation, Authentication and Authorization). Bei JWT authentifiziert das Plugin den Request als angemeldeten Nutzer, sodass die gewohnten Berechtigungsprüfungen greifen (WPGraphQL JWT Authentication). In der Praxis arbeitet man in der Draft-Query mit einem Muster wie asPreview: Boolean, das zwischen Live- und Revisions-Daten umschaltet.

Wie tief diese Authentifizierung im Detail geht – Token-Lebensdauer, Cookie-Nonce-Handhabung, die Unterschiede zwischen den Schnittstellen – behandelt unser Beitrag zu Authentifizierung und Draft-Queries: WPGraphQL vs. REST API. Hier genügt der für die Vorschau relevante Kern: ohne Auth keine Entwürfe, mit Auth der volle, kontrollierte Zugriff. Wer die generelle Angriffsfläche im Blick behalten will, findet die Einordnung im Beitrag zur Sicherheit und Angriffsfläche von Headless WordPress.

Fertige Lösungen: Faust.js vs. HeadstartWP vs. Eigenbau

Sie müssen die Brücke nicht selbst bauen. Faust.js von WP Engine und HeadstartWP von 10up liefern fertige Preview-Handler plus passendes WordPress-Plugin. Ein Eigenbau über den reinen Next.js Draft Mode ist möglich und gibt maximale Kontrolle – gegen mehr Wartungsaufwand. Die Wahl hängt vom restlichen Stack ab, nicht von einer pauschalen Empfehlung.

Faust.js setzt auf das FaustWP-Plugin zusammen mit einem Headless-Secret und einem authorizeHandler; die Vorschau läuft über eine asPreview-Variable in der GraphQL-Query und nutzt die WordPress-Template-Hierarchie (Faust.js-Dokumentation, Post Previews). HeadstartWP verfolgt einen anderen Ansatz: Es nutzt einen kurzlebigen, WordPress-seitig generierten JWT-Token (Default fünf Minuten gültig) und eine Route unter app/api/preview mit dem previewRouteHandler – ein hartkodiertes Secret entfällt damit (HeadstartWP-Dokumentation, Previews). Der Eigenbau schliesslich kombiniert den nativen Draft Mode mit eigener WPGraphQL-Authentifizierung: schlank und ohne Framework-Lock-in, aber jede Zeile davon will gepflegt sein.

Alle drei Wege nutzen letztlich den Next.js Draft Mode unter der Haube – der Unterschied liegt darin, wie viel Brücke schon fertig geliefert wird. Für ein reines App-Router-Setup ohne Framework-Bindung ist der Eigenbau oft der sauberste Weg, weil er keine Framework-Konventionen mitschleppt, die man später nur teilweise nutzt.

Sicherheit: Cookie, noindex und Sitemap-Ausschluss

Vorschau-Routen dürfen nie öffentlich indexiert werden. Drei Pflichtmassnahmen sichern das ab: Das HttpOnly-Cookie __prerender_bypass trägt einen pro Build neu erzeugten, nicht erratbaren Wert und schützt so vor Manipulation, die Draft-Route trägt noindex, nofollow, und sie steht nicht in der Sitemap. So sieht die Redaktion Entwürfe, der Google-Bot aber nie.

Im Einzelnen: Das Cookie __prerender_bypass ist HttpOnly, sein Wert wird bei jedem Build neu und nicht erratbar generiert (Next.js-Dokumentation, draftMode) – ein Angreifer kann eine Vorschau-Sitzung also nicht einfach nachbauen. Die Draft-Route selbst muss auf noindex, nofollow gesetzt werden, sonst landet ein unfertiger Entwurf im Suchindex. Ebenso wichtig: Vorschau-Pfade aus sitemap.ts und llms.txt ausschliessen, damit weder klassische Suchmaschinen noch KI-Suchmaschinen wie ChatGPT, Perplexity oder Gemini den Pfad als kanonisch verstehen.

Zwei weitere Punkte runden die Absicherung ab. Erstens muss die Route den Token oder das Secret prüfen, bevor enable() läuft – andernfalls hätte man einen offenen Cache-Bypass, über den sich jeder das dynamische Rendering erzwingen könnte. Zweitens tragen Draft-Mode-Antworten nicht-cachebare Header (private, no-cache, no-store, max-age=0, must-revalidate) (Next.js-Dokumentation, Draft Mode Guide), sodass kein CDN je einen Entwurf zwischenspeichert. Diese Disziplin ist dieselbe, die auch beim Rendern von Gutenberg-Blöcken im Headless-Frontend gilt: Was nicht öffentlich sein soll, darf an keiner Stelle der Auslieferungskette öffentlich werden.

Ehrlich eingeordnet: wann sich der Aufwand lohnt

Offen gesagt: Diese Funktion sucht kaum jemand aktiv über Google – aber fast jede Redaktion fragt im Gespräch danach. Live-Vorschau ist kein SEO-Thema, sondern ein Vertrauens- und Akzeptanz-Thema. Wer Redaktionen für Headless gewinnen will, muss diesen Einwand vor dem Projekt lösen, nicht danach.

Das macht die Vorschau zu einem klassischen Fall von hohem Geschäftswert bei geringem Suchvolumen. Die Live-Vorschau ist in der Praxis die häufigste Akzeptanz-Hürde bei Redaktions-Teams – und sie ist emotional aufgeladen, weil sie an den alltäglichen Arbeitsfluss rührt. Unsere klare Empfehlung: Den Vorschau-Workflow vor Projektstart demonstrieren, nicht erst beim Go-live. Eine fünfminütige Demo, in der jemand einen Entwurf schreibt, auf «Vorschau» klickt und das produktive Layout sieht, entkräftet den Einwand zuverlässiger als jede Architektur-Folie.

Die Vorschau ist dabei nur ein Baustein eines grösseren Bildes. Wie sich der gesamte Redaktionsalltag headless anfühlt – Blöcke, Medien, Mehrfach-Autoren, Freigabe-Workflows –, behandelt der Beitrag zur Redaktion und Editor-UX bei Headless WordPress im Detail. Die Vorschau ist die Tür; die Editor-UX ist der Raum dahinter.

Nächster Schritt

Ob die Live-Vorschau in Ihrem konkreten Setup über Faust.js, HeadstartWP oder einen schlanken Eigenbau am besten aufgehoben ist, hängt an Ihrem restlichen Stack – und lässt sich in einem kurzen Gespräch sauber einordnen. Wenn Sie eine Headless-Migration planen oder den Redaktions-Einwand im eigenen Team gerade klären müssen, vereinbaren wir gerne ein Erstgespräch – 15 Minuten, kostenlos. Was wir konkret übernehmen – von der Architektur bis zum Redaktions-Onboarding –, zeigt die Übersicht unserer Leistungen für Headless-WordPress-Projekte.