Wenn das Backend zur Geduldsprobe wird
Acht Sekunden, bis der Editor lädt. 34 Plugins, von denen niemand mehr sagen kann, welche die Site wirklich braucht. Und vor jedem Update die stille Frage, ob danach noch alles steht. Falls dir das bekannt vorkommt: Deine WordPress-Site ist nicht kaputt. Sie ist über Jahre gewachsen, und das Fundament trägt die Last nicht mehr.
Warum ein WordPress-Backend mit den Jahren zäh wird und welche Sofortmaßnahmen helfen, habe ich im Artikel WordPress-Backend zu langsam: was tun? auseinandergenommen. Der Text hier ist die Fortsetzung für den Fall, dass du die Ursache beheben willst statt der Symptome.
Die gute Nachricht: Dafür brauchst du keinen Relaunch mit Stichtag, Nachtschicht und zugekniffenen Augen. Eine Migration zu Sanity lässt sich in fünf Etappen schneiden, bei denen die Site jederzeit vollständig online bleibt. Genau diesen Weg gehen wir jetzt durch: Etappe für Etappe, mit dem offiziellen Werkzeug und ehrlichen Aufwandsspannen aus meinen Projekten.
Warum Etappen statt Big Bang
Vorab die Begriffsklärung: Big Bang heißt, die neue Site entsteht monatelang im Verborgenen und wird an einem Stichtag komplett umgeschaltet. Das klingt nach Ordnung, hat aber drei eingebaute Sollbruchstellen.
- Content-Freeze: Während der Bauphase darf die Redaktion nichts Wesentliches ändern, sonst laufen alte und neue Site auseinander. Bei drei Monaten Projektlaufzeit sind das drei Monate Stillstand.
- SEO-Risiko im Block: Alle URLs, Templates und internen Links ändern sich in einer Nacht. Geht etwas schief, merkst du es erst, wenn die Rankings bereits fallen.
- Alles-oder-nichts-Budget: Der Nutzen kommt erst ganz am Ende. Kippt das Projekt vorher, hast du bezahlt und nichts bekommen.
Die Alternative trägt den Namen Strangler-Muster: Ein neues Frontend stellt sich vor beide Systeme und übernimmt die Site Bereich für Bereich, bis das alte System leer ist. Jede Etappe liefert ein nutzbares Ergebnis, nach jeder kannst du pausieren. Merksatz: Nicht die Migration ist das Risiko, sondern der Stichtag.
Etappe 1: Der Content-Audit entscheidet, was mitkommt
Gewachsene WordPress-Sites schleppen Ballast: verwaiste Landingpages aus alten Kampagnen, doppelt gepflegte Teamseiten, Blogartikel von 2019 ohne einen einzigen Besucher im letzten Jahr. Nichts davon verdient Migrationsaufwand. Deshalb beginnt jede Migration bei mir mit einer Inventur, nicht mit Code.
Drei Quellen reichen für die Entscheidungsgrundlage: die Seitenliste aus WordPress, zwölf Monate Zugriffsdaten aus deiner Web-Analyse und die Suchanfragen aus der Google Search Console. Daraus entsteht eine Tabelle mit drei Spalten: migrieren, archivieren, löschen.
Zur Inventur gehört auch der unbequeme Teil: Shortcodes und Page-Builder-Elemente. Notiere jedes Plugin, das Inhalte erzeugt, etwa Formulare, Slider oder Tabellen. Jeder Eintrag auf dieser Liste braucht in Etappe 3 eine eigene Übersetzungsregel. Aus meinen Audits: Diese Liste bestimmt den Importaufwand stärker als die reine Seitenzahl.
Eine Beobachtung aus meinen Projekten zum Schluss: Von gewachsenen Marketing-Sites überleben selten mehr als zwei Drittel der Inhalte den Audit. Vermisst hat den gelöschten Rest noch niemand.
Etappe 2: Content-Modellierung in Sanity
Jetzt zum Denkfehler, den ich am häufigsten sehe: das WordPress-Modell in Sanity nachbauen. Eine Seite mit einem großen HTML-Feld bleibt eine Seite mit einem großen HTML-Feld, auch wenn darunter ein Content Lake liegt. Damit verschenkst du den eigentlichen Grund für den Umzug.
Sanity denkt in strukturierten Inhalten: ein Dokumenttyp je Inhaltsart, also Blogartikel, Leistungsseite, Teammitglied, Referenz. Fließtext wird Portable Text, wiederkehrende Elemente werden eigene Objekte. Ein Vorteils-Kasten mit Icon, Titel und Text ist dann ein Objekt mit drei Feldern statt einer HTML-Wüste.
Die Vorlage dafür liefert dein Audit aus Etappe 1: Welche Seitentypen existieren wirklich, welche Bausteine wiederholen sich? Bei einer typischen Marketing-Site lande ich bei fünf bis acht Dokumenttypen und rund einem Dutzend Bausteinen. Deutlich mehr ist meist ein Zeichen, dass die Inventur unvollständig war.
Denk bei der Modellierung an die Felder, die WordPress im Hintergrund mitführt: Slug, Meta-Titel, Meta-Beschreibung, Veröffentlichungsdatum, Autor. Sie wandern als gewöhnliche Felder in deine Dokumenttypen und kommen in Etappe 3 direkt aus der REST API mit. So bleibt die SEO-Substanz erhalten, bevor überhaupt eine Zeile Frontend existiert.
Investiere hier die meiste Sorgfalt: Das Content-Modell ist die einzige Etappe, die sich später nur teuer korrigieren lässt. Ein Importskript wirfst du nach Gebrauch weg, ein schiefes Modell begleitet dich Jahre.
Etappe 3: Export und Import mit offiziellem Werkzeug
Zum handwerklichen Kern. Der Weg von WordPress nach Sanity führt über drei Schritte: Inhalte herausholen, HTML in Portable Text übersetzen, als NDJSON importieren. Für jeden Schritt existiert dokumentiertes Werkzeug, nichts davon ist Bastelei (Stand: Oktober 2026).
Schritt 1: Inhalte aus WordPress holen
Zwei Wege stehen offen. Der klassische WXR-Export unter «Werkzeuge → Daten exportieren» liefert eine XML-Datei mit den Rohinhalten. Sein Haken: Shortcodes stehen dort unaufgelöst im Text. Aus deinem Slider wird eine kryptische Klammer-Zeile, mit der kein Importer etwas anfangen kann.
Deshalb nehme ich fast immer die WordPress REST API: Unter /wp-json/wp/v2/posts liefert jede Installation ihre Inhalte als fertig gerendertes HTML, bis zu 100 Beiträge pro Abruf, Paginierung inklusive. Shortcodes sind darin bereits aufgelöst. Ein Node-Skript von zwei Dutzend Zeilen sammelt so den kompletten Bestand ein.
Eine Ausnahme gehört erwähnt: Builder wie Elementor speichern am Inhaltsfeld vorbei in eigenen Datenstrukturen. Dort prüfst du im Audit den Einzelfall; zuweilen ist das Nachbauen der Seite im neuen Content-Modell schneller als jede automatische Übersetzung.
Schritt 2: HTML in Portable Text übersetzen
Für die Übersetzung stellt Sanity die Funktion htmlToBlocks aus dem Paket @portabletext/block-tools bereit; es hieß früher @sanity/block-tools, und unter dem alten Namen führen es ältere Guides noch (Stand: Oktober 2026). Die Funktion nimmt HTML entgegen und erzeugt Portable-Text-Blöcke passend zu deinem Schema. Überschriften, Listen, Links und Hervorhebungen übersetzt sie von allein; für Sonderfälle wie Inline-Styles oder eingebettete Videos ergänzt du eigene Deserialisierungs-Regeln nach dem offiziellen Guide.
Hier zahlt sich die Shortcode-Liste aus Etappe 1 aus: Jeder Eintrag wird entweder eine Regel, ein eigener Baustein im Content-Modell oder eine bewusste Streichung. Plane den Schritt iterativ: übersetzen, im Studio prüfen, Regel nachschärfen, abermals laufen lassen.
Schritt 3: NDJSON-Import über die Sanity-CLI
Das Zielformat heißt NDJSON: eine Datei, ein Sanity-Dokument je Zeile. Eingespielt wird sie mit npx sanity datasets import -d production inhalte.ndjson. Das frühere Einzelwerkzeug sanity-import ist seit März 2026 eingestellt; der Weg führt heute durch die reguläre Sanity-CLI (Stand: Oktober 2026).
Zwei Details machen den Import wiederholbar. Erstens: stabile Dokument-IDs aus den WordPress-Post-IDs ableiten, etwa post-123. Zweitens: Mit der Option --replace überschreibt jeder Durchlauf den vorigen Stand. Du kannst also korrigieren und beliebig oft neu einspielen. Merksatz: Ein Import, den du nur einmal laufen lassen kannst, ist kein Werkzeug, sondern eine Wette.
Die Mediathek nimmt denselben Weg: Trägst du im Dokument die Eigenschaft _sanityAsset mit der alten Bild-URL ein, in der Form image@https://deine-site.de/wp-content/uploads/beispiel.jpg, lädt der Import die Datei eigenständig herunter und legt sie als Sanity-Asset an. Deine Bilder ziehen automatisch mit um, ohne manuelles Hochladen.
Etappe 4: Parallelbetrieb nach dem Strangler-Muster
Jetzt kommt der Teil, der den Big Bang überflüssig macht. Ein Next.js-Frontend stellt sich vor beide Systeme: Migrierte Routen beantwortet es aus Sanity, alle übrigen reicht es über Rewrites an das alte WordPress weiter. Von außen bleibt das eine Site unter einer Domain, niemand sieht die Baustelle.
Technisch ist das in Next.js wenig Aufwand: Die Rewrite-Konfiguration kennt einen Fallback-Modus, der alles, was deine neuen Routen nicht beantworten, an eine andere Adresse durchreicht. Das alte WordPress läuft dafür unter einer Subdomain weiter, etwa legacy.deine-site.de, für Besucher unsichtbar.
Der Umzug läuft dann Route für Route. Ein realistisches Szenario für eine Marketing-Site mit 200 Seiten: zuerst der Blog, weil dort die meiste Redaktionsarbeit anfällt, danach die Leistungsseiten, zuletzt Sonderfälle wie Karrierebereich und Kampagnen-Landingpages. Nach jeder Etappe prüfst du Zugriffe und Rankings, bevor die nächste startet.
Die Redaktion arbeitet währenddessen durch: Migrierte Bereiche pflegt sie im Sanity Studio, der Rest bleibt vorerst in WordPress. Der gefürchtete Content-Freeze entfällt, weil es keinen Zeitraum gibt, in dem beide Systeme denselben Inhalt halten müssen.
Und wenn eine Etappe hakt? Dann drehst du den Rewrite zurück, und die alte Route liefert wieder WordPress aus. Dieser Rückwärtsgang ist der stille Wert des Musters: Jeder Schritt bleibt umkehrbar, kein Fehler ist endgültig.
Etappe 5: Redirects und SEO-Absicherung
Deine Rankings sind Kapital, und diese Etappe schützt es. Die wichtigste Entscheidung fällt früh: URLs beibehalten, wo immer es geht. Ein Artikel, der unter /blog/mein-artikel weiterlebt, braucht keine Weiterleitung und behält seine Signale ohne Abschlag.
Wo sich URLs doch ändern, gilt Handwerk: permanente Weiterleitungen, gepflegt als Mapping-Tabelle aus deinem Audit und ausgespielt über die redirects-Konfiguration von Next.js. Ein Detail dazu: Next.js sendet bei permanent: true den Statuscode 308, den Google genauso als dauerhaftes Umzugssignal wertet wie den klassischen 301. Die Signale wandern auf die neue Adresse; rechne dafür mit Wochen, nicht mit Tagen.
Nach jedem Etappen-Umzug gehören drei Kontrollen in den Kalender: 404-Fehler im Log, Abdeckungsbericht in der Search Console, aktualisierte XML-Sitemap. Das klingt unspektakulär, verhindert aber genau die Ranking-Verluste, die Big-Bang-Relaunches so teuer machen.
Was kostet das? Spannen aus meinen Projekten
Jetzt zur Frage hinter jeder Anfrage. Vorab die Einordnung: Die folgenden Spannen sind happycoding-Projekterfahrung, keine Branchennorm. Sie gelten für Marketing-Sites mit 50 bis 300 Inhalten; ein wilder Shortcode-Bestand verschiebt sie nach oben.
| Etappe | Spanne (Personentage) |
|---|---|
| Content-Audit | 1 bis 3 |
| Content-Modell und Studio-Einrichtung | 3 bis 8 |
| Export- und Import-Skripte | 3 bis 10 |
| Frontend je Seitentyp | 1 bis 3 |
| Redirects und SEO-Absicherung | 1 bis 2 |
In Summe liegen typische Projekte bei 20 bis 40 Personentagen, verteilt über zwei bis vier Monate Parallelbetrieb. Der größte Unsicherheitsfaktor sind die Übersetzungsregeln: Eine Site mit sauberem Gutenberg-HTML landet am unteren Rand, ein Builder-Bestand mit 15 Content-Plugins am oberen.
Zur vollen Wahrheit gehören die laufenden Kosten beider Welten. Was Sanity monatlich kostet, schlüsselt dir mein Kosten-Artikel zu Sanity auf; die Dreijahresrechnung findest du im TCO-Vergleich WordPress gegen Sanity und Next.js. Kurzfassung: Die Migration kauft dir niedrigere Betriebskosten, aber erst die Nutzungsdauer macht daraus eine Rendite.
Ehrlich geprüft: Wann WordPress bleiben darf
Ich verdiene an Sanity-Projekten, gerade deshalb gehört dieser Abschnitt hinein. In drei Konstellationen rate ich dir von der Migration ab:
- Die Site ist klein und ruhig: unter 20 Seiten, seltene Änderungen, Backend-Schmerz überschaubar. Dann ist eine Migration Aufwand ohne Hebel.
- Plugins tragen dein Geschäft: Buchungssystem, Mitgliederbereich, kleiner Shop. Diese Funktionen müsstest du neu bauen lassen, und das sprengt jede Audit-Rechnung.
- Strukturierte Inhalte bringen dir nichts: Wenn ein Kanal reicht und niemand Inhalte wiederverwendet, zahlt sich der Modellierungsaufwand nie zurück.
Schwankst du grundsätzlich zwischen Headless, Baukasten und klassischem WordPress, hilft dir mein Entscheidungsleitfaden für Unternehmen. Und treiben dich vor allem Lastspitzen um, lies den Vergleich von Sanity und WordPress bei hohen Zugriffszahlen.
Nächste Schritte
Wenn deine Site Kandidatin ist: Starte mit Etappe 1, und zwar diese Woche. Ein Content-Audit kostet wenige Tage, verpflichtet dich zu nichts und liefert selbst dann Wert, wenn du schlussendlich bei WordPress bleibst. Wie ich Sanity-Projekte aufsetze und betreue, zeigt dir meine Leistungsseite zu Sanity als Headless CMS.
Du willst vorab wissen, ob sich der Weg für deine Site rechnet? Schick mir die URL, und ich sage dir im Gespräch offen, was ich migrieren würde und was nicht: Buch dir ein unverbindliches Erstgespräch.
