Przenoszenie strony WordPress ze środowiska deweloperskiego (np. dev.klient.pl) na produkcję (klient.pl) to rytuał, który każdy programista wykonuje setki razy. A jednak, w 2026 roku, pozostaje to najczęstszym źródłem słynnego “Białego Ekranu Śmierci” (WSOD).

Dlaczego? Ponieważ wielu deweloperów wciąż traktuje bazę danych WordPressa jak prosty arkusz Excela, w którym można po prostu użyć funkcji “Znajdź i Zamień”.

To fundamentalny błąd.

W tym obszernym, inżynierskim poradniku (ponad 1500 słów), przeanalizujemy architekturę bazy danych WordPressa, wyjaśnimy pojęcie Serializacji Danych i dostarczymy niezawodny protokół migracji nawet największych serwisów.

Część 1: Ukryta Pułapka (Serializacja)

Aby zrozumieć, dlaczego migracje się nie udają, musisz zrozumieć, jak PHP przechowuje złożone struktury danych.

Co to jest Serializacja?

Wyobraź sobie, że masz tablicę opcji motywu:

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

Aby zapisać tę tablicę w jednej komórce bazy danych (np. w tabeli wp_options), PHP “pakuje” ją w specyficznie sformatowany ciąg znaków. Ten proces nazywa się Serializacją.

Wynik wygląda tak: a:2:{s:11:"theme_color";s:4:"blue";s:8:"logo_url";s:26:"http://dev.site.com/logo.png";}

Problem “Długości”

Przyjrzyj się uważnie temu fragmentowi: s:26:"http://dev.site.com/logo.png".

s: String (ciąg znaków).
26: Liczba znaków w tym ciągu.

Jeśli wykonasz standardowe zapytanie SQL:

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

Zmienisz adres URL na http://site.com/logo.png, który ma 22 znaki. ALE licznik s:26 pozostanie bez zmian w bazie danych.

Gdy WordPress próbuje załadować tę opcję, PHP mówi:

“Zaraz. Kazałeś mi oczekiwać 26 znaków, ale znalazłem tylko 22. Te dane są uszkodzone.”

I PHP wyrzuca CAŁĄ tablicę do kosza. Nagle Twój motyw resetuje się do ustawień domyślnych, widżety znikają, a płatne wtyczki ponownie proszą o klucze licencyjne.

Część 2: Rozwiązanie - Narzędzia świadome serializacji

Z powodu tego mechanizmu NIE MOŻESZ używać zwykłych edytorów tekstu ani prostego SQL do migracji bazy WordPress. Potrzebujesz narzędzi, które:

Rozpakują (Unserialize) dane.
Podmienią ciąg znaków.
Przeliczą liczbę znaków.
Spakują (Serialize) dane z powrotem.

Metoda 1: WP-CLI (Złoty Standard)

W 2026 roku każdy szanujący się dostawca hostingu (Kinsta, WP Engine, Cyberfolks, LH.pl) oferuje dostęp do SSH. To najszybsza metoda. Działa bezpośrednio na serwerze, skanując tabele z prędkością tysięcy wierszy na sekundę.

Komenda:

wp search-replace 'https://stara.pl' 'https://nowa.pl' --all-tables --precise

--all-tables: Zapewnia skanowanie wszystkich tabel, także tych z wtyczek.
--precise: Wymusza użycie silnika PHP dla lepszej obsługi serializacji.
--dry-run: Pokazuje raport “co by się stało”, bez wprowadzania zmian. Zawsze uruchamiaj to najpierw!

Metoda 2: Wtyczka “Better Search Replace” (Dla początkujących)

Jeśli nie masz dostępu do SSH (dlaczego płacisz za taki hosting?), użyj wtyczki Better Search Replace. To graficzna nakładka na tę samą logikę.

Zainstaluj wtyczkę.
Zaznacz wszystkie tabele.
Odznacz “Case-Insensitive” (adresy URL są zazwyczaj pisane małymi literami).
Uruchom “Dry Run”.
Jeśli znajdzie dopasowania, odznacz Dry Run i wykonaj.

Metoda 3: Skrypt Interconnect/it (Narzędzie Ratunkowe)

Jeśli nie możesz dostać się do panelu Admina (bo strona przekierowuje na starą domenę) i nie masz SSH.

Pobierz skrypt Search Replace DB (od interconnect/it).
Wgraj folder (np. _replace) na serwer przez FTP.
Otwórz twoja-strona.pl/_replace w przeglądarce.
Skrypt połączy się z bazą i wykona bezpieczną podmianę.
KRYTYCZNE: Usuń folder natychmiast po użyciu. Pozostawienie go to ogromna dziura bezpieczeństwa.

Część 3: Kompletny Protokół Migracji

Nie działaj “na czuja”. Postępuj zgodnie z tą listą kontrolną, aby zapewnić 100% uptime.

Krok 1: Kontrola Przedlotowa

Backup: Wyeksportuj bazę danych (mysqldump).
Środowisko: Upewnij się, że wersje PHP są zgodne na obu serwerach.
Media: Upewnij się, że folder wp-content/uploads został przeniesiony w całości (użyj rsync).

Krok 2: Przełączenie

Zaimportuj bazę na nowy serwer.
Edytuj wp-config.php, aby wskazywał na nową bazę.
Dodaj tymczasowo define( 'WP_HOME', 'https://nowa-strona.pl' ); aby wymusić adres.

Krok 3: Podmiana (Replacement)

Uruchom komendę WP-CLI lub skrypt Search-Replace. Wskazówka: Najpierw podmień wersje http:// na https://, lub po prostu rdzeń domeny stara.pl -> nowa.pl, jeśli jesteś pewien, że nie zepsuje to np. e-maili w bazie.

Krok 4: Sprzątanie

Permalinki: Wejdź w Ustawienia -> Bezpośrednie odnośniki i kliknij “Zapisz zmiany”. To regeneruje plik .htaccess i naprawia błędy 404.
Cache: Wyczyść Redis (Object Cache) i cache strony.
Robots.txt: Upewnij się, że nie skopiowałeś Disallow: / ze środowiska dev! To klasyczna katastrofa SEO.

Część 4: Rozwiązywanie Problemów

“Zrobiłem wszystko, ale strona wciąż przekierowuje na starą!”

Sprawdź wp-config.php. Czy masz zahardcodowane stałe WP_SITEURL?
Sprawdź tabelę wp_options. Spójrz ręcznie na wiersze siteurl i home.
Sprawdź .htaccess. Niektóre wtyczki bezpieczeństwa wpisują tam przekierowania.

Podsumowanie

Migracja bazy danych to nie “edycja tekstu”. To chirurgiczna operacja na danych. Szanuj Serializację. Używaj WP-CLI. I nigdy, przenigdy nie dotykaj pliku SQL notatnikiem.

Kompletny Przewodnik Migracji Bazy Danych WordPress (Edycja 2026)