Wie lange dauert eine Headless-WordPress-Migration im Jahr 2026
Sechs bis sechzehn Wochen für typische Projekte. Die Form sind vier Phasen: Analyse, Scoping, Build und Umstellung, Tuning. Die Variablen, die den Plan strecken oder verkürzen, sind Katalogumfang, Anzahl der Integrationen, URL-Erhalt und die Bereitschaft des Redaktionsteams, nicht die Wahl des Frameworks. Alle Wochenspannen in diesem Artikel sind Schätzungen aus unserer eigenen Projektpraxis, keine Marktstudie; der verbindliche Zeitplan entsteht nach der Analyse.
Dieser Artikel ist im Headless-WordPress-Servicepfeiler verankert und gehört zur Entscheidungsmatrix Next.js vs. Astro für die Framework-Frage und zu Cloudflare Workers und WordPress am Edge für die Runtime-Schicht.
TL;DR
- Reine Redaktionsseiten unter fünfzig Seiten: vier bis sechs Wochen.
- WooCommerce mit bis zu wenigen tausend SKUs und Standard-Integrationen: zehn bis vierzehn Wochen.
- Multi-Region oder mehrsprachig mit individuellen Integrationen: vierzehn bis sechzehn Wochen, gelegentlich länger.
- Die teuren Wochen sind das Scoping (Woche eins bis zwei) und der Umstellung (das letzte Wochenende), nicht der Build selbst.
- Die Preisgestaltung ist projektindividuell; wir veröffentlichen den Zeitplan, nicht den Preis.
Welche Phasen hat eine Headless-WordPress-Migration
Die Phasen sind keine Etiketten in einem Gantt-Diagramm; sie bilden unterschiedliche Arbeitsmodi ab, für die unterschiedliche Personen im Raum gebraucht werden.
Phase 1, Analyse (Woche null bis zwei)
Stakeholder, das Redaktionsteam, der Analytics-Verantwortliche und der technische Ansprechpartner durchlaufen drei bis fünf Sitzungen über ein bis zwei Wochen. Die Lieferobjekte sind ein Audit des Content-Modells, eine Performance-Baseline aus dem Live-System (TTFB, TTI, LCP pro Template), ein Inventar von Plugins und Integrationen sowie ein Entwurf der SEO-Migrationskarte.
Das Ergebnis der Analyse ist Entscheidungsinput, keine Architektur. Ein Team, das die Analyse überspringt, um “Zeit zu sparen”, zahlt die Kosten in Woche acht zurück, wenn eine nicht deklarierte Integration auftaucht und der Datenlayer neu entworfen werden muss.
Phase 2, Scoping (Woche zwei bis drei)
Architekturentscheidung: Astro 5+ oder Next.js 15, Wahl des Renderings pro Route, Data-Fetching-Muster (REST oder GraphQL), Strategie zur Cache-Invalidierung. Die Redirect-Map wird hier abgenommen, nicht später. Der redaktionelle Workflow wird finalisiert: Vorschauen, Entwürfe, geplante Veröffentlichungen, Mehr-Autoren-Flows.
Das Scoping endet mit einem schriftlichen Engagement-Letter und einer fixen Liste der Lieferobjekte. Was hier fehlt, wird in Woche zehn zur Change-Order, also zum teuersten Zeitpunkt für eine Umfang-Verhandlung.
Phase 3, Build und Umstellung (Woche drei bis zwölf)
Der Build läuft in Zwei-Wochen-Sprints mit einer wöchentlichen Demo. Jede Demo läuft auf Staging, nicht auf Localhost, damit das Team sieht, wie sich die redaktionelle Seite im neuen Stack tatsächlich verhält. Der erste Sprint umfasst das Designsystem und ein einzelnes Template Ende-zu-Ende; die folgenden Sprints fächern sich nach Template-Typ auf.
Der Umstellung selbst ist ein Fenster von achtundvierzig bis zweiundsiebzig Stunden, bewusst geplant. Zwei Muster funktionieren: DNS-Switch (sauberer, langsamerer Rollback) und Reverse-Proxy-Umstellung (schnellerer Rollback, mehr bewegliche Teile). Die Redirect-Map wird am Edge angewendet, nicht in PHP.
Das parallele Messfenster läuft ein bis zwei Wochen vor dem Umstellung. Es fängt Regressionen bei Tracking-Tags, Schema-Validierung und Core Web Vitals ab, bevor sie produktiv gehen.
Phase 4, Tuning und Wartung (Woche zwölf bis sechzehn)
Die Edge-Cache-TTLs werden pro Route justiert. Observability (Cloudflare Logpush, synthetische Tests, Alerting auf TTFB und 5xx-Raten) wird eingebaut. Die Übergabe in die Wartung deckt neue Feature-Arbeit, vierteljährliche Tech-Radar-Reviews und eine Roadmap für die sich wandelnden Anforderungen des Redaktionsteams ab.
Diese Phase wird am häufigsten ausgelassen. Das Auslassen kostet sechs Monate kleiner Vorfälle, die das Team nicht diagnostizieren kann, weil nichts instrumentiert ist.
Was verzögert eine Headless-WordPress-Migration
Drei Muster verschieben ein Sechs-Wochen-Projekt auf zwölf und ein Zwölf-Wochen-Projekt auf zwanzig.
Spät entdeckte Integrationen. Ein individuelles Payment-Gateway, eine Legacy-ERP-Integration über SOAP, ein Nischen-Plugin ohne REST-Schnittstelle. Jede einzelne braucht einen maßgeschneiderten Adapter. Jeder Adapter bedeutet zwei bis vier zusätzliche Wochen Build, plus Vertragsverhandlungen, falls eine dritte Partei das Upstream-System besitzt.
URL-Erhalt. Eine Site mit dreißig eindeutigen URL-Mustern ist mechanisch. Eine Site mit dreihundert Mustern und einer Permalink-Umstrukturierung ist ein eigenes Projekt. Die 301-Map wird im Scoping abgenommen, nicht in Woche zehn improvisiert.
Umbau des Content-Modells. Wenn die existierenden WordPress-Inhalte um Theme-Templates herum strukturiert sind statt um strukturierte Felder, kann das Frontend sie nicht deterministisch verarbeiten. Der Umbau des Content-Modells fügt zwei bis sechs Wochen hinzu und erfordert eine Verfügbarkeit des Redaktionsteams, die die meisten Teams unterschätzen.
Wie lässt sich eine Headless-WordPress-Migration beschleunigen
Vier Bedingungen verkürzen den Plan zuverlässig.
Sauberes Content-Modell. Custom Post Types, ACF- oder Meta-Box-Feldgruppen oder ein kürzlich erfolgter Umzug auf den Block Editor mit strukturierten Patterns. Das Frontend liest strukturierte Daten und rendert deterministisch. Spart zwei bis vier Wochen.
Vorhandenes Designsystem. Eine Figma-Bibliothek, ein Token-Set oder eine Komponentenbibliothek, die das Team bereits verwendet hat. Spart eine bis zwei Wochen Grundlagenarbeit im ersten Sprint.
Verfügbarkeit des Redaktionsteams. Wenn das Redaktionsteam wöchentlich an Vorschauen teilnehmen und Flows abnehmen kann, stockt der Build nicht beim Warten auf Klärung. Spart eine bis zwei Wochen über das gesamte Projekt.
Senior-Team auf beiden Seiten. Ein Senior-Product-Owner auf Kundenseite halbiert den Frage-Antwort-Zyklus. Die Agentur kann das nicht herstellen; es muss vom Auftraggeber kommen.
Was vor einer Headless-WordPress-Migration zu prüfen ist
Eine Schätzung ohne Inventur ist geraten. Die folgende Liste lässt sich im Backend und in der Datenbank an einem Arbeitstag abarbeiten, bevor jemand einen Termin nennt. Jeder Punkt ist eine Stelle, an der ein klassisches Theme etwas gratis erledigt hat und ein Headless-Build es neu bauen muss.
Inhaltstypen und Taxonomien. Wie viele Custom Post Types und Taxonomien es gibt und welche davon eigene Archive unter indexierten URLs haben. Jeder Typ mit Archiv ist ein eigenes Template und eine eigene Route im Frontend.
ACF-Felder und Meta. Feldgruppen, Repeater, Flexible Content, Beziehungsfelder. Zu prüfen ist, ob sie in der REST API (show_in_rest) oder im WPGraphQL-Schema verfügbar sind. Flexible Content mit einem Dutzend Layouts bedeutet ein Dutzend Komponenten.
Shortcodes und Plugin-Blöcke. Inhalte, die als Shortcode in der Datenbank liegen, kommen im Frontend als roher Text in eckigen Klammern an. Die Vorkommen zählt man mit einer Abfrage auf post_content, bevor man entscheidet, ob sie gerendert oder umgeschrieben werden.
Vorschau und Entwürfe. Ein klassisches Theme hat die Vorschau von Haus aus. Bei Headless muss sie gebaut werden: eine authentifizierte Abfrage des Entwurfs und ein Vorschaumodus im Frontend. Die Redaktion bemerkt das Fehlen in der ersten Woche. Für authentifizierte REST-Anfragen bietet WordPress seit Version 5.6 Anwendungspasswörter: Sie funktionieren über HTTP Basic, sind standardmäßig nur auf Sites mit HTTPS aktiv und erlauben keine Anmeldung in wp-admin (Integrationsleitfaden für Anwendungspasswörter).
Formulare. Contact Form 7 oder Gravity Forms rendern im PHP-Theme. Ohne Theme braucht ein Formular einen Endpunkt, Validierung, Spamschutz und die DSGVO-Einwilligungstexte, die bisher das Plugin ergänzt hat.
Suche. Das eingebaute ?s= verschwindet zusammen mit dem Theme. Zur Wahl stehen ein REST-Suchendpunkt, ein externer Index oder ein statischer Index, der beim Build entsteht. Jede Option hat andere Wartungskosten.
Marktspezifische Checkout-Integrationen. Plugins lokaler Zahlungsanbieter, Abholstationen-Auswahl im Checkout, Bestellexport in Rechnungstools. Diese Plugins sind für einen Checkout geschrieben, den WooCommerce rendert, also müssen sie im Headless-Build gegen die API des Anbieters geprüft werden, nicht gegen den PHP-Code des Plugins. Genau diese Integrationen tauchen im Abschnitt über Verzögerungen zu spät auf.
Weiterleitungen. Ein Export aus dem Plugin “Redirection” oder aus den Regeln in .htaccess, dazu die URL-Listen aus der Sitemap und der Google Search Console. Daraus entsteht die 301-Map, die im Scoping abgenommen wird.
Das Ergebnis ist eine Tabelle mit drei Spalten: Element, wo es heute lebt, wer es neu baut. Zeilen ohne Verantwortlichen sind Wochen, die im Zeitplan noch fehlen.
Wie lange dauert eine Headless-WooCommerce-Migration
Ein WooCommerce-Shop mit dreitausend SKUs und einem individuellen Checkout migriert nicht in sechs Wochen. Wer diesen Zeitplan anbietet, verkauft einen anderen Umfang und verhandelt später nach. Die ehrliche Antwort für dieses Profil sind zwölf bis vierzehn Wochen.
Eine Multi-Region-Site mit fünf Locales und locale-spezifischen Commerce-Flows ist ebenfalls kein Sechs-Wochen-Projekt. Übersetzungs-Workflows, Hreflang-Validierung, locale-spezifische Cache-Strategien und regionsbezogene Payment-Integrationen fügen vier bis sechs Wochen selbst zu einer gesunden Baseline hinzu.
Wie lange dauert eine kleine Headless-WordPress-Website
Eine kleine Redaktionsseite, eine frische WordPress-Installation, ein sauberes Content-Modell und ein Senior-Team können in fünf Wochen ausliefern. Sechzehn Wochen für dieses Profil sind aufgepolsterter Umfang.
Eine Neuprojekt-Headless-Site (keine Migration, nur ein neues Frontend auf einem neuen WordPress) überspringt den Großteil von Phase eins und kürzt Phase drei. Sechs bis acht Wochen insgesamt.
Was kostet eine Headless-WordPress-Migration
Die Preisgestaltung ist projektindividuell. Wir veröffentlichen keine Servicepreise auf der öffentlichen Site. Der Engagement-Letter bindet Stunden an die vier obigen Phasen, mit einer festen Obergrenze auf Phase eins (sie ist durch die Anzahl der Interviews begrenzt, nicht durch etwas, das skaliert) und Abrechnung nach Aufwand oder Festpreis auf Phase drei (je nachdem, wie stabil der Umfang nach dem Scoping ist).
Wir rechnen in EUR oder USD ab, EU-Rechtsraum, B2B-Vertrag. Siehe den Headless-WordPress-Servicepfeiler für das Zusammenarbeitsmodell und die Über-uns-Seite WPPoland für das Team und den EU-Standardrechtsraum.
Wie plant man Go-live und Rollback einer Headless-Migration
Das Fenster von achtundvierzig bis zweiundsiebzig Stunden ist kurz, deshalb fallen die meisten Entscheidungen dafür vorher. Die erste betrifft das Muster. Ein DNS-Switch ist sauberer, der Rollback dauert aber länger. Eine Reverse-Proxy-Umstellung erlaubt einen schnelleren Rollback und bringt mehr bewegliche Teile mit. Welches Muster passt, hängt davon ab, wie teuer eine Stunde Ausfall für die Site ist und wer im Team den Proxy betreuen kann.
Die zweite Entscheidung betrifft die Kriterien für den Rollback. Sie sollten vor dem Wochenende schriftlich feststehen, etwa steigende 5xx-Raten, fehlende Tracking-Tags oder Redirects aus der abgenommenen Map, die ins Leere laufen, damit niemand in der Nacht über Schwellen verhandelt. Das parallele Messfenster ein bis zwei Wochen vorher liefert dafür die Vergleichswerte aus dem alten System.
Die dritte betrifft die Besetzung. Der technische Ansprechpartner und jemand aus dem Redaktionsteam sollten erreichbar sein, weil Probleme mit Vorschauen oder geplanten Veröffentlichungen oft erst auffallen, wenn Redakteure im neuen Stack arbeiten.
Wie man die Dauer einer Headless-Migration selbst abschätzt
Die Variablen, von denen die Projektdauer abhängt, lassen sich prüfen, bevor jemand ein Angebot erstellt. Sie verschieben ein Projekt zwischen sechs und sechzehn Wochen; das Framework macht höchstens eine Woche Unterschied.
- Katalog. Redaktionelle Seiten und SKUs zählen. Eine Site unter fünfzig Seiten ohne Shop ist ein anderes Profil als WooCommerce mit einigen tausend Produkten.
- Integrationen. Alles auflisten, was Daten mit WordPress austauscht: ERP, Payment-Gateway, Plugins ohne REST-Schnittstelle. Jede Position, die erst im Build auftaucht, bedeutet einen eigenen Adapter.
- URL-Muster. Die Adressliste exportieren und nach Struktur gruppieren. Dreißig Muster sind mechanische Arbeit, dreihundert mit einer Permalink-Umstellung ein eigenes Projekt.
- Content-Modell. Prüfen, ob Inhalte in Custom Post Types und ACF- oder Meta-Box-Feldern liegen oder über Theme-Templates verteilt sind.
- Redaktion. Namentlich festlegen, wer auf Kundenseite regelmäßig Vorschauen abnimmt und Fragen des Teams beantwortet.
Mit dieser Liste dienen die ersten Analyse-Sitzungen der Prüfung vorhandener Daten, und es ist schneller klar, zu welchem Profil aus dem TL;DR die Site passt.
Wie man Inhaltstypen und Felder in REST API und WPGraphQL freigibt
Der ACF-Punkt der Checkliste hat einen konkreten technischen Grund. Ein Custom Post Type erscheint erst in der REST API, wenn er mit show_in_rest => true registriert wird. Dieses Argument legt eine Route im Namespace wp/v2 an, und das URL-Segment entspricht standardmäßig dem Namen des Typs, sofern rest_base nicht gesetzt ist (REST-API-Handbuch von WordPress). Taxonomien brauchen dasselbe Argument in register_taxonomy.
WPGraphQL hat einen eigenen Schalter. Ein Inhaltstyp kommt ins GraphQL-Schema, sobald show_in_graphql und graphql_single_name (Camel Case, ohne Leerzeichen, beginnt mit einem Buchstaben) gesetzt sind. graphql_plural_name ist optional, ohne diesen Wert bekommt das Listenfeld das Präfix all (WPGraphQL-Dokumentation). Dieselbe Dokumentation beschreibt eine typische Headless-Falle: Anonyme Anfragen liefern veröffentlichte Einträge nur, wenn public oder publicly_queryable auf true steht. Ein Typ, der als nicht öffentlich registriert wurde, weil das Theme kein Template dafür hat, liefert Daten nur an Nutzer mit Bearbeitungsrecht. Die Dokumentation empfiehlt dann ein explizites publicly_queryable => true.
Deshalb gehören für jeden Inhaltstyp drei Werte in die Inventur der Analyse: show_in_rest, show_in_graphql und publicly_queryable. Fehlt einer, ist das eine Änderung im Registrierungscode, nicht im Frontend.
Wie man eine 301-Redirect-Map für eine Headless-Migration vorbereitet
Google behandelt eine Änderung der URLs als Website-Umzug und empfiehlt serverseitige permanente Weiterleitungen (301 oder 308) von jeder alten URL auf ihr Gegenstück, nach einer vor dem Umzug erstellten Zuordnung. Dieselbe Dokumentation warnt davor, viele alte URLs auf eine einzige unpassende Seite wie die Startseite zu leiten. Weiterleitungen sollen so lange wie möglich bestehen bleiben, in der Regel mindestens ein Jahr. Bei mittelgroßen Sites kann es einige Wochen oder länger dauern, bis Google die neuen URLs statt der alten zeigt, und die Sichtbarkeit in der Suche kann in dieser Zeit schwanken (Google Search Central zum Website-Umzug mit URL-Änderungen).
Wird die Map am Edge angewendet, zählt das Limit der Plattform. Die Datei _redirects bei Cloudflare Pages nimmt bis zu 2.000 statische und 100 dynamische Weiterleitungen auf, insgesamt 2.100, und jede Regel darf höchstens 1.000 Zeichen haben. Größere Maps laufen über Bulk Redirects (Dokumentation von Cloudflare Pages). Deshalb prägt die Zahl der URL-Muster aus der Analyse die Architektur: Dreißig Muster passen als dynamische Regeln ins Limit, Tausende einzelner URLs ohne gemeinsames Muster brauchen einen anderen Mechanismus.
SSG, ISR oder SSR und wie das Rendering die Veröffentlichung beeinflusst
Im Scoping wird das Rendering pro Route festgelegt, und diese Wahl entscheidet, wann eine im WordPress-Backend gespeicherte Änderung auf der Site erscheint. Astro rendert Seiten, Routen und Endpunkte standardmäßig beim Build vor. Eine einzelne Seite wechselt mit export const prerender = false auf Rendering bei Bedarf, und output: 'server' kehrt den Standard für das ganze Projekt um. Beides braucht einen Server-Adapter (Astro-Dokumentation). In einer rein statischen Variante bedeutet jede Veröffentlichung einen neuen Build, also braucht der Redaktions-Workflow einen Build-Auslöser nach dem Speichern eines Beitrags.
Next.js bietet Incremental Static Regeneration. Der Export revalidate legt die Zeit fest, nach der die nächste Anfrage die Neugenerierung der Seite im Hintergrund startet, und revalidatePath sowie revalidateTag invalidieren den Cache bei Bedarf, etwa über einen Webhook beim Veröffentlichen. Die Dokumentation nennt die Grenzen: ISR funktioniert nicht mit einem statischen Export, die Unterstützung in Adaptern hängt von der Plattform ab, und bei mehreren Instanzen ist der Standard-Cache pro Instanz, sodass eine Invalidierung nur die Instanz erreicht, die den Aufruf empfangen hat, solange kein gemeinsamer Cache-Handler konfiguriert ist (Next.js-Leitfaden zu ISR).
Darum werden Vorschau und geplante Veröffentlichungen im Scoping zusammen mit dem Rendering geklärt und nicht am Ende des Builds.
Weiterführende Artikel
Die unterstützenden Artikel im Cluster, nach Thema.
- Cloudflare Workers und WordPress am Edge zur Runtime-Schicht des neuen Stacks.
