Next.js oder WordPress für eine Business-Website 2026

Next.js oder WordPress für eine Business-Website — wofür sollten Sie sich entscheiden?

Ich baue kommerziell mit Next.js, und trotzdem rate ich Leuten häufiger zu WordPress, als sie erwarten. Keine der beiden Plattformen ist abstrakt betrachtet besser; sie scheitern an unterschiedlichen Stellen, und Sie entscheiden, mit welchem Scheitern Sie leben können. WordPress scheitert langsam — angehäufte Plugins, aufgeschobene Updates, ein Theme, das niemand mehr anzufassen wagt. Next.js scheitert sofort, am Mittwoch, an dem jemand einen neuen Seitentyp braucht und die einzige Person, die ihn hinzufügen kann, bis Montag ausgebucht ist.

Die Kurzversion. Wenn der Großteil der Arbeit nach dem Launch Text auf Seiten ist, erledigt von jemandem, der keinen Code deployt, ist WordPress günstiger und weniger nervig. Wenn es größtenteils um Verhalten geht — Rendering, Routing, strukturierte Daten, Checkout, Tracking oder eine App, neben der die Marketing-Website steht —, rechnet sich Next.js.

Welche eine Frage entscheidet wirklich?

Jeder Vergleich zu diesem Thema streitet über Time to First Byte, Bundle-Größe und Hosting-Rechnungen. Nichts davon entscheidet irgendetwas, denn beide Plattformen lassen sich sowohl schnell als auch grauenhaft bauen. Die Frage, die tatsächlich entscheidet, ist unspektakulärer: Wer bearbeitet diese Website an einem Dienstagnachmittag, und was will diese Person ändern?

Es gibt zwei Arten von Änderungen. Eine inhaltliche Änderung ist Text, Bilder, eine Seite, die wie die letzten zwanzig aussieht. Eine strukturelle Änderung ist ein neues Feld, ein neuer Seitentyp, eine Integration, eine andere Rendering-Strategie für eine Route. WordPress macht inhaltliche Änderungen kostenlos und strukturelle Änderungen plugin-förmig. Next.js macht strukturelle Änderungen kostenlos und inhaltliche Änderungen deploy-förmig — außer Sie binden ein CMS an, was eine echte Entscheidung mit eigener Rechnung ist.

Wo gewinnt WordPress wirklich?

Ich will hier konkret werden, denn fast jeder Vergleich zu diesem Thema wird von jemandem geschrieben, der eine der beiden Antworten verkauft.

• Der Editor. Wer auch immer Sie als Nächstes einstellen, hat WordPress schon benutzt. Eine Marketing-Neueinstellung veröffentlicht am ersten Tag eine Seite — ohne Schulung, ohne Branch, ohne Deploy-Pipeline.
• Das Plugin-Ökosystem. Buchungen, Mitgliedschaften, Multi-Währung, Rechnungsstellung, Ticketing für Events — jemand hat das gelöst, an Tausenden Installationen gehärtet und pflegt es weiter. Das in Next.js nachzubauen ist echtes Geld für ein Problem, das nicht Ihr Geschäft ist.
• Die Kosten einer kleinen Änderung. Eine Telefonnummer in der Fußzeile zu korrigieren dauert dreißig Sekunden und ist praktisch risikofrei. Auf einer code-verwalteten Website sind das ein Commit, ein Review, ein Build und ein Deploy.
• Einen Betreuer finden. Wenn ich morgen verschwinde, können Sie einen WordPress-Entwickler in fast jeder Stadt innerhalb einer Woche ersetzen; ein Senior-Next.js-Entwickler dauert länger und kostet mehr. Der Bus-Faktor ist ein legitimes Beschaffungskriterium, das in jeder Vergleichstabelle fehlt, die ich gelesen habe.
• Zeit bis zum ersten Launch. Ein Theme plus Konfiguration erreicht schneller eine überzeugende Live-Website als jeder individuelle Build.

Ein Plugin ist eine gekaufte Entscheidung, und Kaufen schlägt Bauen bei allem, worin Ihr Geschäft nicht tatsächlich gut ist. Diese Logik hört nicht auf zu gelten, nur weil der Code zufällig PHP ist.

Wo gewinnt Next.js wirklich?

Die Vorteile sind real, aber enger gefasst, als das Marketing suggeriert. Sie konzentrieren sich auf Last, Kontrolle und Eigentümerschaft.

• Geschwindigkeit unter Last. Eine vorgerenderte Seite, ausgeliefert von einem CDN, führt pro Anfrage nichts aus — kein PHP-Worker, kein Datenbank-Roundtrip, kein Objekt-Cache, der warmgehalten werden muss. Traffic-Spitzen hören auf, ein Ereignis zu sein. Cariva betreibt 326 serverseitig gerenderte SEO-Seiten genau nach diesem Modell.
• Angriffsfläche. Kein Admin-Login auf Ihrer Marketing-Website, kein Drittanbieter-Plugin mit Datenbank-Zugangsdaten, kein Theme, das beliebigen PHP-Code ausführt. Ihre Angriffsfläche sind Ihre eigenen API-Routen und Ihr Dependency-Baum — beide können Sie selbst lesen.
• Rendering-Kontrolle pro Route. Die Preisseite vorrendern, den Blog stündlich revalidieren, das Dashboard bei Anfrage rendern. Eine Entscheidung pro Datei im App Router statt eines seitenweiten Caching-Plugins, das Sie durch Ausprobieren einstellen.
• Strukturierte Daten und Tracking gehören Ihnen. Sitemaps, Canonicals, hreflang und JSON-LD werden zu typisiertem Code, der einen Build fehlschlagen lässt, wenn er falsch ist, statt zu Einstellungen in einem gemieteten Plugin. Dasselbe gilt für Analytics und serverseitiges Conversion-Tracking.
• Keine Plugin-Steuer. Keine Verlängerungen, keine Kompatibilitätsmatrix, kein Morgen, an dem ein Auto-Update das Kontaktformular offline nimmt und es zwei Tage lang niemand bemerkt.

Diese Website ist das Beispiel, für das ich ohne Einschränkung geradestehen kann: Lighthouse SEO 100 auf allen zwölf Routen-Templates, CLS 0,000 und eine Total Blocking Time von 106 ms auf der Startseite. Das sind Laborwerte, gemessen auf Mobilgeräten gegen die Produktivumgebung und nicht einer Fallstudie entnommen, und für diese Domain liegen noch keine CrUX-Felddaten vor, an denen man sie prüfen könnte. Das zählt auch geschäftlich. Google-Ads-Konten mit überdurchschnittlicher Landingpage-Erfahrung und Anzeigenrelevanz korrelieren mit einem Cost-per-Click, der rund 36 % unter dem Durchschnitt liegt (Search Engine Land, 2023). Geschwindigkeit ist ein Posten im Media-Budget, keine Eitelkeits-Kennzahl.

Welche Plattform passt zu Ihrer Art von Website?

Broschüren-Website mit wöchentlichen Änderungen

Fast immer WordPress. Acht Seiten, ein Kontaktformular, ein News-Bereich, den jemand freitags aktualisiert. Die technische Obergrenze ist irrelevant, weil Sie ihr nie nahekommen; die Bearbeitungsuntergrenze ist alles. Ich rate nur davon ab, wenn die Website der Hauptverkaufskanal für etwas Teures ist und Paid Traffic sie trägt.

Content-lastiger Publisher

WordPress gewinnt beim Workflow und verliert bei der Auslieferung. Entwürfe, Revisionen, Terminierung, Rollen und Medienverwaltung sind dort ausgereift und mühsam nachzubauen. Ist das Redaktionsteam zufrieden und die Website langsam, ist der ehrliche Fix meist Caching, Bildbehandlung und gezielte Template-Chirurgie — kein Plattformwechsel. Brauchen Sie wirklich beides, ist Headless der Kompromiss, und der kostet mehr als jede der beiden Optionen allein.

E-Commerce

Sind Katalog, Checkout, Steuern und Versand Standard, ist ein Plugin oder eine gehostete Plattform die vernünftige Wahl. Individuell wird es, wenn das Modell es nicht ist: Abos mit ungewöhnlichen Regeln, angebotsbasierte B2B-Preise, ein Konfigurator oder ein Conversion-Pfad, den Sie durchgängig instrumentieren müssen. Der Markt ist für manche groß genug, um das zu rechtfertigen — der E-Commerce-Markt in den VAE soll von 12,30 Mrd. USD im Jahr 2026 auf 21,01 Mrd. USD bis 2031 wachsen, ein CAGR von 11,29 % (Mordor Intelligence, 2026) —, aber Marktgröße ist kein Grund, den eigenen Warenkorb zu schreiben. Ein individueller E-Commerce-Build rechtfertigt sich durch ein Geschäftsmodell, nie durch Ambition.

Produkt- oder SaaS-Marketing-Website

Next.js, kaum diskutabel. Marketing-Website und Produkt teilen sich ein Designsystem, eine Komponentenbibliothek, eine Auth-Grenze und eine Deploy-Pipeline. Ein separates CMS auf einem separaten Host bedeutet doppelt alles und dauerhafte Drift zwischen der App und den Seiten, die sie verkaufen.

Mehrsprachige Website

Hier wird WordPress still und leise teuer. Mehrsprachigkeits-Plugins funktionieren, aber hreflang-Cluster, x-default, sprachspezifische Canonicals und RTL-Layout sind das, was kaputtgeht, und Sie debuggen es über einen Einstellungsbildschirm. In Next.js ist das Code, den Sie in einem Pull Request prüfen und im Build absichern. Wenn echter arabischer Content zählt — keine maschinell übersetzten Seiten —, entscheidet genau dieser Unterschied.

Was sind die versteckten Kosten auf beiden Seiten?

Die Baukosten sind die Zahl, die jeder vergleicht, und die, die am wenigsten zählt. Die Kosten, die das Ergebnis über drei Jahre entscheiden, sind wiederkehrend und asymmetrisch verteilt.

Keine der beiden Spalten ist sauber. WordPress verwandelt Geld in Wartungsfenster und Plugin-Konflikte. Next.js verwandelt Geld in Entwicklerabhängigkeit für alles, was die Form des Contents ändert. Egal, wofür Sie sich entscheiden, die Rechnung kommt — nur in einer anderen Währung.

Ändert die Plattform, wie Google und KI-Antwortmaschinen Sie sehen?

Weniger, als beide Lager behaupten. Beide Plattformen erzeugen HTML auf dem Server, und beide können hervorragend ranken. Was Sichtbarkeit killt, ist nicht PHP gegen React — es ist Content, der erst nach der JavaScript-Ausführung existiert.

Dieser Unterschied hat sich verschärft. Stand Mitte 2026 führt keiner der großen KI-Crawler JavaScript aus: instrumentierte Messungen fanden, dass GPTBot bei rund 11,5 % der Anfragen JS herunterlädt und ClaudeBot bei rund 23,8 % — und es nie ausführt (AI-Crawler-Instrumentierungsdaten, 2026). Googlebot rendert; die Antwortmaschinen meist nicht. Ein serverseitig gerendertes WordPress-Theme ist hier in Ordnung. Eine React-Single-Page-App, die ihren Text erst clientseitig aufbaut, ist es nicht — und eine Next.js-Seite, die Content hinter einem rein clientseitigen Akkordeon versteckt, ebenso wenig.

# Does your headline exist in the raw HTML, before any JavaScript runs?
curl -sL -A "Mozilla/5.0 (compatible; GPTBot/1.1; +https://openai.com/gptbot)" \
  https://example.com/pricing \
  | grep -o "<h1[^>]*>[^<]*</h1>"

# Count how much of the page is real text vs. script payload
curl -sL https://example.com/pricing | wc -c

Was Next.js Ihnen gibt, ist die Autorenschaft über die maschinenlesbare Ebene: Sitemaps, Robots-Regeln, Canonicals, hreflang und JSON-LD als typisierte Module, die einen Build ablehnen können — eine andere Qualität von Garantie als eine Plugin-Checkbox. Seien Sie skeptisch bei allem, was obendrauf als "KI-Optimierung" verkauft wird. Ahrefs analysierte im Mai 2026 mehr als 137.000 Domains und fand heraus, dass 97 % der llms.txt-Dateien nie von einem KI-Crawler abgerufen wurden. Die Arbeit, die sich auszahlt, ist technisches SEO und Core Web Vitals, das Sie in Felddaten überprüfen können, auf beiden Plattformen.

Löst Headless-WordPress den Streit?

Teilweise, und es lohnt sich, genau zu wissen, welchen Teil. Headless behält WordPress als Bearbeitungsumgebung bei und ersetzt das Theme durch ein Next.js-Frontend, das die REST- oder GraphQL-API ausliest. Redakteure behalten die Oberfläche, die sie kennen; Sie bekommen Rendering-Kontrolle, ein CDN-ausgeliefertes Frontend und code-eigene SEO-Ausgabe.

// src/app/blog/[slug]/page.tsx
import {notFound} from 'next/navigation';

const WP = process.env.WP_API_URL!; // https://cms.example.com/wp-json/wp/v2

type WpPost = {
  id: number;
  slug: string;
  title: {rendered: string};
  content: {rendered: string};
  modified_gmt: string;
};

async function getPost(slug: string): Promise<WpPost | null> {
  const url = new URL(`${WP}/posts`);
  url.searchParams.set('slug', slug);
  url.searchParams.set('_fields', 'id,slug,title,content,modified_gmt');

  const res = await fetch(url, {
    // Served from cache until the webhook below invalidates the tag.
    next: {revalidate: 3600, tags: ['wp:posts', `wp:post:${slug}`]}
  });
  if (!res.ok) throw new Error(`WordPress returned ${res.status}`);

  const [post] = (await res.json()) as WpPost[];
  return post ?? null;
}

export default async function Page({params}: {params: Promise<{slug: string}>}) {
  const {slug} = await params;
  const post = await getPost(slug);
  if (!post) notFound();

  return (
    <article>
      <h1 dangerouslySetInnerHTML={{__html: post.title.rendered}} />
      <div dangerouslySetInnerHTML={{__html: post.content.rendered}} />
    </article>
  );
}

// src/app/api/wp-revalidate/route.ts
import {revalidateTag} from 'next/cache';

export async function POST(request: Request) {
  if (request.headers.get('x-wp-secret') !== process.env.WP_WEBHOOK_SECRET) {
    return new Response('Forbidden', {status: 403});
  }

  const {slug} = (await request.json()) as {slug?: string};
  revalidateTag(slug ? `wp:post:${slug}` : 'wp:posts', 'max');

  return Response.json({revalidated: true});
}

Jetzt der Teil, den Anbieter überspringen. Headless reduziert weder Kosten noch Komplexität — es erhöht beides.

• Sie betreiben jetzt zwei Systeme: eine WordPress-Installation, die weiterhin Core- und Security-Updates braucht, plus ein Frontend, das Deploys braucht. Die Wartungsfläche ist gewachsen.
• Jedes Plugin, das Frontend-Ausgabe rendert, funktioniert nicht mehr. Formulare, Slider, Page-Builder, SEO-Plugin-Markup, Cookie-Banner — diese Ausgabe war die Aufgabe des Themes, und das Theme ist weg. Prüfen Sie das, bevor Sie sich festlegen; das ist es, woran die meisten dieser Projekte scheitern.
• Vorschau und Entwürfe müssen gebaut werden. Redakteure erwarten, unveröffentlichte Arbeit zu sehen — das bedeutet Draft-Modus, einen Token-Austausch und einen Umgehungspfad am Cache vorbei.
• Cache-Invalidierung ist jetzt Ihre Aufgabe. Der Webhook oben ist das Minimum; auch Kategorieseiten, Sitemaps und Menüs brauchen Tags, sonst veröffentlicht jemand und nichts erscheint.

Headless ist richtig, wenn ein echtes Redaktionsteam WordPress behalten muss und das Frontend wirklich eine Anwendung sein muss. Es ist falsch, wenn jemand einfach nur eine schnellere Broschüren-Website will — das bestehende Theme zu reparieren ist günstiger und risikoärmer, als zwei Plattformen zu betreiben.

Was, wenn Sie sich falsch entscheiden — wie schwer ist ein späterer Wechsel?

Ein Wechsel ist überlebbar, und in eine Richtung deutlich einfacher. Von WordPress zu Next.js ist ein ausgetretener Pfad: Content liegt in einer Datenbank hinter einer dokumentierten API, und URLs sind meist sauber. Von Next.js zurück zu WordPress ist seltener und unordentlicher, weil im Code gespeicherter Content erst zurück in ein Content-Modell übersetzt werden muss.

1. 1

   Zuerst jede live URL erfassen

   Exportieren Sie aus der XML-Sitemap, der Search Console, den Server-Logs und der Analytics. Die Logs sind am wichtigsten — sie zeigen URLs, die noch Traffic und Links erhalten, aber in keiner Sitemap auftauchen.

2. 2

   Das Content-Modell einfrieren, bevor Sie Code schreiben

   Jeder Beitragstyp, jede Taxonomie und jedes Custom Field wird zu einem typisierten Schema. Machen Sie das auf Papier. Ein Feld erst mitten im Build zu entdecken ist genau das, was aus einer vierwöchigen Migration eine zwölfwöchige macht.

3. 3

   Templates neu bauen, nicht Seiten

   Sie portieren acht bis fünfzehn Seitentypen. Wenn Sie einzelne Seiten neu bauen, war das Content-Modell falsch.

4. 4

   Redirects eins zu eins zuordnen

   Jede alte URL löst über genau einen 301 auf, ohne Ketten. Trailing Slashes, Pfade in Großschreibung, paginierte Archive und Query-String-Varianten sind die Stellen, an denen Rankings still versickern.

5. 5

   Parität vor DNS verifizieren, dann Felddaten beobachten

   Crawlen Sie Staging und Produktion und vergleichen Sie Titel, Canonicals, Überschriften, strukturierte Daten und interne Links. Prüfen Sie nach dem Launch einen Monat lang täglich Coverage, Impressionen und Core Web Vitals.

Das ist das Protokoll, mit dem ich Thrifty UAE ohne Ranking-Verlust von einem PHP-Laravel-Monolithen auf Next.js umgezogen habe, und es ist dasselbe bei einer SEO-sicheren Migration oder einem Rebuild, egal wovon Sie kommen. Selten ist die Technologie das Risiko. Nicht abgebildete URLs sind es.

Wie entscheide ich das mit einem Kunden?

Ich frage nach den letzten zehn Änderungswünschen, danach, wer die Website bearbeiten wird, welcher Kanal die Rechnungen bezahlt, und ob es eine Anwendung gibt, neben der diese Website stehen muss. Vier Antworten, zehn Minuten — weit öfter entscheidend als ein Performance-Audit.

Zeigen die Antworten auf WordPress, sage ich das — lieber bevor eine Rechnung existiert als danach. Zeigen sie auf einen Next.js-Build, ist das Argument konkret und überprüfbar statt ideologisch. Jedes Projekt beginnt mit einem ersten Projektgespräch über das, was Sie bereits haben — schicken Sie mir die URL, und ich sage Ihnen ehrlich, ob sich ein Plattformwechsel lohnt oder ob Ihre Website drei Fixes braucht und gar keinen Rebuild.