Eine Staging-Website ist von einer temporären Subdomain auf die Produktionsdomain gezogen. Nach Änderung zweier Optionen sieht die Startseite korrekt aus; Bilder, Page-Builder-Schaltflächen, Widgets, Canonical-Tags und Anmelde-Cookies verweisen jedoch weiter auf die Zwischenadresse.
Dieser Beitrag zeigt, welche URLs tatsächlich geändert werden müssen, wie serialisierte WordPress-Daten intakt bleiben und welche leicht übersehenen Verweise nach dem Umzug geprüft werden sollten.
- 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 und Rollback-Plan
- So unterstützt AIOWS: AIOWS Backup Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was beim Ändern von WordPress-URLs zu beachten ist
Eine URL-Änderung kann die öffentliche Website-Adresse, den Ort der WordPress-Dateien und absolute Verweise in Inhalten, Metadaten, Widgets oder Plugin-Tabellen betreffen. homebestimmt die öffentliche Adresse; siteurlbeschreibt, wo WordPress selbst installiert ist. Meist sind beide Werte gleich, sie erfüllen jedoch unterschiedliche Aufgaben.
Viele WordPress-Werte sind serialisiert und speichern die Länge enthaltener Zeichenfolgen. Eine einfache SQL-Ersetzung ändert den Text, aber nicht diese Längenangabe und kann den Wert unlesbar machen. DNS, TLS, Proxyregeln, Serverweiterleitungen, Caches und Rückrufadressen externer Dienste gehören nicht zur Datenbankersetzung.
Ein realistisches WordPress-Beispiel
Eine Staging-Website wechselt von preview.example.comauf die Produktionsdomain. Nach der Änderung von homeund siteurlfunktioniert die Navigation, doch ein Page Builder speichert die Vorschauadresse weiterhin in serialisierten Metadaten. Bilder laden vom alten Host, Canonical-Links widersprechen der Browseradresse und Links zur Passwortrücksetzung führen zurück zur Staging-Seite. Für die Datenbank ist eine gezielte, serialisierungssichere Ersetzung nötig; die Rückrufadresse des Maildienstes wird separat geändert.
Warum es wichtig ist und wann URLs ersetzt werden müssen
Ersetzen Sie gespeicherte URLs, wenn sich Domain, Protokoll, Unterverzeichnis oder Installationspfad tatsächlich geändert haben. Zeigt lediglich DNS auf einen neuen Server, während die öffentliche Adresse gleich bleibt, ist keine datenbankweite Ersetzung nötig. Untersuchen Sie Weiterleitungsschleifen getrennt: Datenbank, Reverse Proxy, Webserver, WordPress und CDN können jeweils eigene Weiterleitungen erzeugen.
Der einfache Weg für Einsteiger
- Sichern Sie die Zieldatenbank und erfassen Sie alte und neue URL, Protokoll, Pfad, Tabellenpräfix, Netzwerkumfang und ausgeschlossene Spalten.
- Prüfen Sie zuerst
homeundsiteurl. Eine vorübergehende Definition inwp-config.phpdient nur dazu, den benötigten Dashboard-Zugang wiederherzustellen. - Führen Sie mit einem Werkzeug für serialisierte Daten zunächst einen Probelauf aus. Prüfen Sie betroffene Tabellen und Trefferzahlen und ersetzen Sie anschließend nur die exakte alte Adresse. GUID-Werte bleiben ohne dokumentierten Sonderfall unverändert.
- Leeren Sie WordPress-, Objekt-, Seiten-, Browser- und CDN-Caches erst, wenn gespeicherte Werte und Serverweiterleitungen stimmen.
- Prüfen Sie typische Seiten sowie Medien, Menüs, Page-Builder-Inhalte, Widgets, REST API, Anmeldung, Passwortrücksetzung, Canonical-Links, Sitemap, Weiterleitungen, Formulare und externe Rückrufadressen.
Der technische Weg
Verwenden Sie WP-CLI search-replaceoder ein anderes Werkzeug, das serialisierte Daten verarbeitet. Beginnen Sie mit einem Probelauf, begrenzen Sie den Tabellenumfang, prüfen Sie die Trefferzahlen und speichern Sie Befehl, Ausnahmen, Ausgabe und Exit-Status. GUID-Werte werden nur geändert, wenn ein dokumentierter Sonderfall dies ausdrücklich verlangt.
- Bei Multisite müssen Netzwerktabellen, Tabellen einzelner Sites, Domain-Mapping und Uploads separat geplant werden.
- Suchen Sie nach dem exakten alten Protokoll, Host, Port und Pfad; zu allgemeine Fragmente können Texte oder E-Mail-Adressen verändern.
- Suchen Sie nach dem Austausch erneut nach dem alten Host und beurteilen Sie jeden Resttreffer, statt ihn automatisch zu löschen.
Risiken, häufige Fehler und Rollback-Plan
- Eine einfache SQL-Ersetzung kann serialisierte Theme- und Plugin-Einstellungen beschädigen.
- Ein falscher Wert für
siteurlkann Dashboard und WordPress-Dateien unerreichbar machen. - Unbegründete Änderungen an GUID-Werten können Feedreader und andere externe Empfänger beeinträchtigen.
- Wer Caches vor der Korrektur von Daten und Weiterleitungen leert, erschwert die Diagnose, ohne die Ursache zu beheben.
Sichern Sie die Zieldatenbank unmittelbar vor der Ersetzung und bewahren Sie die Trefferzahlen des Probelaufs auf. Scheitert die Prüfung, spielen Sie diese Datenbankkopie zurück, leeren nur die vom Rollback betroffenen Caches und bestimmen den Umfang erneut.
So unterstützt AIOWS
AIOWS Backup Manager
Der AIOWS Backup Manager kann den unterstützten Wiederherstellungspunkt erstellen, der vor Änderungen an gespeicherten URLs oder Umgebungseinstellungen benötigt wird. Sichern Sie die Zieldatenbank und alle Dateien, die für die Rückkehr zum aktuellen Stand erforderlich sind, und prüfen Sie den Speicherort des Pakets.
Die URL-Ersetzung selbst braucht ein Werkzeug, das serialisierte WordPress-Daten korrekt verarbeitet. Der Backup Manager ändert weder DNS und Proxyregeln noch Serverweiterleitungen oder Rückrufadressen externer Dienste. Prüfen Sie nach der Datenbankänderung home, siteurl, Medien, Menüs, Widgets, Anmeldung, Weiterleitungen, Canonical-Links, Formulare und Rückrufadressen.
Bewahren Sie das Paket auf, bis die neue Domain diese Tests bestanden hat. Hat die Ersetzung gespeicherte Werte beschädigt oder den Zugriff verhindert, stellen Sie die Datenbank von vor der Änderung wieder her, statt eine zweite breite Ersetzung über den unbekannten Zustand auszuführen.
Passende AIOWS-Artikel
- WordPress-Umzug: Website sicher migrieren
- WordPress nach dem Umzug defekt? Vollständige Fehlerbehebung
- WordPress-Umzugscheckliste: vor und nach der Migration
Fazit und empfohlener Weg
Sichern Sie zuerst die Zieldatenbank und legen Sie homesowie siteurlbewusst fest. Prüfen Sie den Umfang mit einem Probelauf und ersetzen Sie nur die exakte alte Adresse. Leeren Sie die betroffenen Caches anschließend und testen Sie sowohl sichtbare Seiten als auch externe Rückrufadressen. Verbleibende Treffer werden geprüft und nicht pauschal gelöscht.
