{"id":1138,"date":"2026-03-12T17:24:48","date_gmt":"2026-03-12T14:24:48","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1138"},"modified":"2026-08-04T21:56:29","modified_gmt":"2026-08-04T21:56:29","slug":"wordpress-urls-nach-migration-aendern","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-urls-nach-migration-aendern\/","title":{"rendered":"WordPress-URLs nach der Migration sicher \u00e4ndern"},"content":{"rendered":"

Eine Staging-Website ist von einer tempor\u00e4ren Subdomain auf die Produktionsdomain gezogen. Nach \u00c4nderung zweier Optionen sieht die Startseite korrekt aus; Bilder, Page-Builder-Schaltfl\u00e4chen, Widgets, Canonical-Tags und Anmelde-Cookies verweisen jedoch weiter auf die Zwischenadresse.<\/p>\n

Dieser Beitrag zeigt, welche URLs tats\u00e4chlich ge\u00e4ndert werden m\u00fcssen, wie serialisierte WordPress-Daten intakt bleiben und welche leicht \u00fcbersehenen Verweise nach dem Umzug gepr\u00fcft werden sollten.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler und Rollback-Plan<\/a><\/li>\n
  7. So unterst\u00fctzt AIOWS: AIOWS Backup Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was beim \u00c4ndern von WordPress-URLs zu beachten ist<\/h2>\n

    Eine URL-\u00c4nderung kann die \u00f6ffentliche Website-Adresse, den Ort der WordPress-Dateien und absolute Verweise in Inhalten, Metadaten, Widgets oder Plugin-Tabellen betreffen. home<\/code> bestimmt die \u00f6ffentliche Adresse; siteurl<\/code> beschreibt, wo WordPress selbst installiert ist. Meist sind beide Werte gleich, sie erf\u00fcllen jedoch unterschiedliche Aufgaben.<\/p>\n

    Viele WordPress-Werte sind serialisiert und speichern die L\u00e4nge enthaltener Zeichenfolgen. Eine einfache SQL-Ersetzung \u00e4ndert den Text, aber nicht diese L\u00e4ngenangabe und kann den Wert unlesbar machen. DNS, TLS, Proxyregeln, Serverweiterleitungen, Caches und R\u00fcckrufadressen externer Dienste geh\u00f6ren nicht zur Datenbankersetzung.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Eine Staging-Website wechselt von preview.example.com<\/code> auf die Produktionsdomain. Nach der \u00c4nderung von home<\/code> und siteurl<\/code> funktioniert 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\u00fccksetzung f\u00fchren zur\u00fcck zur Staging-Seite. F\u00fcr die Datenbank ist eine gezielte, serialisierungssichere Ersetzung n\u00f6tig; die R\u00fcckrufadresse des Maildienstes wird separat ge\u00e4ndert.<\/p>\n

    Warum es wichtig ist und wann URLs ersetzt werden m\u00fcssen<\/h2>\n

    Ersetzen Sie gespeicherte URLs, wenn sich Domain, Protokoll, Unterverzeichnis oder Installationspfad tats\u00e4chlich ge\u00e4ndert haben. Zeigt lediglich DNS auf einen neuen Server, w\u00e4hrend die \u00f6ffentliche Adresse gleich bleibt, ist keine datenbankweite Ersetzung n\u00f6tig. Untersuchen Sie Weiterleitungsschleifen getrennt: Datenbank, Reverse Proxy, Webserver, WordPress und CDN k\u00f6nnen jeweils eigene Weiterleitungen erzeugen.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Sichern Sie die Zieldatenbank und erfassen Sie alte und neue URL, Protokoll, Pfad, Tabellenpr\u00e4fix, Netzwerkumfang und ausgeschlossene Spalten.<\/li>\n
    2. Pr\u00fcfen Sie zuerst home<\/code> und siteurl<\/code>. Eine vor\u00fcbergehende Definition in wp-config.php<\/code> dient nur dazu, den ben\u00f6tigten Dashboard-Zugang wiederherzustellen.<\/li>\n
    3. F\u00fchren Sie mit einem Werkzeug f\u00fcr serialisierte Daten zun\u00e4chst einen Probelauf aus. Pr\u00fcfen Sie betroffene Tabellen und Trefferzahlen und ersetzen Sie anschlie\u00dfend nur die exakte alte Adresse. GUID-Werte bleiben ohne dokumentierten Sonderfall unver\u00e4ndert.<\/li>\n
    4. Leeren Sie WordPress-, Objekt-, Seiten-, Browser- und CDN-Caches erst, wenn gespeicherte Werte und Serverweiterleitungen stimmen.<\/li>\n
    5. Pr\u00fcfen Sie typische Seiten sowie Medien, Men\u00fcs, Page-Builder-Inhalte, Widgets, REST API, Anmeldung, Passwortr\u00fccksetzung, Canonical-Links, Sitemap, Weiterleitungen, Formulare und externe R\u00fcckrufadressen.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      Verwenden Sie WP-CLI search-replace<\/code> oder ein anderes Werkzeug, das serialisierte Daten verarbeitet. Beginnen Sie mit einem Probelauf, begrenzen Sie den Tabellenumfang, pr\u00fcfen Sie die Trefferzahlen und speichern Sie Befehl, Ausnahmen, Ausgabe und Exit-Status. GUID-Werte werden nur ge\u00e4ndert, wenn ein dokumentierter Sonderfall dies ausdr\u00fccklich verlangt.<\/p>\n