Migracja bazy danych WordPress: WP-CLI, backup i dane serializowane

Jeśli przeprowadzka domeny jest przy okazji przebudową serwisu, zobacz nasze usługi migracji do Astro i Next.js.

#1. Dlaczego REPLACE w SQL psuje dane serializowane WordPressa

WordPress zapisuje wiele opcji konfiguracyjnych, układów widżetów i ustawień motywu w tabeli wp_options (a także w wp_postmeta, wp_usermeta i wp_termmeta) jako serializowane tablice lub obiekty. Serializowany ciąg PHP deklaruje typ danych i długość w bajtach każdej wartości tekstowej.

#Jak serializowany ciąg PHP zapisuje długość

Weźmy serializowany ciąg z ustawieniem domeny: s:22:"https://old-domain.com";

W tej strukturze:

• s oznacza typ string (ciąg znaków).
• 22 mówi, że wartość ma dokładnie 22 bajty.
• "https://old-domain.com" to sama wartość.

Tablica opcji motywu w PHP wygląda tak:

$options = array(
    'theme_color' => 'blue',
    'logo_url'    => 'http://dev.site.com/logo.png'
);

Po serializacji zajmuje jedną komórkę w bazie: a:2:{s:11:"theme_color";s:4:"blue";s:8:"logo_url";s:28:"http://dev.site.com/logo.png";}

Każdy klucz i każda wartość ma swoją długość: theme_color to 11 bajtów, logo_url to 8, a adres URL to 28.

#Dlaczego błędna długość ciągu sprawia, że WordPress gubi opcję

Jeśli zmienisz domenę zwykłym REPLACE w SQL, na przykład z old-domain.com na my-new-company-domain.com, zapytanie przepisze wartość, ale znacznik długości zostawi bez zmian: s:22:"https://my-new-company-domain.com";

Nowa wartość ma 33 bajty, a znacznik nadal mówi 22. WordPress odczytuje taki wiersz przez maybe_unserialize(). PHP czyta 22 bajty (https://my-new-company), oczekuje cudzysłowu zamykającego, trafia na myślnik i unserialize() zwraca false. Opcja, której spodziewał się motyw albo wtyczka, wraca jako false, więc motyw wraca do ustawień domyślnych, widżety znikają, a część wtyczek ponownie prosi o klucze licencyjne.

To samo działa w drugą stronę. Podmiana dev.site.com na site.com w przykładzie z logo daje adres o długości 24 bajtów pod znacznikiem, który wciąż mówi 28. Nieczytelna staje się wtedy cała tablica, nie tylko logo:

UPDATE wp_options SET option_value = REPLACE(option_value, 'dev.site.com', 'site.com');

Podmiana przeżyje zwykły REPLACE w SQL tylko wtedy, gdy stary i nowy ciąg mają dokładnie tę samą długość. To przypadek, a nie metoda. Dlatego do migracji bazy WordPress nie nadaje się ani edytor tekstu otwarty na pliku SQL, ani ręczne zapytanie. Potrzebne jest narzędzie, które rozpakuje dane, podmieni ciąg, przeliczy długości i spakuje dane z powrotem.

#Serializowane obiekty i __PHP_Incomplete_Class

Jeśli serializowany ciąg reprezentuje obiekt: O:31:"WPPoland\Database\CustomObject":1:{...}

PHP dopasowuje zapisaną nazwę klasy do klasy załadowanej w czasie działania. Jeśli klasa nie jest załadowana w chwili odczytu (na przykład dlatego, że definiująca ją wtyczka jest nieaktywna albo migracja zmieniła przestrzeń nazw), PHP tworzy w zamian obiekt zastępczy __PHP_Incomplete_Class. Nie da się wywołać jego metod, a kod oczekujący prawdziwego obiektu przestaje działać. Narzędzia świadome serializacji rozpakowują i ponownie pakują takie wartości, ale nie zmieniają nazw klas.

#2. Jak zmienić domenę WordPressa przez WP-CLI

WP-CLI ma polecenie search-replace. Oficjalna dokumentacja podaje, że polecenie “inteligentnie obsługuje dane serializowane PHP i nie zmienia wartości kluczy głównych” (dokumentacja polecenia WP-CLI, tłumaczenie własne). To standardowa metoda aktualizacji adresów URL w bazie WordPress.

#Krok 1: eksport kopii bazy danych

Zanim zmienisz jakikolwiek wiersz, wyeksportuj pełną kopię SQL. Przy okazji sprawdź, czy wersje PHP na starym i nowym serwerze są zgodne, i przenieś cały folder wp-content/uploads (na przykład przez rsync):

# Eksport bazy do pliku SQL
wp db export backup-pre-domain-migration.sql

#Krok 2: próba search-replace z —dry-run

Najpierw uruchom polecenie z --dry-run. Według dokumentacji ta flaga “wykonuje całą operację wyszukiwania i zamiany i pokazuje raport, ale nie zapisuje zmian w bazie” (tłumaczenie własne).

# Próba: raport tego, co by się zmieniło, bez zapisu
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables-with-prefix --skip-columns=guid --dry-run

Raport to tabela z kolumnami Table, Column, Replacements i Type, z jednym wierszem na każdą kolumnę, w której jest dopasowanie. Pod nią pojawia się linia w rodzaju Success: 245 replacements to be made. (liczby zależą wyłącznie od Twojej strony). Kolumna Type pokazuje SQL albo PHP, czyli silnik, który obsłużył daną kolumnę.

#Co naprawdę robi —precise

Dokumentacja opisuje --precise jako flagę, która “wymusza użycie PHP (zamiast SQL) dla wszystkich kolumn” (tłumaczenie własne). Domyślnie polecenie “używa szybkich zapytań SQL, ale automatycznie przełącza się na PHP dla kolumn zawierających dane serializowane” (tłumaczenie własne). Do ochrony danych serializowanych --precise nie jest więc potrzebne, bo WP-CLI sam je wykrywa. Użyj tej flagi, gdy chcesz przetwarzania w PHP wszędzie, na przykład gdy nie ufasz wykrywaniu w kolumnie z nietypową zawartością, i zaakceptuj dłuższy czas działania.

#Które tabele: domyślnie, —all-tables i —all-tables-with-prefix

Domyślnie polecenie obejmuje tylko tabele zarejestrowane w obiekcie $wpdb, czyli tabele rdzenia oraz tabele wtyczek, które się tam zarejestrowały. Zakres poszerzają dwie flagi:

Wiele wtyczek tworzy własne tabele bez rejestracji w $wpdb, więc domyślne uruchomienie może pominąć zapisane w nich adresy. --all-tables-with-prefix to bezpieczniejszy sposób, żeby je objąć. --all-tables stosuj tylko wtedy, gdy baza należy wyłącznie do tej jednej strony: jeśli dwie instalacje WordPressa dzielą bazę z różnymi prefiksami, --all-tables przepisze też adresy drugiej strony.

#Dlaczego pominąć kolumnę guid

Dokumentacja WordPressa o przenoszeniu strony jest jednoznaczna w sprawie kolumny guid w wp_posts: “Nigdy, pod żadnym pozorem nie zmieniaj zawartości kolumny GUID” (Moving WordPress, developer.wordpress.org, tłumaczenie własne). Ta sama strona wyjaśnia, że czytniki kanałów używają GUID, żeby rozpoznać, czy już pokazały dany wpis, więc “zmiana GUID sprawi, że wiele czytników nagle ponownie wyświetli Twoje treści” (tłumaczenie własne). Dokumentacja WP-CLI używa dokładnie tego przypadku jako przykładu pomijania kolumny: --skip-columns=guid.

#Krok 3: właściwa podmiana

Jeśli raport z próby wygląda dobrze, uruchom to samo polecenie bez --dry-run. --skip-columns przyjmuje też nazwy z tabelą (table.column), a --skip-tables wyklucza całe tabele, co pomaga w dużych bazach z tabelami logów:

# Wykonanie, GUID bez zmian, z niezarejestrowanymi tabelami wtyczek z prefiksem strony
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables-with-prefix --skip-columns=guid

Żeby przygotować zmigrowany plik SQL bez ruszania działającej bazy, użyj --export, które według dokumentacji zapisuje “przekształcone dane jako plik SQL zamiast zapisywać zmiany w bazie” (tłumaczenie własne):

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

#Krok 4: mixed content po przejściu na HTTPS

Jeśli strona przechodzi przy okazji z HTTP na HTTPS, uruchom drugi przebieg dla zapisanych na sztywno niezabezpieczonych odwołań:

# Zamiana starych linków HTTP na linki HTTPS w nowej domenie
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables-with-prefix --skip-columns=guid

#Krok 5: odświeżenie bezpośrednich odnośników i cache obiektów

Po udanym przebiegu, przy aktywnym cache obiektów, WP-CLI sam wypisuje komunikat Please remember to flush your persistent object cache with wp cache flush. Zrób to, wygeneruj ponownie reguły przepisywania i sprawdź zapisane adresy:

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

Bez dostępu do konsoli ten sam efekt dla reguł przepisywania daje wejście w Ustawienia > Bezpośrednie odnośniki i kliknięcie “Zapisz zmiany”. Wyczyść też cache strony w używanej wtyczce lub na serwerze.

#Zmiana domeny w WordPress multisite

W sieci multisite dodaj --network, żeby przejść przez “wszystkie tabele zarejestrowane w $wpdb w instalacji multisite” (tłumaczenie własne). Przewodnik Moving WordPress dodaje ręczne kontrole, których polecenie nie załatwia: tabele wp_site i wp_blogs trzeba “i tak przejrzeć ręcznie” (tłumaczenie własne), podobnie jak każdą tabelę opcji podstrony (wp_2_options, wp_3_options i tak dalej) pod kątem wartości home, siteurl i fileupload_url. Kolumna domain w tabelach sieci przechowuje samą nazwę hosta, więc wyszukiwanie https://old-domain.com jej nie znajdzie. Zaktualizuj też stałe sieci, które ekran konfiguracji sieci kazał dodać do wp-config.php. Instrukcje zmiany adresu strony w samym przewodniku według jego autorów “dotyczą wyłącznie pojedynczych instalacji WordPressa” (tłumaczenie własne).

#3. Ustawienie WP_HOME i WP_SITEURL w wp-config.php

Jeśli baza wciąż zawiera starą domenę, a stronę trzeba uruchomić pod nową, obie wartości można nadpisać w wp-config.php. Dokumentacja wp-config.php podaje, że WP_SITEURL “nadpisuje wartość siteurl z tabeli wp_options” (tłumaczenie własne), a WP_HOME nadpisuje wartość home, “ale nie zmienia jej w bazie danych” (tłumaczenie własne). Wartość home to adres, który wpisują odwiedzający, a siteurl to adres, pod którym leżą pliki rdzenia. Obie powinny zawierać https:// i nie kończyć się ukośnikiem.

#Tymczasowe nadpisanie adresów w wp-config.php na stagingu

Nadpisanie zmienia routing i adresy zasobów, ale nie zapisane wiersze. Linki w treści wpisów, w metadanych i w ustawieniach wtyczek nadal wskazują starą domenę, dopóki nie uruchomisz search-replace. Dokumentacja ostrzega też, że “adres wróci do starej wartości z bazy, jeśli ta linia zostanie kiedyś usunięta z wp-config” (tłumaczenie własne). Traktuj stałe jako sposób na wejście do kokpitu, a przed startem wykonaj pełną podmianę:

// Nadpisanie zapisanych adresów, dopóki baza zawiera starą domenę
define( 'WP_HOME', 'https://new-domain.com' );
define( 'WP_SITEURL', 'https://new-domain.com' );

Dopóki stałe są zdefiniowane, dwóch pól adresu w Ustawienia > Ogólne nie da się edytować, bo wartości są wpisane na sztywno.

#Adres strony na podstawie bieżącej nazwy hosta

Dokumentacja pokazuje też wariant dynamiczny oparty na $_SERVER['HTTP_HOST'], przydatny, gdy jedna baza kodu działa lokalnie, na stagingu i na produkcji:

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

Towarzyszy mu ostrzeżenie: HTTP_HOST “jest tworzony dynamicznie przez PHP na podstawie nagłówka HTTP HOST w żądaniu, co może umożliwić podatności typu file inclusion” (tłumaczenie własne). Gdy Apache działa z UseCanonicalName On, SERVER_NAME pochodzi z konfiguracji serwera, i dokumentacja nazywa go w takim przypadku bezpieczniejszym wyborem. Na publicznym serwerze produkcyjnym lepsza jest stała wartość albo lista dozwolonych hostów.

#Inne sposoby zmiany adresu: wp option update, RELOCATE i functions.php

Przewodnik Moving WordPress wymienia kilka sposobów zmiany dwóch zapisanych wartości:

• WP-CLI: wp option update home 'https://example.com' i wp option update siteurl 'https://example.com'. Zapisuje wartości w wp_options i nic poza tym nie zmienia.
• functions.php: tymczasowo dodaj update_option( 'siteurl', ... ) i update_option( 'home', ... ) do aktywnego motywu, załaduj stronę kilka razy, a potem usuń kod. Przewodnik pisze wprost: “Nie zostawiaj tego kodu w pliku functions.php” (tłumaczenie własne).
• RELOCATE: dodaj define( 'RELOCATE', true ); do wp-config.php, zaloguj się przez wp-login.php pod nowym adresem, sprawdź oba pola w Ustawienia > Ogólne i usuń linię. Przewodnik uznaje pozostawienie jej za niebezpieczne i zaznacza, że aktualizuje ona tylko adres strony, więc pozostałe odwołania nadal wymagają search-replace.
• Bezpośrednia edycja bazy: po zrobieniu kopii edytuj wiersze siteurl i home w tabeli opcji w phpMyAdmin (prefiks tabel może być inny niż wp_).

Żaden z tych sposobów nie zmienia adresów w treści, dlatego search-replace z sekcji 2 pozostaje głównym krokiem.

#4. Search-replace bez SSH: Better Search Replace i Search Replace DB

Przewodnik WordPressa po migracji wymienia dwie alternatywy dla WP-CLI na hostingach bez dostępu do powłoki.

#Wtyczka Better Search Replace

Jeśli masz jeszcze dostęp do kokpitu, wtyczka Better Search Replace wymienia wśród swoich funkcji “obsługę serializacji dla wszystkich tabel” (tłumaczenie własne) i dodaje swoją stronę w menu Narzędzia:

1. Zainstaluj i włącz wtyczkę, potem otwórz Narzędzia > Better Search Replace.
2. Wpisz stary adres w polu wyszukiwania, a nowy w polu zamiany.
3. Zaznacz tabele do przetworzenia.
4. Przy pierwszym przebiegu zostaw włączoną opcję próbną (dry run, domyślna od wersji 1.0.1) i sprawdź, ile pól by się zmieniło.
5. Wyłącz próbę i uruchom ponownie.

Wtyczka działa w ramach żądań PHP, więc na bardzo dużych tabelach może trafić na limit czasu wykonania na hostingu. Nie pomoże też, gdy kokpit już przekierowuje na starą domenę.

#Skrypt Search Replace DB od interconnect/it

Gdy nie ma ani WP-CLI, ani kokpitu, przewodnik wskazuje skrypt interconnect/it, który pozwala “bezpiecznie zmienić wszystkie wystąpienia starej domeny lub ścieżki na nowe” (tłumaczenie własne), z ostrzeżeniem, by “korzystać z tej opcji tylko wtedy, gdy swobodnie czujesz się w administrowaniu bazą danych” (tłumaczenie własne). Wgraj go do folderu o losowej nazwie, uruchom próbę, potem podmianę i od razu usuń folder: każdy, kto go znajdzie, może odczytać i przepisać bazę.

#5. Skrypt PHP do search-replace w danych serializowanych

Jeśli podmiana ma działać we własnym kodzie PHP (na przykład w pipeline wdrożeniowym bez WP-CLI), ta klasa rekurencyjnie przechodzi przez tablice i obiekty, podmienia ciągi i ponownie serializuje dane, więc znaczniki długości przelicza samo PHP.

Utwórz ją jako scripts/class-serialization-replace.php:

<?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;
    }

    /**
     * Punkt wejścia: rekurencyjne wyszukiwanie i zamiana ciągów w danych.
     */
    public function process( $data ) {
        if ( is_string( $data ) ) {
            // Sprawdzenie, czy ciąg jest serializowany
            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;
    }

    /**
     * Sprawdza, czy ciąg jest serializowany.
     */
    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() zwraca właściwości dostępne z zakresu wywołania, czyli tutaj tylko publiczne, więc prywatne i chronione właściwości obiektów przechodzą bez zmian. Wewnątrz WordPressa wykrywaniem zajmują się funkcje rdzenia is_serialized() i maybe_unserialize(), a sprawdzoną opcją pozostaje WP-CLI.

#6. Przekierowanie starej domeny regułami 301

Dokumentacja Google o przenoszeniu witryny ze zmianą adresów URL wymaga stałych przekierowań po stronie serwera, “takich jak 301 i 308” (tłumaczenie własne), z każdego starego adresu na jego nowy odpowiednik. Dokumentacja przekierowań wyjaśnia, że przy tych stałych kodach “potok indeksowania traktuje przekierowanie jako sygnał, że jego cel powinien być kanoniczny” (tłumaczenie własne). Kody tymczasowe (302, 303, 307) takiego sygnału nie wysyłają.

#Przekierowanie 301 w Nginx z zachowaniem ścieżki

Ścieżkę i parametry zapytania zachowuje $request_uri. Przewodnik Google o przenoszeniu witryn odradza kierowanie wielu starych adresów na jedną niezwiązaną stronę, na przykład nową stronę główną. Poniższa reguła daje mapowanie strona do strony:

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

    # tutaj ssl_certificate i ssl_certificate_key dla starej domeny

    # Stałe przekierowanie z zachowaniem ścieżki i parametrów zapytania
    return 301 https://new-domain.com$request_uri;
}

Stara domena nadal potrzebuje ważnego certyfikatu: żądanie HTTPS do niej kończy się błędem już przy uzgadnianiu TLS, zanim Nginx zdąży wysłać przekierowanie.

#Przekierowanie 301 w .htaccess Apache na nową domenę

Dodaj te reguły na początku pliku .htaccess na starej domenie:

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

Dokumentacja mod_rewrite Apache podaje, że “domyślnie ciąg zapytania jest przekazywany bez zmian” (tłumaczenie własne), więc ?page=2 przetrwa przekierowanie.

#Przekierowanie na brzegu przez Cloudflare Worker

Jeśli ruch do starej domeny idzie przez proxy Cloudflare, przekierowanie może obsłużyć Worker, bez odpytywania serwera źródłowego. Kod używa składni modułów z przykładu przekierowania w dokumentacji Cloudflare:

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. Lista kontrolna migracji SEO i konfiguracja Google Search Console

#Jak użyć narzędzia zmiany adresu w Search Console

Strona pomocy narzędzia zmiany adresu Google stawia takie warunki:

1. Własność: “Musisz być właścicielem zarówno starej, jak i nowej usługi w Search Console” (tłumaczenie własne).
2. Tylko poziom domeny: narzędzia “można używać tylko w usługach na poziomie domeny” i “nie przenosi ono żadnych subdomen poniżej wskazanej domeny (w tym www)” (tłumaczenie własne). Wersje z www i bez www, które są albo były w użyciu, zgłoś osobnymi wnioskami.
3. Najpierw przekierowanie: ustaw przekierowanie 301 ze starej strony głównej na nową i z pozostałych stron. Narzędzie sprawdza, czy jesteś właścicielem obu witryn i czy kilka stron zwraca przekierowania 301.
4. Uruchomienie: otwórz starą usługę, przejdź do ustawień, wybierz zmianę adresu i wskaż nową usługę.
5. Mapy witryn: prześlij nową mapę strony XML. Przewodnik Google o przenoszeniu witryn podaje, że ostrzeżenia o przekierowujących adresach w starej mapie są normalne, dopóki zgłoszone są obie.

Narzędzie nie jest potrzebne przy przejściu z HTTP na HTTPS, przy zmianie między www a wersją bez www w tej samej domenie ani przy zmianach ścieżek w obrębie jednej domeny.

#Co jeszcze zaktualizować w nowej domenie

Przewodnik o przenoszeniu witryn wymienia zmiany na stronie, które idą w parze z przekierowaniami:

• Zaktualizuj linki wewnętrzne tak, by prowadziły bezpośrednio do nowych adresów, a nie przez przekierowanie.
• Daj każdemu nowemu adresowi tag canonical wskazujący na samego siebie.
• Jeśli używasz hreflang, “zaktualizuj adnotacje tak, by korzystały z nowych adresów URL” (tłumaczenie własne).
• Sprawdź, czy robots.txt w nowej domenie nie zawiera wciąż przeniesionego ze stagingu Disallow: /.

#8. Jak długo utrzymywać przekierowania po zmianie domeny WordPress

Google podaje dwie wartości. Strona pomocy narzędzia zmiany adresu mówi, że przekazywanie sygnałów trwa “przez 180 dni od rozpoczęcia migracji w Search Console” (tłumaczenie własne), i prosi o utrzymanie przekierowań co najmniej przez 180 dni, “dłużej, jeśli nadal widzisz na nie ruch z wyszukiwarki Google” (tłumaczenie własne). Przewodnik o przenoszeniu witryn idzie dalej: przekierowania należy utrzymywać jak najdłużej, zwykle co najmniej rok. Częścią tego jest przedłużanie rejestracji starej domeny, bo przekierowania przestają działać w dniu jej wygaśnięcia.

Co do czasu, ten sam przewodnik podaje, że w przypadku średniej witryny “może to potrwać kilka tygodni lub dłużej” (tłumaczenie własne), zanim Google stopniowo zacznie pokazywać nowe adresy, a większe witryny potrzebują więcej czasu. Wahania pozycji w tym okresie są normalne, więc przeprowadzkę ocenia się na podstawie danych z Search Console w skali tygodni, nie dni.

#9. Dlaczego WordPress nadal przekierowuje na starą domenę po migracji

Jeśli po podmianie strona wciąż odsyła na stary adres, sprawdź po kolei te miejsca:

• wp-config.php: zapomniana stała WP_HOME albo WP_SITEURL ze starą wartością nadpisuje bazę.
• wp_options: uruchom wp option get home i wp option get siteurl albo odczytaj oba wiersze w phpMyAdmin.
• .htaccess i konfiguracja serwera: część wtyczek bezpieczeństwa i przekierowań zapisuje tam reguły przekierowań, a stary blok server może nadal istnieć.
• Cache: cache strony, cache obiektów (wp cache flush), CDN i pamięć przeglądarki z wcześniejszym przekierowaniem 301 mogą serwować stary cel.

#10. Lista kontrolna zmiany domeny WordPress

Ta lista przydaje się przy każdej migracji WordPressa na nową domenę:

• Zrób kopię bazy i całego systemu plików, razem z wp-content/uploads.
• Skonfiguruj nowy hosting i zainstaluj certyfikaty SSL dla nowej domeny, a na starej utrzymaj ważny certyfikat.
• Zaimportuj bazę i zaktualizuj dane dostępowe w wp-config.php.
• Uruchom wp search-replace z --dry-run i --skip-columns=guid i przejrzyj raport.
• Wykonaj podmianę dla wariantów HTTPS i HTTP.
• Usuń niepotrzebne już tymczasowe linie WP_HOME, WP_SITEURL lub RELOCATE.
• Odśwież reguły przepisywania i cache, potem sprawdź home i siteurl.
• Ustaw przekierowania 301 strona do strony na starej domenie.
• Zaktualizuj tagi canonical, adnotacje hreflang i linki wewnętrzne.
• Zgłoś zmianę adresu w Search Console i prześlij nową mapę strony.
• Utrzymuj przekierowania i rejestrację starej domeny przez co najmniej rok.

Potrzebujesz pomocy przy migracji bazy WordPress albo konfiguracji przekierowań na poziomie serwera? Nasz zespół programistów WordPress przeprowadzi audyt bazy, wykona migrację i skonfiguruje Search Console. Skontaktuj się z nami, żeby omówić projekt.