WordPress-Domain in der Datenbank ändern

Ein Unternehmen wechselt von example.net zu example.com. DNS zeigt bereits mit beiden Namen auf den neuen Server, doch WordPress erzeugt noch den alten Canonical-Host, das Zertifikat deckt nur den neuen Namen ab und eine sofortige globale Ersetzung könnte Administratoren aussperren, bevor Redirects und Cookies bereit sind.

Der Beitrag zeigt, in welcher Reihenfolge DNS, TLS, WordPress-Adressen und gespeicherte URLs umgestellt werden, wie beide Domains während der Abnahme genutzt werden und wann ein Rollback nötig ist.

Was das Thema bedeutet

Eine WordPress-Domainänderung koordiniert die maßgeblichen Anwendungsadressen mit gespeicherten eigenen URLs sowie DNS, TLS, Proxy, Cookies, E-Mail und Weiterleitungen. home und siteurl haben unterschiedliche Aufgaben, Multisite ergänzt Netzwerk- und Subsite-Zuordnungen. Die Datenbankersetzung ist ein Schritt des Cutovers, nicht die gesamte Domainmigration.

• Erfassen Sie alte und neue Hosts, home und siteurl, DNS samt TTL, Zertifikat, Proxy-Ursprung, Cookie-Domain, Multisite-Modus, Mailidentitäten, externe Callbacks und aktuellen Notfallzugang für Administratoren.
• Trennen Sie Canonical-Anwendungseinstellungen von Inhaltsreferenzen und externen Systemen wie OAuth-Callbacks, Zahlungs-Webhooks, Lizenzen, Analytics-Properties, Mailauthentifizierung und festem Servercode.
• Kehren Sie zu alten Canonical-Werten zurück, wenn Login, Cookies, TLS, Callbacks, Multisite-Routing oder kritische Transaktionen scheitern oder ein Eigentümer seine gespeicherte Domain nicht bewerten kann.

Ein realistisches WordPress-Beispiel

Vor dem Cutover werden homeund siteurl, Zertifikat, DNS-Einträge, Proxy-Konfiguration, Cookies und externe Callbacks erfasst. Die Canonical-Adressen in WordPress werden geordnet geändert; gespeicherte Inhalts- und Medien-URLs folgen erst danach mit einer serialisierungssicheren Vorschau.

Warum es wichtig ist und wann es eingesetzt wird

Die Domainänderung findet in einem geplanten Wartungsfenster statt, sobald der neue Host über HTTPS erreichbar ist und beide Namen für Tests zur Verfügung stehen. Die alte Domain bleibt aktiv, bis Login, Cookies, Medien, Formulare, Webhooks, E-Mail und Weiterleitungen abgenommen sind.

Unterscheiden Sie WordPress-Konfiguration, Datenbankinhalte und externe Systeme. OAuth-Callbacks, Zahlungs-Webhooks, Lizenzserver, Analytics-Dienste und Mailauthentifizierung werden nicht automatisch durch eine Datenbankersetzung aktualisiert. Für jede Abhängigkeit braucht es eine zuständige Person und einen eigenen Test.

Der einfache Weg für Einsteiger

1. Richten Sie die neue Domain zunächst am Server ein und stellen Sie ein gültiges Zertifikat bereit.
2. Notieren Sie die bisherigen Werte von homeund siteurlund sichern Sie die Datenbank.
3. Ändern Sie die WordPress-Adressen und prüfen Sie sofort Frontend und Administratorzugang über die neue Domain.
4. Suchen Sie anschließend mit einer serialisierungssicheren Vorschau nach internen Verweisen auf den alten Host.
5. Aktivieren Sie Weiterleitungen erst, nachdem Medien, Formulare und Cookies unter beiden Hosts geprüft wurden.

Der technische Weg

Technisch prüfen Sie zuerst die neue Domain direkt am Ursprung und am Proxy. Anschließend ändern Sie die Canonical-Werte, testen den Administratorzugang und führen für eigene Alt-Domain-Verweise einen Dry Run aus. Bei Multisite gehören Netzwerk- und Subsite-Zuordnungen ausdrücklich in die Planung.

• Testen Sie öffentlichen Weg und Admin-Login, Medien, Formulare, REST, Cron, Canonical und hreflang, Sitemap, Cookies, Callbacks und E-Mail; verfolgen Sie dann je alten Weg genau einen Redirect zum passenden neuen Pfad.
• Kontrollieren Sie am Proxy den übergebenen Host, das extern verwendete HTTPS-Protokoll und die gesetzten Cookie-Domains; bei Multisite zusätzlich Netzwerk- und Subsite-Zuordnungen.
• Prüfen Sie OAuth-Callbacks, Zahlungs-Webhooks, Lizenzdienste und Mailauthentifizierung unabhängig von der Datenbankersetzung.
• Protokollieren Sie die geänderten WordPress-Adressen, den Tabellenumfang der Ersetzung und die Redirect-Regeln des Cutovers.

Risiken, häufige Fehler, Backup und Rollback

Eine zu frühe Datenbankänderung kann Administratoren aussperren; eine globale Ersetzung kann fremde Kennungen oder historische Angaben verändern. Halten Sie deshalb einen serverseitigen Notfallzugang und eine geprüfte Datenbanksicherung bereit. Bei Fehlern an Login, TLS, Cookies oder kritischen Integrationen werden die vorherigen Canonical-Werte wiederhergestellt.

• Die Ausschlussliste schützt fremd verwaltete Ziele und historische Angaben davor, durch eine globale Alt-zu-neu-Ersetzung verändert zu werden.
• Im Rollback-Test müssen alter Host, Administratorzugang und kritische Integrationen noch funktionieren; ein Redirect darf fehlende Assets oder falsches Proxy-Vertrauen nicht verdecken.
• Planen Sie den Cutover erst, wenn für externe Callbacks, Mailauthentifizierung und Lizenzdienste jeweils eine zuständige Person benannt ist.
• Treten nach dem Cutover Fehler bei Login, Cookies oder Multisite-Routing auf, stoppen Sie weitere Ersetzungen und stellen zuerst die vorherigen WordPress-Adressen wieder her.

Halten Sie alte und neue Domain, DNS-TTL, Zertifikat und Rückfallwerte fest. Die alte Umgebung wird erst abgeschaltet, wenn das Team den Cutover ausdrücklich freigegeben hat.

Passende AIOWS-Artikel

• WordPress-URLs nach einem Umzug suchen und ersetzen
• HTTP-URLs in WordPress sicher durch HTTPS ersetzen
• WordPress Suchen-und-Ersetzen rückgängig machen

Fazit und empfohlener Weg

Empfohlen sind zuerst DNS und TLS, geschützter Adminzugang, geordnete Canonical-Änderung, geprüfte serialisierungsfähige Ersetzung und direkte Alt-zu-neu-Redirects. Beide Domains bleiben bis zur Abnahme von Anwendung, Integrationen und Suchsignalen aktiv.

Offizielle Quellen

• WordPress migrieren
• WP-CLI-Befehl search-replace