Eine migrierte Website öffnet sich unter der neuen Domain, doch Bildblöcke, Menülinks und Page-Builder-Einstellungen laden weiterhin vom Staging-Host. Das Team will jedes Vorkommen des alten Hostnamens ersetzen, obwohl Sicherungen, GUID-Werte, externe Archivlinks und eine Multisite-Unterseite unterschiedlich behandelt werden müssen.
Sie erfahren, welche gespeicherten URLs tatsächlich geändert werden müssen, wie eine Vorschau den Umfang sichtbar macht und wie Sie die neue Domain prüfen, bevor die alte Umgebung abgeschaltet wird.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS Ersetzungs-Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Bei einer URL-Ersetzung nach der Migration werden gespeicherte Verweise von der alten Website-Adresse auf die neue geändert, nachdem Dateien, Datenbank, DNS und Anwendung umgezogen sind. URLs stehen in Klartext, JSON, serialisierten PHP-Werten, Block-Markup, Optionen und Plugin-Tabellen. Eine sichere Ersetzung versteht diese Formate und beschränkt sich auf nachgewiesene eigene Referenzen, statt jedes Byte blind auszutauschen.
- Inventarisieren Sie Treffer des alten Hosts nach Tabelle, Spalte, Werttyp und zuständiger Komponente und erfassen Sie home, siteurl, Multisite-Zuordnung, Upload-Pfade, Canonical-Host, HTTPS-Bereitschaft und Zeitstempel der Quelldatenbank.
- Trennen Sie interne Navigations- und Medienverweise von GUID-Historie, E-Mail-Adressen, fremden Callbacks, Lizenzendpunkten, archivierten Nachweisen und Texten, in denen die alte Domain wörtlich erhalten bleiben soll.
- Legen Sie vor dem Schreibvorgang fest, wer den Lauf freigibt und wie die Sicherung für einen möglichen Rollback bereitgehalten wird.
Ein realistisches WordPress-Beispiel
Bei der Bestandsaufnahme werden Treffer des alten Hosts nach Tabelle, Spalte und Werttyp geordnet. Interne Navigations- und Medienverweise dürfen auf die neue Domain zeigen; GUIDs, externe Archivlinks, E-Mail-Adressen und bewusst erhaltene historische Angaben benötigen dagegen eine eigene Entscheidung. Erst danach folgt eine serialisierungssichere Vorschau.
Warum es wichtig ist und wann es eingesetzt wird
Der richtige Zeitpunkt liegt nach dem Aufbau der neuen Umgebung und vor der Abschaltung der alten. Zertifikat, DNS-Ziel und WordPress-Konfiguration müssen bereits stimmen. So lassen sich verbliebene Alt-Domain-Verweise von Fehlern unterscheiden, die gar nicht aus der Datenbank stammen.
Nach dem Schreibvorgang werden typische Seiten und Medien gecrawlt, Block- und Page-Builder-Editoren geöffnet sowie Formulare, Login, Webhooks, Cron-Aufgaben, Canonicals und Weiterleitungen geprüft. Die alte Umgebung bleibt erreichbar, bis während eines repräsentativen Zeitraums keine unerklärten Anfragen mehr eintreffen.
Der einfache Weg für Einsteiger
- Notieren Sie alte und neue Domain exakt mit Protokoll, Host und gegebenenfalls Pfad.
- Erstellen Sie eine geprüfte Datenbanksicherung und starten Sie eine serialisierungssichere Vorschau nur für die vorgesehenen Tabellen.
- Kontrollieren Sie je Datenart einige Treffer und nehmen Sie GUIDs, fremde URLs sowie historische Texte aus dem Auftrag.
- Führen Sie die Ersetzung erst aus, wenn die neue Domain mit gültigem Zertifikat erreichbar ist.
- Öffnen Sie danach typische Seiten, Medien und Editoren und prüfen Sie die Weiterleitungen vom alten Host.
Der technische Weg
Technisch beginnt die Arbeit mit einer Dry-Run-Ausgabe pro Tabelle. Prüfen Sie neben der Trefferzahl auch Beispiele aus Klartext, JSON und serialisierten Werten. Bei Multisite gehören Netzwerk- und Subsite-Domains, Pfadstruktur und ausgeschlossene Tabellen ausdrücklich in den Auftrag.
- Zählen Sie verbleibende Alt-Domain-Treffer, crawlen Sie typische Seiten und Medien, öffnen Sie Block- und Builder-Editoren und testen Sie Formulare, Login, Webhooks, geplante Aufgaben, Canonicals sowie Redirects vom alten Host.
- Verwenden Sie ein WordPress-fähiges Werkzeug, das serialisierte Werte neu schreibt, und führen Sie Vorschau und Ausführung mit identischen Optionen aus.
- Für den technischen Lauf protokollieren Sie zusätzlich Tabellenpräfix, Primärschlüssel und Werkzeugoptionen, damit Vorschau und Ausführung denselben Datenbestand bearbeiten.
- Protokollieren Sie Such- und Ersatzwert, Tabellenumfang, Ausschlüsse und Trefferzahlen des ausgeführten Laufs.
Risiken, häufige Fehler, Backup und Rollback
Eine zu breite Ersetzung kann serialisierte Werte beschädigen, fremde Domains verändern oder historische Kennungen überschreiben. Solche Ziele dürfen nicht ohne ausdrückliche Prüfung in den Schreibauftrag gelangen.
- Prüfen Sie vor dem Schreiben ausdrücklich GUID-Spalten, externe Callback-URLs und archivierte Texte; sie gehören in der Regel auf die Ausschlussliste.
- Bei Multisite prüfen Sie jede Netzwerk- und Subsite-Zuordnung separat; protokollrelative oder kodierte Varianten können sonst unbemerkt bleiben.
- Führen Sie die Ersetzung nach Fertigstellung der neuen Umgebung und vor Abschaltung der alten aus, wenn alte und neue Zuordnung sowie Zuständigkeiten für Ausnahmen feststehen.
- Brechen Sie den Lauf ab, sobald die Schreibzahl von der freigegebenen Vorschau abweicht, ein serialisierter Wert nicht mehr lesbar ist oder Login, Editor beziehungsweise Integrationen Fehler zeigen.
Die Sicherung bleibt bis zum Ende des Wartungsfensters unangetastet. Nach einem Abbruch wird die geprüfte Datenbank wiederhergestellt, bevor ein neuer Versuch beginnt.
Wie AIOWS unterstützt:
AIOWS Ersetzungs-Manager
AIOWS Ersetzungs-Manager führt die URL-Änderung über eine Vorschau und einen ausdrücklich freigegebenen Schreibvorgang aus. Dafür werden alter und neuer Wert einschließlich Protokoll, Slash, Großschreibung und Kodierung genau festgelegt. Tabellen, Spalten und Ausschlüsse begrenzen den Auftrag; eine zuvor geprüfte Datenbanksicherung bleibt Voraussetzung.
Prüfen Sie im Dry Run die Zuordnung vom alten zum neuen Host und bewahren Sie den Bericht auf. Klären Sie Abweichungen zwischen Vorschau- und Schreibzahlen, bevor Sie fortfahren. Anschließend werden nicht nur verbleibende Treffer gezählt, sondern auch die tatsächlich betroffenen WordPress-Funktionen getestet.
Das Modul kann die fachliche Bedeutung eines Treffers nicht selbst beurteilen und keine bereits beschädigte Serialisierung reparieren. Historische Angaben, externe Ziele und Plugin-spezifische Daten benötigen deshalb weiterhin eine verantwortliche Prüfung. Ändert sich der freigegebene Umfang zwischen Vorschau und Ausführung, wird der Dry Run wiederholt.
Passende AIOWS-Artikel
- HTTP-URLs in WordPress sicher durch HTTPS ersetzen
- WordPress Suchen und Ersetzen ohne serialisierte Daten zu beschädigen
- WordPress-Domain in der Datenbank ändern
Fazit und empfohlener Weg
Empfohlen sind tabellenweise Bestandsaufnahme, serialisierungsfähige Vorschau, geprüfte Ausschlüsse und ein begrenzter Schreibvorgang nach Inbetriebnahme der neuen Domain. Datenbankzählung und echter Crawl schließen ab; die alte Umgebung bleibt bis zur fachlichen Abnahme erhalten.
