WordPress zu Next.js migrieren: Ablauf, Dauer und SEO-Sicherung
Der Umzug von WordPress zu Next.js oder Astro in sechs Phasen: Redirect-Map fuer jede alte URL, Content-Migration nach Sanity, SEO-Paritaet beim Launch. Dauer 3-6 Wochen, Preis ab 8.000 Euro netto.
Eine WordPress-Website lässt sich zu Next.js migrieren, ohne Rankings zu verlieren, wenn jede alte URL eine 1:1-Weiterleitung bekommt und Inhalte, Titel und Meta-Angaben vollständig mitwandern. Next.js steht hier für das Code-System als Ganzes. Ohne App-Logik, Login oder serverseitige Daten pro Anfrage bauen wir denselben Weg mit Astro, die Phasen sind identisch. Eine Marketing-Website mit 10-30 Seiten ist bei uns typischerweise in 3-6 Wochen live, danach folgen zwei Wochen Monitoring. Dieser Artikel zeigt die zwei möglichen Wege, sechs Projektphasen, eine Übernahme-Tabelle pro Inhaltstyp, die fünf realen Risiken und was das Projekt kostet.
Das Wichtigste in Kürze
- Ranking-Verlust ist kein Naturgesetz: Er entsteht, wenn die Redirect-Map Lücken hat, nicht durch den Wechsel des Systems.
- Zwei Wege, eine Entscheidung: WordPress als Headless-Backend behalten oder Inhalte nach Sanity umziehen und WordPress abschalten. Wir empfehlen Weg zwei.
- Dauer: 3-6 Wochen bis Go-Live bei 10-30 Seiten, plus zwei Wochen Monitoring mit 404-Report und Ranking-Abgleich.
- Preis: Wir rechnen die Migration als Relaunch-Projekt ab, unsere Relaunch-Pakete starten bei 8.000 Euro netto.
- Laufend: Sanity Free deckt 20 Plätze, 10.000 Dokumente und 100 GB Assets ab, Vercel Pro kostet 20 $ pro Monat und Entwickler-Platz. Nahezu keine laufenden Plattformgebühren.
- Ohne App-Logik, Login oder serverseitige Daten pro Anfrage ist Astro der Default, Next.js kommt, sobald eine dieser drei Anforderungen auftaucht.
Die kurze Antwort
Der Umzug von WordPress zu Next.js läuft in sechs Phasen: Audit und Redirect-Map, Content-Modell in Sanity, Content-Migration, Frontend-Aufbau, SEO-Parität und Launch, Monitoring. Die Rankings bleiben stehen, wenn drei Dinge stimmen: Jede alte URL zeigt per 301-Weiterleitung auf genau ein neues Ziel, die Inhalte kommen vollständig mit, und Titel, Meta-Descriptions, Canonicals (die Angabe, welche URL die maßgebliche Fassung einer Seite ist) sowie strukturierte Daten werden unverändert übernommen. Mehr dazu im Leitfaden zum Relaunch ohne SEO-Verlust.
Next.js steht in diesem Artikel für das Code-System als Ganzes. Brauchst du keine App-Logik, keinen Login und keine serverseitig pro Anfrage berechneten Daten, bauen wir dieselbe Website mit Astro, und der Ablauf ändert sich an keiner Stelle. Astro liefert für statische Inhalte standardmäßig 0 KB JavaScript, nur interaktive Teile laden Skripte. Deshalb ist Astro unser Default und Next.js die Wahl, sobald Login, Dashboard oder personalisierte Inhalte dazukommen. Die Unterschiede im Detail stehen im Vergleich Astro vs. Next.js.
Zur Abrechnung: Wir behandeln eine Migration als Relaunch-Projekt, unsere Relaunch-Pakete starten bei 8.000 Euro netto. Der Umzug einer Marketing-Website mit 10-30 Seiten dauert typischerweise 3-6 Wochen bis Go-Live, das Monitoring kommt obendrauf. Laufend zahlst du danach kaum noch Plattformgebühren: Sanity Free umfasst 20 Plätze, 10.000 Dokumente, 100 GB Assets und 100 GB Bandbreite pro Monat, Vercel Pro kostet 20 $ pro Monat und Entwickler-Platz. Theme- und Plugin-Lizenzen fallen weg. Was ein solches Projekt insgesamt bedeutet, rechnen wir in Webentwicklung Kosten durch.
Zwei Wege, und wir bauen nur einen davon
Eine Entscheidung bestimmt alles danach: Bleibt WordPress als Redaktionssystem im Hintergrund stehen und liefert nur noch Daten an ein neues Frontend, oder ziehen die Inhalte nach Sanity um und WordPress wird abgeschaltet? Der erste Weg heißt headless, also WordPress ohne eigene Ausgabe-Schicht, die Inhalte kommen über die REST-API oder WPGraphQL, eine Abfrage-Schnittstelle für WordPress-Daten. Beide Wege führen zu einer schnellen Website. Sie unterscheiden sich in dem, was du danach noch pflegen musst.
Wir sagen offen, wo wir stehen: Wir bauen den zweiten Weg. Headless WordPress kostet denselben Relaunch-Aufwand und lässt die WordPress-Installation trotzdem stehen, mit Updates, Plugin-Abhängigkeiten und Angriffsfläche. Wir haben den ersten Weg in Headless WordPress trotzdem im Detail beschrieben, damit du die Rechnung selbst nachvollziehen kannst.
Headless WordPress bleibt eine Ausnahme
WordPress als Backend zu behalten ist genau dann vertretbar, wenn an der Installation Geschäftslogik hängt, die du kurzfristig nicht ersetzen kannst. Alles andere ist Gewöhnung, und Gewöhnung ist ein schlechter Grund, dauerhaft zwei Systeme zu betreiben.
- WooCommerce oder ein Mitglieder-Plugin trägt Umsatzlogik, die du nicht in einem Zug ersetzen willst.
- Eine Schnittstelle in ein ERP oder eine Kundendatenbank ist gegen WordPress gebaut und hat einen eigenen Wartungsvertrag.
- In beiden Fällen gilt: Headless mit Enddatum, nicht als Dauerzustand. Ohne Enddatum bleibt es ein zweites System, das gepflegt werden will.
Wähle den Umzug nach Sanity, wenn
Zieh die Inhalte um, wenn die Website vor allem Marketing und Content trägt und du das doppelte Betreiben von zwei Systemen vermeiden willst. Headless-WordPress bedeutet weiterhin Server, Updates, Plugin-Pflege und Sicherheits-Patches, nur eben unsichtbar hinter der neuen Oberfläche.
- Deine Website besteht aus Beiträgen, Seiten, Services und Referenzen, nicht aus Shop- oder Mitgliederlogik.
- Du willst ein Content-Modell mit klaren Feldern statt eines Editors, in dem Layout und Inhalt vermischt sind.
- Mehrsprachigkeit steht an: Bei uns kostet jede weitere Sprache keinen Aufpreis pro Sprache.
- Du willst Inhalte über API und MCP-Server, eine standardisierte Schnittstelle für KI-Werkzeuge, auch von Agenten anlegen und prüfen lassen.
Unsere Empfehlung für Marketing-Websites ist der zweite Weg, und der Grund ist Betriebsaufwand. Headless WordPress verschiebt die Pflege nur. Du betreibst weiter eine WordPress-Installation mit Updates und Lizenzen und dazu ein Frontend. Mit Sanity als strukturierter Content-Datenbank fällt eine ganze Betriebsschicht weg, und du steuerst Content-Modell, Templates, Rendering, Schema, Sitemap und interne Verlinkung im Code. Was ein Headless CMS genau ist und wie Sanity im Alltag funktioniert, steht in den beiden verlinkten Artikeln.
Wann sich der Wechsel lohnt
Der Wechsel rechnet sich, wenn dich der Ist-Zustand konkret Geld oder Sichtbarkeit kostet. Diese sieben Auslöser sehen wir in Erstgesprächen am häufigsten.
Ladezeit ist zum Verkaufsthema geworden
Page Builder und ein Dutzend Plugins laden Skripte, die sich gegenseitig blockieren. Wenn Core Web Vitals, also Googles Messwerte für Ladeverhalten und Stabilität, dauerhaft rot sind, ist Optimieren am bestehenden System irgendwann teurer als der Neubau. Details in Core Web Vitals.
Plugin-Abhängigkeit blockiert Entscheidungen
Jede Funktion hängt an einer Erweiterung, jede Erweiterung an einem Anbieter. Ein Update legt das Layout lahm, ein eingestelltes Plugin erzwingt einen Umbau.
Sicherheit und Wartung fressen Budget
Updates, Backups, Patches und Kompatibilitätstests laufen monatlich, ohne dass die Website dadurch besser wird.
Mehrsprachigkeit steht an
Übersetzungs-Plugins bauen Parallelstrukturen, hreflang, also die Auszeichnung, welche Sprachfassung für welches Land gilt, wird zur Fehlerquelle.
Das Content-Modell passt nicht mehr
Du brauchst strukturierte Felder für Services, Referenzen, Standorte und Personen, aber alles landet in einem Fließtext-Editor.
Du willst programmatische Seiten
Standort- oder Anwendungsfall-Seiten aus einer Datenquelle gehen nur mit echter Substanz pro Seite. Sonst wertet Google sie als Doorway-Pages ab, also als Seiten, die nur existieren, um ein Keyword abzudecken. Das haben wir auf unserer alten Website selbst erlebt.
KI-Antworten werden zum Kanal
Saubere strukturierte Daten, llms.txt und schnelle Auslieferung sind im Code direkt steuerbar. Wie das zusammenhängt, steht in technisches SEO.
Wann du bei WordPress bleibst
Bleib, wenn die Website funktioniert und keiner der sieben Punkte auf dich zutrifft. Ein sauber aufgesetztes WordPress mit einem schlanken Theme, wenigen Plugins und gepflegten Inhalten ist kein Problem, das gelöst werden muss. Eine Migration bindet Budget und Aufmerksamkeit, beides kannst du auch in Inhalte stecken.
- Die Website hat bis etwa 30 Seiten, eine Sprache und keine programmatischen Seiten in Planung.
- Kernfunktionen hängen an Plugins, für die es im Code keinen Ersatz mit vertretbarem Aufwand gibt.
- Dein Traffic kommt fast vollständig aus bezahlten Kanälen, organische Sichtbarkeit ist kein Ziel.
- Es gibt niemanden im Haus, der Inhalte pflegt, und die Website ändert sich einmal im Jahr.
Der Ablauf in sechs Phasen
Der Ablauf ist immer gleich, egal ob am Ende Next.js oder Astro läuft. Die Phasen 1 bis 5 ergeben zusammen die 3-6 Wochen bis Go-Live, Phase 6 läuft zwei Wochen danach. Wir arbeiten die Reihenfolge strikt ab: Ohne fertige Redirect-Map geht keine Website live.
Audit und Redirect-Map
Wir crawlen die alte Website mit Screaming Frog oder Ahrefs, ziehen einen Ranking-Snapshot und lesen die WordPress-URL-Muster aus: Datums-Permalinks wie /2021/08/titel, Kategorie-Pfade wie /blog/kategorie/titel, Anhang-Seiten, Autoren- und Paginierungsseiten. Das Slug-Mapping entsteht direkt aus dem Export, jede alte URL bekommt genau ein neues Ziel. Ergebnis: eine vollständige Redirect-Map 1:1 und eine Liste der Seiten, die Traffic tragen. Dauer: der Projektstart, bevor eine Zeile Frontend-Code entsteht.
Content-Modell in Sanity
Wir übersetzen Beiträge, Seiten, Custom Post Types, Kategorien, Tags, Medien und Sprachen in Dokumenttypen mit definierten Feldern. Aus einem Fließtext-Feld werden Textblöcke, Bilder, Zitate und Call-to-Action-Blöcke mit eigenen Feldern. Ergebnis: ein Schema, gegen das Import und Frontend gleichzeitig gebaut werden können. Dauer: parallel zum Ende von Phase 1.
Content-Migration
Die Inhalte kommen über den WXR-Export, das XML-Exportformat von WordPress, oder über die REST-API beziehungsweise WPGraphQL. Danach transformieren wir sie in das Sanity-Schema und importieren sie als NDJSON, ein Zeilen-für-Zeilen-Format für Datensätze, über `sanity dataset import`. Alle Assets aus /wp-content/uploads laden wir herunter und in Sanity neu hoch, damit keine Bild-URL mehr auf die alte Installation zeigt. Ergebnis: alle Inhalte und Medien im neuen System, prüfbar Seite für Seite. Dauer: der größte Einzelblock im Projekt.
Frontend-Aufbau
Templates, Komponenten, Navigation und Formulare entstehen neu im Code, angebunden an Sanity. Hier fällt die Entscheidung zwischen statischer Auslieferung über ein CDN, also ein Auslieferungsnetz mit Servern nah am Nutzer, und Server-Rendering pro Anfrage. Ergebnis: eine Vorschau-Umgebung, in der dein Team jede Seite gegen das Original vergleichen kann. Dauer: läuft teils parallel zu Phase 3.
SEO-Parität und Launch
Titel, Meta-Descriptions, Canonicals, strukturierte Daten, Sitemap, robots.txt und hreflang werden gegen den Vorher-Crawl abgeglichen, Feld für Feld. Dann gehen Redirects live, wir reichen die Sitemap in der Search Console und bei Bing ein und melden die URLs über IndexNow. Ergebnis: Go-Live ohne fehlende Metadaten und ohne tote Links. Dauer: die letzten Tage vor dem Umschalten.
Monitoring
Zwei Wochen lang laufen 404-Report und Ranking-Abgleich gegen den Snapshot aus Phase 1. Auffällige Seiten korrigieren wir sofort, meist sind es Redirect-Lücken bei alten Anhang- oder Paginierungsseiten. Ergebnis: eine belegbare Aussage darüber, wo die Rankings nach dem Wechsel stehen. Dauer: zwei Wochen nach Go-Live, danach übergibt das Projekt an die laufende SEO-Betreuung.
Was aus WordPress wie übernommen wird
Nicht jeder Inhaltstyp wandert gleich. Beiträge und Seiten sind Fleißarbeit, Formulare und Plugin-Funktionen brauchen eine Entscheidung. Diese Tabelle nutzen wir im Erstgespräch, um den Aufwand früh sichtbar zu machen.
Was aus WordPress wie übernommen wird
| Aus WordPress | Ziel im neuen System | Aufwand |
|---|---|---|
| Beiträge | Dokumenttyp mit Textblöcken, Autor, Datum, Bild | Gering, automatisiert über Export und Import |
| Seiten | Eigener Dokumenttyp oder Baukasten aus Sections | Mittel, Layout-Entscheidung pro Seitentyp |
| Custom Post Types | Je ein eigener Dokumenttyp mit definierten Feldern | Mittel, hängt an der Feldqualität im Original |
| Kategorien und Tags | Referenzen auf Taxonomie-Dokumente | Gering, 1:1 übertragbar |
| Medien | Sanity Asset-Bibliothek, neu hochgeladen | Mittel, Menge entscheidet, Bild-URLs ändern sich |
| Formulare | Eigene Formular-Komponente mit externem Versanddienst | Mittel, Plugin-Logik wird nicht übernommen |
| SEO-Plugin-Daten | Felder für Titel, Description, Canonical, Schema | Gering, wenn Yoast oder Rank Math sauber gepflegt ist |
| Redirects | Redirect-Regeln in der Hosting-Konfiguration | Mittel, Ketten müssen aufgelöst werden |
| Kommentare | Externer Dienst oder bewusste Abschaltung | Gering, meist eine Produktentscheidung |
| Suche | Client-Index oder Suchdienst statt WordPress-Suche | Mittel, abhängig von Seitenzahl und Sprachen |
Risiken und wie wir sie abfangen
Fünf Dinge gehen bei Migrationen regelmäßig schief, und alle fünf sind vermeidbar. Wir planen sie von Anfang an ein.
- Ranking-Verlust. Ursache ist fast immer eine unvollständige Redirect-Map. Gegenmittel: Vorher-Crawl plus Ranking-Snapshot, jede alte URL bekommt ein Ziel, und zwei Wochen 404-Report nach dem Launch decken den Rest auf.
- Plugin-Funktionen ohne Ersatz. Buchungssysteme, Rechner, Mitgliederbereiche. Gegenmittel: Wir listen im Audit jede Plugin-Funktion mit Nutzung und entscheiden vor Projektstart pro Funktion: nachbauen, extern einbinden oder streichen.
- Bild-URLs. Alte Pfade unter /wp-content/uploads brechen, sobald WordPress abgeschaltet wird. Gegenmittel: Assets vollständig herunterladen, neu hochladen, alle Verweise im Inhalt beim Import umschreiben.
- Redirect-Ketten. Alte Websites tragen oft schon Weiterleitungen von früheren Relaunches, die dann drei Sprünge lang werden. Gegenmittel: Wir lösen jede Kette auf eine einzige Weiterleitung zum finalen Ziel auf.
- Design-Abweichung. Wenn das neue Frontend anders aussieht als gewohnt, wird jede Ranking-Schwankung dem Design zugeschrieben. Gegenmittel: Entweder bewusst neu gestalten oder 1:1 portieren, aber nicht beides halb. Für Webflow-Projekte haben wir denselben Ablauf in Webflow zu Next.js migrieren beschrieben.
Kosten und Dauer
Wir rechnen eine Migration als Relaunch-Projekt ab, und unsere Relaunch-Pakete starten bei 8.000 Euro netto. Der Preis hängt an Seitentypen, Inhaltsmenge und den Funktionen, die aus Plugins nachgebaut werden müssen. Eine Marketing-Website mit 10-30 Seiten geht typischerweise in 3-6 Wochen live, das zweiwöchige Monitoring kommt dazu.
Die laufenden Kosten sinken nach dem Wechsel deutlich. WordPress selbst ist kostenlos, die Kosten entstehen über Hosting, Theme- und Plugin-Lizenzen und die Wartung, die daran hängt. Nach der Migration läuft eine Astro- oder Next.js-Website mit Sanity Free typischerweise mit 0-20 $ Hosting pro Monat, also nahezu keine laufenden Plattformgebühren. Welche Alternativen sonst infrage kommen, ordnen wir in WordPress Alternative ein.
- Projektpreis: Relaunch-Paket ab 8.000 Euro netto, abhängig von Seitentypen, Inhaltsmenge und Funktionen.
- Dauer: 3-6 Wochen bis Go-Live bei 10-30 Seiten, plus zwei Wochen Monitoring.
- Laufend: Sanity Free mit 20 Plätzen, 10.000 Dokumenten, 100 GB Assets und 100 GB Bandbreite pro Monat.
- Hosting: Vercel Pro 20 $ pro Monat und Entwickler-Platz inklusive 20 $ Nutzungsguthaben, keine Grundgebühr pro Projekt.
Unser Urteil: so haben wir es selbst gemacht
Unsere eigene Website ist der Referenzfall. in-sync.io kam 2026 von Wix und lief nach genau diesen Phasen: Audit, Content-Modell, Migration, Frontend, SEO-Parität, Monitoring. Heute stehen 49 Wissen-Artikel, 10 Service-Seiten und 17 Stadtseiten in einer einzigen Sanity-Datenbank, zweisprachig mit hreflang, mit Server-Rendering, llms.txt, IndexNow und FAQPage-Schema. Ehrlich dazu: Die alte Wix-Website rankte für praktisch nichts. Die neue ist seit Juni 2026 live und baut ihre Rankings auf.
Dass eine 1:1-Portierung des Designs funktioniert, zeigt Yarowa. Der internationale B2B-Kunde hatte eine fünfsprachige Website in Webflow. Wir haben den Export 1:1 nach Astro portiert und auf Vercel gehostet: 5 Sprachen, 21 Seiten-Templates, 163 Sections, Design unverändert. Der Umbau auf Sanity mit Presentation Mode ist in Planung. Für deine WordPress-Migration heißt das: Du musst dich nicht zwischen neuer Technik und vertrautem Design entscheiden. Wie wir Relaunch-Projekte aufsetzen, steht auf unserer Seite zur Website-Relaunch-Agentur, die Umsetzung selbst läuft über unsere Webentwicklung.
Häufige Fragen
Ja. Inhalte kommen per WXR-Export oder über die REST-API beziehungsweise WPGraphQL heraus, werden transformiert und als NDJSON nach Sanity importiert, das Frontend entsteht neu in Next.js oder Astro. Bei 10-30 Seiten dauert das typischerweise 3-6 Wochen bis Go-Live, plus zwei Wochen Monitoring.
Nicht, wenn jede alte URL per 301 auf genau ein neues Ziel zeigt und die Inhalte vollständig mitkommen. Wir ziehen vorher einen Crawl und einen Ranking-Snapshot, bauen die Redirect-Map 1:1 und prüfen zwei Wochen lang 404-Report und Rankings gegen diesen Snapshot.
Sie wandern nicht mit. Formulare, Suche und Kommentare werden im Code oder über externe Dienste ersetzt, Funktionen wie Buchungssysteme entscheiden wir im Audit einzeln: nachbauen, extern einbinden oder streichen. Genau deshalb steht diese Liste vor Projektstart, nicht danach.
Nur wenn dein Team täglich darin arbeitet oder Plugins Umsatzlogik tragen. Sonst betreibst du weiterhin Server, Updates und Lizenzen hinter einem neuen Frontend. Für Marketing-Websites empfehlen wir den vollständigen Umzug nach Sanity, weil eine ganze Betriebsschicht wegfällt.
Wir rechnen sie als Relaunch-Projekt ab, unsere Relaunch-Pakete starten bei 8.000 Euro netto. Der Preis hängt an Seitentypen, Inhaltsmenge und nachzubauenden Funktionen. Laufend liegen die Plattformkosten danach typischerweise bei 0-20 $ Hosting pro Monat mit Sanity Free.
Astro ist unser Default, wenn die Website Inhalte ausliefert: Für statische Inhalte lädt sie standardmäßig 0 KB JavaScript. Next.js nehmen wir, sobald App-Logik, Login oder serverseitig pro Anfrage berechnete Daten nötig sind. Der Migrationsablauf bleibt in beiden Fällen identisch.
Nächster Schritt
Schick uns deine WordPress-URL, und du bekommst eine Einschätzung zu Seitentypen, Aufwand und Redirect-Umfang.
Headless WordPress
Der Zwischenweg: WordPress bleibt, das Frontend geht.
Website-Relaunch ohne SEO-Verlust
Die Checkliste, mit der Rankings den Umzug überstehen.
WordPress oder Next.js
Das direkte Duell in zehn Kriterien, mit klarer Empfehlung.
301-Weiterleitungen richtig setzen
Statuscodes, Redirect-Map und die Fehler, die Rankings kosten.
CMS-Migration: Ablauf und Kosten
Der Überblick über jeden Systemwechsel, system-unabhängig.
