Headless WordPress mit Next.js: Lohnt es sich für Unternehmen?

Etwa alle sechs Monate liest jemand in Ihrer Geschäftsleitung einen Tech-Artikel mit dem Titel „WordPress ist tot, setzen Sie auf Headless mit Next.js“, und die Frage landet auf Ihrem Tisch: „Sollte unsere Website headless werden?“

Die ehrliche Antwort lautet: manchmal ja, oft nein, und der Unterschied ist wichtig, denn eine Fehlentscheidung kostet 15.000 € bis 60.000 €, um sie rückgängig zu machen.

Dieser Ratgeber richtet sich an Marketingleitung, Gründer und technische Verantwortliche in deutschen Unternehmen, die überlegen, von einer klassischen WordPress-Website auf eine Architektur mit Headless WordPress und Next.js umzusteigen. Wir erklären, was „headless“ 2026 tatsächlich bedeutet, wo es glänzt, wo es enttäuscht, was es in Euro kostet und wie die DSGVO die Wahl von Hosting und Infrastruktur beeinflusst.

Was bedeutet „Headless WordPress mit Next.js“ eigentlich?

Bei einer klassischen WordPress-Website speichert dieselbe Installation Ihre Inhalte UND erzeugt die HTML-Seiten, die Ihre Besucher sehen. Redakteure melden sich unter /wp-admin an, schreiben einen Beitrag, und dieselbe PHP-Anwendung erzeugt die <html>-Ausgabe im Browser.

Bei einem Headless-Setup wird das in zwei Teile getrennt:

1. WordPress bleibt Ihr CMS: der Ort, an dem Redakteure Inhalte schreiben, Medien verwalten und die Seitenstruktur pflegen. Die PHP-Anwendung läuft weiter, stellt Inhalte aber als Daten bereit (JSON über die REST-API oder GraphQL über das Plugin WPGraphQL), statt Seiten zu rendern.
2. Next.js wird Ihr Frontend: eine separate JavaScript-Anwendung, die Inhalte aus WordPress abruft und die sichtbaren Seiten erzeugt, entweder beim Build (statisch), bei jeder Anfrage (serverseitig gerendert) oder hybrid mit Incremental Static Regeneration (ISR).

Besucher sehen eine Next.js-Seite. Redakteure sehen das WordPress-Backend. Beide kommunizieren über eine API.

Warum fragen deutsche Unternehmen 2026 nach Headless WordPress?

Einige Treiber halten diese Frage im Mittelstand und in SaaS-Unternehmen am Leben:

• Performance und Core Web Vitals. Next.js mit sauberer statischer Generierung schlägt ein Standard-WordPress-Theme beim Largest Contentful Paint (LCP) und bei der Time to First Byte (TTFB). Das ist für Nutzererlebnis und SEO-Rankings wichtig.
• Angriffsfläche. Ein Headless-Setup verbirgt wp-login.php und xmlrpc.php vor der Öffentlichkeit und reduziert so die Angriffsfläche für Brute-Force-Attacken, die deutsche Hoster ständig sehen, drastisch.
• Recruiting von Frontend-Entwicklern. In Berlin, München und Hamburg finden Sie leichter React- und Next.js-Entwickler als erfahrene WordPress-PHP-Entwickler. Mit Headless setzen Sie Frontend-Talente ein, ohne dass diese PHP lernen müssen.
• Gestaltungsfreiheit. Designer arbeiten mit Tailwind, Radix, Framer Motion und modernen Animationsbibliotheken, ohne gegen die Konventionen von WordPress-Themes anzukämpfen.
• Multi-Channel-Publishing. Eine WordPress-Installation kann Website, mobile App, internes Portal und Partner-Microsite gleichzeitig bespielen, ohne Inhalte zu kopieren.

Das ist alles real. Es ist nur nicht immer für Ihre konkrete Situation relevant.

Wann ist Headless WordPress mit Next.js die richtige Wahl?

Nach einigen Jahren, in denen wir deutsche Kunden bei dieser Entscheidung begleitet haben, lautet die klare Antwort: Headless ist sinnvoll, wenn mindestens zwei Punkte dieser Liste zutreffen.

Müssen Sie Inhalte in mehreren Frontends veröffentlichen?

Ein deutsches SaaS-Unternehmen mit Marketing-Website, In-App-Hilfecenter und mobiler App, die alle dieselben Blog-Inhalte brauchen, profitiert klar von einem einzigen WordPress-CMS für drei Frontends. Ein redaktioneller Ablauf, drei Ausspielwege.

Stoßen Sie mit klassischem WordPress an echte Performance-Grenzen?

Gemeint sind wirklich messbare Grenzen: Seiten, die nach einem echten Performance-Audit, auf einem deutschen Hoster wie Hetzner oder Mittwald, mit WP Rocket und Bildoptimierung immer noch über 2,5 Sekunden LCP liegen. Nicht „fühlt sich langsam an“. Wenn Sie die Arbeit gemacht haben und es immer noch langsam ist, ist Headless eine glaubwürdige Antwort (zusammen mit Änderungen an der Caching-Architektur).

Haben Sie eigene React- oder Next.js-Entwickler?

Wenn Ihr Team bereits React-Frontends für Ihr Produkt baut, kann es mit Headless WordPress auch die Marketing-Website übernehmen: gleicher Stack, gleiche Tools, gleiche Deployment-Pipeline. Arbeitet Ihr Team nur mit PHP, erfordert Headless ein paralleles Know-how, das Sie nicht haben.

Haben Sie ein komplexes individuelles Designsystem?

Marken mit stark individualisiertem Designsystem (eigene Bewegungssprache, individuelle Typografie, besonderes Scrollverhalten) stoßen oft an die Grenzen von WordPress-Themes. Next.js bietet unbegrenzte Freiheit im Frontend, allerdings mit mehr Entwicklungsaufwand.

Haben Sie ein echtes Budget für laufende Frontend-Entwicklung?

Headless-Websites sind in der Wartung teurer als klassische WordPress-Websites. Jede Änderung an einem Inhaltstyp wirkt sich auf das WordPress-Backend UND das Next.js-Frontend aus. Liegt Ihr jährliches Budget für Marketing-Technologie bei 15.000 €, ist Headless vermutlich nicht sinnvoll.

Treffen zwei oder mehr dieser Bedingungen zu, lohnt sich eine ernsthafte Prüfung. Trifft keine oder nur eine zu, lautet die ehrliche Antwort: Eine gut gebaute klassische WordPress-Website mit gutem Caching dient Ihnen besser.

Wann passt Headless WordPress nicht?

Die umgekehrten Fälle kommen mindestens genauso oft vor.

Ihr Team ist nicht technisch und bearbeitet Inhalte visuell

Der klassische Editor und der Block-Editor (Gutenberg) von WordPress sind für nicht technische Redakteure leistungsstark: Bilder ziehen, Blöcke ablegen, live in der Vorschau sehen. Bei Headless wird die Live-Vorschau komplizierter (das Frontend ist eine separate Anwendung), und jeder Block, der im Frontend etwas Besonderes tut, braucht eine eigene Next.js-Komponente.

Das Ergebnis: Redakteure sehen im Gutenberg-Editor Blöcke, die nicht dem entsprechen, was Besucher sehen, bis ein Entwickler jeden einzelnen angebunden hat. Wir haben erlebt, wie Marketingteams innerhalb von drei Monaten nach dem Livegang darüber sehr verärgert waren.

Sie sind auf WordPress-Plugins angewiesen, die HTML im Frontend ausgeben

Viele WordPress-Plugins wie Popup-Builder, Formulare, Social-Sharing, ähnliche Beiträge oder ähnliche Produkte geben HTML direkt im WordPress-Frontend aus. Nichts davon funktioniert bei Headless einfach so. Entweder bietet das Plugin eine Headless-taugliche API (selten bei den Plugins, die Marketingteams lieben), oder es muss als Next.js-Komponente neu gebaut werden.

Ihre Website besteht überwiegend aus Inhalten (unter 200 Seiten) und ist nicht extrem langsam

Für eine mittelgroße Unternehmenswebsite oder einen Content-Blog ist eine optimierte klassische WordPress-Website bei einem deutschen Managed-Hoster (Mittwald, Raidboxes, Hetzner) mit WP Rocket und sauberer Bildoptimierung schnell genug. Headless bringt dann mehr Komplexität und Kosten ohne nennenswerten Nutzen.

Sie haben kein Budget für zwei getrennte Deployments

Sie betreiben und bezahlen dann einen WordPress-Hoster (für das CMS) UND einen Next.js-Hoster (für das Frontend). Build-Pipelines, Monitoring, Fehlerüberwachung: alles doppelt. Das Domain-Routing wird komplexer. Liegt Ihr Hosting-Budget bei 20 € pro Monat, passt das nicht.

Was kostet Headless WordPress mit Next.js in Deutschland?

Ehrliche Preisspannen für 2026 in Euro für ein Projekt mit einem deutschen Unternehmen.

Kosten für die Erstentwicklung

Projektumfang	Deutsche Agentur	Nearshore (PL/RO/UA)	Hinweise
Migration einer bestehenden WordPress-Website mit 30 Seiten auf Headless	18.000–38.000 €	11.000–22.000 €	Inklusive Next.js-Setup, Übernahme des Designs, grundlegende Inhaltstypen
Neue Headless-Marketing-Website (50–80 Seiten)	28.000–60.000 €	17.000–36.000 €	Inklusive Designsystem, CMS-Schema, Page Builder
Komplexes Headless WordPress (100+ Seiten, individuelle Blöcke, mehrsprachig)	55.000–140.000 €+	33.000–80.000 €+	Inklusive individuellem WPGraphQL-Schema, ISR-Strategie, eigenen Gutenberg-Blöcken
Enterprise (Multisite-CMS, mehrere Frontends, mehrere Regionen)	120.000–400.000 €+	70.000–220.000 €+	Mandantenfähig, CDN, Edge Functions, vollständige Observability

Laufende monatliche Kosten

Headless bedeutet zwei Infrastrukturrechnungen statt einer.

• WordPress-Hosting (nur CMS, kein öffentlicher Traffic): 15–80 € pro Monat bei einem kleinen Managed-Hoster oder VPS. Hetzner CX22 oder Mittwald Space S reichen, da nur Redakteure und Ihr Next.js-Build-Prozess darauf zugreifen.
• Next.js-Hosting: 0–500 €+ pro Monat. Der kostenlose Tarif von Vercel genügt bei wenig Traffic, Vercel Pro kostet 20 $ pro Nutzer und Monat für den Produktivbetrieb, oder Sie nutzen Hetzner/AWS EU mit eigenem Deployment für vollständige Datenhoheit. Netlify, Cloudflare Pages und Coolify auf einem Hetzner-VPS sind ebenfalls verbreitet.
• Headless-Plugins: Die meisten sind kostenlos (WPGraphQL, ACF), einige kommerziell (Faust.js, Atlas-Hosting-Pakete): 0–200 € pro Monat.
• Build-Pipeline: GitHub Actions (für kleine Projekte kostenlos), GitLab CI/CD oder Vergleichbares.
• Monitoring: Sentry, Vercel Analytics usw.: 0–100 € pro Monat.

Realistische Infrastrukturkosten insgesamt: 50–250 € pro Monat für eine kleine bis mittelgroße Headless-Website.

Wartung und Weiterentwicklung

Planen Sie jährlich rund 20–30 % der Erstellungskosten für die laufende Entwicklung ein: neue Inhaltstypen, neue Blöcke, Performance-Optimierung, Updates von Abhängigkeiten.

Das Muster, das wir am häufigsten sehen: Kunden planen zu wenig Wartungsbudget ein und haben am Ende ein Frontend, das den Designwünschen des Marketingteams sechs Monate hinterherhinkt.

Wie wirkt sich Headless WordPress auf DSGVO und Datenhoheit aus?

Hier sind zwei Architekturentscheidungen wichtig.

Wo läuft WordPress?

Es gelten dieselben Regeln wie bei einem klassischen Setup. WordPress-Hosting für deutsche Kunden sollte in EU-Regionen liegen: Hetzner (Falkenstein, Nürnberg), Mittwald, Raidboxes, IONOS oder AWS Frankfurt mit unterzeichnetem AVV. Die verborgene WordPress-Installation speichert weiterhin Redakteurskonten, eventuell Formulareinsendungen und Nutzerdaten. Die DSGVO gilt wie immer.

Wo läuft Next.js?

Diese Frage unterschätzen die meisten Teams. Das Standard-Deployment von Vercel wird aus Edge-Regionen in den USA ausgeliefert, sofern Sie keine regionalen Einschränkungen konfigurieren. Für datenschutzsensible Websites, also alles mit Formularen, Login oder E-Commerce, ist das ein Problem.

Drei sinnvolle Optionen:

1. Vercel Enterprise mit fester Region Frankfurt: am schnellsten umgesetzt, erfordert einen Enterprise-Vertrag.
2. Next.js selbst gehostet bei Hetzner oder Mittwald: vollständige Datenhoheit, erfordert DevOps-Kompetenz.
3. Cloudflare Pages mit Beschränkung auf die EU: ein Mittelweg, doch beim Thema Datenhoheit bei Cloudflare haben manche Datenschutzbeauftragte noch offene Fragen.

Für Mittelstandskunden wählen wir standardmäßig Option 2 mit einem unterzeichneten AVV von Hetzner. Das ist nicht trendy, aber gut begründbar.

Was ist mit der Protokollierung von IP-Adressen?

Beide Ebenen (WordPress und Next.js) brauchen Cookie-Banner, Datenschutzerklärung und Analytics, die deutsche Einwilligungsregeln einhalten. Headless vereinfacht das nicht, sondern fügt ein zweites Deployment hinzu, das synchron gehalten werden muss.

Wie lange dauert ein Headless-WordPress-Projekt 2026?

Realistische Zeiträume:

• Migration einer bestehenden kleinen Website (30 Seiten): 6–10 Wochen
• Neue mittelgroße Marketing-Website (50–80 Seiten): 10–18 Wochen
• Komplexes mehrsprachiges Headless WordPress: 4–7 Monate
• Enterprise mit mehreren Frontends: 6–12+ Monate

Das größte Zeitrisiko ist die Treue zum Designsystem. Wenn das Design in Figma geliefert wird und die Next.js-Entwickler jede Mikrointeraktion nachbauen müssen, verschwinden Wochen. Legen Sie das Designsystem fest, bevor die Frontend-Arbeit beginnt.

Wie ist eine Headless-WordPress-Website sinnvoll aufgebaut?

Eine saubere Architektur 2026 sieht so aus:

1. WordPress-Core auf einem kleinen Managed-Hoster oder Hetzner-VPS, nur für Redakteure und den Build-Prozess erreichbar. wp-admin hinter einer IP-Allowlist oder Cloudflare Access. Öffentliche WordPress-Seiten deaktiviert (kein Frontend-Theme).
2. Das Plugin WPGraphQL stellt Inhalte als GraphQL-Endpunkte bereit. Individuelle Felder (ACF Pro) werden über die ACF-GraphQL-Erweiterung ins Schema aufgenommen.
3. Individuelle Gutenberg-Blöcke für ein gutes Redaktionserlebnis. Jeder Block hat eine passende Next.js-Komponente, die ihn im Frontend rendert.
4. Next.js-Anwendung in einem separaten Git-Repository (oder Monorepo), die Inhalte per GraphQL abruft: beim Build (SSG) für dauerhafte Seiten, per ISR für gelegentlich geänderte Inhalte und per SSR für wirklich dynamische Seiten.
5. Webhook von WordPress zum Next.js-Hoster, der bei Inhaltsänderungen einen Rebuild auslöst. So ist eine veröffentlichte Seite innerhalb von 1–2 Minuten live.
6. Bild-Pipeline mit der integrierten Bildoptimierung von Next.js ODER einem separaten Dienst wie imgix oder Cloudinary, wenn Sie Zuschnitte in Echtzeit brauchen.
7. Formulare über einen Headless-tauglichen Formulardienst (Formspree, Plunk, n8n selbst gehostet bei Hetzner) oder über Next.js-API-Routen, die an ein CRM weiterleiten.

Die zwei wichtigsten Designentscheidungen: ISR oder vollständiges SSG (beeinflusst Deploy-Geschwindigkeit und Entwicklerkomfort) und GraphQL oder REST (GraphQL ist bei nicht trivialen Schemas deutlich angenehmer).

Welche Plugins brauchen Sie für Headless WordPress?

Das Wesentliche:

• WPGraphQL: kostenlos, der De-facto-Standard für Headless WordPress. Stellt das komplette WordPress-Schema als GraphQL bereit.
• WPGraphQL for Advanced Custom Fields: bringt ACF-Felder ins GraphQL-Schema.
• Advanced Custom Fields Pro: der Standard für Oberflächen mit individuellen Feldern.
• Yoast SEO: Auch bei Headless brauchen Sie Meta-Titel, Beschreibungen, Canonical-URLs und Schema-Markup. Die Yoast-Daten werden von Next.js abgerufen und ausgegeben.
• WPGraphQL for Yoast SEO: bringt die Yoast-Daten in Ihr GraphQL-Schema.
• Polylang oder WPML, wenn Sie Mehrsprachigkeit brauchen (bei Headless wählen wir meist Polylang, weil WPML zusätzliche GraphQL-Komplexität mitbringt).
• WP Mail SMTP, damit Ihr verborgenes CMS E-Mails zum Zurücksetzen von Passwörtern tatsächlich versendet.

Verzichten Sie auf die meisten frontendorientierten Plugins (Popup-Builder, Page Builder wie Elementor), denn sie lassen sich nicht übertragen. Nutzen Sie nur Plugins für das Backend.

Welche Fehler machen deutsche Unternehmen bei Headless WordPress am häufigsten?

Nach der Prüfung gescheiterter Migrationen dominieren vier Muster.

Das Redaktionserlebnis wird unterschätzt

Für das Marketingteam ist der Editor jetzt die einzige Berührung mit der Website. Funktioniert die Vorschau nicht oder sehen Blöcke im Editor anders aus als auf der Live-Website, wird das Team das System innerhalb weniger Wochen ablehnen. Planen Sie Budget für eine gute Redaktions-UX ein: Live-Vorschau, originalgetreue Block-Vorschauen, Abläufe von Entwurf über Staging bis Produktion.

Formulare werden nicht durchdacht umgesetzt

Formulare sind der am meisten unterschätzte Teil jeder Headless-Migration. Kontaktformulare, Newsletter-Anmeldungen, geschützte Downloads: Jedes braucht einen durchdachten API-Endpunkt, Spamschutz, DSGVO-konforme Einwilligung und CRM-Anbindung. Wir haben erlebt, wie Formulare beim Launch ausfielen, weil das Team annahm, „das WordPress-Kontaktformular-Plugin funktioniert ja weiter“.

Zu viele individuelle Gutenberg-Blöcke

Jeder individuelle Block verdoppelt den Wartungsaufwand: einmal in PHP (WordPress) und einmal in React (Next.js). Beschränken Sie sich auf 10–20 wiederverwendbare Blöcke. Widerstehen Sie der Versuchung, 80 zu bauen.

Der falsche Frontend-Hoster

Vercel in der Standardkonfiguration ist großartig für Prototypen, aber teuer im großen Maßstab und mit der oben beschriebenen Frage der Datenhoheit. Selbst-Hosting bei Hetzner ist günstiger, erfordert aber DevOps-Kompetenz. Entscheiden Sie bewusst, nicht aus Gewohnheit.

Wann ist es sinnvoller, bei klassischem WordPress zu bleiben?

Das Gespräch „Bleiben Sie bei klassischem WordPress“ führen wir häufiger als „Wechseln Sie zu Headless“. Die Anzeichen:

• Ihre Website ist inhaltsgetrieben und hat weniger als 200 Seiten
• Ihr Redaktionsteam ist nicht technisch und arbeitet gern mit dem Gutenberg-Editor, so wie er ist
• Die Ladezeit ist mit gutem Caching akzeptabel (LCP unter 2,5 Sekunden auf einem ordentlichen Hoster)
• Sie haben keine eigenen React-Entwickler
• Ihr jährliches Budget für Marketing-Technologie liegt unter 25.000 €

In diesem Fall investieren Sie klüger in: einen guten deutschen Hoster (Mittwald, Raidboxes, Hetzner), Caching mit WP Rocket oder FlyingPress, Bildoptimierung, einen Wartungsvertrag und Yoast SEO. So erhalten Sie 80 % des Performance-Vorteils von Headless zu 20 % der Kosten.

Zur allgemeinen Frage, ob Sie Plugins selbst entwickeln oder kaufen sollten, lesen Sie unseren Ratgeber zur individuellen WordPress-Plugin-Entwicklung oder sehen Sie sich unsere Leistungen im Bereich Webentwicklung an.

Häufige Fragen zu Headless WordPress mit Next.js

Sollten Sie auf Headless umsteigen?

Die ehrliche Zusammenfassung: Headless WordPress mit Next.js ist eine echte Architektur, die echte Probleme löst: Publishing für mehrere Frontends, echte Performance, kleinere Angriffsfläche und ein besseres Arbeitsumfeld für Frontend-Entwickler. Für das richtige Unternehmen ist es ein großer Schritt nach vorn.

Für das falsche Unternehmen ist es eine 40.000 € teure Methode, die Abläufe des Marketingteams zu zerstören und die Wartungskosten zu verdoppeln.

Wenn Sie in 30 Minuten klären möchten, ob Ihre Situation passt, buchen Sie einen Termin oder senden Sie uns die Details über die Kontaktseite. Wir haben Kunden je nach Ausgangslage schon beide Richtungen empfohlen und sagen Ihnen ehrlich, welche zu Ihnen passt.