WordPress Relaunch Migration planen: Änderungen kontrolliert umsetzen

Ein WordPress-Relaunch ist nicht nur ein Designwechsel. URLs, Inhalte, Datenmodelle, Funktionen und externe Anbindungen können sich gleichzeitig ändern. Für Geschäftsführung, Projektverantwortliche und technische Leitung entsteht dadurch ein Risiko: Nach dem Go-Live ist oft unklar, ob Fehler schon vorher bestanden oder durch die Migration entstanden sind. Eine kontrollierte Migration beginnt deshalb mit einer Bestandsaufnahme und endet nicht mit dem Umschalten der Domain. Entscheidend sind überprüfbare Zwischenstände: Welche Inhalte und Funktionen werden übernommen? Welche URLs ändern sich? Wie werden Daten geprüft? Und wie lässt sich im Fehlerfall zurückschalten? Dieser Beitrag zeigt ein Vorgehen, mit dem Sie Änderungen schrittweise planen, testen und nach dem Go-Live belegen können – auch dann, wenn WordPress durch eine statische Architektur ersetzt wird.

Kurz gesagt

Planen Sie den Relaunch als kontrollierte Veränderung des bestehenden Systems, nicht als einmaligen Veröffentlichungstermin. Erfassen Sie vorab Inhalte, URLs, Funktionen, Datenquellen und Abhängigkeiten. Testen Sie Migration und Redirects in einer getrennten Umgebung und definieren Sie vor dem Go-Live klare Abbruch- und Rollback-Kriterien. Nach der Veröffentlichung prüfen Sie technische Funktion, Inhalte und Zugriffe anhand einer vorher festgelegten Liste.

Ausgangslage

Ein bestehendes WordPress-System enthält meist mehr als sichtbare Seiten. Dazu gehören Custom Post Types, Taxonomien, Metadaten, Formulare, Benutzerrollen, Schnittstellen, Suchfunktionen und Regeln, die sich über Jahre entwickelt haben. Manche Elemente sind dokumentiert, andere stecken in Plugins, Theme-Code oder redaktionellen Abläufen.

Beim Relaunch werden häufig mehrere Ebenen gleichzeitig verändert: Inhalte werden neu strukturiert, URLs angepasst, Plugins ersetzt und das Frontend überarbeitet. Bei einem Wechsel zu einer statischen Website kommen zusätzlich Export, Transformation und ein neues Veröffentlichungsverfahren hinzu. Fehler sind dann schwer zuzuordnen, wenn es keinen verlässlichen Ausgangszustand gibt.

Der zentrale Planungsgrundsatz lautet: Erfassen → kontrolliert ändern → Wirkung prüfen. Das entspricht dem Prinzip Know → Change → Prove. Jeder größere Schritt braucht einen dokumentierten Ausgangspunkt, eine begrenzte Änderung und eine passende Prüfung.

Entscheidungskriterien

Bevor Sie Zeitplan und technische Umsetzung festlegen, klären Sie, was sich tatsächlich ändern soll. Die folgenden Kriterien bestimmen Umfang, Reihenfolge und Testtiefe.

1. Welche Funktionen müssen erhalten bleiben?

Erstellen Sie eine Funktionsliste, nicht nur eine Seitenliste. Berücksichtigen Sie unter anderem Suche, Formulare, Mitgliederbereiche, Filter, Rechner, Downloads, APIs und automatisierte Abläufe. Für jede Funktion sollte feststehen:

• Wer nutzt sie – Redaktion, Kundschaft, interne Teams oder externe Systeme?
• Welche Daten benötigt sie?
• Wird sie unverändert übernommen, ersetzt oder beendet?
• Wie lässt sich ihr korrekter Zustand nach dem Relaunch testen?

Eine Funktion, die niemand benennen oder prüfen kann, ist ein offenes Migrationsrisiko. Bei komplexen WordPress-Systemen hilft es, Inhalte, Daten und Funktionen getrennt zu betrachten. Dazu passt der Beitrag WordPress als Plattform.

2. Welche URLs haben Bedeutung?

Erfassen Sie bestehende URLs aus mehreren Quellen: WordPress-Inhalte, XML-Sitemap, Webserver oder Analysewerkzeuge, interne Verlinkung und bekannte externe Verweise. Vergleichen Sie sie mit der geplanten Struktur. Jede relevante alte URL braucht eine Entscheidung:

• URL bleibt gleich.
• Inhalt erhält eine neue URL und einen passenden Redirect.
• Inhalt wird mit einer anderen Seite zusammengeführt.
• Inhalt entfällt ohne gleichwertigen Ersatz.

Nicht jede alte URL muss auf die Startseite umgeleitet werden. Ein Redirect sollte auf das thematisch passende Ziel führen. Gibt es kein sinnvolles Ziel, ist ein Redirect nicht automatisch die richtige Lösung. Prüfen Sie außerdem Weiterleitungsketten und Schleifen, bevor sie live gehen.

3. Welche Inhalte und Daten werden migriert?

Legen Sie fest, welche Inhaltstypen, Felder, Taxonomien und Beziehungen übernommen werden. Stimmen Sie Datenmodell und Zielsystem ab, bevor Sie den Export bauen. Ein Seitentitel und ein Fließtext reichen nicht, wenn das bestehende System strukturierte Angaben wie Regionen, Kategorien, Status oder Verknüpfungen verwendet.

Definieren Sie für jeden Inhaltstyp eine Zuordnung: Quelle, Zielfeld, notwendige Transformation und Umgang mit fehlenden oder ungültigen Werten. Entscheiden Sie auch, was mit Entwürfen, Revisionen, Medien, Weiterleitungen und nicht mehr verwendeten Datensätzen geschieht. Der Beitrag Datenmodelle statt Plugin-Stapel vertieft die Frage, wie Inhalte strukturiert werden sollten.

4. Wie wird die Migration wiederholbar?

Ein einmaliger manueller Import ist schwer zu prüfen und kaum reproduzierbar. Bevorzugen Sie einen Ablauf, den Sie in einer Testumgebung wiederholen können. Halten Sie fest, welche Eingaben verwendet werden, welche Transformationen stattfinden und welche Ergebnisse erwartet werden. Bei einer statischen Migration gehören dazu etwa Exportformat, Zuordnung der Inhaltstypen, Medienpfade und Validierungsregeln.

5. Was gilt als bestanden – und wann wird abgebrochen?

Definieren Sie Abnahmekriterien vor dem Test. Beispiele sind: alle priorisierten URLs liefern den erwarteten Status, wichtige Inhalte sind vollständig, Formulare übermitteln korrekt, Zugriffsrechte stimmen und keine kritischen Fehler treten in Logs oder Browserkonsole auf. Legen Sie ebenso fest, welche Abweichungen einen Go-Live verhindern und wer die Entscheidung trifft.

6. Wie aktuell müssen Inhalte zum Umschaltzeitpunkt sein?

Bei einer wenig veränderten Website kann ein geplanter Export ausreichen. Bei häufig aktualisierten Inhalten müssen Sie festlegen, wie Änderungen zwischen Testmigration und Go-Live übernommen werden. Möglich sind ein redaktioneller Freeze, ein finaler Delta-Export oder ein enger abgestimmter Umschaltzeitraum. Entscheidend ist, dass niemand nach dem letzten Datenabzug unbemerkt weiterarbeitet.

Vorgehen: Migration in kontrollierbare Schritte teilen

1. Bestand sichern und dokumentieren

Sichern Sie Datenbank und Dateien und prüfen Sie, ob die Sicherung tatsächlich wiederherstellbar ist. Dokumentieren Sie Systemversionen, aktive Plugins, Theme-Anpassungen, externe Dienste, Cronjobs, Rollen und bekannte Sonderfälle. Erfassen Sie außerdem die wichtigsten Kennzahlen oder Prüfwerte, die Sie später vergleichen wollen – etwa Seitenstatus, Formularfunktion oder Zahl der migrierten Datensätze. Backups allein ersetzen kein Betriebskonzept; wichtig ist ein getesteter Wiederherstellungsweg.

2. URL-Inventar und Redirect-Mapping erstellen

Führen Sie alte und neue URLs in einer Tabelle zusammen. Ergänzen Sie pro Zeile den Inhaltstyp, das Ziel, die Entscheidung und den Prüfstatus. Markieren Sie Prioritäten: stark verlinkte Seiten, zentrale Einstiegsseiten, Formulare und URLs mit externen Verweisen sollten besonders sorgfältig geprüft werden.

Redirects lassen sich beispielsweise in einer Apache-Konfiguration mit mod_rewrite festlegen:

RewriteEngine On

RewriteRule ^alter-pfad/?$ /neuer-pfad/ [R=301,L]
RewriteRule ^ratgeber/alt-thema/?$ /wissen/neues-thema/ [R=301,L]

Die Regeln bilden einzelne, fachlich passende Zuordnungen ab. Legen Sie sie erst fest, wenn Ziel-URLs final sind, und testen Sie sie zunächst in einer Testumgebung. Prüfen Sie eine Weiterleitung beispielsweise mit curl -I https://example.com/alter-pfad/; kontrollieren Sie Statuscode und Location-Header.

3. Inhalte und Daten migrieren

Führen Sie einen vollständigen Testlauf mit einer Kopie der Quelldaten durch. Prüfen Sie nicht nur, ob Datensätze vorhanden sind, sondern auch, ob Beziehungen und Felder semantisch korrekt übertragen wurden. Stichproben sollten verschiedene Inhaltstypen, Sonderzeichen, leere Felder, Medien und Randfälle abdecken.

Bei WordPress als Zielsystem müssen Sie außerdem Rollen und Berechtigungen prüfen. Bei einem Wechsel des Systems ist zu klären, welche Funktionen künftig im CMS, im Frontend oder in einem separaten Backend liegen. Diese Entscheidungen beeinflussen sowohl den Migrationsumfang als auch den späteren Betrieb.

4. Testumgebung mit Abnahmekriterien prüfen

Die Testumgebung sollte dem geplanten Live-System möglichst ähnlich sein, aber von Suchmaschinen und regulären Nutzern getrennt bleiben. Prüfen Sie dort:

• zentrale Vorlagen und Navigation auf Desktop und Mobilgeräten,
• interne Links, Bilder, Downloads und Weiterleitungen,
• Formulare, Suche, Filter und geschützte Bereiche,
• Metadaten, Canonical-URLs und Indexierungsregeln,
• Fehlerprotokolle, Ladeverhalten und Schnittstellen.

Automatisierte Prüfungen können Vollständigkeit und wiederkehrende Fehler schneller sichtbar machen. Sie ersetzen keine fachliche Stichprobe: Ein technisch vorhandener Datensatz kann inhaltlich falsch zugeordnet sein.

5. Rollback und Go-Live vorbereiten

Ein Rollback ist nur dann praktikabel, wenn klar ist, was zurückgesetzt wird. Legen Sie vor dem Go-Live fest, ob Sie DNS, Dateien, Datenbank oder einzelne Dienste zurückstellen müssen. Prüfen Sie, wie neue Inhalte oder Transaktionen behandelt werden, die nach dem Umschalten entstehen. Definieren Sie Verantwortliche, Entscheidungszeitpunkt und Kommunikationsweg.

Planen Sie den Go-Live als Folge konkreter Schritte: letzte Sicherung, gegebenenfalls finaler Datenabzug, Veröffentlichung, Umschaltung und technische Prüfung. Vermeiden Sie parallele Änderungen, die nicht im Ablauf vorgesehen sind. Für WordPress-Änderungen liefert Know → Change → Prove ein passendes Kontrollmodell.

6. Nach dem Go-Live kontrollieren

Prüfen Sie die priorisierten URLs, Redirects, Formulare, Suche und zentrale Nutzerwege erneut auf dem Live-System. Beobachten Sie Server- und Anwendungsfehler und kontrollieren Sie, ob Suchmaschinen wie vorgesehen zugreifen können. Vergleichen Sie die Ergebnisse mit den vorher definierten Kriterien, statt nur auf eine allgemeine „Seite funktioniert“-Einschätzung zu vertrauen.

Die Nachkontrolle sollte auch Verantwortlichkeiten enthalten: Wer bearbeitet gefundene Fehler? Wie werden sie priorisiert? Wann gilt der Relaunch als abgenommen? So bleibt die Übergabe nachvollziehbar und Korrekturen werden nicht zu ungeplanten Daueraufgaben.

Migration von WordPress zu statischer Auslieferung

Eine statische Auslieferung verändert nicht nur die Technik, sondern auch den redaktionellen Prozess. WordPress kann weiterhin als Quelle dienen oder vollständig ersetzt werden. In beiden Fällen müssen Inhalte in ein Zielmodell überführt werden, das Seiten und strukturierte Datensätze zuverlässig abbildet.

Prüfen Sie vorab, welche Funktionen zur Laufzeit serverseitige Logik benötigen. Suche, Formulare, personalisierte Inhalte und dynamische Daten können ein separates Backend, einen Dienst oder eine clientseitige Lösung erfordern. Statisch bedeutet nicht automatisch, dass jede Funktion verschwindet; es bedeutet, dass ihre Ausführung bewusst anders organisiert wird. Die Architekturentscheidung sollte deshalb vom benötigten Prozess ausgehen. Mehr dazu: Astro für Content-Sites und Astro oder WordPress.

Typische Fehler

• Nur das sichtbare Design planen: Funktionen, Daten und Rollen bleiben ungeprüft.
• URLs erst kurz vor dem Go-Live abgleichen: Redirects werden lückenhaft oder führen auf unpassende Ziele.
• Inhalte nur nach Anzahl kontrollieren: Fehlende Beziehungen oder falsche Feldzuordnungen bleiben unentdeckt.
• Zu spät mit echten Daten testen: Sonderfälle tauchen erst im finalen Import auf.
• Rollback mit „wir haben ein Backup“ gleichsetzen: Der Wiederherstellungsweg und der Umgang mit neuen Änderungen sind ungeklärt.
• Nach dem Go-Live nicht mehr prüfen: Fehler bei Weiterleitungen, Formularen oder Indexierung bleiben länger bestehen.
• Statische Migration als Exportaufgabe behandeln: Redaktionsabläufe und dynamische Funktionen werden nicht neu geplant.

Praxisbeispiel

Beim Projekt Garten 1x1 wurde eine bestehende WordPress-Website zu Astro migriert. Ein einmaliges TypeScript-Skript überführte einen WXR-Export in Markdown. Im Zielsystem wurden Content Collections mit Zod-Schema für Pflanzen, Probleme, Aufgaben, Bereiche, Regionen und Ziele eingesetzt. Die Migration zeigt, warum ein Export allein nicht genügt: Die Inhalte müssen in ein überprüfbares Modell passen, das die benötigten Typen und Felder festlegt. Das Projekt umfasste mehrere hundert Pflanzenprofile sowie eine Pagefind-Suche und einen Gartenrechner im Browser.

Empfehlung

• Wenn sich hauptsächlich Gestaltung und einzelne Funktionen ändern, behalten Sie Datenmodell und URLs möglichst stabil und begrenzen Sie die Migration auf klar benannte Änderungen.
• Wenn Inhalte neu strukturiert werden, erstellen Sie zuerst ein Mapping zwischen Quell- und Zielmodell und testen Sie es mit echten Beispieldaten.
• Wenn viele URLs entfallen oder sich ändern, priorisieren Sie URL-Inventar und Redirect-Tests vor dem Go-Live.
• Wenn Redaktion und Daten häufig aktualisiert werden, planen Sie einen finalen Datenabzug oder einen klaren Redaktions-Freeze ein.
• Wenn WordPress durch statische Auslieferung ersetzt wird, prüfen Sie zuerst, welche Prozesse und Laufzeitfunktionen bestehen bleiben müssen. Entscheiden Sie danach über Export, Zielmodell und ergänzende Dienste.
• Wenn der Bestand unklar oder stark angepasst ist, beginnen Sie mit einer technischen Bestandsaufnahme, bevor Sie Umfang und Termin verbindlich festlegen.

Checkliste

• Aktive Funktionen, Inhaltstypen, Rollen und externe Abhängigkeiten sind dokumentiert.
• Alte und neue URLs sind abgeglichen und mit einer Entscheidung versehen.
• Redirects führen auf passende Ziele und sind in der Testumgebung geprüft.
• Das Datenmapping deckt Felder, Beziehungen, Medien und Sonderfälle ab.
• Migration und Import sind mit einer wiederholbaren Teststrecke geprüft.
• Abnahmekriterien und Go-Live-Verantwortliche sind festgelegt.
• Backup und Rollback wurden praktisch geprüft; der Umgang mit neuen Änderungen ist geklärt.
• Nachkontrolle für URLs, Formulare, Suche, Logs und Indexierung ist geplant.

Häufige Fragen

Müssen beim Relaunch alle URLs gleich bleiben?

Nein. Bestehende URLs sollten erhalten bleiben, wenn es dafür einen guten Grund gibt. Ändern sie sich, braucht jede relevante alte URL ein passendes Ziel oder eine bewusste Entscheidung, sie entfallen zu lassen.

Wann sollte die Redirect-Liste erstellt werden?

Sobald die neue Informationsarchitektur und die Ziel-URLs ausreichend stabil sind – nicht erst unmittelbar vor dem Go-Live. So bleibt Zeit, Zuordnungen zu prüfen und Weiterleitungen zu testen.

Kann eine WordPress-Website ohne Datenverlust statisch werden?

Das hängt davon ab, welche Inhalte und Funktionen übertragen werden müssen. Export, Zielmodell und Transformationen sollten in einer Testmigration geprüft werden. Dynamische Abläufe benötigen gegebenenfalls eine neue technische Lösung.

Wann sollte der Go-Live verschoben werden?

Wenn kritische Nutzerwege fehlschlagen, wichtige Inhalte fehlen, Redirects nicht stimmen oder ein belastbarer Rollback nicht möglich ist. Legen Sie solche Kriterien vor dem Umschalten fest.

Weiterführend

• WordPress als Plattform
• WordPress technisch dokumentieren
• Astro für Content-Sites
• Garten 1x1: WordPress zu Astro migrieren

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Astro: Content Collections
• Astro: Why Astro?