WordPress auf Vercel hosten (Headless): Wann es funktioniert und wann nicht

2021 kam ein Client zu mir mit einem Brief, den ich ungefähr vierzig Mal vorher gehört hatte: „Wir wollen das WordPress-Backend, das unsere Redakteure kennen, aber die Website muss schnell sein. Wirklich schnell." Sie hatten etwas über Headless-Architektur auf einer Vercel-Marketing-Seite gelesen. Sie waren verkauft, bevor ich ein Wort sagte. Ich übernahm das Projekt, baute ein Next.js-Frontend auf Vercel, das Inhalte von einer WordPress REST API abrief, und lieferte etwas wirklich Beeindruckendes. Die Lighthouse-Ergebnisse waren wunderbar. Der Client liebte es für etwa drei Monate.fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.

Dann wollte ihr Marketing Manager ein Pop-up-Formular hinzufügen. Dann ein Membership-Plugin. Dann Live-Chat mit bedingter Logik, die an Post-Kategorien gebunden ist. Und langsam, leise, fing das ganze Setup an zu ächzen.

Dieses Projekt hat mir mehr über die echten Grenzen von Headless WordPress beigebracht als jedes Tutorial je könnte. Also lass mich dir das ehrliche Bild geben.

Was „Headless WordPress auf Vercel" tatsächlich bedeutet

Es lohnt sich, hier präzise zu sein, denn Menschen verwenden den Begriff locker.

Du betreibst WordPress (normalerweise auf einem separaten Server, bei einem verwalteten Host wie Kinsta oder WP Engine, oder sogar auf einem günstigen VPS) rein als Content-Management-System. Kein Theme bedient das Frontend. Stattdessen ruft deine Next.js- (oder Nuxt-, oder Astro-, oder SvelteKit-) App Inhalte über die WordPress REST API oder WPGraphQL ab, dann erstellt und deployt Vercel dieses Frontend.Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.

Vercel hostet WordPress selbst nicht. Punkt. WordPress benötigt PHP, eine Datenbank (MySQL) und serverseitige Ausführung. Vercel führt Node.js-Serverless-Funktionen und statische Dateien aus. Du kannst eine WordPress-Installation nicht auf Vercel hochladen, wie du sie auf einen cPanel-Server hochladen würdest.

Wenn also jemand sagt „WordPress auf Vercel hosten", meint er damit eigentlich: Hoste das Frontend auf Vercel, während WordPress irgendwo anders komplett läuft. Dieser Unterschied ist enorm wichtig, und ich bin schockiert, wie oft er in Blog-Beiträgen übergangen wird.frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.

Wann dieses Setup wirklich glänzt

Ich möchte hier fair sein. Ich habe Headless-WordPress- + Vercel-Projekte ausgeliefert, auf die ich wirklich stolz bin, und es gibt spezifische Bedingungen, bei denen sich diese Architektur ihre Komplexität verdient.

Hochverkehrsstarke redaktionelle oder Media-Seiten

Seahawk hatte 2022 ein Projekt für einen Sports-Media-Publisher. Zehntausende Seitenaufrufe pro Tag, Content-Team aus zwölf Personen, Redakteure, die kategorisch weigerten, WordPress zu verlassen. Wir bauten ein Next.js-Frontend auf Vercel mit Incremental Static Regeneration (ISR), eingestellt auf 60-Sekunden-Revalidierungsfenster. An einem großen Spieltag zuckte der ursprüngliche WordPress-Server kaum. Vercels Edge-Netzwerk absorbierte den Traffic-Anstieg ohne ein einziges Gespräch über Skalierung.

Für Seiten, bei denen Inhalte in Batches geändert werden (Artikel gehen live, werden nicht alle zwei Minuten bearbeitet), ist ISR eine brillante Lösung. Du bekommst statische Datei-Performance an der Edge mit hinreichend aktuellem Inhalt.

Seiten, die extreme Frontend-Flexibilität brauchen

Wenn dein Designer benutzerdefinierte Scroll-Animationen, komplexe Component-Übergänge oder ein React-basiertes interaktives Tool mitten auf der Seite will, kämpft ein traditionelles WordPress-Theme dich die ganze Zeit. Ein entkoppeltes Frontend gibt diese Kontrolle dem Developer vollständig zurück. Die Design-Beschränkungen von WordPress-Themes verschwinden einfach.

Entwicklerteams, die bereits tief im Node/React-Ökosystem verwurzelt sind

Wenn dein Team den ganzen Tag React-Apps deployed und PHP wie eine Fremdsprache behandelt, sie in die WordPress-Theme-Entwicklung zu zwingen ist wirklich schmerzhaft. Headless lässt sie in ihrer Welt bleiben und gibt Content-Editoren ein Tool, das sie bereits kennen. Das ist ein echter Produktivitätsgewinn beim richtigen Team.

Der Tooling-Stack, den ich tatsächlich nutze

Wenn ich heute auf Headless WordPress + Vercel gehe, sieht der Stack so aus:

1. WordPress-Host: Kinsta oder Cloudways. Beide kümmern sich um verwaltete MySQL-Backups, ohne dass ich mir Gedanken machen muss. Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
2. GraphQL-Layer: WPGraphQL-Plugin. Es macht Content-Abfragen deutlich sauberer als die REST API für komplexe Post-Typen. WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
3. Frontend-Framework: Next.js. App Router, wenn das Team damit komfortabel ist, Pages Router, wenn wir eine schnellere Übergabe an jemand weniger Erfahrenes brauchen. Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
4. Deployment: Vercel, natürlich. Preview-Deployments pro PR sind allein die Kosten wert. Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
5. On-Demand-Revalidation: WordPress-Webhooks (über ein Custom-Plugin oder Advanced Custom Fields Hooks), die einen Vercel-Revalidation-Endpoint anpingen, wenn Content veröffentlicht wird. WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
6. Vorschau-Content: Das @wpengine/headless-Package oder ein Custom Next.js Draft-Mode-Setup, damit Editoren unveröffentlichte Posts in der Vorschau sehen können, ohne einen Rebuild zu triggern. The @wpengine/headless package or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.

Dieser letzte Punkt zu Vorschauen hat mir länger gedauert, bis ich ihn richtig hinbekommen habe, als mir recht ist, zuzugeben. Editoren erwarten, dass sie auf "Vorschau" in WordPress klicken und genau das sehen, was live geht. Bei einem entkoppelten Setup erfordert das richtige Verdrahtung ungefähr einen ganzen Arbeitstag.

Wo es zusammenbricht (und es bricht zusammen)

Okay. Hier muss ich ehrlich mit dir sein, denn das ist der Teil, den die meisten "Headless ist die Zukunft"-Posts auslassen.

Plugins. So viele Plugins.

WordPresss Stärke kommt aus seinem Plugin-Ökosystem. WooCommerce, Gravity Forms, Membership-Plugins, Booking-Systeme, fortgeschrittene SEO-Tools wie Yoast (ja, Yoast funktioniert noch, aber das Frontend-Rendering seiner Meta-Tags erfordert zusätzliche Verdrahtung), Slider-Plugins, alles, das das Frontend berührt. In einem traditionellen Setup rendert das Plugin PHP direkt in die Seite. In einem Headless-Setup macht es nichts Sichtbares, es sei denn, du hast explizit eine Frontend-Komponente gebaut, um seine Ausgabe zu replizieren.

Ich hatte einen Kunden Ende 2023, der mich mid-project kontaktiert hat (kein Seahawk-Projekt, jemand anderes' Durcheinander, das ich geerbt habe). Sie waren headless gegangen mit guten Absichten und versuchten dann, WooCommerce hinzuzufügen. Was folgte, war eine viermona­tige Umleitung, während wir einen benutzerdefinierten Cart- und Checkout-Flow in React aufgebaut haben, WooCommerce's REST API aufgerufen haben, Stripe-Webhooks manuell gehandhabt haben und im Grunde Räder neu erfunden haben, die WooCommerce bereits gebaut hatte. Der Zeitaufwand war ungefähr dreimal so hoch wie wenn man einfach nur ein traditionelles WordPress + WooCommerce-Setup verwendet hätte.

Headless WooCommerce ist machbar. WooCommerce hat ihre REST API gut dokumentiert. Aber "machbar" und "lohnenswert" sind unterschiedliche Fragen.WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.

Das Vorschau-Erlebnis stimmt nie vollständig überein

Ich habe jetzt sechs oder sieben Headless-WordPress-Projekte gelauncht und ich habe noch nie einen Kunden gehabt, der vollständig zufrieden mit dem Vorschau-Workflow war. Es gibt immer eine Lücke zwischen dem Klicken auf "Vorschau" in WordPress und dem, was tatsächlich rendert. Manchmal ist es ein Draft-Mode-Cookie-Problem. Manchmal ist es ISR-Cache-Timing. Editoren, die aus einem traditionellen WordPress-Setup kommen, finden es desorientierend, und die Beschwerden kommen leise, aber hartnäckig.

Zwei Systeme zum Warten

Das klingt offensichtlich, schleicht sich aber wirklich in Teams ein. Du betreibst nun zwei separate Infrastruktur-Anliegen: den WordPress-Server (mit seinen eigenen Updates, Sicherheits-Patches, Plugin-Konflikten, Datenbank-Backups) und das Vercel-Frontend (mit seiner eigenen Build-Pipeline, Umgebungsvariablen, Serverless-Function-Limits). Wenn etwas um 2 Uhr nachts kaputtgeht, hast du doppelt so viele Orte zum Nachschauen.

Bei Seahawk hatten wir Projekte, bei denen sich ein WordPress-Plugin automatisch aktualisierte und die REST-API-Response-Form stillschweigend änderte, was eine Frontend-Komponente zerstörte. Kein Fehler auf der WordPress-Seite. Einfach nur eine stille Inhaltslücke auf der Live-Site. Diese Art von Fehler ist genuinely schwerer zu fangen als ein klassischer WordPress-Fehler.

Echtzeit-Inhalte sind umständlich

Wenn deine Site Inhalte hat, die sich häufig ändern (denk an Live-Ergebnisse, Aktienkurse, von Nutzern generierte Kommentare, alles was Sub-Minuten-Aktualität braucht), ist ISRs Revalidierungs-Modell ein schlechter Fit. Du landest entweder bei veralteten Daten oder rufst bei jedem Request dein WordPress-Backend auf, was einen großen Teil des Performance-Arguments zunichte macht.

Die Kosten: Was Niemand in den Proposal schreibt

Lass mich konkret über Geld und Zeit sprechen, weil ich gesehen habe, wie Agenturen diese Projekte massiv unterbieten.

• Initiale Build-Overhead: Budgetiere mindestens 30-40% mehr Entwicklungszeit im Vergleich zu einem traditionellen WordPress-Build gleicher Komplexität. Das Gap ist real. Ich habe es über Projekte hinweg verfolgt. Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
• Vercel-Preisgestaltung: Der kostenlose Hobby-Plan reicht nicht für kommerzielle Arbeit. Pro kostet $20/Monat pro Seat, und Bandbreite und Serverless-Function-Execution-Kosten häufen sich auf stark besuchten Sites an. Rechne die Zahlen durch, bevor du dich festlegst. The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
• WordPress-Hosting: Du brauchst immer noch einen zuverlässigen Managed Host. Das sind weitere $30-100/Monat je nach Traffic. Also fällt deine „günstiges Static Hosting"-Erzählung schnell auseinander. You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
• Laufende Wartung: Zwei Plattformen, zwei Sätze potenzieller Probleme. Rechne mit mindestens 20% mehr monatlicher Retainer-Zeit im Vergleich zu einem traditionellen verwalteten WordPress-Setup. Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.

Wann ich es wirklich empfehlen würde

Nach allem, was ich gerade gesagt habe, gibt es konkrete Szenarien, in denen ich einem Kunden würde sagen, dass headless WordPress auf Vercel die Kompromisse wert ist:

• Die Website ist inhaltsreich und leselastig: hauptsächlich Artikel oder Landing Pages, keine Transaktionsflowscontent-heavy and read-heavy: mostly articles or landing pages, not transactional flows
• Das Content-Team kennt WordPress bereits und wird keinen CMS-Wechsel in Betracht ziehenalready knows WordPress and won't entertain switching CMS
• Performance bei Skalierung ist eine echte geschäftliche Anforderung, nicht nur ein nettes Extra
• Das Development-Team ist mit React und moderner JavaScript-Tooling vertraut
• Keine komplexen Plugin-Abhängigkeiten sind in der Anforderung enthalten, oder ihr habt sie explizit ausgeschlossen are in the brief, or you've explicitly scoped around them
• Ein langfristiger technischer Owner ist vorhanden, der beide Seiten des Stacks versteht

Und hier sind die Szenarien, in denen ich Einspruch erheben würde:

• Der Kunde möchte WooCommerce oder eine andere plugin-abhängige Frontend-Funktionalität
• Das Team ist klein und kann den Wartungsaufwand von zwei Systemen nicht tragen
• Redakteure brauchen einen schnellen, vertrauten Preview-Workflow und das Budget zum ordentlichen Aufbau ist nicht vorhanden
• Die Website hat Benutzerkonten, dynamische Personalisierung oder Anforderungen an Echtzeitdaten
• Der Kunde möchte es einfach nur, weil es „modern klingt"

Genau das letzte. Ich höre das häufiger, als mir lieb ist.

Alternativen, die zuerst in Betracht gezogen werden sollten

Bevor ich mich auf diesen Stack einlasse, würde ich zumindest diese Optionen in den Raum stellen:

• Traditionelles WordPress auf einem guten Managed Host: Kinsta, Cloudways oder Rocket.net mit anständigem Caching (WP Rocket oder Nginx FastCGI Cache) bringt dir Lighthouse-Scores in den 90ern, ohne dass du etwas entkoppeln musst. Ich habe gesehen, dass das Clients überrascht, die dachten, sie müssten headless gehen, um schnell zu sein. Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
• Faust.js von WP Engine: Speziell für Headless WordPress gebaut, es erledigt viel der Boilerplate (Preview-Modus, Authentifizierung, Routing), die du dir sonst selbst bauen würdest. Einen Blick wert, wenn du dich auf die Architektur festlegst. Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
• Ein maßgeschneidertes Headless CMS: Wenn dein Team eigentlich nicht das Plugin-Ökosystem von WordPress braucht, könnte etwas wie Sanity oder Contentful einfach besser passen für ein auf Vercel gehostetes Next.js Frontend. Kein PHP-Server zum Warten nötig. If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.

---

FAQ

Kann ich WordPress buchstäblich auf Vercel deployen?

Nein. WordPress benötigt PHP und eine MySQL-Datenbank. Die Infrastruktur von Vercel ist auf Node.js Serverless Functions und statisches Datei-Serving ausgelegt. Du kannst dein Next.js (oder ein anderes JavaScript) Frontend auf Vercel deployen und dieses Frontend Inhalte von einer WordPress-Instanz abrufen lassen, die woanders gehostet wird – aber WordPress selbst läuft auf einem separaten Server.

Schadet Headless WordPress meinem SEO?

Nicht von Natur aus, aber es kann schaden, wenn du es unvorsichtig einrichtest. Mit Next.js bekommst du Server-Side Rendering und Static Generation, beide erzeugen vollständig gerendertes HTML, das Suchmaschinen ohne Probleme indexieren können. Die Risikobereiche sind Meta-Tag-Handling (die Ausgabe von Yoast muss von deinem Frontend explizit konsumiert und gerendert werden) und Sitemap-Generierung (du wirst eine dynamische Sitemap-Route in Next.js bauen wollen, die Daten von WordPress abruft). Wenn du diese richtig hinbekommst, ist SEO kein Problem.

Reicht der kostenlose Plan von Vercel für ein Headless WordPress Frontend?

Für ein persönliches Projekt oder einen Prototyp möglicherweise. Für eine kommerzielle Website, nein. Der Hobby Plan verbietet kommerzielle Nutzung in Vercels Bedingungen, und du wirst die Limits für Serverless Function Invocations bei jeder Website mit echtem Traffic überschreiten. Plane den Pro Plan von Anfang an ein.

Wie handle ich WordPress Preview Mode in Next.js?

Next.js hat einen eingebauten Draft Mode (früher Preview Mode im Pages Router). Das Muster ist: Erstelle eine /api/preview Route in Next.js, die ein Preview-Cookie setzt, dann konfiguriere einen WordPress „Preview"-Button, um diese Route mit einem Secret Token aufzurufen. Wenn das Cookie vorhanden ist, rufen deine Page Components Entwurfsinhalte direkt von WordPress ab statt der gecachten statischen Version. WPGraphQL unterstützt Draft-Post-Queries nativ, weshalb ich es für diesen speziellen Flow dem REST API vorziehe./api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.

Wie sieht es mit Formularen und Kontaktseiten aus?

Formulare gehören zu den sauberen Plugin-zu-Headless-Migrationen. Eine Gravity Forms-Einreichung kann direkt an die Gravity Forms REST API posten. Alternativ kannst du WordPress-Formulare ganz überspringen und etwas wie Netlify Forms verwenden (obwohl du auf Vercel bist) oder eine direkte Formspree-Integration im Frontend. Ehrlich gesagt greife ich bei Formularen normalerweise zu Formspree und bin damit an einem Nachmittag fertig.Formspree and call it done in an afternoon.

---

Headless WordPress auf Vercel ist eine echte Architektur mit echten Use Cases. Es ist kein Allheilmittel und kein Gimmick. Die Teams, die das Meiste daraus herausholen, sind diejenigen, die klar im Blick hatten, was sie aufgeben, die Zeit für das zusätzliche Bauen eingeplant haben und ein spezifisches Performance- oder Flexibilitätsproblem lösten. Wenn das nach deinem Projekt klingt, lohnt es sich. Wenn nicht, spar dir die Komplexität.