Ein Client rief mich 2021 an – Immobilienfirma, ordentliches Budget, hatte ihre vorherige Agentur gerade rausgeschmissen. Der Auftrag war simpel: ihr Listings-Portal neu aufbauen. Ihr vorheriger Dev hatte acht Monate damit verbracht, eine maßgeschneiderte Next.js-Anwendung zu scaffolden. Sah in Demos brillant aus. Konnte von keiner Person ihres Teams ohne einen Pull Request und eine Deployment Pipeline aktualisiert werden. Der Makler, der die Listings verwaltete, nutzte als Notlösung 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.WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
Ich habe es in etwa sechs Wochen in WordPress mit Advanced Custom Fields Pro neu aufgebaut. Seitdem verwalten sie es selbst.WordPress with Advanced Custom Fields Pro in about six weeks. They've been managing it themselves ever since.
Diese Geschichte ist kein Argument gegen Next.js. Sie ist ein Argument dagegen, ein Tool zu wählen, bevor du das Problem verstanden hast. Ich habe auch das Gegenteil getan – einem Client ein WordPress Multisite gegeben, obwohl er eine richtige React-getriebene Anwendung brauchte, und habe zugesehen, wie es achtzehn Monate später unter der Last zusammengebrochen ist.
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.Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
Der ehrliche Zustand beider Technologien im Moment
WordPress betreibt irgendwo über 43% des gesamten Webs. Diese Zahl wird so oft herumgereicht, dass sie ihre Bedeutung verloren hat, aber denk einen Moment darüber nach. Dreiundvierzig Prozent. Das ist keine Legacy-Trägheit – das ist Netzwerkeffekt, Plugin-Ökosystem, Hosting-Infrastruktur und zwei Jahrzehnte institutionellen Wissens, das in jedem gemeinsamen Server auf dem Planeten eingebacken ist.
Next.js ist derweil zum dominierenden React-Framework für Production-Anwendungen geworden. Vercels Nutzungsdaten von 2023 zeigten, dass es hunderte Milliarden Requests pro Monat verarbeitet. Der App Router, eingeführt in Next.js 13, veränderte, wie Menschen über Server Components denken – und ja, er hat auch viele vor 2023 veröffentlichte Tutorials kaputtgemacht, was noch immer Verwirrung in Discord-Servern überall verursacht.Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
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 bin ehrlich. Wenn dein Client ein Marketing-Team, einen Content Manager oder irgendjemanden hat, der ohne Code-Änderungen publizieren muss – WordPress ist fast immer die richtige Antwort. Der Gutenberg-Editor, man mag ihn oder nicht (ich habe seit 2018 eine komplizierte Beziehung damit), gibt nicht-technischen Usern ein Block-basiertes Editing-Erlebnis, das tatsächlich funktioniert.anyone who needs to publish without touching code -- WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Nichts im React-Ökosystem kommt nah an Wordpress's Editorial-Erlebnis out of the box heran. Sanity.io hat ein schönes Studio, Contentful ist solide für strukturierte Inhalte – aber keines hat das Plugin-Ökosystem oder die Search-Engine-Vertrautheit, die WordPress hat. Der durchschnittliche Marketing-Hire hat WordPress schon benutzt. Sie haben eine Headless CMS nicht benutzt.Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
Plugin-Ökosystem-Tiefe
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Das sind nicht bloß Plugins – das sind ganze Plattformen mit ihren eigenen Ökosystemen. Wenn Seahawk ein E-Commerce-Projekt für einen Client mit einem überschaubaren Katalog macht (sagen wir, unter 5.000 SKUs), handhabt WooCommerce gekoppelt mit einem anständigen Hosting-Setup auf Kinsta oder WP Engine das problemlos. Wir reden von Sub-2-Sekunden-Ladezeiten nach Caching, vollständiger Lagerverwaltung, Abandoned-Cart-Recovery, Stripe-Integration – alles an einem Nachmittag konfiguriert.Kinsta or WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration -- all configured in an afternoon.
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-Site 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 ausgeliefert 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
2022 hatte Seahawk ein Fintech-Projekt -- ein Dashboard für ein Unternehmen für Kreditanalytik. Echtzeitdatenströme, komplexe Filterung, rollenbasierte Zugriffskontrolle, API-Integrationen mit drei verschiedenen Datenanbietern. Ich habe mir Headless WordPress etwa zwei Stunden 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 die Datenbeschaffung gebaut. Es läuft immer noch, läuft immer noch schnell, und die Codebase ist etwas, an dem das interne Team des Kunden tatsächlich mitarbeiten kann.
WordPress kann technisch gesehen Dinge wie Anwendungen tun. Aber jedes Mal, wenn ich versucht habe, es in wirklich dynamisches Gebiet zu drängen -- denk an mehrstufige Formulare mit bedingter Logik, die sich in externe APIs einspeist, Echtzeit-Dashboards, alles, was einen feingranularen clientseitigen State erfordert -- bin ich gegen die Architektur ankommen, anstatt mit ihr zu 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. explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
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, Hook-Architektur, das functions.php-Kaninchenloch -- das ist nicht schwer, aber es ist anders. Ich habe talentierte JS-Entwickler eingestellt, die sich eine WordPress-Theme-Codebase ansahen und sich die ersten zwei Wochen verloren fühlten.functions.php rabbit hole -- it's not hard, but it is different. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
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 beim „Headless WordPress" gelandet, als Kompromiss -- WordPress als CMS-Backend, Next.js als Frontend. Das Pitch klingt perfekt. Das Editorial-Team behält seine gewohnte 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:good cases:
- 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:actual problems:
- 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. is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- Preview-Funktionalität für Editoren -- ein Entwurf eines Posts auf dem Next.js-Frontend ansehen -- ist eine ständige Fehlerquelle. Ich habe Tage damit verschwendet, dies über mehrere Projekte hinweg.
- 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:red flags that should make you pause regardless of which direction you're leaning:
- Ein Kunde verlangt Next.js, 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 -- erzielt routinemäßig 90+ bei PageSpeed Insights. Seahawk hat WordPress-Sites konsistent bei 95+ ausgeliefert. Es ist nicht magisch; 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 Abstand zwischen einer „schnellen WordPress-Site" und einer „schnellen Next.js-Site" ist viel enger als die Framework-Evangelisten suggerieren. Googles eigene Core Web Vitals-Forschung zeigt, dass die Herkunftstechnologie weit weniger wichtig ist als die Implementierungsqualität. Die Engpässe in den meisten leistungsschwachen Sites sind Bilder, Render-blockierende Ressourcen und Server-Antwortzeiten -- von denen keine inhärent WordPress- oder Next.js-Probleme sind.Google's own Core Web Vitals research shows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times -- none of which are inherently WordPress or Next.js problems.
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.more control over performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO: WordPress Hat den Ökosystem-Vorteil, nicht den inhärenten Vorteil
Hier ist ein Missverständnis, das ich regelmäßig richtigstellen muss: WordPress ist nicht inhärent besser für SEO. Next.js-Apps mit richtigem serverseitigem Rendering sind vollständig von Google crawlbar. Die <Head>-Komponente, Sitemap-Generierung über next-sitemap, strukturierte Daten über JSON-LD -- alles ist erreichbar.<Head>component, sitemap generation via next-sitemap, structured data via JSON-LD -- it's all achievable.
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 Website von Entwicklern verwaltet wird, die Meta-Tags und strukturierte Daten verstehen, ist SEO mit Next.js nicht schwerer zu implementieren. Wenn die Website einen SEO-Berater oder Marketing-Manager braucht, um Seitentitel anzupassen, ohne ein Ticket einzureichen -- geben Sie 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 hörte. Es ist nicht passiert und ich erwarte nicht, dass es passiert. Die Frage ist nicht, ob WordPress modern ist -- es geht darum, ob es das Problem löst, das du hast. Für einen großen Prozentsatz von Websites ist das der Fall. Automattic investiert weiterhin massiv in Gutenberg und die Full Site Editing Experience. Es entwickelt sich, nur nicht auf Wegen, die Twitter-Feeds aufgeregt machen.
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?
Das hängt wirklich vom Umfang ab, aber für eine vergleichbare Marketing-Website dauert Next.js typischerweise 40–60 % länger für die erste Bereitstellung. Du schreibst Komponenten von Grund auf, richtest ein Design-System ein, integrierst ein CMS, konfigurierst die Bereitstellung. WordPress mit einem Premium-Theme und ACF bringt dich viel schneller viel weiter. Wo sich die Zeitinvestition mit Next.js auszahlt, ist langfristige Skalierbarkeit und Developer Ergonomics -- 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 geht darum, zu wissen, wann man zu jedem greift -- und ehrlich genug zu dir selbst und deinen Kunden zu sein, um diese Entscheidung auf ihrer Realität zu treffen, nicht auf deinen Vorlieben.
Der Immobilien-Client von 2021? Noch immer auf WordPress. Verwaltet seine Angebote selbst. Keine Anrufe von mir am Sonntagabend.