Next.js oder WordPress: Was zu deinem Betrieb passt

Entscheide zuerst über den Betrieb

Die Frage „Was ist besser?“ führt in die falsche Richtung. Beide Systeme können gute und schlechte Websites hervorbringen. Entscheidend ist, wer Inhalte pflegt, welche Funktionen wirklich benötigt werden, wie lange das Projekt betrieben wird und wer bei einem Fehler verantwortlich ist.

Beantworte vor jeder Stack-Diskussion:

• Wie viele Menschen bearbeiten Inhalte und wie oft?
• Welche Funktionen sind heute sicher nötig, welche nur denkbar?
• Gibt es bestehendes WordPress-Wissen oder interne Entwickler?
• Muss derselbe Inhalt in Website, App oder weiteren Kanälen erscheinen?
• Welche Reaktionszeit und welches Wartungsbudget stehen nach dem Launch bereit?

Wann WordPress gut passt

WordPress ist häufig sinnvoll, wenn Redakteure das System kennen, ein klassischer Seiten- und Beitragsbetrieb im Mittelpunkt steht und benötigte Funktionen durch bewährte Erweiterungen wirtschaftlich abgedeckt werden können.

Das gilt nur bei kontrollierter Umsetzung. Ein eigenes oder sorgfältig ausgewähltes Theme, wenige notwendige Plugins, klare ACF-Felder, Updates, Backups und Monitoring gehören zum Betrieb. Ein Page-Builder mit zwanzig Erweiterungen ist nicht automatisch günstig, wenn jede Aktualisierung neue Abhängigkeiten prüft.

Wann Next.js gut passt

Next.js ist interessant, wenn die Oberfläche stark individuell oder interaktiv wird, Inhalte aus einem Headless-CMS in mehreren Kanälen landen, Daten aus verschiedenen Systemen zusammenkommen oder Performance-Budgets technisch eng kontrolliert werden sollen.

Auch hier gibt es keine automatische Qualität. Zu viel Client-JavaScript, schlechte Bildpflege oder unklare Cache-Regeln machen eine Next.js-Seite langsam und teuer. Das Framework bietet Werkzeuge; die Architektur entscheidet über das Ergebnis.

Die Kosten stehen nicht nur im Angebot

Vergleiche über drei Jahre:

• Konzeption und Entwicklung
• Hosting und externe Dienste
• Updates und Sicherheitsarbeit
• redaktionelle Schulung
• Anpassungen an neue Anforderungen
• Abhängigkeit von Plugins, Agentur oder Spezialwissen
• Aufwand einer späteren Migration

Ein günstiger Start kann teuer werden, wenn niemand Updates verantwortet. Ein höherer Entwicklungsaufwand kann sich rechnen, wenn viele Kanäle dieselben Inhalte nutzen. Ohne Betriebsszenario bleiben beide Aussagen Spekulation.

Headless-WordPress ist kein kostenloser Mittelweg

WordPress kann als CMS dienen, während Next.js das Frontend ausliefert. Das bewahrt eine vertraute Redaktion und ermöglicht eine individuelle Oberfläche. Gleichzeitig betreibst du zwei Systeme, eine API-Verbindung, Vorschau, Caching und zwei Fehlerflächen.

Wähle diesen Weg nur, wenn du die Vorteile beider Seiten wirklich brauchst. Für eine einfache Unternehmenswebsite ist die zusätzliche Komplexität oft schwer zu begründen.

Eine gewichtete Entscheidungsmatrix

Bewerte beide Optionen von 1 bis 5 und gewichte die Kriterien nach Bedeutung:

1. 1.Redaktion und vorhandenes Wissen
2. 2.notwendige Funktionen
3. 3.individuelle Interaktion
4. 4.Mehrkanal-Ausgabe
5. 5.Performance-Ziel
6. 6.Sicherheits- und Updateverantwortung
7. 7.Budget über drei Jahre
8. 8.Wechselmöglichkeit zu einem anderen Dienstleister

Schreibe zu jeder Zahl einen Satz. „Next.js: 5 bei Performance“ ist zu pauschal. „Next.js: 4, weil statische Leistungsseiten und ein festes JavaScript-Budget geplant sind“ ist prüfbar.

So entscheide ich in der Praxis

Für ein Team mit sicherem WordPress-Wissen, vielen redaktionellen Änderungen und einer passenden Plugin-Funktion würde ich WordPress nicht aus Prinzip ersetzen. Für eine individuelle Plattform mit mehreren Datenquellen und langfristiger Headless-Strategie würde ich keinen Page-Builder wählen, nur weil er am ersten Tag schneller aussieht.

Die Entscheidung ist gut, wenn sie Anforderungen und Verantwortung sichtbar macht. Sie ist schlecht, wenn sie nur den bevorzugten Stack des Dienstleisters bestätigt.