Ein Kunde rief mich 2021 an, eine Immobilienfirma, anständiges Budget, hatte gerade ihre vorherige Agentur gefeuert. Das Briefing war einfach: Ihr Listings-Portal neu aufbauen. Der ausscheidende Dev hatte acht Monate damit verbracht, eine maßgeschneiderte Next.js-Anwendung zu scaffolden. Sah in Demos brillant aus. Konnte nicht von einer einzelnen Person in ihrem Team ohne Pull Request und Deployment Pipeline aktualisiert werden. Der Makler, der die Listings verwaltete, nutzte als Ausweichweg ein Google Sheet.
Kernaussage: WordPress gewinnt, wenn Redakteure Autonomie brauchen und sich Inhalte täglich ändern; Next.js gewinnt, wenn die Site ein Produkt mit Engineering dahinter ist. Das Team entscheidet, nicht das Framework.
Ich habe es in etwa sechs Wochen in WordPress mit Advanced Custom Fields Pro neu aufgebaut. Seitdem verwalten sie es selbst.
Diese Geschichte ist kein Argument gegen Next.js. Es ist ein Argument dagegen, ein Tool zu wählen, bevor man das Problem verstanden hat. Ich habe das Gegenteil auch gemacht, einem Kunden eine WordPress-Multisite übergeben, obwohl sie eine richtige React-gesteuerte Anwendung brauchten, und dann 18 Monate später dabei zusehen, wie sie unter der Last zusammenbricht.
Nach dem Bau von über 12.000 Websites bei Seahawk Media kümmere ich mich nicht mehr darum, welches Framework „gewinnt". Mir ist wichtig, welches ausgeliefert wird, performant läuft und dich nicht um 23 Uhr am Sonntag heimsucht.
---
Der ehrliche Zustand beider Technologien im Moment
WordPress treibt über 43% des gesamten Webs an. Diese Zahl wird so oft herumgeworfen, dass sie ihre Bedeutung verloren hat, aber bleib einen Moment dabei. 43 Prozent. Das ist keine Legacy-Trägheit, das ist Netzwerkeffekt, Plugin-Ökosystem, Hosting-Infrastruktur und zwei Jahrzehnte institutionelles Wissen, das auf jedem gemeinsam genutzten Server auf dem Planeten eingebacken ist.
Next.js ist unterdessen zum dominierenden React-Framework für Production-Anwendungen geworden. Vercels Nutzungsdaten von 2023 zeigten, dass es hunderte Milliarden Anfragen pro Monat verarbeitet. Der in Next.js 13 eingeführte App Router veränderte, wie Menschen über Server Components denken, und ja, er machte auch viele vor 2023 veröffentlichte Tutorials kaputt, was immer noch Verwirrung in Discord-Servern überall verursacht.
Aber hier ist der Punkt: Diese beiden Technologien sind nicht wirklich Konkurrenten auf die Weise, wie Twitter-Debatten sie wirken lassen. WordPress ist ein CMS mit einer Theme-Schicht. Next.js ist ein React-Framework mit optionaler CMS-Integration. Das Venn-Diagramm dessen, worin sie wirklich gut sind, hat sehr wenig Überschneidung, sobald man spezifisch über Anforderungen wird.
---
Wo WordPress wirklich unschlagbar ist
Inhaltsreiche Websites, die von Nicht-Entwicklern verwaltet werden
Ich werde direkt sein. Falls dein Kunde ein Marketing-Team, einen Content Manager oder jemanden hat, der ohne Code-Berührung veröffentlichen muss, ist WordPress fast immer die richtige Antwort. Der Gutenberg-Editor, mag man ihn oder nicht (ich habe seit 2018 eine komplizierte Beziehung dazu), gibt nicht-technischen Nutzern ein Block-basiertes Editing-Erlebnis, das tatsächlich funktioniert.
Nichts im React-Ökosystem kommt aus der Box an WordPress's Editorial-Erlebnis heran. Sanity.io hat ein schönes Studio, Contentful ist solide für strukturierte Inhalte, aber keine der beiden hat das Plugin-Ökosystem oder die Suchmaschinen-Vertrautheit von WordPress. Ihr durchschnittlicher Marketing-Hire hat WordPress schon mal benutzt. Sie haben ein Headless CMS nicht benutzt.
Plugin-Ökosystem-Tiefe
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Das sind nicht einfach nur Plugins, das sind ganze Plattformen mit ihren eigenen Ökosystemen. Wenn Seahawk ein E-Commerce-Projekt für einen Kunden mit einem bescheidenen Katalog macht (sagen wir, unter 5.000 SKUs), handhabt WooCommerce zusammen mit einem anständigen Hosting-Setup auf Kinsta oder WP Engine das gut. Wir sprechen von Sub-2-Sekunden-Ladezeiten nach dem Caching, vollständige Lagerverwaltung, Warenkorbabbruch-Wiederherstellung, Stripe-Integration, alles an einem Nachmittag konfiguriert.
Diese Funktionalität in einem benutzerdefinierten Next.js-Build mit Shopify oder einer Headless-Commerce-Schicht zu replizieren? Das bedeutet Wochen an Entwicklungszeit und laufende Wartungskosten, die sich die meisten SME-Kunden nicht leisten können.
Budget- und Zeitplan-Realitäten
Ehrlich gesagt haben die meisten Projekte nicht das Budget für eine maßgeschneiderte React-Anwendung. Eine gut gebaute WordPress-Seite mit einem Premium-Theme wie Kadence oder Blocksy, ACF für benutzerdefinierte Datenstrukturen und WP Rocket für Performance kann in zwei bis vier Wochen geliefert und von fast jedem gepflegt werden. Das ist keine Einschränkung, das ist Pragmatismus.
---
Wo Next.js seine Komplexität wirklich verdient
Interaktivität und Anwendungslogik
Im Jahr 2022 hatte Seahawk ein Fintech-Projekt, ein Dashboard für ein Unternehmen aus dem Bereich Kreditanalytik. Echtzeit-Datenströme, komplexe Filter, rollenbasierte Zugriffskontrolle, API-Integrationen mit drei verschiedenen Datenanbietern. Ich habe mir headless WordPress etwa zwei Stunden lang angesehen, bevor ich zugeben musste, dass es das völlig falsche Werkzeug war. Wir haben es in Next.js mit NextAuth.js für die Authentifizierung und React Query für das Datenabrufen gebaut. Es läuft immer noch, ist immer noch schnell, und die Codebasis ist etwas, zu dem das interne Team des Kunden tatsächlich beitragen kann.
WordPress kann technisch gesehen anwendungsähnliche Dinge tun. Aber jedes Mal, wenn ich versucht habe, es wirklich in dynamisches Gebiet zu drängen – denk an mehrstufige Formulare mit bedingter Logik, die in externe APIs fließt, Echtzeit-Dashboards, alles, das eine differenzierte clientseitige State-Verwaltung erfordert – bin ich am Ende gegen die Architektur ankämpfen, nicht mit ihr arbeiten.
Performance in großem Maßstab ohne Plugin-Abhängigkeit
Next.js mit Static Site Generation (SSG) oder Incremental Static Regeneration (ISR) kann Seiten erzeugen, die geradezu beschämend schnell sind. Keine Caching-Plugins erforderlich. Keine WP Rocket-Konfigurationsdrehschrauben. Die Seiten sind einfach... statisches HTML mit Hydration wo man sie braucht.
Vercels Dokumentation zu ISR erklärt den Mechanismus gut, aber die praktische Konsequenz ist diese: Eine Next.js-Website für eine Nachrichtenseite mit 50.000 Artikeln kann einzelne Seiten nach einem Plan neu validieren, ohne die gesamte Website neu zu bauen. Das ist echte Power und etwas, das WordPress nur durch Fragment-Caching annähernd erreicht.
Developer Experience und Team-Zusammensetzung
Wenn du eine Agentur mit einem React-native-Entwicklungsteam bist, hat WordPress-Entwicklung eine echte Lernkurve, die oft unterschätzt wird. PHP, die WordPress-Template-Hierarchie, die Hook-Architektur, das functions.php-Kaninchenloch – es ist nicht schwierig, aber es ist anders. Ich habe talentierte JS-Entwickler eingestellt, die sich eine WordPress-Theme-Codebasis angesehen haben und sich die ersten zwei Wochen verloren gefühlt haben.
Umgekehrt, wenn dein Team in TypeScript und React lebt, ist ein Next.js-Projekt mit einem Headless-CMS wie Contentful oder Sanity eine angenehmere Umgebung. Der Code ist testbar, die Types sind explizit, und der Deployment-Workflow über Vercel oder Netlify ist wirklich gut.
---
Der Headless-WordPress-Mittelweg (Und seine eigentlichen Probleme)
Viele Agenturen sind bei „headless WordPress" gelandet als Kompromiss, WordPress als CMS-Backend, Next.js als Frontend. Das Pitch klingt perfekt. Das Editorial-Team behält seine vertraute Oberfläche; Entwickler bekommen einen modernen Frontend-Stack.
In der Praxis? Es ist wirklich nützlich in spezifischen Situationen und ein echtes Kopfzerbrechen in anderen.
Die guten Fälle:
- Große Publishing-Plattformen, bei denen der Editorial-Workflow nicht verhandelbar ist, aber Frontend-Performance auch eine harte Anforderung darstellt
- Organisationen, die bereits in WordPress-Infrastruktur investiert haben und das Frontend modernisieren möchten, ohne Content-Teams umzuschulen
- Websites mit komplexen Content-Beziehungen, die von ACFs Datenmodellierung profitieren, aber React für die Anzeigeschicht benötigen
Die eigentlichen Probleme:
- WPGraphQL ist ausgezeichnet, aber das Debuggen von GraphQL-Query-Performance im WordPress-Kontext ist schmerzhaft. Du fügst eine Komplexitätsebene hinzu, die dich beißen kann.
- Die Preview-Funktion für Redakteure, die einen Entwurfsbeitrag auf dem Next.js-Frontend sehen, ist eine konstante Quelle von Bugs. Ich habe über mehrere Projekte verteilt Tage damit verschwendet.
- Das Betreiben von zwei separaten Systemen bedeutet zwei separate Fehlerpunkte, zwei Sätze von Infrastrukturkosten und zwei Deployment-Pipelines zum Verwalten.
- Echtzeit-Features sind immer noch unbeholfen. Du bekommst WebSockets nicht aus einer WordPress REST API heraus, ohne erhebliche zusätzliche Arbeit.
Headless WordPress ist keine magische Mittelposition. Es ist eine dritte Option mit ihren eigenen Trade-offs, und es macht nur Sinn, wenn die spezifischen Anforderungen die Komplexität wirklich rechtfertigen.
---
Wie ich wirklich entscheide (meine echte Checkliste)
Nach genug Projekten habe ich das auf eine schnelle Reihe von Fragen reduziert, die ich vor dem zweiten Kundenanruf stelle.
Tendiere zu WordPress, wenn:
- Der Kunde oder sein Team Inhalte unabhängig verwalten muss
- Das Projekt hauptsächlich aus Inhalten und Marketing-Seiten besteht (auch wenn diese komplex sind)
- Das Budget unter £20K liegt und die Zeitleiste unter acht Wochen
- E-Commerce benötigt wird, aber der Katalog liegt unter etwa 10.000 Produkten
- Der Kunde nutzt bereits WordPress und eine Migration hat keinen echten Zweck
Tendiere zu Next.js, wenn:
- Das Projekt erhebliche interaktive oder anwendungsähnliche Anforderungen hat
- Das Team besteht hauptsächlich aus JS/React-Entwicklern
- Du brauchst präzise Kontrolle über die Rendering-Strategie (SSG, SSR, ISR pro Route)
- Das Frontend-Design-System ist maßgeschneidert und React-komponenten-getrieben
- Es gibt einen echten Grund, um eine moderne Headless-CMS wie Sanity oder Contentful zu integrieren
- Langfristig möchte der Klient das Frontend selbst mit hausinternen JS-Entwicklern besitzen und erweitern
Und ein paar Warnsignale, bei denen du innehalten solltest, egal in welche Richtung du dich neigst:
- Ein Kunde, der Next.js verlangt, weil er gelesen hat, dass es „moderner" ist, das ist keine Anforderung.
- WordPress wählen, weil es „einfacher" ist, wenn das Projekt wirklich Anwendungslogik braucht
- Jemand, der den Ausdruck „zukunftssicher" als Rechtfertigung verwendet, ohne zu artikulieren, was die Zukunft wirklich erfordert
---
Leistung: Lassen Sie uns echte Zahlen verwenden
Hier läuft das Gespräch oft schief. Menschen werfen Lighthouse-Scores herum, als würden sie die ganze Geschichte erzählen.
Eine gut optimierte WordPress-Site, anständiges Hosting, WP Rocket oder FlyingPress, WebP-Bilder, ein richtig gebautes Theme, erreicht routinemäßig 90+ auf PageSpeed Insights. Seahawk hat WordPress-Sites konsequent mit 95+ ausgeliefert. Das ist keine Magie; es ist einfach richtige Konfiguration.
Eine schlecht konfigurierte Next.js-App mit Client-seitigen Datenabrufen überall, nicht optimierten Bildern und ohne richtige Caching-Strategie erreicht die 50er. Ich habe das gesehen.
Der Unterschied zwischen einer "schnellen WordPress-Site" und einer "schnellen Next.js-Site" ist deutlich kleiner als Framework-Anhänger behaupten. Googles Untersuchungen zu Core Web Vitals zeigen klar: Die verwendete Technologie spielt eine viel kleinere Rolle als die Qualität der Umsetzung. Was Sites wirklich ausbremst, sind meist Bilder, render-blocking-Ressourcen und langsame Server-Responses. Und das sind keine WordPress- oder Next.js-Probleme.
Was Next.js tatsächlich bietet, ist mehr Kontrolle über die Performance. Du kannst präzise Entscheidungen pro Route treffen, wie Daten abgerufen und wann Seiten gerendert werden. Aber Kontrolle hilft dir nur, wenn du sie richtig einsetzt.
---
SEO: WordPress Hat den Ökosystem-Vorteil, nicht den inhärenten Vorteil
Hier ist ein Missverständnis, das ich regelmäßig korrigieren muss: WordPress ist nicht von Natur aus besser für SEO. Next.js-Apps mit richtigem Server-Side-Rendering sind vollständig von Google crawlbar. Die <Head>-Komponente, Sitemap-Generierung via next-sitemap, strukturierte Daten via JSON-LD, das ist alles erreichbar.
Was WordPress hat, sind Yoast SEO oder Rank Math, die nicht-technischen Benutzern eine visuelle Oberfläche zur Verwaltung von Meta-Titeln, Beschreibungen, kanonischen URLs und Schema-Markup geben. Das ist ein redaktioneller Workflow-Vorteil, kein technischer.
Wenn die Site von Entwicklern verwaltet wird, die Meta-Tags und strukturierte Daten verstehen, ist Next.js SEO nicht schwerer zu implementieren. Wenn die Site von einem SEO-Berater oder Marketing-Manager verwaltet werden muss, der Seitentitel ändern kann, ohne ein Ticket einzureichen, gib ihnen WordPress.
---
FAQ
Ist WordPress alt und wird es durch moderne Frameworks ersetzt?
WordPress wird seit mindestens 2014 „ersetzt", als ich das Argument zum ersten Mal ernsthaft gehört habe. Es ist nicht passiert und ich erwarte nicht, dass es passiert. Die Frage ist nicht, ob WordPress modern ist, sondern ob es das Problem löst, das du hast. Für einen großen Teil der Websites ist das der Fall. Automattic investiert weiterhin massiv in Gutenberg und die Full Site Editing Experience. Es entwickelt sich weiter, nur nicht auf eine Weise, die Twitter-Feeds begeistert.
Kannst du WordPress als Backend mit einem React-Frontend nutzen?
Ja, das ist Headless WordPress, und ich habe die Trade-offs oben behandelt. Die Kurzversion: Nutze WPGraphQL oder die REST API, um Inhalte bereitzustellen, baue dein Frontend in Next.js. Es funktioniert. Es addiert auch Komplexität. Mach es nur, wenn die Anforderungen das wirklich verlangen, nicht weil es architektonisch interessant klingt.
Wie lange dauert es, eine Next.js-Website im Vergleich zu WordPress zu bauen?
Hängt wirklich vom Umfang ab, aber für eine vergleichbare Marketing-Website dauert Next.js typischerweise 40-60% länger für die initiale Entwicklung. Du schreibst Komponenten von Grund auf neu, richtest ein Design System ein, integrierst ein CMS und konfigurierst das Deployment. WordPress mit einem Premium-Theme und ACF bringt dich viel schneller viel weiter. Wo sich Next.js zeitlich amortisiert, ist bei langfristiger Skalierbarkeit und Developer Experience, vorausgesetzt die Teamzusammensetzung rechtfertigt es.
Was ist mit Astro, Remix oder anderen Frameworks?
Wissenswert. Astro ist besonders interessant für inhaltsreiche statische Websites und ich experimentiere damit für kleinere Projekte bei Seahawk. Remix hat ein überzeugendes Datenladungsmodell. Aber keines von beiden hat die Ökosystem-Reife oder Client-Vertrautheit von WordPress, oder die Enterprise-Adoption von Next.js. Für die meisten Agentur-Entscheidungen bleibt es derzeit eine WordPress-oder-Next.js-Entscheidung, alles andere ist eine Nischen-Überlegung.
Sollte ich Clients immer die "bessere" technische Lösung empfehlen?
Nein. Die beste technische Lösung, die das Team eines Clients nicht unterhalten kann, ist schlechter als die zweitbeste Lösung, die sie wirklich nutzen können. Das habe ich mehr als einmal auf die harte Tour gelernt. Liefere das ab, das für die beteiligten Menschen funktioniert, nicht nur das Architektur-Diagramm.
---
Die eigentliche Fähigkeit ist nicht, WordPress oder Next.js zu kennen. Es ist zu wissen, wann man zu welchem Tool greift, und ehrlich genug gegenüber dir selbst und deinen Clients zu sein, um diese Entscheidung auf Basis ihrer Realität zu treffen, nicht auf deine Vorlieben.
Der Immobilien-Client von 2021? Noch immer auf WordPress. Verwaltet seine Angebote selbst. Keine Anrufe von mir am Sonntagabend.