WordPress headless betreiben: Migrationsleitfaden für Next.js

WordPress headless zu betreiben bedeutet: WordPress bleibt der Ort, an dem Redaktionen Inhalte schreiben und verwalten, und das Theme weicht einem eigenständigen Frontend, meist mit Next.js gebaut, das die Inhalte über eine API bezieht. Ihre Redaktion behält die vertraute Verwaltung. Ihre Entwickler:innen erhalten einen modernen Technologie-Stack. Im Gegenzug betreiben Sie zwei Systeme statt eines, und einiges, was WordPress bisher gratis erledigt hat, muss neu gebaut werden.

Dieser Leitfaden erklärt, was sich ändert, wann sich der Wechsel lohnt, wie eine sorgfältige Migration abläuft und was Sie danach budgetieren sollten. Er richtet sich an Gründer:innen und Website-Verantwortliche, die heute WordPress betreiben und den Wechsel abwägen, nicht an Entwickler:innen, die nur ein Code-Beispiel suchen.

Kurz gefasst

• Headless WordPress behält Redaktionsoberfläche und Datenbank, aber eine separate Next.js-Anwendung rendert die öffentlichen Seiten. WordPress erzeugt das HTML Ihrer Website nicht mehr.
• Es lohnt sich bei stark individuellen Frontends, bei Inhalten, die über Web und Apps hinweg genutzt werden, oder bei Teams, die Designänderungen unabhängig ausliefern müssen. Für eine klassische Imageseite oder einen Blog kostet es meist mehr, als es einbringt.
• Verbinden Sie beide Seiten über die REST-API oder WPGraphQL und bauen Sie danach Routing, Vorschau, Formulare, SEO-Angaben und Weiterleitungen selbst auf.
• Migrieren Sie parallel: Bauen Sie das neue Frontend, während die alte Website läuft, prüfen Sie es und schalten Sie erst dann um. Niemals blind umschalten.
• Rechnen Sie mit zwei Hosting-Umgebungen, zwei Codebasen und laufender Wartung auf beiden Seiten.

Was «headless» tatsächlich verändert

In einer klassischen WordPress-Website erledigt ein System alles. Eine Anfrage trifft ein, WordPress lädt Einstellungen, Plugins und das aktive Theme, fragt die Datenbank ab, durchläuft die PHP-Template-Hierarchie und liefert fertiges HTML an den Browser. WordPress.com’s explainer beschreibt genau diesen Ablauf für den gekoppelten Aufbau.

Bei einem Headless-Aufbau erzeugt WordPress keine öffentlichen Seiten mehr. Wie WP Engine’s support documentation es formuliert, bleibt es in erster Linie das Backend für Inhalte und stellt die Daten über eine API einem separat gebauten Frontend zur Verfügung. Der «Head», also das, was Besuchende sehen, ist jetzt eine eigene Anwendung mit eigenem Code, eigenem Hosting und eigenem Veröffentlichungsprozess.

Daraus folgen drei praktische Konsequenzen:

1. Ihr Theme ist weg. Templates, Page Builder und Theme-basierte Widgets lassen sich nicht übernehmen. Das Design wird im neuen Frontend neu gebaut.
2. Plugins teilen sich in zwei Gruppen. Plugins, die Inhalte verwalten (eigene Felder, SEO-Daten, Übersetzungen), funktionieren in der Verwaltung weiter. Plugins, die etwas auf der öffentlichen Seite ausgeben (Formulare, Slider, Kommentarbereiche, viele SEO-Funktionen), brauchen einen Ersatz im Frontend. WordPress.com weist darauf hin, dass viele vertraute Themes, Muster, Kommentare, Formulare und Plugins WordPress.com’s explainer ohne zusätzliche Umsetzung.
3. Ihre Redaktion merkt meist nichts, ausser dass sich Vorschau und einzelne visuelle Bearbeitungsfunktionen anders verhalten, bis Sie diese neu aufbauen.

Sollten Sie überhaupt auf Headless wechseln?

Diese Frage gehört geklärt, bevor eine Zeile Code entsteht. Headless ist ein Tauschgeschäft, und die ehrliche Antwort lautet oft «noch nicht».

Wann es sinnvoll ist

Pantheon’s overview nennt die Fälle, in denen sich Headless auszahlt: stark individualisierte Frontends, Inhalte, die auf mehrere Kanäle verteilt werden, und Frontend-Releasezyklen, die unabhängig vom CMS laufen müssen. In der Praxis sieht das so aus:

• Eine produktähnliche Website mit interaktiven Funktionen, Dashboards oder komplexer Suche, bei der PHP-Templates zur Bremse geworden sind.
• Eine Inhaltsquelle, mehrere Ausgabekanäle. Automattic notes, dass eine einzige WordPress-Installation Websites und mobile Apps gleichermassen versorgen kann.
• Seiten, bei denen Tempo entscheidend ist. Frameworks wie Next.js unterstützen statische Generierung und serverseitiges Rendern, was Pantheon cites als Weg zu besserer Performance. Eine langsame WordPress-Website wird durch Headless aber nicht automatisch schnell. Oft bringen ein aufgeräumtes Theme, besseres Hosting und Caching den grössten Teil des Effekts.
• Sicherheitsrisiken, die Sie verkleinern wollen. Laut WP Engine’s support documentation kann das Entfernen der Theme-Rendering-Schicht die Angriffsfläche der WordPress-Installation verringern. Die Verwaltung muss trotzdem abgesichert werden, und Sie können sie aus dem öffentlichen Internet nehmen oder hinter Zugriffskontrollen legen.
• Frontend-Entwickler:innen, die moderne Werkzeuge wollen. React und Next.js sind deutlich einfacher zu besetzen und zu testen als ein stark angepasstes PHP-Theme.

Der Ansatz wird auch in anspruchsvollen institutionellen Umfeldern eingesetzt. Eine WordCamp Europe 2025 session beschreibt ein Schweizer Berufswahlportal der öffentlichen Hand, das auf Headless WordPress und REST-APIs basiert.

Wann Sie zuwarten sollten

Headless kostet am Anfang und im Betrieb mehr. Automattic schreibt unmissverständlich, dass Automattic notes, weil der Aufbau mehr anfänglichen und laufenden Aufwand erfordert, oft von Spezialist:innen für Backend und Frontend. Ein von HubSpot zitierter WordPress-Referent warnte, es könne eine big investment sein und passe womöglich nicht zu einer neuen Website ohne grosse Kampagne dahinter.

Bleiben Sie bei klassischem WordPress, wenn:

• Ihre Website vor allem aus Seiten und einem Blog besteht und ein gutes Theme den Zweck bereits erfüllt.
• Das Marketing Layouts direkt mit einem Page Builder bearbeitet und auf diese Freiheit angewiesen ist.
• Sie kein Entwicklungsbudget über den ersten Aufbau hinaus haben.
• Ihr Hauptproblem eine langsame, überladene Website ist und nicht eine architektonische Grenze.

Ein einfacher Test: Notieren Sie die drei Dinge, die Sie heute mit WordPress nicht tun können, in den nächsten zwölf Monaten aber tun müssen. Lassen sich diese mit einem Plugin oder einer Theme-Anpassung lösen, brauchen Sie kein Headless. Lautet die Antwort «eine andere Frontend-Architektur», dann wahrscheinlich schon.

Die API wählen: REST oder WPGraphQL

Ihre Next.js-Anwendung braucht einen Weg, Inhalte zu lesen. WordPress bietet zwei Hauptwege, und Vercel’s guide bestätigt, dass beide mit Next.js funktionieren: die REST-API oder WPGraphQL.

	REST-API	WPGraphQL
Verfügbarkeit	In WordPress eingebaut	Kostenloses Plugin zum Installieren
Datenstruktur	Feste Endpunkte pro Inhaltstyp	Sie fragen genau die Felder ab, die Sie brauchen
Verknüpfte Daten abrufen	Oft mehrere Anfragen	Oft eine Anfrage
Lernaufwand	Gering, den meisten Entwickler:innen vertraut	Höher, erfordert GraphQL-Kenntnisse
Passt gut zu	Einfachen Websites, wenigen Inhaltstypen	Komplexen Inhaltsmodellen, vielen Beziehungen

Die REST-API stellt Beiträge, Seiten und eigene Inhaltstypen bereit, ohne dass Sie etwas installieren müssen. WPGraphQL ist ein kostenloses Open-Source-Plugin, das einer WordPress-Website ein erweiterbares GraphQL-Schema und eine entsprechende API hinzufügt. Für eine Website mit einer Handvoll Inhaltstypen reicht REST und hat ein bewegliches Teil weniger. Für eine Website mit eigenen Feldern, Taxonomien und verschachtelten Beziehungen spart GraphQL viele Zugriffe und hält den Frontend-Code aufgeräumt.

Wofür Sie sich auch entscheiden: Entscheiden Sie früh und bleiben Sie dabei. Beides in einem Frontend zu mischen, verdoppelt den Wartungsaufwand.

So läuft eine Migration von WordPress zu Next.js ab

Die folgende Reihenfolge würden wir für eine Unternehmenswebsite wählen. Die Namen der Werkzeuge variieren, die Reihenfolge selten.

Schritt 1: Prüfen, was die heutige Website wirklich leistet

Erfassen Sie jedes URL-Muster, jeden Inhaltstyp, jedes Formular, jedes Plugin, jede Weiterleitung, jede Schnittstelle und jedes Tracking-Skript. Viele Websites hängen still und leise von einem Plugin ab, an das sich niemand mehr erinnert: eine Newsletter-Anmeldung, eine Weiterleitungsliste, ein Sprachumschalter, ein Block mit Schema-Markup. Alles, was nicht auf dieser Liste steht, geht am Tag der Umschaltung kaputt.

Messen Sie ausserdem Ihren Ausgangswert: organischer Verkehr pro Einstiegsseite, Core Web Vitals, Konversionsraten. Sie wollen ein Vorher und ein Nachher haben.

Schritt 2: Inhalte bereinigen und modellieren

Headless legt unsaubere Inhalte offen. Shortcodes in Beitragstexten, Page-Builder-Markup und fest verdrahtete Stile werden in einem neuen Frontend nicht dargestellt. Entscheiden Sie, wie jeder Inhaltstyp gespeichert wird: strukturierte eigene Felder für wiederkehrende Blöcke, sauberer Block-Editor-Inhalt für Artikel. Diesen Schritt unterschätzen Teams, und er dauert oft länger als das Frontend.

Schritt 3: WordPress als Backend vorbereiten

Ein typischer Aufbau beginnt damit, preparing WordPress API access: die gewählte API aktivieren, wo nötig eine Authentifizierung einrichten und eigene Felder bereitstellen. Legen Sie die Verwaltung auf eine eigene Subdomain, beschränken Sie den Zugriff und richten Sie die Domain der öffentlichen Website ausschliesslich auf das Frontend.

Schritt 4: Das Next.js-Frontend bauen

Dieselbe Anleitung von Kinsta beschreibt das Grundmuster: Seiten und dynamische Routen anlegen, die Beiträge abrufen, und die abgerufenen Inhalte darstellen. Darüber hinaus bauen Sie neu auf:

• Routing. Ihre bestehenden URLs müssen erhalten bleiben. Dynamische und Catch-all-Routen können eingehende Pfade auf WordPress-Slugs abbilden, damit /blog/my-post/ weiterhin funktioniert.
• Bilder. Entscheiden Sie, woher Medien ausgeliefert werden, wie sie skaliert werden und welche Formate ausgespielt werden. Next.js bringt eine eigene Bildoptimierung mit, die Sie nutzen können.
• SEO-Angaben. Titel, Beschreibungen, Canonical-Tags, Open-Graph-Daten, XML-Sitemaps und strukturierte Daten muss das Frontend aus den Daten erzeugen, die WordPress liefert. Automattic weist darauf hin, dass Automattic notes, wie es bei einer klassischen Installation der Fall ist.
• Formulare. Kontakt- und Anmeldeformulare brauchen eine neue Verarbeitung, mit Spam-Schutz und Zustellung dorthin, wo die Anfragen landen sollen.
• Suche, Seitennummerierung, Archive und Feeds. Jedes davon ist eine kleine Funktion, für die Sie nun selbst verantwortlich sind.

Schritt 5: Die Vorschau neu aufbauen

Redaktionen erwarten, dass sie auf «Vorschau» klicken und ihren Entwurf sehen. Headless bricht das standardmässig, und Pantheon führt den Verlust eingebauter Funktionen wie der Live-Vorschau als Pantheon’s overview auf. Bauen Sie in Next.js eine Vorschau-Route, die ein sicheres Token akzeptiert und den Entwurf abruft. Testen Sie sie mit der echten Redaktion, nicht nur mit Entwickler:innen. Ist die Vorschau langsam oder unzuverlässig, verliert die Redaktion das Vertrauen in den ganzen Aufbau.

Schritt 6: Festlegen, wie Inhaltsänderungen auf die Live-Website gelangen

Erzeugt das Frontend Seiten im Voraus, muss es erfahren, wann sich Inhalte ändern. Die übliche Antwort ist ein Webhook: Veröffentlicht jemand aus der Redaktion, benachrichtigt WordPress das Frontend, das daraufhin nur die betroffenen Seiten neu baut oder neu validiert. Next.js unterstützt dafür die bedarfsgesteuerte Revalidierung. Die Alternativen sind das Rendern bei jeder Anfrage (immer aktuell, mehr Serverlast) oder eine zeitbasierte Revalidierung (einfach, aber Änderungen erscheinen verzögert). Entscheiden Sie pro Seitentyp: Eine Preisseite, die sofort aktuell sein muss, unterscheidet sich von einem Archiv, das ein paar Minuten hinterherhinken darf.

Schritt 7: Beide Websites parallel betreiben, dann umschalten

Die sicherste Migration stellt das neue Frontend bereit, während die bestehende WordPress-Website weiterläuft, und switches DNS or a reverse proxy, sobald das neue Frontend geprüft ist. Vor der Umschaltung:

1. Crawlen Sie beide Versionen und vergleichen Sie URLs, Titel, Überschriften, Canonical-Tags und strukturierte Daten.
2. Prüfen Sie jede Weiterleitung, auch alte Kampagnen-URLs und das Verhalten bei Schrägstrichen am Ende.
3. Testen Sie Formulare vollständig und stellen Sie sicher, dass Analyse- und Einwilligungswerkzeuge korrekt auslösen.
4. Führen Sie Performance-Tests mit echten Templates durch, auch auf dem Mobilgerät.
5. Halten Sie die alte Website für ein kurzes Rückfallfenster erreichbar.

Migrieren Sie wo möglich Bereich für Bereich statt alles auf einmal. Zuerst den Blog umzuziehen, gibt Ihnen zum Beispiel einen Praxistest der gesamten Kette bei begrenztem geschäftlichem Risiko.

Womit Sie nach dem Start rechnen müssen

Der Aufbau ist der kleinere Teil der Geschichte. Eine Headless-Website besteht aus zwei Produkten.

Wie Kamaan notes, bedeutet ein typischer Aufbau zwei Hosting-Umgebungen: eine für das WordPress-Backend und eine für das entkoppelte Frontend. WordPress.com’s explainer, dass dies mehr Wartung bedeutet, weil Frontend und Backend getrennte Codebasen und Technologien sind. In der Praxis sollten Sie budgetieren für:

• WordPress-Aktualisierungen für Kern, Plugins und PHP, weiterhin nötig, obwohl Besuchende das Theme nie zu Gesicht bekommen.
• Aktualisierungen der Frontend-Abhängigkeiten für Next.js, React und jedes Paket, inklusive Sicherheits-Patches.
• Überwachung beider Seiten sowie der Verbindung dazwischen. Fällt die API aus, liefert die Website möglicherweise veraltete Seiten aus oder bricht ganz ab.
• Unterstützung der Redaktion, da das Veröffentlichen jetzt über eine Kette läuft, die ausfallen kann.
• Entwickler:innen, die beide Welten kennen, oder zwei Parteien, die gut miteinander kommunizieren. Geteilte Verantwortung zwischen einer WordPress-Agentur und einem separaten Frontend-Freelancer ist der Punkt, an dem viele Projekte steckenbleiben.

Wer was wartet, sollte vor dem Start schriftlich festgehalten sein und nicht beim ersten Ausfall herausgefunden werden.

Häufige Fehler

Nur wegen der Geschwindigkeit migrieren. Eine statische Next.js-Website kann sehr schnell sein, eine gut gebaute WordPress-Website aber auch. Machen Sie den Vergleich mit echten Messwerten.

Weiterleitungen und Metadaten vergessen. Verkehrseinbrüche nach einem Plattformwechsel lassen sich fast immer auf geänderte URLs, fehlende Canonicals oder verlorene strukturierte Daten zurückführen.

Inhalte unsauber lassen. Beiträge voller Shortcodes in ein sauberes Frontend zu übernehmen, erzeugt kaputte Seiten. Zuerst aufräumen.

Die Redaktion unterschätzen. Die Menschen, die täglich mit dem System arbeiten, sollten es vor dem Start testen, und ihr Feedback zur Vorschau ist das wertvollste, das Sie bekommen.

Ein Team beauftragen, das wieder verschwindet. Headless-Projekte haben viele bewegliche Teile. Wenn die Personen, die den Umfang definieren, nicht dieselben sind, die bauen, werden die Anforderungen auf halbem Weg neu geschrieben.

Wie wir bei Ampersand vorgehen

Wir sind ein kleines Zürcher Studio, und jedes Projekt wird von der ersten Beratung bis zur Übergabe durchgehend von Senior-Entwickler:innen geführt. Für einen Wechsel von WordPress zu Headless heisst das: Die Person, die Ihre Website prüft und Ihnen sagt, ob Headless der richtige Weg ist, ist dieselbe, die baut und übergibt. Wenn Ihre Anforderungen besser erfüllt sind, indem WordPress bleibt, wie es ist, sagen wir Ihnen das.

Wir bauen Websites, Webanwendungen und Plattformen, übernehmen Systemintegrationen und Plattformwechsel und bieten Audits sowie fachliche Begleitung auf Senior-Niveau an, wenn Sie vor einem Neubau eine zweite Meinung wollen. Unser Ziel ist, dass Sie das Ergebnis selbstständig betreiben können, statt von uns abhängig zu sein. Unsere öffentliche Preisseite listet die Leistungen auf, und die von uns umgesetzten Projekte zeigen, welche Arbeit dahintersteckt. Nach dem Start kostet unser Plan «Run & monitor» für laufende technische Unterstützung CHF 750 pro Monat, unser Plan «Guidance» für beratende Begleitung CHF 799 pro Monat. Plattformwechsel und Aufbauprojekte werden individuell kalkuliert, dafür gibt es deshalb keinen veröffentlichten Preis.

Ein realistischer Entscheidungsweg

Wenn Sie weiterhin unsicher sind, arbeiten Sie diese Reihenfolge ab:

1. Das Problem benennen. Beschreiben Sie die konkrete Grenze, an die Sie stossen, wenn möglich mit Zahlen.
2. Die günstigere Lösung versuchen. Optimieren Sie Theme, Hosting, Caching und Bilder und messen Sie erneut.
3. Einen Bereich prototypisch bauen. Bauen Sie einen einzelnen Seitentyp in Next.js auf Basis Ihrer echten WordPress-Daten. Zwei Wochen Prototyp sagen mehr aus als jeder Artikel.
4. Beide Systeme durchrechnen. Berücksichtigen Sie die Wartung im zweiten Jahr, nicht nur den Aufbau.
5. Gemeinsam mit der Redaktion entscheiden. Erschwert der neue Ablauf deren Arbeit, ist die Architektur für Sie falsch, so elegant sie auch sein mag.

Häufige Fragen

Kann ich meine bestehenden WordPress-Inhalte beim Wechsel zu Headless behalten?

Ja. Die Inhalte bleiben in WordPress und werden über die REST-API oder WPGraphQL bereitgestellt. Arbeit macht meist das Format der Inhalte: Shortcodes, Page-Builder-Markup und Theme-abhängige Gestaltung werden in einem neuen Frontend nicht dargestellt. Planen Sie deshalb einen Bereinigungsdurchgang vor oder während der Migration ein.

Ist Headless WordPress besser für SEO?

Nicht automatisch. Next.js kann schnelle, vollständig gerenderte Seiten ausliefern, was hilft, aber Titel, Canonical-Tags, Sitemaps, strukturierte Daten und Weiterleitungen müssen alle im Frontend neu aufgebaut werden. Eine sorgfältige Migration kann die Rankings halten oder verbessern, eine nachlässige verliert sie.

Brauche ich WPGraphQL, um WordPress mit Next.js zu verbinden?

Nein. Die eingebaute REST-API reicht für viele Websites. WPGraphQL wird attraktiv, wenn Sie viele eigene Felder und Beziehungen haben und diese in einer einzigen Anfrage abrufen wollen, aber es bringt ein Plugin und eine Abfragesprache mit sich, die gepflegt werden müssen.

Kostet Headless mehr als eine normale WordPress-Website?

In der Regel ja. Sie pflegen zwei Codebasen und zwei Hosting-Umgebungen und brauchen Entwickler:innen, die mit beidem vertraut sind. Die Mehrkosten sind gerechtfertigt, wenn die Flexibilität im Frontend, die Auslieferung über mehrere Kanäle oder die Geschwindigkeitsgewinne für Ihr Geschäft zentral sind, nicht wenn es ein Standard-Theme auch täte.

Kann ich schrittweise auf Headless umstellen?

Ja, und das ist oft der sicherste Weg. Sie können das Next.js-Frontend parallel zur laufenden WordPress-Website aufbauen, einen Bereich nach dem anderen umziehen und den Verkehr erst umleiten, wenn das neue Frontend geprüft ist.

Quellen

• WordPress.com’s explainer
• WP Engine’s support documentation
• Pantheon’s overview
• Pantheon cites
• Automattic notes
• big investment
• WordCamp Europe 2025 session
• Vercel’s guide
• WPGraphQL
• preparing WordPress API access
• switches DNS or a reverse proxy
• Kamaan notes