Migration von WordPress-Datenbanken

Wenn der Umzug zugleich ein Neubau ist, finden Sie mehr dazu bei unseren Migrationen zu Astro und Next.js.

#1. Warum SQL REPLACE serialisierte WordPress-Daten beschädigt

WordPress speichert viele Konfigurationsoptionen, Widget-Layouts und Theme-Eigenschaften in der Tabelle wp_options (sowie in wp_postmeta, wp_usermeta und wp_termmeta) als serialisierte Arrays oder Objekte. Ein serialisierter PHP-String gibt für jeden Stringwert den Datentyp und die Länge in Bytes an.

#Wie ein serialisierter PHP-String die Länge speichert

Nehmen wir diesen serialisierten String, der eine Domain-Einstellung enthält: s:22:"https://old-domain.com";

In dieser Struktur gilt:

• s legt den Typ als String fest.
• 22 besagt, dass der Wert genau 22 Bytes lang ist.
• "https://old-domain.com" ist der Wert selbst.

Ein Array mit Theme-Optionen und einer Logo-URL sieht serialisiert so aus: a:2:{s:11:"theme_color";s:4:"blue";s:8:"logo_url";s:28:"http://dev.site.com/logo.png";}

Jeder Schlüssel und jeder Wert trägt seine Länge: theme_color hat 11 Bytes, logo_url 8 und die URL 28.

#Warum eine falsche Stringlänge WordPress die Option verwerfen lässt

Wenn Sie die Domain mit einem normalen SQL-REPLACE ändern, etwa von old-domain.com auf my-new-company-domain.com, schreibt die Abfrage den Wert um, lässt die Längenangabe aber unverändert: s:22:"https://my-new-company-domain.com";

Der neue Wert ist 33 Bytes lang, die Angabe lautet aber weiterhin 22. Beim Lesen der Zeile reicht WordPress sie durch maybe_unserialize(). PHP liest 22 Bytes (https://my-new-company), erwartet das schließende Anführungszeichen, findet stattdessen einen Bindestrich, und unserialize() gibt false zurück. Die Option, die Ihr Theme oder Plugin erwartet, kommt als false an: Das Theme fällt auf seine Standardwerte zurück, Widgets verschwinden, und manche Plugins fragen erneut nach ihren Lizenzschlüsseln.

Umgekehrt passiert dasselbe. Wer im Logo-Beispiel dev.site.com durch site.com ersetzt, erhält eine URL mit 24 Bytes unter einer Angabe, die weiterhin 28 lautet, und das ganze Array wird unlesbar, nicht nur das Logo.

Eine Ersetzung übersteht ein einfaches SQL-REPLACE nur dann, wenn alter und neuer String exakt gleich lang sind. Das ist Zufall, keine Methode.

#Serialisierte Objekte und __PHP_Incomplete_Class

Steht ein serialisierter String für ein Objekt: O:31:"WPPoland\Database\CustomObject":1:{...}

PHP ordnet den gespeicherten Klassennamen einer zur Laufzeit geladenen Klasse zu. Ist die Klasse beim Deserialisieren nicht geladen (zum Beispiel weil das Plugin, das sie definiert, inaktiv ist oder die Migration seinen Namespace umbenannt hat), erzeugt PHP stattdessen einen Platzhalter vom Typ __PHP_Incomplete_Class. Dessen Methoden lassen sich nicht aufrufen, und Code, der das echte Objekt erwartet, schlägt fehl. Serialisierungsfähige Werkzeuge deserialisieren solche Werte und serialisieren sie neu; Klassen benennen sie nicht um.

#2. WordPress-Domain mit WP-CLI ändern

WP-CLI bringt den Befehl search-replace mit. Laut offizieller Referenz “verarbeitet er PHP-serialisierte Daten intelligent und ändert keine Primärschlüsselwerte” (WP-CLI-Befehlsreferenz, eigene Übersetzung). Das ist die Standardmethode, um URLs in der WordPress-Datenbank zu aktualisieren.

#Schritt 1: Datenbank-Backup exportieren

Bevor Sie eine einzige Zeile anfassen, exportieren Sie ein vollständiges SQL-Backup:

# Datenbank in eine SQL-Datei exportieren
wp db export backup-pre-domain-migration.sql

Prüfen Sie bei dieser Gelegenheit auch, ob der neue Server dieselbe PHP-Version wie der alte verwendet, damit sich Theme und Plugins nach dem Umzug gleich verhalten.

#Schritt 2: Probelauf mit search-replace

Führen Sie den Befehl zuerst mit --dry-run aus. Laut Referenz führt das “den gesamten Such- und Ersetzungsvorgang aus und zeigt einen Bericht, speichert die Änderungen aber nicht in der Datenbank” (eigene Übersetzung).

# Probelauf: zeigt, was sich ändern würde, schreibt nichts
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid --dry-run

Der Bericht ist eine Tabelle mit den Spalten Table, Column, Replacements und Type, eine Zeile pro Spalte mit Treffer, gefolgt von einer Zeile wie Success: 245 replacements to be made. (die Zahlen hängen ganz von Ihrer Website ab). Die Spalte Type zeigt SQL oder PHP, also welche Engine diese Spalte verarbeitet hat.

#Was —precise wirklich bewirkt

Die Referenz beschreibt --precise so: “Erzwingt die Verwendung von PHP (statt SQL) für alle Spalten” (eigene Übersetzung). Standardmäßig “nutzt der Befehl schnelle SQL-Abfragen, wechselt aber bei Spalten mit serialisierten Daten automatisch zu PHP” (eigene Übersetzung). Zum Schutz serialisierter Werte brauchen Sie --precise also nicht, denn WP-CLI erkennt sie bereits selbst. Setzen Sie --precise ein, wenn Sie überall PHP-Verarbeitung wollen, etwa weil Sie der Erkennung bei einer Spalte mit ungewöhnlichem Inhalt nicht trauen, und nehmen Sie dafür einen längeren Lauf in Kauf.

#Welche Tabellen: Standard, —all-tables und —all-tables-with-prefix

Standardmäßig verwendet der Befehl nur die Tabellen, die im Objekt $wpdb registriert sind, also die Core-Tabellen und dort registrierte Plugin-Tabellen. Zwei Flags erweitern den Umfang:

Viele Plugins legen eigene Tabellen an, ohne sie in $wpdb zu registrieren, sodass ein Standardlauf dort gespeicherte URLs übersehen kann. --all-tables-with-prefix bezieht sie sicherer ein. Nutzen Sie --all-tables nur, wenn die Datenbank allein dieser Website gehört: Teilen sich zwei WordPress-Installationen eine Datenbank mit unterschiedlichen Präfixen, schreibt --all-tables auch die URLs der anderen Website um.

#Warum die Spalte guid ausgelassen wird

Die WordPress-Dokumentation zum Umzug einer Website ist bei der Spalte guid in wp_posts eindeutig: “Ändern Sie den Inhalt der GUID-Spalte niemals, unter keinen Umständen” (Moving WordPress, developer.wordpress.org, eigene Übersetzung). Die GUID identifiziert einen Beitrag gegenüber Feedreadern; ändert man sie, zeigen diese alte Beiträge als neu an. Die WP-CLI-Referenz verwendet genau diesen Fall als Beispiel für das Auslassen einer Spalte: --skip-columns=guid.

#Schritt 3: Ersetzung ausführen

Sieht der Bericht des Probelaufs richtig aus, führen Sie denselben Befehl ohne --dry-run aus. --skip-columns akzeptiert auch tabellenqualifizierte Namen (table.column), und --skip-tables schließt ganze Tabellen aus, was bei großen Datenbanken mit Log-Tabellen hilft:

# Ausführen, GUIDs behalten, nicht registrierte Plugin-Tabellen mit dem Präfix einbeziehen
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables-with-prefix --skip-columns=guid

Um eine migrierte SQL-Datei zu erzeugen, ohne die Live-Datenbank anzufassen, verwenden Sie --export. Laut Referenz schreibt die Option “die umgewandelten Daten als SQL-Datei, statt die Ersetzungen in der Datenbank zu speichern” (eigene Übersetzung):

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid --export=migrated.sql

#Schritt 4: Gemischte Inhalte nach dem Wechsel auf HTTPS beheben

Zieht die Website zugleich von HTTP auf HTTPS um, folgt ein zweiter Lauf für fest eingetragene unsichere Verweise:

# Alte HTTP-Links durch HTTPS-Links auf der neuen Domain ersetzen
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables-with-prefix --skip-columns=guid

#Schritt 5: Permalinks und Objekt-Cache leeren

Nach einem erfolgreichen Lauf gibt WP-CLI bei aktivem Objekt-Cache selbst den Hinweis Please remember to flush your persistent object cache with wp cache flush aus. Folgen Sie ihm, erzeugen Sie die Rewrite-Regeln neu und prüfen Sie die gespeicherten URLs:

wp rewrite flush
wp cache flush
wp option get home
wp option get siteurl

Ohne Shell erreichen Sie dasselbe für die Rewrite-Regeln über Einstellungen > Permalinks und einen Klick auf “Änderungen speichern”. Leeren Sie danach auch den Page-Cache Ihres Caching-Plugins.

#Domainwechsel bei WordPress Multisite

Bei Multisite fügen Sie --network hinzu, damit der Befehl “alle in einer Multisite-Installation in $wpdb registrierten Tabellen” durchläuft (eigene Übersetzung). Multisite speichert außerdem die Domain jeder Website ohne Schema in der Spalte domain von wp_blogs und wp_site und die Netzwerk-Domain in DOMAIN_CURRENT_SITE in wp-config.php. Eine Suche nach https://old-domain.com findet in diesen Spalten kein nacktes old-domain.com, prüfen Sie die Spalten und die Konstante also separat. Die WordPress-Dokumentation zum Ändern der Website-URL weist darauf hin, dass ihre Anleitungen “nur für Einzelinstallationen von WordPress gelten” (eigene Übersetzung).

#3. WP_HOME und WP_SITEURL in wp-config.php setzen

Enthält die Datenbank noch die alte Domain, die Website soll aber schon unter der neuen laden, können Sie beide Werte in wp-config.php überschreiben. Laut Dokumentation zu wp-config.php “überschreibt WP_SITEURL den Wert für siteurl aus der Tabelle wp_options”, und WP_HOME überschreibt den Wert für home, “ändert ihn aber nicht in der Datenbank” (eigene Übersetzung). Der Wert home ist die Adresse, die Besucher eintippen; siteurl ist die Adresse, unter der die Core-Dateien liegen. Beide sollten https:// enthalten und keinen abschließenden Schrägstrich haben.

#Vorübergehende URL-Überschreibung in wp-config.php auf Staging

Die Überschreibung ändert Routing und Asset-URLs, nicht die gespeicherten Zeilen. Links in Beitragsinhalten, Post-Meta und Plugin-Einstellungen zeigen weiter auf die alte Domain, bis Sie ein Search-Replace ausführen. Die Dokumentation warnt außerdem, dass “die URL auf den alten Datenbankwert zurückfällt, sobald diese Zeile aus wp-config entfernt wird” (eigene Übersetzung). Betrachten Sie die Konstanten als Zugang zum Dashboard und führen Sie vor dem Livegang die vollständige Ersetzung aus:

// Gespeicherte URLs überschreiben, solange die Datenbank noch die alte Domain enthält
define( 'WP_HOME', 'https://new-domain.com' );
define( 'WP_SITEURL', 'https://new-domain.com' );

Solange die Konstanten definiert sind, lassen sich die beiden URL-Felder unter Einstellungen > Allgemein nicht bearbeiten, weil die Werte fest eingetragen sind.

#Website-URL aus dem aktuellen Hostnamen setzen

Die Dokumentation zeigt eine dynamische Variante auf Basis von $_SERVER['HTTP_HOST'], nützlich, wenn eine Codebasis auf lokalen, Staging- und Produktionshosts läuft:

define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] );
define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] );

Dazu gehört eine Warnung: HTTP_HOST “wird von PHP dynamisch aus dem HTTP-Host-Header der Anfrage erzeugt und kann daher Sicherheitslücken durch Dateieinbindung ermöglichen” (eigene Übersetzung). Läuft Apache mit UseCanonicalName On, stammt SERVER_NAME dagegen aus der Serverkonfiguration, und die Dokumentation nennt es in diesem Fall die sicherere Wahl. Auf einem öffentlichen Produktionsserver ist ein fester Wert oder eine Liste erlaubter Hosts vorzuziehen.

#Weitere Wege zur Website-URL: wp option update, RELOCATE und functions.php

Der WordPress-Leitfaden Moving WordPress nennt mehrere Wege, die beiden gespeicherten Werte zu ändern:

• WP-CLI: wp option update home 'https://example.com' und wp option update siteurl 'https://example.com'. Das schreibt die Werte in wp_options und ändert sonst nichts.
• functions.php: vorübergehend update_option( 'siteurl', ... ) und update_option( 'home', ... ) ins aktive Theme einfügen, die Website ein paarmal laden und den Code wieder entfernen. Der Leitfaden sagt klar: “Lassen Sie diesen Code nicht in der Datei functions.php” (eigene Übersetzung).
• RELOCATE: define( 'RELOCATE', true ); in wp-config.php einfügen, sich über wp-login.php unter der neuen Adresse anmelden, beide Felder unter Einstellungen > Allgemein prüfen und die Zeile wieder entfernen. Der Leitfaden nennt es unsicher, sie stehen zu lassen, und weist darauf hin, dass sie nur die Website-URL aktualisiert; alle anderen Verweise brauchen weiterhin ein Search-Replace.
• Direkte Bearbeitung der Datenbank: nach einem Backup die Zeilen siteurl und home in der Optionstabelle in phpMyAdmin bearbeiten (das Tabellenpräfix kann von wp_ abweichen).

Keiner dieser Wege berührt URLs im Inhalt. Deshalb bleibt das Search-Replace aus Abschnitt 2 der Hauptschritt.

#4. Search-Replace ohne SSH: Better Search Replace und Search Replace DB

Der WordPress-Migrationsleitfaden nennt zwei Alternativen zu WP-CLI für Hosts ohne Shell-Zugang.

#Plugin Better Search Replace

Wenn Sie das Dashboard noch erreichen, führt das Plugin Better Search Replace unter Werkzeuge > Better Search Replace eine serialisierungsfähige Ersetzung aus:

1. Plugin installieren und aktivieren.
2. Die alte URL in Search for und die neue URL in Replace with eintragen.
3. Die zu verarbeitenden Tabellen auswählen.
4. Beim ersten Durchgang Run as dry run? aktiviert lassen und den Bericht prüfen.
5. Die Probelauf-Option deaktivieren und erneut ausführen.

Lassen Sie die Option für Groß- und Kleinschreibung (Case-Insensitive) deaktiviert, damit nur exakte Treffer ersetzt werden. Das Plugin läuft innerhalb von PHP-Anfragen, kann bei sehr großen Tabellen also an das Ausführungszeitlimit des Hosts stoßen, und es nützt nichts mehr, wenn das Dashboard bereits auf die alte Domain umleitet.

#Skript Search Replace DB von interconnect/it

Sind weder WP-CLI noch das Dashboard verfügbar, verweist der Leitfaden auf das Skript von interconnect/it, um “alle Vorkommen Ihrer alten Domain oder Ihres alten Pfads sicher auf die neuen zu ändern”, mit der Warnung, “diese Option nur zu nutzen, wenn Sie mit Datenbankadministration vertraut sind” (eigene Übersetzung). Laden Sie es in einen zufällig benannten Ordner hoch, führen Sie zuerst den Probelauf und dann die Ersetzung aus und löschen Sie den Ordner sofort danach: Wer ihn findet, kann die Datenbank lesen und umschreiben.

#5. PHP-Skript für Search-Replace in serialisierten Daten

Brauchen Sie die Ersetzung in eigenem PHP-Code (etwa in einer Deployment-Pipeline ohne WP-CLI), durchläuft diese Klasse Arrays und Objekte rekursiv, ersetzt Strings und serialisiert neu, sodass PHP die Längenangaben selbst neu berechnet.

Legen Sie sie als scripts/class-serialization-replace.php an:

<?php
declare(strict_types=1);

namespace WPPoland\Database\Migrator;

class SerializationAwareReplacer {

    private string $search;
    private string $replace;

    public function __construct( string $search, string $replace ) {
        $this->search  = $search;
        $this->replace = $replace;
    }

    /**
     * Einstiegspunkt: Strings in den Daten rekursiv suchen und ersetzen.
     */
    public function process( $data ) {
        if ( is_string( $data ) ) {
            // Prüfen, ob der String serialisiert ist
            if ( $this->is_serialized_string( $data ) ) {
                $unserialized = unserialize( $data );
                if ( false !== $unserialized ) {
                    return serialize( $this->process( $unserialized ) );
                }
            }
            return str_replace( $this->search, $this->replace, $data );
        }

        if ( is_array( $data ) ) {
            $cleaned = [];
            foreach ( $data as $key => $value ) {
                $cleaned[ $key ] = $this->process( $value );
            }
            return $cleaned;
        }

        if ( is_object( $data ) ) {
            $cleaned = clone $data;
            foreach ( get_object_vars( $data ) as $key => $value ) {
                $cleaned->$key = $this->process( $value );
            }
            return $cleaned;
        }

        return $data;
    }

    /**
     * Prüft, ob ein String serialisiert ist.
     */
    private function is_serialized_string( string $string ): bool {
        $string = trim( $string );
        if ( 'N;' === $string ) {
            return true;
        }
        if ( strlen( $string ) < 4 ) {
            return false;
        }
        if ( ':' !== $string[1] ) {
            return false;
        }
        $last_char = substr( $string, -1 );
        if ( ';' !== $last_char && '}' !== $last_char ) {
            return false;
        }
        $token = $string[0];
        switch ( $token ) {
            case 's':
                if ( '"' !== substr( $string, -2, 1 ) ) {
                    return false;
                }
                return true;
            case 'a':
            case 'O':
                return (bool) preg_match( "/^{$token}:[0-9]+:/s", $string );
            case 'b':
            case 'i':
            case 'd':
                return (bool) preg_match( "/^{$token}:[0-9.E-]+;\$/", $string );
        }
        return false;
    }
}

get_object_vars() sieht, von außerhalb der Klasse aufgerufen, nur öffentliche Eigenschaften, private und geschützte Eigenschaften von Objekten bleiben also unverändert. Innerhalb von WordPress übernehmen die Core-Funktionen is_serialized() und maybe_unserialize() die Erkennung; WP-CLI bleibt die getestete Option.

#6. Alte Domain mit 301-Regeln umleiten

Googles Dokumentation zu Websiteumzügen mit URL-Änderungen verlangt dauerhafte serverseitige Weiterleitungen, “etwa 301 und 308” (eigene Übersetzung), von jeder alten URL auf ihr neues Gegenstück. Die Dokumentation zu Weiterleitungen erklärt, dass bei diesen dauerhaften Codes “die Indexierungspipeline die Weiterleitung als Signal dafür nutzt, dass das Weiterleitungsziel kanonisch sein sollte” (eigene Übersetzung); temporäre Codes (302, 303, 307) senden dieses Signal nicht.

#Nginx-301-Weiterleitung mit Erhalt der Request-URI

Pfad und Query-String bleiben mit $request_uri erhalten. Googles Leitfaden zum Websiteumzug rät davon ab, viele alte URLs auf eine einzige, unpassende Seite wie die neue Startseite zu schicken; die Regel unten erzeugt eine Zuordnung Seite für Seite:

server {
    listen 80;
    listen 443 ssl;
    server_name old-domain.com www.old-domain.com;

    # ssl_certificate und ssl_certificate_key für die alte Domain gehören hierher

    # Dauerhafte Weiterleitung mit Erhalt von Pfad und Query-String
    return 301 https://new-domain.com$request_uri;
}

Die alte Domain braucht weiterhin ein gültiges Zertifikat: Eine HTTPS-Anfrage an sie scheitert sonst schon beim TLS-Handshake, bevor Nginx die Weiterleitung senden kann.

#Apache-301-Weiterleitung per .htaccess auf eine neue Domain

Fügen Sie diese Regeln ganz oben in die .htaccess auf der alten Domain ein:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} ^(?:www\.)?old-domain\.com$ [NC]
  RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]
</IfModule>

mod_rewrite hängt den ursprünglichen Query-String standardmäßig an das Ziel an, ?page=2 übersteht die Weiterleitung also.

#Weiterleitung per Cloudflare Worker am Edge

Läuft die alte Domain über den Cloudflare-Proxy, kann ein Worker die Weiterleitung beantworten, ohne den Ursprungsserver zu erreichen. Der Code folgt der Modulsyntax aus Cloudflares eigenem Weiterleitungsbeispiel:

export default {
  async fetch(request) {
    const base = "https://new-domain.com";
    const { pathname, search } = new URL(request.url);
    return Response.redirect(`${base}${pathname}${search}`, 301);
  },
};

#7. SEO-Checkliste für die Migration und Einrichtung der Google Search Console

#Tool zur Adressänderung in der Search Console nutzen

Die Hilfeseite zum Tool zur Adressänderung nennt diese Bedingungen:

1. Inhaberschaft: “Sie müssen Inhaber sowohl der alten als auch der neuen Property in der Search Console sein” (eigene Übersetzung).
2. Nur auf Domainebene: Das Tool “kann nur für Properties auf Domainebene verwendet werden” und “verschiebt keine Subdomains unterhalb der angegebenen Domain (einschließlich www)” (eigene Übersetzung). Reichen Sie separate Anträge für die www- und Nicht-www-Varianten ein, die genutzt werden oder früher genutzt wurden.
3. Zuerst die Weiterleitung: Richten Sie eine 301-Weiterleitung von der alten auf die neue Startseite und von den übrigen Seiten ein. Das Tool prüft, ob Sie Inhaber beider Websites sind und ob einige Seiten 301-Weiterleitungen zurückgeben.
4. Ausführen: Öffnen Sie die alte Property, gehen Sie zu den Einstellungen, wählen Sie die Adressänderung und dann die neue Property.
5. Sitemaps: Reichen Sie die neue XML-Sitemap ein. Laut Googles Leitfaden zum Websiteumzug sind Warnungen zu weiterleitenden URLs in der alten Sitemap zu erwarten, solange beide eingereicht sind.

Für einen Wechsel von HTTP auf HTTPS, zwischen www und Nicht-www auf derselben Domain oder für Pfadänderungen innerhalb einer Domain ist das Tool nicht nötig.

#Was auf der neuen Domain noch angepasst werden muss

Der Leitfaden zum Websiteumzug nennt die Änderungen auf der Website, die zu den Weiterleitungen gehören:

• Interne Links aktualisieren, damit sie direkt auf die neuen URLs zeigen statt über eine Weiterleitung.
• Jeder neuen URL ein selbstreferenzierendes Canonical-Tag geben.
• Bei Einsatz von hreflang “die Annotationen unbedingt auf die neuen URLs aktualisieren” (eigene Übersetzung).
• Prüfen, ob die robots.txt auf der neuen Domain nicht noch ein Disallow: / aus dem Staging enthält.

#8. Wie lange Weiterleitungen nach einem WordPress-Domainwechsel bestehen bleiben

Google nennt zwei Zeiträume. Die Hilfeseite zur Adressänderung sagt, dass die Weitergabe der Signale “180 Tage nach dem Start der Migration in der Search Console” andauert, und bittet darum, die Weiterleitungen mindestens 180 Tage beizubehalten, “länger, wenn Sie noch Zugriffe über die Google Suche darauf sehen” (eigene Übersetzung). Der Leitfaden zum Websiteumzug geht weiter: Weiterleitungen so lange wie möglich beibehalten, in der Regel mindestens ein Jahr. Dazu gehört, die Registrierung der alten Domain zu verlängern, denn die Weiterleitungen enden an dem Tag, an dem die Domain ausläuft.

Zur Dauer sagt derselbe Leitfaden, dass es bei einer mittelgroßen Website “einige Wochen oder länger dauern kann” (eigene Übersetzung), bis Google nach und nach die neuen URLs anzeigt; größere Websites brauchen länger. Ranking-Schwankungen in diesem Zeitraum sind zu erwarten, beurteilen Sie den Umzug also anhand von Search-Console-Daten über Wochen, nicht über Tage.

#9. Warum WordPress nach der Migration noch auf die alte Domain umleitet

Schickt die Website Sie nach der Ersetzung weiter auf die alte Adresse, prüfen Sie diese Stellen in dieser Reihenfolge:

• wp-config.php: Eine vergessene Konstante WP_HOME oder WP_SITEURL mit dem alten Wert überschreibt die Datenbank.
• wp_options: wp option get home und wp option get siteurl ausführen oder die beiden Zeilen in phpMyAdmin lesen.
• .htaccess und Serverkonfiguration: Manche Sicherheits- und Weiterleitungs-Plugins schreiben dort Weiterleitungsregeln, und ein alter server-Block kann noch existieren.
• Caches: Page-Cache, Objekt-Cache (wp cache flush), ein CDN und der Browser-Cache einer früheren 301 können alle das alte Ziel ausliefern.

#10. Checkliste für den WordPress-Domainwechsel

Nutzen Sie diese Checkliste für Ihre WordPress-Domainmigrationen:

• Datenbank und vollständiges Dateisystem sichern, einschließlich wp-content/uploads.
• Neuen Host konfigurieren, SSL-Zertifikate für die neue Domain installieren und auf der alten ein gültiges Zertifikat behalten.
• Datenbank importieren und Zugangsdaten in wp-config.php aktualisieren.
• wp search-replace mit --dry-run und --skip-columns=guid ausführen und den Bericht prüfen.
• Die Ersetzung für die HTTPS- und die HTTP-Variante ausführen.
• Nicht mehr benötigte temporäre Zeilen mit WP_HOME, WP_SITEURL oder RELOCATE entfernen.
• Rewrite-Regeln und Caches leeren, danach home und siteurl prüfen.
• Seitengenaue 301-Weiterleitungen auf der alten Domain einrichten.
• Canonical-Tags, hreflang-Annotationen und interne Links aktualisieren.
• Adressänderung in der Search Console und die neue Sitemap einreichen.
• Weiterleitungen und die Registrierung der alten Domain mindestens ein Jahr beibehalten.

Sie brauchen Hilfe bei der Migration Ihrer WordPress-Datenbank oder bei Weiterleitungsregeln auf Serverebene? Als WordPress-Entwickler prüfe ich Ihre Datenbank, führe die Migration durch und richte die Search Console ein. Kontaktieren Sie mich, um Ihr Projekt zu besprechen.