Migracja strony WordPress na inny hosting krok po kroku

Przenoszenie strony WordPress na nowy serwer nie musi być stresujące, jeśli potraktujesz je jak projekt z jasno opisanymi etapami, listą kontrolną i planem awaryjnym. Dobrze zaplanowana migracja pozwoli uniknąć przestojów, utraty danych i spadków w wynikach wyszukiwania. W tym poradniku znajdziesz praktyczną ścieżkę, która obejmuje przygotowania, wykonanie i testy, a także wskazówki dotyczące optymalizacji wydajności oraz bezpieczeństwa po przenosinach. Jeśli zarządzasz sklepem WooCommerce, serwisem o dużym ruchu lub witryną multimedialną, zwróć szczególną uwagę na etapy minimalizujące ryzyko utraty zamówień i przerw w działaniu.

Plan i przygotowanie do migracji

Dobre przygotowanie oszczędza nerwy i czas. Zanim cokolwiek skopiujesz, określ cel, wymagania i zakres. Zbuduj listę kontrolną, zrób punkt przywracania i przygotuj narzędzia. W wielu przypadkach największe problemy wynikają nie z techniki, lecz z pośpiechu i braku planu.

• Określ okno serwisowe: kiedy ruch jest najmniejszy (np. noc z niedzieli na poniedziałek)? Dla e‑commerce pamiętaj o sezonowości i promocjach.
• Sprawdź parametry nowego serwera: wersja PHP, MariaDB/MySQL, pamięć, limity uploadu, biblioteka obrazów (GD/Imagick), moduły serwera (Apache/Nginx), HTTP/2/3, opcje opcache i dysk NVMe.
• Ustal strategię przeniesienia: ręczna (SFTP + phpMyAdmin/WP‑CLI), automatyczna (narzędzia do migracji), hybrydowa (backup + ręczne poprawki).
• Porównaj środowiska: nazwy katalogów, prefiksy tabel, dostępność SSH, reguły .htaccess vs. konfiguracja Nginx, wersje bibliotek, reguły bezpieczeństwa (mod_security, open_basedir).
• Zmniejsz TTL rekordów DNS do 300 s co najmniej 24 h przed przełączeniem, aby skrócić propagację po zmianie serwera docelowego.
• Ustal plan na sklepy: włącz tryb konserwacji albo „zamrożenie” tworzenia nowych treści (np. WooCommerce: chwilowe wstrzymanie zamówień lub skrócone okno migracji, zgranie kolejki Action Scheduler).
• Zweryfikuj wymagania compliance (RODO): gdzie fizycznie będzie przetwarzana baza danych, logi, kopie; czy nowy dostawca spełnia wymogi umowne.

Pamiętaj, że pierwszym krokiem powinno być zabezpieczenie danych. Zrób co najmniej jedną kopia w innym miejscu niż oba hostingi (np. dysk lokalny lub chmura). Zadbaj także o dokumentację: dostęp do paneli, SFTP/SSH, dane do bazy, klucze i solty, wersje motywów oraz używane wtyczki.

Wykonanie pełnej kopii zapasowej

Niezależnie od metody przeniesienia, najpierw stwórz pełny backup. To nie jest opcja – to zabezpieczenie przed niespodziankami. Idealnie wykonaj dwie kopie: automatyczną (np. wtyczką) oraz manualną (ręczny eksport plików i bazy). Powyższe podejście pozwala zredukować ryzyko błędów specyficznych dla danego narzędzia.

• Kopia plików: cały katalog WordPressa (wp-content, wp-includes, wp-admin), pliki konfiguracyjne (wp-config.php, .htaccess lub odpowiedniki dla Nginx), dodatkowe katalogi poza standardową strukturą.
• Kopia bazy danych: wszystkie tabele z prefiksem (domyślnie wp_), ale także ewentualne tabele niestandardowe tworzone przez wtyczki (np. logi, rankingi, formularze).
• Archiwizacja zewnętrzna: zaszyfruj archiwum i przechowuj je w bezpiecznej lokalizacji (chmura, magazyn obiektowy, dysk offline). Nie zostawiaj dumpów SQL w katalogu publicznym – to klasyczny błąd.

Uwaga: jeśli korzystasz z CDN lub zewnętrznych magazynów mediów, upewnij się, że posiadasz ich niezależną kopię lub pewność, że po migracji będą wskazywały na właściwy zasób. W przypadku multimediów hostowanych w usługach typu S3/Cloud Storage – zarchiwizuj definicje konfiguracji i polityki IAM.

Eksport bazy danych i plików

Eksport to punkt, w którym najczęściej pojawiają się subtelne problemy: kodowanie znaków, wielkość plików, serializacja danych, różnice w silniku tabel. Zadbaj o poprawność eksportu i pamiętaj, że baza WordPressa zawiera dane wrażliwe (użytkownicy, hasła zahashowane, sesje, tokeny).

• Eksport bazy:
  • phpMyAdmin: zaznacz wszystkie tabele, wybierz „Szybki” lub „Niestandardowy”, ustaw format SQL, kodowanie UTF‑8, włącz opcję dodawania instrukcji DROP/CREATE dla odtwarzania struktury.
  • WP‑CLI: wp db export dump.sql – szybkie i niezawodne, dobre dla dużych baz i automatyzacji.
  • MySQL/MariaDB CLI: mysqldump -u user -p –single-transaction –routines –triggers dbname > dump.sql – bezpieczniej dla dużych instancji.
• Eksport plików:
  • SFTP/SSH: pobierz cały katalog strony; sprawdź uprawnienia plików i katalogów oraz ukryte pliki (.htaccess, .user.ini).
  • Archiwizacja tar/zip: na serwerze źródłowym utwórz archiwum, pobierz jednym plikiem – oszczędza czas i minimalizuje ryzyko przerwania transferu.
• Serializacja i adresy URL:
  • WordPress często przechowuje dane w polach serializowanych (np. ustawienia motywów). Sposób podmiany domeny musi ten format respektować.
  • Bezpieczna podmiana: WP‑CLI search-replace lub zaufana wtyczka migracyjna, która rozumie serializację.

Dodatkowe dane: jeżeli masz zadania CRON (systemowe), kolejki (np. Action Scheduler), potoki CI/CD, integracje API (ERP/marketing automation), spisz klucze, webhokki, harmonogramy. Ustal, które elementy mają być zmigrowane 1:1, a które skonfigurowane od nowa na nowym środowisku.

Tworzenie środowiska na nowym hostingu

Docelowe środowisko musi być zgodne z wymaganiami WordPressa i Twojej aplikacji. Często jest to dobry moment na aktualizację wersji PHP, przejście na nowszy serwer WWW czy włączenie obsługi HTTP/2/3. Jednocześnie nie warto zmieniać zbyt wiele naraz – łatwiej diagnozować problemy, gdy zmienna jest tylko jedna.

• Załóż nową bazę danych, utwórz użytkownika z silnym hasłem i pełnymi uprawnieniami do tej bazy. Zanotuj host, nazwę, login i hasło – będą potrzebne do wp-config.php.
• Wgraj pliki WordPressa: najlepiej spakowane archiwum rozpakować po stronie serwera (unzip/tar), aby uniknąć bardzo długiego transferu małych plików.
• Skonfiguruj PHP: memory_limit (np. 256–512 MB), max_execution_time (np. 120–300 s na czas importu), upload_max_filesize i post_max_size (większe niż rozmiar importowanego pliku).
• Włącz logi błędów i przygotuj dostęp do logów serwera (error_log PHP, access/error log WWW). Diagnostyka to połowa sukcesu.
• Przygotuj certyfikat SSL w panelu hostingu (Let’s Encrypt) lub plan jego instalacji. Nawet przed przełączeniem domeny możesz użyć tymczasowej domeny technicznej do weryfikacji HTTPS.
• Jeśli nowy hosting używa innego serwera HTTP (Nginx zamiast Apache), dopasuj reguły przepisywania – permalinków czy ochrony plików w wp-content/uploads. Plik .htaccess nie zadziała pod Nginx bez translacji do server block.

Ważne: dla środowisk staging włącz blokadę indeksowania (noindex) oraz ewentualnie podstawowe uwierzytelnianie HTTP. Nie chcesz, aby wyszukiwarki indeksowały kopię serwisu pod domeną techniczną.

Import danych i konfiguracja WordPressa

Teraz odtworzysz zawartość na nowym serwerze i wskazesz WordPressowi właściwe połączenie z bazą. Ten etap wymaga dokładności – pojedyncza literówka w nazwie hosta lub użytkownika może skończyć się błędem „Error establishing a database connection”.

• Import bazy:
  • phpMyAdmin: importuj dump SQL, w razie dużych plików skorzystaj z trybu „Niestandardowy” i rozsądnych limitów czasu lub z narzędzia linii komend.
  • WP‑CLI: wp db import dump.sql – szybki i odporny na duże pliki; przed importem utwórz pustą bazę.
• Konfiguracja wp-config.php:
  • Ustaw DB_NAME, DB_USER, DB_PASSWORD, DB_HOST zgodnie z nowym środowiskiem.
  • Zaktualizuj klucze i sole uwierzytelniania (AUTH_KEY itd.) – generator w serwisie WordPress.org. To podnosi bezpieczeństwo.
  • W razie zmiany prefiksu tabel dopasuj $table_prefix, lecz zwykle pozostaje bez zmian.
  • Na czas debugowania możesz dodać: define(’WP_DEBUG’, true); define(’WP_DEBUG_LOG’, true); po migracji wyłącz.
• Podmiana adresów:
  • Jeżeli przenosisz także domenę lub protokół (HTTP→HTTPS), wykonaj bezpieczną podmianę adresów: WP‑CLI wp search-replace 'stara-domena’ 'nowa-domena’ –skip-columns=guid.
  • Sprawdź tablice: wp_options (siteurl, home), wp_posts (guid, post_content), meta i ustawienia motywów.
• Uprawnienia plików:
  • Pliki: 644, katalogi: 755 (zależnie od środowiska). Unikaj 777 – ryzyko bezpieczeństwa.
  • W katalogu uploads/ sprawdź właściciela procesów (www-data lub inny użytkownik) – brak zgodności powoduje błędy zapisu.

Po imporcie zaloguj się do panelu wp-admin, wejdź w Ustawienia → Bezpośrednie odnośniki i zapisz ustawienia bez zmian, aby WordPress odświeżył reguły przepisywania. Jeśli korzystasz z reguł Nginx, upewnij się, że są poprawnie zdefiniowane w konfiguracji serwera.

Testy przed przełączeniem DNS

Najbezpieczniej jest gruntownie przetestować stronę na nowym serwerze, zanim naprowadzisz ruch produkcyjny. Możesz użyć domeny tymczasowej, wpisu w pliku hosts lub zapory IP do ograniczenia dostępu. Priorytetem jest kompletność treści, działanie formularzy, płatności i integracji zewnętrznych.

• Test przez plik hosts:
  • Na własnym komputerze dopisz mapowanie domeny na nowy adres IP. Dzięki temu zobaczysz serwis tak, jakby już działał po migracji, ale tylko na Twojej maszynie.
• Checklista funkcjonalna:
  • Strona główna, podstrony, wpisy, paginacja, wyszukiwarka, formularze (kontakt, newsletter), wysyłka e‑mail (SMTP – test transakcyjny), koszyk, checkout, bramki płatności i webhokki, logowanie/rejestracja użytkowników.
  • Wtyczki cache’ujące i optymalizujące obrazy – wyczyść i odbuduj pamięć podręczną, aby upewnić się, że zasoby ładują się poprawnie.
  • Obrazy i multimedia: linki względne/bezpośrednie, miniatury, generacja nowych rozmiarów.
  • Mapa strony, robots.txt, znaczniki kanoniczne, przekierowania 301 (http→https, www↔non‑www) – porównaj ze starym hostem.
  • Sprawdź prędkość ładowania (Lighthouse/Pagespeed), TTFB, nagłówki cache i kompresji.
• Różnice środowisk:
  • Jeśli pojawiają się błędy 500/502/504, zajrzyj do logów. Często problemem jest brak rozszerzenia PHP, zbyt niski limit pamięci, niekompatybilna wersja PHP albo blokady serwera.

Gdy wszystko działa, możesz przygotować przełączenie rekordów DNS. Jeżeli wcześniej obniżyłeś TTL, propagacja będzie szybka. Dla serwisów o krytycznej dostępności rozważ dwuetapowe przełączenie – najpierw tylko część ruchu przez zmianę rekordu w środowisku testowym (np. load balancer), a następnie pełne przełączenie.

Przełączenie ruchu i optymalizacja po migracji

Przełączenie to moment „na żywo”. W praktyce oznacza zmianę adresów IP w panelu rejestratora domeny lub hostingu, a czasem modyfikację rekordów CNAME/ALIAS, jeśli korzystasz z CDN lub usług pośredniczących. Po przełączeniu monitoruj działanie serwisu przez co najmniej kilkanaście godzin.

• Zmiana rekordów:
  • A/AAAA dla domeny i subdomen, CNAME dla www, MX dla poczty (jeśli zmieniasz), TXT (SPF, DKIM, DMARC), SRV – sprawdź spójność konfiguracji.
• Po przełączeniu:
  • Wyczyść wszelkie warstwy cache: wtyczka, serwer (Nginx FastCGI/Reverse proxy), CDN, przeglądarka. To zminimalizuje „duchy” starych zasobów.
  • Włącz i przetestuj stale włączone HTTPS – przekierowanie 301 z http na https, poprawne łańcuchy certyfikatów, HSTS (po upewnieniu się, że wszystko działa).
  • Jeśli zmieniłeś adresy URL, zaktualizuj Google Search Console i mapy strony. Prześlij nowy sitemap.xml i monitoruj raporty indeksowania.
• Optymalizacja wydajności:
  • Włącz i skonfiguruj mechanizmy buforowania: page cache, obiektowy (Redis/Memcached), OPcache. Prawidłowy cache znacząco obniża obciążenie CPU.
  • Skonfiguruj kompresję (gzip/brotli), HTTP/2 push (lub lepiej preloading), reguły cache dla statycznych zasobów, lazy loading, optymalizację obrazów (WebP/AVIF).
  • Jeśli masz CDN, sprawdź przepływ nagłówków cache-control i wykluczenia dla ścieżek dynamicznych (np. /wp-admin/).
• Automatyczne zadania:
  • Rozważ wyłączenie pseudo‑CRON WordPressa i zastąpienie go systemowym CRON: define(’DISABLE_WP_CRON’, true) i wpis w crontab co 5 min uruchamiający wp-cron.php.
  • Zbadaj kolejkowanie (Action Scheduler) – czy zadania przetwarzają się poprawnie po migracji.

Jeżeli korzystasz z usług mailingowych, wykonaj test transakcyjny (reset hasła, potwierdzenia zamówień). Upewnij się, że rekordy SPF/DKIM/DMARC odpowiadają nowej infrastrukturze, w przeciwnym razie wiadomości mogą trafiać do SPAM‑u.

Najczęstsze problemy i ich rozwiązania

Migracje rzadko przechodzą zupełnie bez zgrzytów. Poniżej zestawienie problemów, które pojawiają się najczęściej, oraz praktyczne sposoby ich eliminacji.

• Biały ekran śmierci / 500 Internal Server Error:
  • Włącz WP_DEBUG i sprawdź logi; podnieś memory_limit; wyłączaj problematyczne rozszerzenia PHP; tymczasowo dezaktywuj motyw‑dziecko lub pluginy, aby zidentyfikować konflikt.
• Error establishing a database connection:
  • Zweryfikuj poświadczenia w wp-config.php, host bazy (czasem to 127.0.0.1, a nie localhost), uprawnienia użytkownika i czy baza istnieje.
• Nieprawidłowe linki / mieszana zawartość (Mixed Content):
  • Wykonaj search-replace adresów http→https i starej→nowej domeny; upewnij się, że style i skrypty ładują się po HTTPS, a CDN przepuszcza nagłówki.
• Brak miniatur / błędy zapisu w uploads:
  • Sprawdź właściciela i uprawnienia katalogów; zweryfikuj ścieżki uploadu w Ustawienia → Media (czy nie wskazują starej ścieżki absolutnej).
• Przekierowania pętli (redirect loop):
  • Zweryfikuj reguły .htaccess lub konfigurację Nginx; sprawdź ustawienia siteurl/home, wymuszanie HTTPS i www/non‑www – rozbieżności powodują pętle.
• Nieaktywne wtyczki premium po migracji:
  • Niektóre licencje są przypisane do domeny lub IP. Zaloguj do kont producenta, dezaktywuj starą instalację, aktywuj nową. Zweryfikuj hooki aktualizacji.
• WooCommerce – utracone zamówienia:
  • Na czas eksportu włącz tryb konserwacji lub krótkie okno freeze, a po przełączeniu zsynchronizuj kolejki i webhokki. Rozważ szybki diff bazy (tylko tabele zamówień) i dogranie brakujących rekordów.
• Problemy z obrazami po zmianie domeny:
  • Niektóre kreatory stron zapisują absolutne ścieżki. Użyj WP‑CLI search-replace obejmującego metadane, a następnie zregeneruj miniatury (np. Regenerate Thumbnails).
• Spadki SEO:
  • Zweryfikuj przekierowania 301, kanoniczne, mapę strony; w GSC prześlij nowy sitemap, korzystaj z raportów Pokrycia; monitoruj błędy 404 i szybko dodawaj reguły 301.

Gdyby mimo wszystko było źle, plan awaryjny to szybki rollback. Posłuż się wykonaną wcześniej kopią: przywróć bazę i pliki na starym serwerze, cofnij zmianę DNS i spokojnie diagnozuj przyczyny, nie tracąc dostępności usługi.

Metody automatyczne i hybrydowe

Dla mniejszych stron lub gdy chcesz skrócić czas, użyj narzędzi do przenoszenia: Duplicator, Migrate Guru, All‑in‑One WP Migration, UpdraftPlus. Ich przewagą jest łatwość i obsługa serializacji, wadą – limity rozmiaru oraz zależność od konfiguracji PHP. Zawsze testuj wynik i miej ręczną alternatywę. Metoda hybrydowa (wtyczka + ręczne poprawki) sprawdza się przy customowych wdrożeniach.

• Duplicator: pakiet archiwum + instalator; szybkie odtworzenie na docelowym serwerze; uważaj na limity rozmiaru i czas wykonywania.
• Migrate Guru: działa przez zewnętrzny serwer pośredniczący; dobry do dużych witryn; zweryfikuj politykę prywatności i transferu danych.
• All‑in‑One WP Migration: prosta obsługa, ale duże witryny mogą wymagać wersji premium lub obejścia limitów.
• UpdraftPlus: backup do chmury i przywracanie; pamiętaj o pełnym logu działań i testach odtworzeniowych.

Rada: nawet przy automatyzacji zrób równoległe ręczne archiwum. Podstawą bezpiecznej migracji jest możliwość powrotu do stanu sprzed zmian.

Checklisty, dobre praktyki i utrzymanie po migracji

Po udanym przeniesieniu warto wykonać kilka dodatkowych kroków, które wpływają na długofalową stabilność i wydajność. Przemyśl przyszłe aktualizacje, monitorowanie i ochronę przed awariami.

• Bezpieczeństwo:
  • Zmień hasła do paneli, SFTP/SSH i bazy. Usuń pliki instalacyjne, dump.sql i archiwa z katalogów publicznych. Włącz WAF lub reguły aplikacyjne.
  • Skonfiguruj kopie przyrostowe, rotacje i testy odtworzeń. Kopia, której nie umiesz przywrócić, nie istnieje.
• Monitorowanie:
  • Healthchecks, uptime monitoring, alerty e‑mail/SMS, metryki serwera i aplikacji (CPU, RAM, I/O, zapytania DB, błędy 5xx). Zbieraj logi w jednym miejscu.
• Wydajność i UX:
  • Optymalizacja obrazów, minifikacja i łączenie zasobów, preloading krytycznych czcionek, lazy load wideo. Analizuj realne dane w CrUX/Field Data.
• Procesy:
  • Wprowadź rutynę aktualizacji rdzenia, motywów i pluginów; testuj na stagingu przed produkcją. Dokumentuj zmiany – przyspieszysz diagnozę w razie regresji.

Jeżeli korzystasz z zewnętrznej poczty (np. Google Workspace, Microsoft 365), pamiętaj o poprawnym przeniesieniu rekordów MX i testach dostarczalności. Rozważ wdrożenie dedykowanego SMTP dla WordPressa, aby unikać problemów z wysyłką transakcyjną.

Podsumowanie: kluczem do udanej migracji jest plan, rzetelna kopia zapasowa, kontrola nad każdym etapem i cierpliwe testy. Gdy przełączysz ruch, monitoruj obciążenie i logi – pierwsze godziny po przenosinach to najcenniejsze dane diagnostyczne. Dobrze wykonana migracja nie tylko przenosi serwis, ale bywa także okazją do uporządkowania konfiguracji, podniesienia poziomu bezpieczeństwo i optymalizacji działania. Po zakończeniu upewnij się, że certyfikaty SSL odnawiają się automatycznie, kopie są wykonywane regularnie, a krytyczne integracje działają bez zakłóceń. Dzięki temu kolejna migracja – jeśli kiedyś będzie potrzebna – stanie się już tylko rutyną.