WordPress vs Next.js: Was B2B-Unternehmen 2026 wählen sollten

Die kurze Antwort

Für eine B2B-Website, die 2026 neu gebaut oder ersetzt wird, trägt Next.js mit einem Headless-CMS weiter, sobald Ladezeit, Mehrsprachigkeit, Sicherheit und strukturierte Inhalte über Jahre planbar sein sollen. Headless heißt: Das Content-System hat keine eigene Ausgabe-Schicht, es liefert Inhalte nur über eine API aus, also über eine Programmierschnittstelle, an die ein Frontend deiner Wahl andockt. WordPress bleibt die richtige Wahl, wenn viele Autoren regelmäßig publizieren, im Haus kein Entwickler sitzt und das Budget unter dem Niveau eines Relaunch-Projekts liegt.

Der Unterschied ist kein Geschwindigkeitsduell, sondern ein Kontrollunterschied. Bei WordPress bestimmen Theme und Plugins, was am Ende im Browser ankommt, und jedes Update kann daran etwas verschieben. Bei Next.js bestimmst du es selbst: Rendering, Caching, strukturierte Daten, Sitemap-Logik und interne Verlinkung liegen im Code. Das ist ein Gewinn, wenn jemand diesen Code pflegt. Es ist ein Problem, wenn niemand da ist.

Eine Haltung dazu, damit du weißt, woran du bei uns bist: Wir arbeiten nicht mit WordPress und bieten auch kein Headless WordPress an. Der Umbau auf headless kostet den vollen Relaunch-Aufwand, und die WordPress-Installation bleibt danach mit Updates, Plugin-Abhängigkeiten und Angriffsfläche trotzdem stehen. Du betreibst zwei Systeme statt einem. Einzige Ausnahme: An der Installation hängt Geschäftslogik, die kurzfristig nicht ersetzbar ist, etwa WooCommerce, eine Mitgliederverwaltung oder eine ERP-Schnittstelle. Dann ist Headless WordPress eine Übergangslösung mit Enddatum, kein Dauerzustand. Wer alle Optionen nebeneinander sehen will, findet sie in der Übersicht der WordPress-Alternativen. Hier geht es nur um das direkte Duell.

Was die beiden Systeme im Alltag unterscheidet

WordPress baut jede Seite in dem Moment zusammen, in dem sie aufgerufen wird: Der Server holt die Inhalte aus der Datenbank, das Theme gießt sie in HTML, aktive Plugins hängen ihre eigenen Dateien an. Das ist der Grund, warum eine WordPress-Website mit den Jahren träger wird, ohne dass jemand etwas falsch gemacht hat. Jede zusätzliche Funktion bringt ihren eigenen Code mit.

Next.js dreht die Reihenfolge um. Seiten werden entweder beim Build vorab erzeugt und danach als fertige Dateien aus einem CDN ausgeliefert, also aus einem weltweit verteilten Auslieferungsnetz, oder pro Anfrage auf dem Server gerendert, wenn die Daten frisch sein müssen. Das Vorab-Erzeugen heißt SSG (Static Site Generation), das Rendern pro Anfrage SSR (Server-Side Rendering). Die Inhalte kommen dabei nicht aus dem Framework selbst, sondern aus einer Content-Datenbank wie Sanity.

Für die meisten B2B-Marketing-Websites ist Astro unser Standard, weil es für statische Inhalte weniger JavaScript ausliefert. Next.js setzen wir ein, sobald Login, App-Logik oder serverseitige Daten pro Anfrage im Spiel sind. Wo genau die Grenze liegt, steht im Vergleich Astro vs Next.js. Für das Duell mit WordPress ändert das wenig: Beide gehören zur selben Klasse, du baust das Frontend selbst und die Inhalte liegen getrennt davon.

WordPress vs Next.js: der Vergleich in zehn Kriterien

Die folgende Tabelle nimmt die zehn Punkte, an denen Entscheidungen in unseren Projekten tatsächlich kippen. Die rechte Spalte beschreibt Next.js mit Sanity, weil Next.js allein kein Redaktionssystem mitbringt und der Vergleich sonst schief wäre.

Redaktion, Content-Modell und Mehrsprachigkeit

WordPress gewinnt den ersten Eindruck in der Redaktion, und das ist kein kleiner Punkt. Ein neuer Werkstudent kennt den Editor, Rollen und Freigaben sind da, und für fast jeden Wunsch gibt es ein Plugin. Der Preis dafür zeigt sich später: Was über Seiten und Beiträge hinausgeht, wird über Custom-Field-Plugins nachgerüstet, und das Content-Modell wächst an der Oberfläche statt in der Struktur.

Auf der anderen Seite definierst du die Dokumenttypen im Code, bevor der erste Text existiert. Ein Referenzprojekt: LeanWave von Otto ID Solutions, RFID für Textilservice und Wäschereien. 64 Dokumente und 86 Bild-Assets liegen dort in einer Sanity-Datenbank, das Team arbeitet im Presentation Mode und sieht die echte Seite beim Schreiben, und jede Änderung stößt über einen Webhook, also einen automatischen Aufruf bei jedem Speichern, einen neuen Build an.

Mehrsprachigkeit trennt die beiden Systeme am deutlichsten. Bei LeanWave liegt Englisch auf der Wurzel, Deutsch unter /de, die URL-Segmente sind übersetzt (/solutions wird zu /de/loesungen), und hreflang verweist wechselseitig inklusive x-default. Hreflang ist die Auszeichnung, die Google sagt, welche Sprachversion zu welcher Seite gehört. Bei Yarowa laufen fünf Sprachen über 21 Seiten-Templates und 163 Sections. Solche Strukturen sind in WordPress möglich, aber sie hängen an einem Plugin, an dessen Update-Zyklus und an dessen Umgang mit URLs.

Ladezeit und ausgeliefertes JavaScript

Ladezeit entsteht nicht durch schlechte Arbeit, sondern durch Addition. Ein Theme bringt sein eigenes CSS und JavaScript mit, jedes Plugin hängt seine Dateien dazu, und niemand entfernt sie wieder, weil unklar ist, welche Funktion daran hängt. Genau das ist der strukturelle Unterschied: In einem selbst gebauten Frontend gibt es diese Addition nicht, weil nichts mitkommt, das du nicht selbst eingebaut hast.

Zahlen dazu aus unserer eigenen Messung vom 13.09.2026: leanwave.com, das wir statisch mit Astro bauen, lädt auf der Startseite rund 39 KB JavaScript in drei Dateien. Zum Vergleich: Eine Webflow-Kundenseite von uns kommt an derselben Stelle auf rund 740 KB, verteilt auf dreizehn Dateien. Für WordPress haben wir keine eigene Messung, die wir hier zitieren könnten, deshalb nennen wir auch keine Zahl. Der Mechanismus dahinter ist aber derselbe: Was das System mitliefert, bestimmt das System, nicht du.

Astro liefert für statische Inhalte standardmäßig 0 KB JavaScript aus, nur interaktive Teile laden Skripte nach. Diese Teile heißen Islands, also einzelne Bereiche einer Seite, die für sich interaktiv werden. Next.js liegt darüber, gibt dir aber dieselbe Kontrolle darüber, was wann geladen wird. Was das für die Messwerte bedeutet, die Google bewertet, steht in unserem Artikel zu den Core Web Vitals.

Sicherheit, Wartung und Abhängigkeit von Entwicklern

Eine WordPress-Installation ist ein laufender Betrieb. Kern, Theme und Plugins brauchen Updates, und jedes Update kann eine andere Erweiterung stören, weshalb Aktualisierungen oft verschoben werden. Das Redaktions-Login liegt öffentlich auf der Domain und wird automatisiert abgeklopft. Das ist kein Argument gegen WordPress an sich, es ist eine Betriebsaufgabe, die jemand übernehmen muss, dauerhaft und mit Budget.

Bei einem eigenen Frontend verschiebt sich diese Aufgabe. Auf der Website selbst liegt kein Redaktions-Login, die Inhalte liegen in Sanity und werden über die API geholt. Updates betreffen Bibliotheken im Code, nicht eine Installation, die sich unter Last selbst ändert. Dafür handelst du dir eine andere Abhängigkeit ein, und die verschweigen wir nicht: Ohne jemanden, der den Code anfasst, entstehen keine neuen Templates und keine neue Logik.

Diese Grenze ist der ehrlichste Punkt im ganzen Vergleich. Inhalte pflegt die Redaktion selbst, jeden Tag, ohne Entwickler. Ein neuer Seitentyp, eine neue Sektion, eine Änderung an der Ausgabe-Logik brauchen dagegen eine Entwicklerin oder eine Agentur, entweder im Haus oder als Webentwicklungs-Partner. Wer das nicht will oder nicht dauerhaft bezahlen kann, ist bei WordPress besser aufgehoben. Das ist keine Höflichkeit, das ist die Rechnung.

Kosten im ersten Jahr und laufend

WordPress ist als Software kostenlos, und genau das macht den Vergleich unübersichtlich. Die Kosten entstehen an anderer Stelle: Hosting, Theme-Lizenz, Plugin-Lizenzen, dazu die Zeit für Updates und Fehlersuche. Konkrete Hosting- oder Plugin-Preise nennen wir hier nicht, weil wir sie nicht selbst geprüft haben. Prüfe für dein Angebot, welche Lizenzen jährlich verlängert werden müssen und wie viele Stunden Wartung darin eingerechnet sind.

Auf der anderen Seite ist das erste Jahr teurer und die Jahre danach sind es nicht. Sanity Free kostet 0 $ und bringt 20 Plätze, 10.000 Dokumente, 100 GB Assets und 100 GB Bandbreite pro Monat mit, Presentation Mode und Visual Editing inklusive; Growth liegt bei 15 $ pro Platz und Monat mit 25.000 Dokumenten. Vercel Pro kostet 20 $ pro Entwickler-Seat und Monat, inklusive 20 $ Nutzungsguthaben und ohne Grundgebühr pro Projekt. In Summe läuft eine solche Website typischerweise mit 0-20 $ Hosting pro Monat, also mit nahezu keinen laufenden Plattformgebühren. Mehrsprachigkeit kostet dabei keinen Aufpreis pro Sprache.

Das erste Jahr rechnen wir als Relaunch-Projekt ab, unsere Relaunch-Pakete starten bei 8.000 € netto. Eine Marketing-Website mit 10-30 Seiten liegt typischerweise bei 3-6 Wochen bis Go-Live, das Monitoring danach kommt dazu. Wie sich diese Summe zusammensetzt, steht in Webentwicklung Kosten und in Was kostet eine B2B-Website.

SEO- und GEO-Hebel: was du selbst steuerst

Beide Systeme haben eine API. WordPress bietet die REST-API und WPGraphQL, Sanity liefert seine Inhalte ebenfalls über API und MCP-Server, also über einen Server, über den KI-Agenten definierte Aktionen in einem System ausführen. Der Unterschied liegt nicht am Zugang zu den Inhalten. Er liegt daran, wie tief du in die Ausgabe eingreifen kannst: Rendering, Caching, strukturierte Daten, Sitemap-Logik und interne Verlinkung liegen bei einem eigenen Frontend im Code und nicht hinter den Einstellungen eines Plugins.

Praktisch heißt das: Du kannst Inhalte und Seiten programmatisch erzeugen und prüfen, statt sie einzeln anzulegen. Auf in-sync.io laufen 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten aus einer Sanity-Datenbank, zweisprachig mit hreflang, dazu Server-Rendering, llms.txt, IndexNow und FAQPage-Schema. Diese Hebel sind dieselben, die in technisches SEO und in der Generative Engine Optimization zählen, wenn ChatGPT, Perplexity oder Google AI Overviews entscheiden, welche Quelle sie zitieren.

Eine Warnung, die wir selbst bezahlt haben: Programmatisch erzeugte Seiten funktionieren nur mit echter Substanz pro Seite. Ohne eigene Substanz landen sie bei Google als Doorway-Pages, also als Seiten, deren einziger Zweck ein Keyword ist. Auf unserer alten Website ist uns genau das passiert. Die Technik macht den Hebel größer, sie ersetzt den Inhalt nicht.

Wann WordPress, wann Next.js

Die Entscheidung fällt nicht am System, sondern an drei Fragen: Wer pflegt die Inhalte, wer pflegt die Technik, und wie lange soll die Website halten. Die folgenden zwei Listen sind die Kurzfassung dessen, was wir in Erstgesprächen abfragen.

Wähle WordPress, wenn

WordPress ist die richtige Wahl, wenn die Redaktion den Takt vorgibt und niemand im Haus Code anfasst. Das ist häufiger der Fall, als Agenturen zugeben.

Wähle Next.js, wenn

Next.js lohnt sich, sobald die Website ein System sein soll und nicht nur eine Sammlung von Seiten. Ab diesem Punkt zahlt sich der höhere Einstieg über die Jahre zurück.

Wenn die Entscheidung für Next.js fällt und bereits eine WordPress-Installation läuft, ist der Weg dorthin ein eigenes Thema. Der Ablauf mit Vorher-Crawl, Redirect-Map und Monitoring steht in WordPress zu Next.js migrieren.

Unser Urteil: so bauen wir es

Wir bauen B2B-Websites mit Astro und Sanity als Standard und wechseln zu Next.js, sobald Login, App-Logik oder serverseitige Daten pro Anfrage nötig sind. in-sync.io selbst läuft auf Next.js, Sanity und Vercel, seit dem Umzug von Wix im Jahr 2026. Alle Inhalte, 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten, kommen aus einer Datenbank, zweisprachig, mit Server-Rendering, hreflang, llms.txt, IndexNow und FAQPage-Schema.

Dazu gehört die unbequeme Hälfte: Unsere alte Wix-Website hat praktisch keine Rankings geholt, die neue ist seit Juni 2026 online und arbeitet sich gerade erst hoch. Ein Systemwechsel liefert keine Rankings, er liefert die Voraussetzungen dafür. Was danach passiert, hängt an Inhalten, Links und Zeit.

Wenn du von WordPress kommst, gehen wir direkt auf Sanity mit eigenem Frontend, nicht auf einen Zwischenschritt. Der Ablauf ist bei uns immer derselbe: Vorher-Crawl mit Screaming Frog oder Ahrefs, Ranking-Snapshot, Redirect-Map 1:1 für jede alte URL, Launch-Checkliste, Einreichung in Search Console und Bing, IndexNow, danach zwei Wochen Monitoring mit 404-Report und Ranking-Abgleich. Wie wir das als Projekt aufsetzen, steht auf unserer Seite zur Relaunch-Begleitung.

Häufige Fragen

Nächster Schritt

Wenn du zwischen einem WordPress-Relaunch und einem eigenen Frontend stehst, rechnen wir beide Wege an deinem Seitenumfang durch: Schreib uns kurz, worum es geht.