Ein Client rief mich 2021 an — Immobilienfirma, ordentliches Budget, hatte gerade ihre vorherige Agentur gefeuert. Das Briefing war simpel: ihr Listings-Portal neu aufbauen. Ihr bisheriger Dev hatte acht Monate damit verbracht, eine maßgeschneiderte Next.js-Anwendung hochzufahren. Sah in Demos brillant aus. Konnte von niemand anderem im Team ohne Pull Request und Deployment Pipeline aktualisiert werden. Der Immobilienmakler, der die Listings verwaltete, nutzte Google Sheets als Workaround.
Ich habe es in WordPress mit Advanced Custom Fields Pro in etwa sechs Wochen neu aufgebaut. Sie verwalten es seitdem selbst.Advanced Custom Fields Proin 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 man das Problem verstanden hat. Ich habe das Gegenteil auch schon getan — einem Client eine WordPress-Multisite gegeben, obwohl sie eine echte React-getriebene Anwendung brauchten, und zugesehen, wie sie anderthalb Jahre später unter der Last zusammenbrach.
Nach dem Bau von 5.000+ Websites bei Seahawk Media kümmert mich nicht mehr, welches Framework „gewinnt". Mich kümmert, welches ausgeliefert wird, performt und dich nicht um 23 Uhr am Sonntagabend 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 herumgeworfen, dass sie ihre Bedeutung verloren hat, aber bleib einen Moment dabei. Dreiundvierzig Prozent. Das ist keine technische Trägheit — das ist Netzwerkeffekt, Plugin-Ökosystem, Hosting-Infrastruktur und zwei Jahrzehnte institutionalisiertes Wissen, das in jeden gemeinsam genutzten Server auf dem Planeten eingebacken ist.
Next.js hingegen ist das dominante React-Framework für Produktionsanwendungen geworden. Die Nutzungsdaten von Vercel aus dem Jahr 2023 zeigten, dass es hunderte Milliarden Anfragen pro Monat verarbeitet. Der in Next.js 13 eingeführte App Router hat verändert, wie Menschen über Server-Komponenten denken — und ja, er hat auch viele Tutorials, die vor 2023 veröffentlicht wurden, zerstört, 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 bin ehrlich. Wenn dein Client ein Marketing-Team, einen Content-Manager oder irgendjemanden hat, der veröffentlichen muss, ohne Code anzufassen — WordPress ist fast immer die richtige Antwort. Der Gutenberg-Editor, man mag ihn oder nicht (ich habe seit 2018 ein kompliziertes Verhältnis zu ihm), gibt nicht-technischen Nutzern eine Block-basierte Editing-Erfahrung, die tatsächlich funktioniert.anyonewho 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 WordPress's Editorial-Erlebnis out of the box nahe. Sanity.io hat ein wunderschönes Studio, Contentful ist solide für strukturierte Inhalte — aber keines von beiden hat das Plugin-Ökosystem oder die Suchmaschinen-Vertrautheit, die WordPress hat. Der durchschnittliche Marketing-Einsteiger hat WordPress schon benutzt. Sie haben ein Headless CMS noch nicht benutzt.
Plugin-Ökosystem-Tiefe
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. Das sind nicht einfach nur Plugins — es sind ganze Plattformen mit eigenen Ökosystemen. Wenn Seahawk ein E-Commerce-Projekt für einen Kunden mit einem bescheidenen Katalog macht (sagen wir, unter 5.000 SKUs), kümmert sich WooCommerce gepaart mit einem anständigen Hosting-Setup auf Kinsta oder WP Engine darum. Wir sprechen von Sub-2-Sekunden-Ladezeiten nach dem Caching, vollständiger Bestandsverwaltung, Abandonment-Cart-Recovery, Stripe-Integration — alles an einem Nachmittag konfiguriert.Kinstaor 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-Website 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 bereitgestellt und von fast jedem gewartet 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 Kreditanalytik-Unternehmen. Echtzeit-Datenfeeds, komplexe Filterung, rollenbasierte Zugriffskontrolle, API-Integrationen mit drei verschiedenen Datenanbietern. Ich habe mir Headless WordPress etwa zwei Stunden angeschaut, bevor ich zugeben musste, dass es das falsche Tool war. Wir haben es in Next.js mit NextAuth.js für die Authentifizierung und React Query für den Datenabruf gebaut. Es läuft immer noch, ist immer noch schnell, und die Codebase 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 in wirklich dynamisches Terrain zu drücken — denken Sie an mehrstufige Formulare mit bedingter Logik, die in externe APIs führen, Echtzeit-Dashboards, alles, das feinkörnige clientseitige State-Verwaltung erfordert — bin ich am Ende gegen die Architektur angekämpft, 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 Implikation ist diese: Eine Next.js-Site für eine Nachrichtenpublikation mit 50.000 Artikeln kann einzelne Seiten nach Plan neu validieren, ohne die gesamte Site zu rebuilden. Das ist wirklich mächtig und etwas, das WordPress nur durch Fragment-Caching annähernd erreichen kann.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-nativen Entwickler-Team bist, hat WordPress-Entwicklung eine echte Lernkurve, die oft unterschätzt wird. PHP, die WordPress Template Hierarchy, Hook-Architektur, das functions.php-Kaninchenloch — es ist nicht schwer, aber es ist anders. Ich habe talentierte JS-Entwickler eingestellt, die einen WordPress-Theme-Codebase anschauten und sich in den ersten zwei Wochen verloren fühlten.functions.phprabbit hole — it's not hard, but itisdifferent. 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 auf „Headless WordPress" als Kompromiss gelandet — 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:goodcases:
- 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 dir Probleme bereiten 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 Redakteure — das Ansehen eines Draft-Posts auf dem Next.js-Frontend — ist eine ständige Quelle von Bugs. Ich habe bei diesem Problem über mehrere Projekte hinweg Tage 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 einige rote Flaggen, die dich unabhängig davon aufhorchen lassen sollten, für welche Richtung du dich neigst:red flagsthat should make you pause regardless of which direction you're leaning:
- Ein Klient, der Next.js fordert, 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 erstelltes Theme — erreicht routinemäßig 90+ bei PageSpeed Insights. Seahawk hat WordPress-Sites konsistent mit 95+ geliefert. Das ist keine Magie; es ist nur 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 viel geringer als die Framework-Evangelisten vermuten lassen. Googles eigene Core Web Vitals-Forschung zeigt, dass die ursprüngliche Technologie viel weniger zählt als die Implementierungsqualität. Die Engpässe bei den meisten schlecht ausgeführten Sites sind Bilder, Render-Blocking-Ressourcen und Server-Response-Zeiten — nichts davon sind inhärent WordPress- oder Next.js-Probleme.Google's own Core Web Vitals researchshows 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 wirklich bietet, ist mehr Kontrolle über die Leistung. Sie können genaue Entscheidungen pro Route treffen darüber, wie Daten abgerufen werden und wann Seiten gerendert werden. Aber Kontrolle hilft nur, wenn Sie sie richtig ausüben.more controlover 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 eine Fehlvorstellung, die ich regelmäßig korrigieren muss: WordPress ist nicht inhärent besser für SEO. Next.js-Apps mit richtigem Server-seitigen Rendering sind von Google vollständig crawlbar. Die <Head>-Komponente, Sitemap-Generierung via next-sitemap, strukturierte Daten via JSON-LD — alles ist erreichbar.<Head>component, sitemap generation vianext-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 Next.js SEO nicht schwerer zu implementieren. Wenn die Website einen SEO-Berater oder Marketing-Manager braucht, der Seitentitel anpassen 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 Prozentsatz von Websites tut es das. Automattic investiert weiterhin massiv in Gutenberg und Full Site Editing. Es entwickelt sich, nur nicht auf Wegen, die Twitter-Feeds begeistern würden.
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?
Wirklich abhängig vom Umfang, aber für eine vergleichbare Marketing-Website dauert Next.js beim initialen Launch typischerweise 40–60% länger. Du schreibst Komponenten von Grund auf, richtest ein Design System ein, integrierst ein CMS, konfigurierst das Deployment. WordPress mit einem Premium-Theme und ACF bringt dich viel weiter, schneller. Wo sich Next.js die Zeitinvestition zurückholt, ist die 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 zu kennen oder Next.js zu kennen. Es ist zu wissen, wann man zu welchem greifen sollte — und ehrlich genug gegenüber dir selbst und deinen Clients zu sein, um diese Entscheidung basierend 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.