Dein Besucher landet auf deiner WordPress-Startseite und wartet. Der Server startet PHP, fragt die Datenbank siebzehnmal ab, führt Theme-Funktionen aus, lädt Plugin-Hooks, rendert das DOM und malt schließlich Text — 2,8 Sekunden nach dem Klick. Du hast bereits drei Caching-Plugins installiert. Dein LCP liegt immer noch bei 3,1 Sekunden, dein CLS springt bei Schriftwechsel auf und ab, und Google Search Console meldet immer wieder die gleichen Core Web Vitals Fehler. Das Problem ist nicht dein Hosting oder dein CDN. WordPress wurde 2003 entwickelt, um Blog-Posts mit serverseitigem PHP bei jeder Anfrage zu rendern. Zwei Jahrzehnte später fragst du diese gleiche Laufzeit ab, um Marketing-Seiten, E-Commerce-Plattformen und Web-Apps zu betreiben — während Googles Core Web Vitals Algorithmus entscheidet, ob jemand deine Inhalte findet. Kein Plugin kann das Execution-Modell umschreiben, aber eine Next.js-Migration kann. Hier ist die technische Aufschlüsselung, was kaputt geht und die genauen Muster, die es beheben.

Dieser Artikel schlüsselt genau auf, warum WordPress-Seiten langsam sind, ordnet jedes Problem den Core Web Vitals Metriken zu, die darunter leiden, und zeigt dir, wie eine headless Next.js-Architektur sie an der Wurzel behebt. Nicht mit Flickschusterei. An der Wurzel.

Inhaltsverzeichnis

Why Your WordPress Site Is Slow and How Next.js Fixes It

Core Web Vitals 2026 verstehen

Google hat seine Core Web Vitals im März 2024 aktualisiert und First Input Delay (FID) durch Interaction to Next Paint (INP) ersetzt. Diese Änderung ist wichtiger, als die meisten Menschen realisieren. Hier sind die vier Metriken, die deine Seiten-Performance-Note bestimmen:

Metrik Was es misst Gut Verbesserungsbedürftig Schlecht
LCP (Largest Contentful Paint) Wie schnell dein Hauptinhalt lädt ≤ 2,5s 2,5s – 4,0s > 4,0s
INP (Interaction to Next Paint) Reaktionsfähigkeit auf Benutzereingaben ≤ 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) Visuelle Stabilität während des Ladens ≤ 0,1 0,1 – 0,25 > 0,25
TTFB (Time to First Byte) Server-Antwortzeit ≤ 800ms 800ms – 1800ms > 1800ms

Laut Chrome UX Report von Anfang 2026 erfüllen nur 42% der WordPress-Ursprünge alle drei Core Web Vitals Schwellenwerte. Vergleiche das mit 67% für Next.js-betriebene Ursprünge. Das ist kein marginaler Unterschied — es ist eine andere Liga.

Warum diese Metriken wirklich wichtig sind

Google ist klar: Core Web Vitals sind ein Ranking-Signal. Aber über SEO hinaus korrelieren diese Metriken direkt mit Umwandlungsraten. Vodafone stellte fest, dass eine 31%ige Verbesserung beim LCP zu einer 8%igen Steigerung des Umsatzes führte. Shopifys interne Daten zeigen, dass jede 100ms-Reduzierung der Seitenladezeit die Konversion um 1,3% erhöht.

Deine WordPress-Seite ist nicht nur langsam. Sie kostet dich Geld.

Warum WordPress architektonisch langsam ist

Lass mich dir durchgehen, was passiert, wenn jemand eine typische WordPress-Seite besucht:

  1. DNS-Lookup → löst deine Domain auf
  2. TCP/TLS-Handshake → stellt sichere Verbindung her
  3. Request trifft den Server → Apache/Nginx empfängt ihn
  4. PHP startet WordPress → lädt wp-config.php, initialisiert den WordPress-Core
  5. Plugin-Initialisierung → jedes aktive Plugin hooks in init, wp_loaded etc.
  6. Theme lädt → functions.php läuft, Template-Hierarchie wird aufgelöst
  7. Datenbankabfragen ausführen → WP_Query läuft, oft 30-100+ Abfragen pro Seite
  8. PHP rendert HTML → Template-Dateien generieren die volle Seite
  9. HTML an Browser gesendet → endlich beginnt die Antwort
  10. Browser parst HTML → entdeckt CSS, JS, Schriftarten, Bilder
  11. Render-blockierende Ressourcen laden → Stylesheets von 15 verschiedenen Plugins
  12. Seite rendert endlich → Benutzer sieht Inhalte

Schritte 4 bis 9 passieren bei jeder single nicht-gecachten Anfrage. Das ist PHP, das 200+ Dateien parst, Dutzende Datenbankabfragen ausführt und HTML generiert — alles bevor der Browser ein einzelnes Byte erhält.

Das PHP-Problem

PHP 8.3 ist erheblich schneller als PHP 7.x, und die meisten WordPress-Hosts unterstützen es jetzt. Aber selbst mit PHP 8.3 und aktiviertem OPcache läufst du immer noch einen synchronen, blockierenden Prozess. Der WordPress-Core allein lädt ungefähr 100.000 Zeilen PHP-Code bei jeder Anfrage. Füge WooCommerce hinzu und du bist über 400.000 Zeilen.

Hier ist die Sache: Caching-Plugins wie WP Super Cache oder W3 Total Cache funktionieren, indem sie diesen Prozess unterbrechen — sie servieren stattdessen eine vorgenerierte HTML-Datei. Aber sie führen ihre eigene Komplexität ein, brechen bei personalisiertem Inhalt und können immer noch nicht beheben, was im Browser passiert.

Das Theme-Problem

Die meisten WordPress-Themes sind für Flexibilität gebaut, nicht für Performance. Ein Theme wie Avada, Divi oder Elementor lädt sein gesamtes CSS- und JavaScript-Framework auf jeder Seite, egal ob du diese Funktionen nutzt oder nicht. Ich habe Elementor-Seiten gesehen, die 2,5MB CSS und 1,8MB JavaScript auf einem einfachen Blog-Post laden.

<!-- Typischer WordPress head auf einer Page-Builder-Seite -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 weitere Stylesheets -->

Jedes davon ist eine render-blockierende Ressource. Dein LCP kann nicht stattfinden, bis alle heruntergeladen und geparst sind.

Plugin-Übergewicht: Der stille Performance-Killer

Die durchschnittliche WordPress-Seite läuft 20-30 Plugins. Ich habe Seiten mit 70+ gesehen. Jedes Plugin könnte:

  • Seine eigenen CSS- und JS-Dateien hinzufügen (oft auf jeder Seite, selbst wo nicht verwendet)
  • WordPress-Hooks registrieren, die bei jeder Anfrage ausgeführt werden
  • Seine eigenen Datenbankabfragen ausführen
  • Seine eigenen PHP-Dateien während der Bootstrap-Phase laden
  • Inline-Skripte und Styles zu <head> hinzufügen

Ein echtes Beispiel

Ich habe kürzlich eine Marketing-Seite mit WordPress und 34 aktiven Plugins überprüft. Hier ist, wie der Netzwerk-Wasserfall aussah:

  • 47 CSS-Dateien auf der Startseite geladen
  • 38 JavaScript-Dateien auf der Startseite geladen
  • Gesamtseitengröße: 4,7MB
  • Gesamtanfragen: 127
  • LCP: 6,8 Sekunden auf 4G
  • TTFB: 2,1 Sekunden

Der Kunde hatte bereits ein Optimierungs-Plugin (Autoptimize) und ein Caching-Plugin (LiteSpeed Cache) installiert. Selbst mit beiden aktiv lag das LCP bei 4,2 Sekunden. Immer noch fehlgeschlagen.

Das Kernproblem? Du kannst das fundamentale Problem nicht weglösen, Code zu laden, den du nicht brauchst. 47 CSS-Dateien zu minimieren und zu kombinieren lässt dich immer noch mit einer massiven CSS-Nutzlast, die das Rendern blockiert.

Die Plugin-Abhängigkeitsfalle

Hier ist, was das noch schlimmer macht: Plugins hängen von anderen Plugins ab. Du installierst WooCommerce, dann brauchst du ein Payment-Gateway-Plugin, dann ein Shipping-Calculator-Plugin, dann ein Product-Filter-Plugin. Jedes fügt Gewicht hinzu. Du kannst keines entfernen, ohne die Funktionalität zu brechen.

Das ist die WordPress-Falle. Die Architektur ermutigt, Plugins für alles zu verwenden, und es gibt keinen Mechanismus, um ungenutzten Code zu tree-shaken.

Why Your WordPress Site Is Slow and How Next.js Fixes It - architecture

Datenbankabfrage-Probleme, die Plugins nicht beheben können

WordPress verwendet eine einzelne MySQL-Datenbank mit einem notorisch flachen Schema. Die wp_options-Tabelle ist mit autoload='yes'-Einträgen bei jeder single Anfrage gefüllt. Ich habe wp_options-Tabellen mit 3.000+ autoload-Zeilen gesehen, die insgesamt 8MB Daten ausmachten.

-- Überprüfe deine autoload-Optiongröße
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- Wenn das > 1MB zurückgibt, hast du ein Problem

Die wp_postmeta-Tabelle ist ein weiterer Alptraum. Sie speichert alles als Schlüssel-Wert-Paare, was bedeutet, dass WordPress keine effizienten Abfragen durchführen kann. Du möchtest alle Produkte unter €50 finden? Das ist ein JOIN auf wp_postmeta mit einem String-Vergleich auf einem Text-Feld, das eine Zahl speichert. Kein Index kann dich retten.

Realitätscheck der Abfragezahl

Installiere das Query Monitor-Plugin auf deiner WordPress-Seite und schau dir die Abfagezahl an. Eine "einfache" WooCommerce-Produktseite läuft typischerweise 150-300 Datenbankabfragen. Ein Blog-Post mit verwandten Posts, beliebten Posts-Seitenleiste und Breadcrumbs? Üblicherweise 80-120 Abfragen.

Vergleiche das mit einem Headless-Ansatz, wo dein Next.js-Frontend genau eine API-Anfrage (oder null, wenn Static Generation verwendet wird) tätigt, um alle benötigten Daten zu erhalten.

WordPress-Hosting: Du zahlst wahrscheinlich zu viel für Mittelmäßigkeit

Lass uns über Hosting sprechen, denn hier wird viel Geld verschwendet.

Hosting-Typ Monatliche Kosten Typischer TTFB Kann Architektur beheben?
Shared (GoDaddy, Bluehost) €3-15 1,5-4,0s Nein
Managed WordPress (WP Engine, Flywheel) €25-300 400ms-1,2s Nein
Premium Managed (Kinsta, Pagely) €35-600 200ms-600ms Nein
VPS/Dedicated (DigitalOcean, AWS) €20-500 200ms-800ms Nein
Next.js auf Vercel/Edge €0-20 50-150ms Ja

Bemerke die letzte Spalte. Kein Hosting-Upgrade behebt die architektonischen Probleme. Du zahlst Premium-Preise, um PHP schneller laufen zu lassen, wenn die echte Lösung ist, PHP nicht bei jeder Anfrage auszuführen.

Kinsta verrechnet €35/Monat für ihren Starter-Plan mit 25.000 Besuchen. Vercel-Free-Tier verarbeitet 100GB Bandbreite. Selbst Vercel-Pro-Plan bei €20/Monat gibt dir Edge-Deployment über sein globales CDN. Die Mathematik lügt nicht.

Wie Next.js jede Core Web Vital behebt

Lass mich spezifisch werden. Hier ist, wie Next.js (besonders mit dem App Router in Next.js 14/15) jede Metrik adressiert:

TTFB beheben

Next.js gibt dir mehrere Rendering-Strategien:

// Static Generation - TTFB praktisch null (von CDN serviert)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// Das wird zur Build-Zeit vorgeneriert
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

Mit Static Generation werden deine Seiten vorgenerierte HTML-Dateien serviert von Edge-CDN-Knoten weltweit. TTFB fällt auf 50-100ms unabhängig davon, wo deine Benutzer sind. Keine PHP-Ausführung, keine Datenbankabfragen, keine serverseitige Verarbeitung zur Request-Zeit.

Für dynamische Inhalte unterstützt Next.js ISR (Incremental Static Regeneration), das gecachte statische Seiten serviert und im Hintergrund revalidiert:

// Revalidiere alle 60 Sekunden
export const revalidate = 60;

LCP beheben

Next.js beinhaltet die <Image>-Komponente, die alles verarbeitet, das WordPress-Plugins versuchen (und verfehlen):

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero-Banner"
      width={1200}
      height={600}
      priority // Preloads das LCP-Bild
      sizes="100vw"
      // Generiert automatisch srcset, nutzt WebP/AVIF,
      // lazy loads standardmäßig, verhindert CLS
    />
  );
}

Die priority-Prop sagt Next.js, das Bild vorzuladen und direkt das LCP zu verbessern. Die automatische Format-Aushandlung serviert WebP oder AVIF für unterstützte Browser und reduziert Bildgröße um 30-50% im Vergleich zu JPEG. Kein Plugin nötig.

Next.js eliminiert auch render-blockendes CSS durch CSS Modules und automatische kritische CSS-Extraktion. Nur das auf einer spezifischen Seite verwendete CSS wird geladen.

INP beheben

INP misst, wie schnell deine Seite auf Benutzerinteraktionen reagiert. WordPress-Seiten verfehlen INP wegen:

  • Schweres JavaScript von Plugins, die den main thread blockieren
  • jQuery und seine Plugins, die um Execution-Zeit konkurrieren
  • Keine Code-Aufteilung — alles lädt upfront

Next.js verarbeitet das mit automatischer Code-Aufteilung. Jede Seite lädt nur das JavaScript, das sie braucht:

// Diese Komponente lädt nur, wenn der Benutzer zu ihr scrollt
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // Nicht auf Server rendern
});

React Server Components (Standard im App Router) gehen noch weiter: Komponenten, die keine Interaktivität brauchen, senden Null-JavaScript zum Browser. Ein Blog-Post ohne interaktive Elemente? Null KB Komponenten-JavaScript.

CLS beheben

CLS in WordPress kommt üblicherweise von:

  • Bildern ohne explizite Dimensionen
  • Ads, die zu spät laden und Inhalte nach unten schieben
  • Web-Fonts, die FOUT/FOIT verursachen
  • Von Plugins injizierte Banner, die nach Load erscheinen

Next.js verhindert CLS standardmäßig. Die <Image>-Komponente erfordert Dimensionen (oder nutzt fill mit einem größenbestimmten Container). Das next/font-Modul inline Font-Deklarationen und nutzt font-display: swap mit Null Layout-Shift:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

Kein FOUT. Kein Layout-Shift von Fonts. Es funktioniert einfach.

Die Headless-Architektur: WordPress als CMS, Next.js als Frontend

Hier ist der Teil, den viele Leute missen: Headless zu gehen bedeutet nicht, WordPress aufzugeben. Es bedeutet, WordPress für das zu nutzen, wofür es wirklich gut ist — Content-Management — während Next.js das Frontend verarbeitet.

Die Architektur sieht so aus:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
Content-Editoren                              Deine Benutzer
nutzen das vertraute                          erhalten schnelle Seiten
WP-Dashboard                                  von Edge serviert

Dein Content-Team behält seinen Workflow. Deine Benutzer erhalten eine schnelle Seite. Du erhältst sauberen, wartbaren Code.

Wir machen viel von dieser Art Arbeit in unserer Next.js-Entwicklungspraxis und Headless-CMS-Entwicklung. Das Muster ist gut etabliert und kampfgetestet.

Was ist mit anderen Headless-CMS-Optionen?

WordPress ist nicht die einzige Option für die Content-Layer. Wenn du von Grund auf neu anfängst, sind zweckgebundene Headless-CMS-Plattformen wie Sanity, Contentful oder Storyblok oft bessere Wahlen. Sie sind API-first gebaut, also gibt es keinen Legacy-Ballast.

Aber wenn du Jahre von Inhalten in WordPress hast und ein Team, das darin trainiert ist, ist Headless WordPress mit WPGraphQL ein vollkommen gültiger Ansatz.

Echte Performance-Benchmarks: WordPress vs. Next.js

Hier sind echte Zahlen von Migrationen, die wir gemacht haben und öffentlich verfügbare Case Studies:

| Metrik | WordPress (optimiert) | Next.js (statisch) | Verbesserung | |--------|----------------------|-------------------|-------------|| | TTFB | 650ms | 80ms | 87% schneller | | LCP | 3,8s | 1,2s | 68% schneller | | INP | 380ms | 90ms | 76% schneller | | CLS | 0,18 | 0,01 | 94% besser | | Seitengröße | 3,2MB | 450KB | 86% leichter | | Anfragen | 85 | 12 | 86% weniger | | Lighthouse-Score | 45-65 | 95-100 | Tag und Nacht |

"Optimiert" WordPress bedeutet: PHP 8.3, Redis-Objekt-Cache, CDN, Bildoptimierungs-Plugin, Caching-Plugin, Datenbankoptimierung. All die Dinge, die du tun sollst. Und es ist immer noch nicht nah dran.

Migrationspfad: Von monolithischem WordPress zu Headless Next.js

Migration muss nicht alles-oder-nichts sein. Hier ist der phasierte Ansatz, den wir üblicherweise empfehlen:

Phase 1: Bewertung (1-2 Wochen)

  • Überprüfe aktuelle WordPress-Seiten-Performance mit PageSpeed Insights und CrUX-Daten
  • Inventarisiere alle Plugins und ordne sie Frontend vs. Backend-Funktionalität zu
  • Identifiziere Content-Modelle und benutzerdefinierte Felder
  • Bewerte, ob WordPress als Headless-CMS beibehalten oder Inhalte komplett migriert werden

Phase 2: Frontend-Bau (4-8 Wochen)

  • Richte Next.js-Projekt mit dem App Router auf
  • Installiere und konfiguriere WPGraphQL auf WordPress
  • Baue Komponenten-Bibliothek, die aktuelles Design entspricht (oder redesigne — gute Zeit dafür)
  • Implementiere Static Generation für Content-Seiten
  • Richte Preview-Modus für Content-Editoren auf

Phase 3: Launch und Weiterleitungen (1-2 Wochen)

  • Stelle Next.js-Frontend auf Vercel bereit (oder Netlify oder Cloudflare Pages)
  • Konfiguriere DNS und Weiterleitungen
  • Verifiziere, dass alle URLs ordnungsgemäß weitergeleitet werden (SEO-Erhaltung ist kritisch)
  • Sperre WordPress-Admin ab (entferne öffentlichen Zugang)

Phase 4: Optimierung (laufend)

  • Überwache Core Web Vitals in Google Search Console
  • Optimiere ISR-Revalidierungsintervalle
  • Füge Edge Middleware für Personalisierung hinzu
  • Erwäge Migration zu einem zweckgebundenen Headless-CMS, wenn WordPress ein Engpass wird

Wenn du diese Art Migration in Betracht ziehst, kannst du unsere Preisseite für Ballpark-Zahlen überprüfen oder direkt Kontakt aufnehmen, um deine spezifische Situation zu diskutieren.

Für Seiten, die stattdessen mit Astro gebaut sind (besonders inhaltslastige Blogs und Marketing-Seiten), haben wir auch eine Astro-Entwicklungspraxis, die noch aggressivere Performance für statisch-first Seiten liefert.

FAQ

Kann ich WordPress beschleunigen, ohne zu Next.js zu wechseln?

Ja, bis zu einem Punkt. Beginne mit einem qualitätsvollen Host (Kinsta oder Cloudways), aktiviere Redis-Objekt-Caching, nutze ein leichtes Theme wie GeneratePress, reduziere Plugins auf unter 15 und konfiguriere ein CDN. Du kannst auf diese Weise eine WordPress-Seite in den "Verbesserungsbedürftig"-Bereich für Core Web Vitals bekommen. Aber durchgehend in den "Gut"-Bereich über alle Metriken zu brechen — besonders INP — ist mit einer traditionellen WordPress-Architektur extrem schwierig.

Wie viel kostet eine Migration von WordPress zu Headless Next.js?

Es hängt von der Site-Komplexität ab. Eine einfache Marketing-Seite (10-30 Seiten, Blog) läuft üblicherweise €15.000-€40.000 für eine volle Migration. E-Commerce-Seiten mit WooCommerce sind mehr involviert, von €50.000-€150.000+. Der ROI kommt üblicherweise von verbesserten Umwandlungsraten und reduzierten Hosting-Kosten. Unsere Preisseite hat mehr Details.

Werden meine SEO-Rankings fallen, wenn ich zu Next.js wechsle?

Nicht, wenn du die Migration ordnungsgemäß verarbeitest. Ordnungsgemäße 301-Weiterleitungen, identische URL-Strukturen (oder gemappte Weiterleitungen), gültige Meta-Tags, strukturierte Daten und eine XML-Sitemap sind alle essentiell. Next.js hat tatsächlich SEO-Vorteile — schnellere Core Web Vitals verbessern Rangfolgen direkt, und die Metadata API macht es einfach, Meta-Tags programmgesteuert zu verwalten. Die meisten Seiten sehen Rangfolge-Verbesserungen innerhalb von 2-3 Monaten nach der Migration.

Verlieren Content-Editoren das WordPress-Admin, wenn wir Headless gehen?

Nein. In einem Headless-Setup dient WordPress weiterhin als Content-Management-Backend. Editoren nutzen das gleiche Dashboard, den gleichen Editor, den gleichen Workflow. Sie sehen nur das Frontend-Theme nicht mehr — stattdessen nutzen sie einen Preview-Button, der die Next.js-gerenderte Version zeigt. Einige Teams finden, das ist tatsächlich besser, weil die Preview eine genaue Darstellung der Production-Seite ist.

Was ist mit WooCommerce — kann Next.js E-Commerce verarbeiten?

Ja, aber es ist ein größeres Projekt. Du kannst WooCommerce headless über seine REST API oder die WPGraphQL WooCommerce-Extension nutzen. Alternativ migrieren viele Teams zu Shopifys Storefront API oder Saleor für das Commerce-Backend, nutzen Next.js als Frontend. Der Checkout-Flow erfordert sorgfältige Verarbeitung, da er Zahlungsverarbeitung und PCI-Compliance involviert. Es ist möglich, aber planen für extra Entwicklungszeit.

Ist Next.js die einzige Option für ein schnelles Frontend?

Nein. Astro, Remix, SvelteKit und sogar Nuxt (für Vue-Teams) sind alle tauglich. Astro ist besonders exzellent für inhaltslastige Seiten, weil es standardmäßig Null-JavaScript verschifft. Next.js gewinnt für Seiten, die signifikante Interaktivität, dynamische Features oder E-Commerce brauchen. Wir arbeiten mit beiden Next.js und Astro je nach Projekt-Bedarf.

Wie funktioniert Incremental Static Regeneration (ISR) mit WordPress-Inhalten?

Wenn du einen Post in WordPress veröffentlichst oder aktualisierst, feuert ein Webhook und sagt deinem Next.js-Deployment, diese spezifische Seite zu revalidieren. Der nächste Besucher erhält eine frisch generierte statische Seite, die dann im Edge gecacht wird. Die Revalidierung passiert im Hintergrund, also warten Benutzer nie auf einen Build. Du kannst auch zeitbasierte Revalidierung setzen (z.B. jeden 60 Sekunden neubauen) als Fallback.

Was ist der größte Fehler, den Teams machen, wenn sie Headless gehen?

Versuch, ihre WordPress-Seite 1:1 in Next.js zu replizieren. Eine Headless-Migration ist eine Gelegenheit, deine Content-Architektur zu überdenken, deine Seiten-Strukturen zu vereinfachen und Jahre angesammelter Unordnung zu eliminieren. Teams, die es als frischen Start behandeln — behalten den Inhalt aber überdenken die Präsentation — enden mit dramatisch besseren Ergebnissen als Teams, die versuchen, jedes Widget und jede Seitenleiste aus ihrem alten Theme zu kopieren.