Von WordPress zu Next.js: „Headless First“ oder ein sauberer Umstieg.

Was wird von WordPress nach Next.js übertragen und was nicht?

Als Daten wandern Ihre Beiträge, Seiten, Kategorien, Tags, Medien und Benutzer. Aber Theme, Plugins und die Ausgabe von Shortcodes bleiben zurück. Prüfen Sie vor der Entwicklung die REST-API: Sie listet /wp/v2/posts, /wp/v2/pages, /wp/v2/categories, /wp/v2/tags, /wp/v2/media und /wp/v2/users (direkt per Browser) und zeigt damit, welche Inhaltstypen wirklich JSON zurückgeben.

Die Layout-Ebene bleibt zurück. Haben Ihre Redakteure Seiten mit Blöcken oder einem Page-Builder gebaut, enthält Ihr „Body“-Feld Roh-HTML oder Block-Markup. Das müssen Sie parsen (zum Beispiel nach „Portable Text“ in Sanity), und dabei zerlegen Sie visuelle Layouts in strukturierte Felder. Formulare und Schieberegler bauen Sie neu, ebenso das Markup aus Plugins. Aber auch Ihre SEO-Metadaten brauchen einen Exportweg: WPGraphQL liefert Yoast-Titel und -Beschreibungen über sein „seo“-Feld.

Öffnen Sie /wp-json/ auf Ihrer Domain. Lesen Sie danach den Quellcode Ihrer Seite, und schon haben Sie in wenigen Minuten eine Liste der Datenlücken (ohne CMS-Zugriff). Die Bewertung nutzt dieselben öffentlichen Signale. So erfasst sie Ihr Markup, Ihre Header und strukturierte Daten, noch bevor Sie eine Zeile Code festschreiben.

Wie planen Sie die URL-Struktur und Weiterleitungen, damit Ihr Suchverkehr erhalten bleibt??

Weisen Sie zuerst jeder alten URL eine neue URL zu (das ist Ihre URL-Zuordnung). Danach richten Sie dauerhafte serverseitige Weiterleitungen ein, damit Ihr Suchverkehr den Seiten folgt. Google fordert Sie auf, alte URLs neuen zuzuordnen und Weiterleitungsketten zu vermeiden. Außerdem sollen Sie eine neue Sitemap einreichen und den Traffic auf beiden Seiten beobachten. Und ohne Zuordnung raten Sie nur blind ins Blaue.

In Next.js schreiben Sie Ihre Regeln in die Option „redirects“ der Datei „next.config.js“. Aber testen Sie sie zuerst. Die Einstellung „permanent: true“ sendet einen 308-Status, den Browser und Suchroboter auf unbestimmte Zeit zwischenspeichern (ein falscher Redirect klebt ewig fest). Prüfen Sie deshalb jede Regel, bevor Sie sie veröffentlichen. Pfadmuster werden vom Stammverzeichnis aus abgeglichen, und „/old-blog/:slug“ erfasst „/old-blog/a/b“ nicht. Für verschachtelte URLs brauchen Sie daher eigene Regeln. Das Muster greift deutlich enger, als es aussieht.

Lassen Sie Ihre Weiterleitungen mindestens ein Jahr lang aktiv. Entfernen Sie alle „noindex“-Tags oder „robots disallow“-Regeln, die aus der Staging-Umgebung übrig sind, und setzen Sie Ihre Canonical-Tags auf die neuen URLs. Sperrt Ihr Headless-Backend Suchmaschinen aus, kann das SEO-Feld jedes Beitrags „noindex“ zurückgeben, und Ihre Yoast-URLs zeigen unter Umständen auf Ihren CMS-Host (statt auf die Live-Domain). Und genau solche Reste aus der Staging-Umgebung sind der stille Grund, warum ein Relaunch scheitert.

Wie werden Inhalte aus WordPress übertragen: Export, API oder Crawling??

Sobald Ihre Website mehr als nur ein paar Seiten hat, migrieren Sie Ihre Inhalte über die API: Die REST-API gibt Beiträge, Seiten, Tags, Kategorien und Medien als JSON zurück. Gerendertes HTML lesen Sie nur als Ausweichweg aus (wenn in den Endpunkten Daten fehlen). Nehmen Sie dafür das API-Muster von Sanity. Ein CLI-Skript fragt die REST-API ab, schreibt Dokumente und läuft seitenweise weiter, bis keine Antworten mehr zurückkommen.

Die Medienliste gibt pro Seite standardmäßig 10 Einträge zurück, Ihr Skript muss deshalb in einer Abrufschleife die Parameter „page“ und „per_page“ setzen. Die Tools von Sanity schreiben Änderungen stapelweise. Sie laufen standardmäßig im Trockenlauf und prüfen Ihre Dokumente gegen Ihr Studio-Schema (Fehler fallen so auf, bevor Datensätze geschrieben werden). Bauen Sie Ihr Skript mit deterministischen IDs idempotent, und laden Sie Assets parallel hoch, aber mit einer Ratenbegrenzung wie „p-limit“. Und vor einem Skript, das Sie nicht jederzeit sicher erneut ausführen können, haben Sie im Ernstfall zu Recht Respekt.

Rendert ein Page-Builder Ihr Markup, crawlen Sie die Ausgabe, parsen das HTML und gleichen die Gesamtzahlen Ihrer Datensätze mit Ihrer Master-URL-Liste ab. Und tun Sie das vor dem Livegang (solange Fehler nichts kosten). Danach sind es die Probleme Ihrer Leser.

Was erhalten Ihre Redakteure bei Next.js im Vergleich zu WordPress??

Beim Umstieg auf Headless behalten Ihre Redakteure den WordPress-Admin-Bereich; migrieren Sie Ihre Inhalte, bekommen sie einen neuen Editor in Sanity Studio oder Contentful. In beiden Fällen verschwindet die visuelle Arbeitsfläche Ihres Themes und Page-Builders. Aber der Arbeitsalltag ändert sich grundlegend: Ihre Redakteure bearbeiten künftig strukturierte Felder und füllen Formulare aus, statt Seiten direkt in der Leseransicht zusammenzuklicken.

Vorschauen sind der erste Punkt, den Ihre Redakteure ansprechen. Bauen Sie in Next.js eine Vorschau-Route, die Inhaltsentwürfe abruft, und testen Sie sie vor dem Livegang mit Ihrem langsamsten Redakteur. Doch bei ISR passiert etwas Unscheinbares: Die erste Anfrage nach Ablauf Ihres Revalidate-Fensters liefert weiterhin den alten Stand aus, während die Neugenerierung im Hintergrund läuft. Sagen Sie das Ihrem Team früh.

Als Nächstes spüren Sie die Plugins. Ihre SEO-, Formular- und Weiterleitungs-Plugins laufen im neuen Frontend nicht mehr; jede Funktion müssen Sie als Feld, Dienst oder Routing-Regel neu bauen. Aber dafür gewinnen Sie etwas Handfestes: Ein Plugin-Update Ihrer Redakteure kann das Frontend dann schlicht nicht mehr kaputtmachen.

Wie lange dauert eine Migration von WordPress zu Next.js, und wovon hängt der Aufwand ab??

Wie lange Ihre Migration dauert, hängt zuerst von der Zahl Ihrer URLs und Inhaltstypen ab. Auch Ihre Medienbibliothek zählt, ebenso Ihre Integrationen und Sprachversionen. Ein öffentlicher Scan kann keinen Termin zusagen. Doch von außen erfassen Sie diese Faktoren trotzdem: Ihre Sitemap liefert die Zahl der URLs, Ihre /wp-json/-Routen zeigen die Inhaltstypen (und deren Struktur), während Formulare und Skripte Ihre Integrationen verraten. Zählen Sie zuerst. Dann schätzen Sie.

Diese Faktoren verstärken sich gegenseitig. Viele URLs bei einem Inhaltstyp bedeuten meist viele Weiterleitungen. Wenige URLs bei vielen Inhaltstypen bedeuten meist Aufwand bei der Schemamodellierung. Zeigt Ihre Medienliste standardmäßig 10 Einträge an, erzeugt eine große Bibliothek Tausende Anfragen; jede zusätzliche Sprachversion vervielfacht außerdem jede URL, die Sie zuordnen. Und aus der Praxis solcher Umstellungen bestätigt sich die Regel: Zeitaufwendig ist selten der Bau selbst. Weitaus mehr Zeit kostet die Einigung darauf, wie Ihre Inhalte aufgebaut sein sollen.

Mit ISR aktualisieren Sie zwischengespeicherte statische Inhalte, ohne die gesamte Website neu zu bauen. So wachsen Ihre Deployment-Zeiten nicht mehr automatisch mit der Zahl Ihrer Seiten.

Wann sollten Sie nicht von WordPress zu Next.js wechseln??

Ändern Sie nichts, wenn Ihre Website einwandfrei läuft, Ihre Redakteure gut damit arbeiten und kein Problem mit Anwendungen, Personalisierung oder Redaktionssystem besteht, das ein neues Frontend lösen würde. Bleiben Sie bei Ihrem jetzigen Aufbau, bis handfeste Fakten etwas anderes verlangen. Machen Sie zuerst die kostenlose Bewertung. Liegt Ihre Punktzahl im Bereich von 80 bis 100, ist die aktuelle Version nicht Ihr Engpass. Und ein Umbau bindet dann nur Budget und gefährdet Ihren Suchverkehr, bei verschwindend geringem Ertrag.

„Headless WordPress“ lohnt sich als Zwischenschritt nur dann, wenn Ihre Redakteure ihren Admin-Bereich behalten müssen und Ihr Frontend das eigentliche Problem ist. Sonst betreiben Sie zwei Systeme: WordPress für Inhalte und Next.js für Seiten. Beide müssen Sie aktualisieren, hosten und überwachen. Wenn Sie umsteigen, wählen Sie den Stack passend zur Website: Astro für eine Inhalts- oder Marketing-Website, Next.js mit Sanity oder Contentful, wenn Sie eine Anwendung betreiben, Personalisierung einsetzen oder ein großes Redaktionsteam haben. Doch jeder dieser Wege nimmt Ihren Redakteuren, was sie gewohnt sind: die visuelle Arbeitsfläche, Plugins und einen gehosteten Admin-Bereich (alle drei, nicht nur eines).

Fragen und Antworten.

Weiterlesen.

1. 01WordPress-AlternativenBleiben, auf Headless umsteigen oder wechseln: Das hängt von Ihren Seiten ab.
2. 02WordPress zu AstroVorgefertigte Seiten, Inhalte im Markdown-Format oder in einem Headless-CMS.
3. 03Next.js-SEO-AuditRendering-Modus, Metadaten, Hydration-Kosten.
4. 04Headless-CMS-SEO-AuditRendering, Canonicals, Vorschauen, strukturierte Daten aus dem Template.