Problemy z migracją WordPress – jak uniknąć pułapek w 2026

Każda migracja WordPress wpada w jeden z trzech wzorców. Zrozumienie, w którym jesteś, to połowa sukcesu – bo każdy ma inne ryzyka.

Scenariusz 1: zmiana hostingu, ten sam adres domeny. Najprostszy przypadek. Domena nie zmienia się, więc serializowane dane w bazie pozostają nietknięte. Ryzyka to głównie różnice w wersji PHP, nieobecne rozszerzenia (np. imagick, sodium), inny silnik bazy (MariaDB 10.6 vs 10.11) i czasem konfiguracja .htaccess vs nginx. Jeśli przenosisz się np. z OVH na CyberFolks, migracja gratis robi to za ciebie – ale i tak zweryfikuj wersję PHP po stronie nowego hostingu (zalecam PHP 8.2 lub 8.3 dla WordPressa 6.x).

Scenariusz 2: zmiana domeny. Tu zaczynają się schody. Każde wystąpienie starego URL w bazie musi zostać zamienione, ale nie przez zwykłe SQL update – bo połamiesz serializowane tablice w wp_options, postmeta, widgetach i theme settings. Zawsze używaj WP-CLI `wp search-replace` albo skryptu interconnectit.com. Po zamianie obowiązkowo 301 redirect ze starej domeny na nową, inaczej tracisz pozycje w Google.

Scenariusz 3: dev/staging → produkcja. Najbardziej podstępny scenariusz, bo łatwo zapomnieć o robots.txt z `Disallow: /` lub o wyłączonej indeksacji w Ustawieniach → Czytanie. Klasyk: deploy piątek wieczorem, w niedzielę spadek pozycji w GSC, w poniedziałek panika. Sprawdź też, czy nie zostały testowe zamówienia WooCommerce, hardkodowane URL-e w plikach motywu i czy masz włączone caching pluginy (WP Rocket lubi się przenieść z włączonymi regułami pasującymi do starego serwera).

Zanim ruszysz cokolwiek, zrób backup plików (FTP/SSH) i bazy (`wp db export backup.sql`). Brzmi banalnie, ale 80% katastrof migracyjnych kończy się dramatycznie tylko dlatego, że nie było do czego wrócić. Jeśli twoja strona padła całkowicie po aktualizacji albo po przenosinach, zerknij na WordPress padł po aktualizacji – tam są szybkie patenty na rollback. Na temat samego doboru hostingu dla migracji pomocny będzie też przewodnik problemy z aktualizacją WordPress.

Error 500 (Internal Server Error) to królowa problemów po migracji. Nie ma jednej przyczyny – serwer mówi tylko, że coś poszło nie tak po stronie aplikacji. Trzeba diagnozować po kolei.

Najczęstsze winowajcy:

1. Zła wersja PHP. Jeśli stara strona działała na PHP 7.4, a nowy hosting startuje z PHP 8.2, niektóre wtyczki (zwłaszcza stare WooCommerce extensions) padają na deprecated functions. Sprawdź `error_log` w katalogu strony – tam zobaczysz fatal error z nazwą wtyczki. Tymczasowo przełącz PHP w panelu hostingu na 8.0, potem aktualizuj wtyczki.
2. Uprawnienia plików. Po rsync/FTP czasami pliki dostają 777 lub 644 zamiast standardu (755 dla katalogów, 644 dla plików). Komenda ratunkowa: `find . -type d -exec chmod 755 {} \;` i `find . -type f -exec chmod 644 {} \;`. Pliki `wp-config.php` zostaw 600 dla bezpieczeństwa.
3. Złe ścieżki w pluginach. Niektóre wtyczki cache'ują absolute paths w wp_options. Po migracji `/home/oldserver/htdocs/...` nie istnieje. Wyłącz wszystkie pluginy przez `wp plugin deactivate --all` i włączaj po jednym.
4. .htaccess z poprzedniego serwera. Jeśli stary host miał Apache z mod_rewrite, a nowy nginx, .htaccess jest ignorowany lub kruszy nginx. Wygeneruj nowy: `wp rewrite flush --hard`.
5. Memory limit. Domyślne 64MB nie wystarczy dla WooCommerce. Dodaj do `wp-config.php`: `define('WP_MEMORY_LIMIT', '512M');`.

Jeśli żadna z tych opcji nie pomaga, włącz debug mode w `wp-config.php`:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Logi pojawią się w `wp-content/debug.log` – tam najczęściej leży konkretny komunikat. Więcej w problemy z hostingiem WordPress i biały ekran śmierci WordPress. Jeśli błąd dotyczy konkretnej wtyczki, zobacz konflikty wtyczek WordPress.

Strona ładuje się, ale wygląda jak HTML z 1998 roku – bez stylów, układu, czasem z połową obrazków. To klasyka migracji ze zmianą domeny lub z HTTP na HTTPS.

Diagnoza w 30 sekund. Otwórz DevTools (F12) → zakładka Console. Jeśli widzisz komunikaty typu `Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure script` – masz mixed content. Strona ładuje zasoby z `http://staradomena.pl/wp-content/...` zamiast z nowej, bezpiecznej.

Trzy najczęstsze przyczyny i fixy:

Krok po kroku:

1. Zrób search-replace przez WP-CLI (NIE przez phpMyAdmin SQL!).
2. Wyczyść cache: `wp cache flush` + jeśli masz Redis: `redis-cli FLUSHALL`.
3. Wyłącz i włącz ponownie wtyczkę cache (W3 Total Cache, WP Rocket, LiteSpeed).
4. W przeglądarce: hard refresh (Ctrl+Shift+R).
5. Sprawdź `wp-config.php` – jeśli masz `WP_HOME` i `WP_SITEURL` zdefiniowane, zaktualizuj je tam też.

Jeśli używasz Cloudflare, włącz Always Use HTTPS i SSL Mode na Full (strict) – inaczej będziesz miał pętle redirectów. Problem ze ślamazarnym ładowaniem po migracji? Zerknij w WordPress wolno się ładuje, problemy z cache WordPress oraz problemy z SSL i HTTPS.

Baza danych to najbardziej kruchy element migracji. Wystarczy jedna różnica między serwerami i dostajesz polskie znaki w postaci `Ä…` zamiast `ą`, błędy `Error establishing a database connection`, albo posty bez treści.

Top 5 problemów z bazą po migracji:

1. Collation mismatch. Stary serwer miał `utf8_general_ci`, nowy `utf8mb4_unicode_ci`. Eksport wsadziłeś as-is i emoji oraz emotki z opisów produktów się posypały. Fix: re-export ze świadomym ustawieniem charset – `mysqldump --default-character-set=utf8mb4` – i import na bazę utworzoną z `CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci`.
2. Niepoprawny prefix tabel. Stara strona używała `wp_xyz_` (security przez obscurity), nowa baza ma standardowe `wp_`. Trzeba albo przemianować tabele, albo zmienić `$table_prefix` w `wp-config.php`. WordPress nie odpali, jeśli prefix nie zgadza się z bazą.
3. SQL strict mode. MariaDB 10.6+ często ma włączony `STRICT_TRANS_TABLES`, który odrzuca `0000-00-00` jako datę – a stare WooCommerce posty mają takie wartości. Wyłączysz to w `my.cnf`: `sql_mode=""` lub konkretnie bez STRICT.
4. Za mały `max_allowed_packet`. Import dużej bazy (>500MB) pada na MySQL packet too large. Zwiększ do 256M w `my.cnf` i restartuj MariaDB.
5. Foreign keys i innodb vs myisam. Migracja MyISAM → InnoDB potrafi rzucić błędem przy starym schemacie. Zwykle pomaga `ALTER TABLE wp_posts ENGINE=InnoDB;`.

Komendy ratunkowe (WP-CLI po imporcie):

wp db check --allow-root
wp db repair --allow-root
wp db optimize --allow-root

Jeśli widzisz `Error establishing a database connection` od razu po migracji – sprawdź dane dostępowe w `wp-config.php` (DB_HOST często nie jest `localhost`, tylko np. `db.cyberfolks.pl`), a potem czy user MySQL ma uprawnienia GRANT ALL na bazie. Pełna check-lista: problemy z bazą danych WordPress oraz optymalizacja bazy MySQL.

Wybór narzędzia decyduje o tym, czy migracja zajmie 30 minut czy cały weekend. Każde ma inne ograniczenia – szczególnie w darmowych wersjach.

Tabela porównawcza (stan na 2026):

Moja rekomendacja w 2026:

• Mała strona (do 500 MB): All-in-One WP Migration darmowe – zwiększ limit przez modyfikację `constants.php` lub kup Unlimited Extension za 99 USD jednorazowo.
• Średnia strona (500MB–5GB): Migrate Guru – darmowe, robi cuda w chmurze, działa nawet z taniego sharedu bez SSH.
• Sklep WooCommerce 5GB+: WP-CLI ręcznie (pokażę w następnej sekcji) albo agencja. Duplicator Pro przy 10GB+ potrafi się crashować na timeout PHP.
• Multisite: Duplicator Pro lub WP-CLI – inne narzędzia często źle obsługują network setup.
• BaseLinker / sklep z dużą integracją: WP-CLI + osobny export tabel `wp_baselinker_*`. Więcej w problemy z BaseLinker integracją i migracja sklepu WooCommerce bez utraty zamówień.

Pamiętaj: jeśli przenosisz się na CyberFolks, ich zespół zrobi migrację gratis w ramach pakietu – nawet sklepy WooCommerce. To często szybsze i bezpieczniejsze niż własne narzędzia.

Ręczna migracja przez SSH/WP-CLI to złoty standard dla większych stron. Zajmuje 1–3 godziny i daje pełną kontrolę. Oto kompletny przepis, którego sam używam.

Pre-migration checklist:

• [ ] Backup bazy: `wp db export /tmp/backup-$(date +%F).sql`
• [ ] Backup plików: `tar -czf /tmp/files-backup.tar.gz /home/user/htdocs/domena.pl`
• [ ] Spis aktywnych pluginów: `wp plugin list --status=active --format=csv > plugins.csv`
• [ ] Wersja PHP, MySQL, WordPress (notatka)
• [ ] Lista cron jobów: `crontab -l > cron-backup.txt`
• [ ] DNS TTL obniżony do 300s (24h przed)

Krok 1: Eksport bazy ze starego serwera.

wp db export /tmp/old-db.sql --add-drop-table --default-character-set=utf8mb4

Krok 2: Transfer plików na nowy serwer.

rsync -avz --progress /home/old/htdocs/domena.pl/ user@nowyserwer:/home/new/htdocs/domena.pl/

`rsync` jest szybszy od FTP, kontynuuje przerwane transfery i pokazuje progress. Jeśli SSH nie jest dostępny, użyj plugin Duplicator Pro do spakowania całości w jeden plik.

Krok 3: Utwórz bazę na nowym serwerze.

mysql -u root -p -e "CREATE DATABASE nowabaza CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;"
mysql -u root -p -e "GRANT ALL ON nowabaza.* TO 'newuser'@'localhost' IDENTIFIED BY 'haslo';"

Krok 4: Import bazy.

mysql -u newuser -p nowabaza < /tmp/old-db.sql

Krok 5: Update wp-config.php.

Zmień DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. Dodaj `define('WP_HOME', 'https://nowadomena.pl');` i `define('WP_SITEURL', 'https://nowadomena.pl');`.

Krok 6: Search-replace URLi (jeśli zmiana domeny).

wp search-replace 'http://stara.pl' 'https://nowa.pl' --skip-columns=guid --all-tables
wp search-replace '//stara.pl' '//nowa.pl' --skip-columns=guid --all-tables

Krok 7: Permissions, cache flush, weryfikacja.

chown -R www-data:www-data /home/new/htdocs/domena.pl/
wp cache flush
wp rewrite flush --hard
wp cron event run --due-now

Krok 8: Test. Zedytuj plik `hosts` na komputerze, dodaj `IP_NOWEGO_SERWERA domena.pl` – możesz przetestować nową stronę zanim DNS się przełączy. Sprawdź: stronę główną, 5 random podstron, koszyk WooCommerce, formularze kontaktowe, panel admin.

Zero downtime to święty Graal migracji. Da się to zrobić, ale wymaga planowania na 24–48 godzin przed właściwą operacją.

Faza 1: Przygotowanie (T-48h do T-24h).

Obniż DNS TTL dla rekordów A i AAAA do 300 sekund (5 minut). Domyślnie TTL bywa 3600 lub 14400 – po przełączeniu DNS niektórzy klienci dostawaliby starą wersję strony przez 4 godziny. Z TTL 300s propagacja zajmie maks 5–10 minut.

Faza 2: Klon na staging (T-24h do T-2h).

Skopiuj całą stronę na nowy serwer pod tymczasowym subdomain (`staging.domena.pl` lub przez plik hosts). Przetestuj wszystko:

• [ ] Strona główna ładuje się
• [ ] Logowanie do panelu admin działa
• [ ] WooCommerce: dodanie do koszyka, checkout, płatność (sandbox)
• [ ] Formularze kontaktowe wysyłają maile
• [ ] Galerie, slidery, mapy się ładują
• [ ] Permalinks działają (test 5 random URLi)
• [ ] HTTPS jest aktywny (Let's Encrypt wystawiony)
• [ ] Search Console: nowy adres IP w robots.txt? (zwykle nie trzeba)
• [ ] Backup, cron jobs, indeksacja włączona

Faza 3: Sync ostatniej różnicy (T-30min).

Jeśli sklep ciągle przyjmuje zamówienia, zrób tzw. "delta sync": wyeksportuj tabele `wp_posts`, `wp_postmeta`, `wp_woocommerce_*` ze starego serwera i nadpisz na nowym. Trwa to 5–15 minut. W tym czasie włącz na starej stronie maintenance mode (`wp maintenance-mode activate`).

Faza 4: Przełączenie DNS (T=0).

Zaktualizuj rekord A w panelu DNS na IP nowego serwera. Propagacja: 5–10 minut przy TTL 300. Monitoruj: `dig domena.pl +short` z różnych lokalizacji (możesz użyć dnschecker.org).

Faza 5: Weryfikacja (T+10min do T+24h).

• Wyłącz maintenance mode
• Sprawdź, czy nowe zamówienia wpadają na nowy serwer
• Submit nowy sitemap w GSC
• Stary serwer trzymaj jeszcze 7 dni jako fallback

Pułapka: jeśli używasz Cloudflare z proxy włączonym (orange cloud), DNS TTL nie ma znaczenia – Cloudflare cache'uje IP origin po stronie swoich edge serwerów. Wtedy zmień origin IP w panelu Cloudflare i propagacja jest natychmiastowa.

Zmiana domeny w bazie WordPress to operacja, na której najczęściej ludzie wywalają sobie stronę. Powód: serializowane dane PHP.

Dlaczego SQL find-replace to katastrofa. WordPress przechowuje wiele opcji jako serializowane tablice PHP w polach `option_value`, `meta_value`, `widget_data`. Format wygląda tak: `s:11:"hello world";`. Liczba `11` to długość stringa. Jeśli zmienisz `hello world` na `bye`, SQL UPDATE nie zaktualizuje tej liczby – serializacja się rozjedzie i WordPress przy odczycie dostanie błąd. Efekt: brak widgetów, zresetowane theme options, połamane ACF fields.

Dwa właściwe sposoby.

Sposób 1: WP-CLI (zalecane).

wp search-replace 'http://stara.pl' 'https://nowa.pl' \
  --skip-columns=guid \
  --all-tables \
  --report-changed-only

Flagi które warto znać:
- `--skip-columns=guid` – nie zmieniaj GUID postów (Google używa ich jako identyfikatorów)
- `--all-tables` – zamiast tylko core WP, też custom plugin tables (BaseLinker, WooCommerce subscriptions itp.)
- `--dry-run` – pokaż co by zmieniło, bez wykonywania
- `--report-changed-only` – krótszy output

Sposób 2: skrypt interconnectit.com (Better Search Replace).

Pobierz z `https://interconnectit.com/products/search-and-replace-for-wordpress-databases/`, wgraj do katalogu strony, otwórz w przeglądarce. UI z checkboxami, wskazujesz tabele, dry run i go. Działa jeśli nie masz SSH.

Co zamienić (kolejność ma znaczenie):

1. `http://stara.pl` → `https://nowa.pl` (z protokołem)
2. `//stara.pl` → `//nowa.pl` (protocol-relative)
3. `stara.pl` → `nowa.pl` (bez protokołu, ostatnia – żeby nie złapać `nowastara.pl`)
4. Stara ścieżka pliku: `/home/old/htdocs/` → `/home/new/htdocs/`

Sprawdzenie po fakcie:

wp db search 'stara.pl' --all-tables

Jeśli nic nie zwraca, jest czysto. Jeśli zwraca pojedyncze rekordy (np. backup pluginów), zignoruj. Jeśli zwraca dziesiątki – powtórz search-replace z innym wzorcem.

Migracja może zniszczyć pozycje w Google szybciej niż algorithm update. Na szczęście większości problemów da się uniknąć przez 5 prostych kroków.

Najgorsze błędy SEO podczas migracji:

1. Brak 301 redirectów ze starych URLi. Zmieniasz strukturę permalinks z `/?p=123` na `/%postname%/`? Zmieniasz domenę? Każdy stary URL musi przekierowywać 301 na nowy, inaczej Google traci całą equity linków zewnętrznych. W .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^stara\.pl$ [NC]
RewriteRule ^(.*)$ https://nowa.pl/$1 [R=301,L]

2. robots.txt z `Disallow: /` z dev środowiska. Klasyk. Strona deployed, robots blokuje wszystko, w 3 dni Google deindeksuje wszystko. Zawsze sprawdź robots.txt zaraz po migracji.

3. Ustawienia → Czytanie → "Proś wyszukiwarki o nieindeksowanie tej strony" zaznaczone. WordPress dodaje wtedy `noindex` do każdej strony. Odznacz natychmiast po migracji.

4. Brak canonical tags lub złe canonicale wskazujące na starą domenę. Sprawdź w Yoast SEO / RankMath, czy canonical URL renderuje się prawidłowo.

5. Sitemap ze starymi URL-ami. Wygeneruj sitemap od nowa (`wp yoast sitemap rewrite` lub odpowiednik) i zsubmituj w Google Search Console pod nową properly.

Checklist SEO post-migration:

• [ ] 301 redirect ze starej domeny (jeśli zmiana domeny)
• [ ] robots.txt sprawdzony, brak Disallow: /
• [ ] Indeksacja włączona w Ustawieniach → Czytanie
• [ ] Canonical URLs renderują się prawidłowo
• [ ] Nowy sitemap.xml wygenerowany
• [ ] Sitemap zsubmitowany w GSC
• [ ] Nowa property dodana w GSC
• [ ] Change of Address tool w GSC (przy zmianie domeny)
• [ ] GA4 i Google Tag Manager nadal działają
• [ ] Schema markup renderuje się (Rich Results Test)
• [ ] Internal links nie wskazują na starą domenę (`wp db search 'stara.pl'`)
• [ ] Wszystkie obrazy mają alt texts
• [ ] Core Web Vitals nie pogorszyły się (PageSpeed Insights)

Najczęstszy efekt zaniedbania: drop pozycji o 20–40% przez 2–3 tygodnie, potem powolny powrót. Niektóre keyword nigdy nie wracają – zwłaszcza jeśli zapomniałeś o redirectach. Więcej o utrzymaniu prędkości po migracji w WordPress wolno się ładuje i wybór dobrego hostingu w najlepszy hosting WordPress.

Nie każda migracja nadaje się do zrobienia samemu. Są scenariusze, w których oszczędność 1500 zł na agencji może kosztować 30 000 zł utraconych zamówień.

Zlecaj agencji jeśli:

1. Sklep WooCommerce z 5000+ produktów lub aktywnymi zamówieniami. Każda sekunda downtime to potencjalnie utracony klient. Profesjonalna migracja sklepu wymaga znajomości WooCommerce (transients, sessions, cart fragments), integracji z BaseLinker/Subiekt/Comarch, gateway'ów płatności (Przelewy24, Stripe, PayU webhooks). Sam case: sklep z 12 000 produktów i 200 zamówieniami dziennie – migracja zajęła 6h z zerowym downtime, koszt 2200 zł. Klient wyceniał własne zrobienie na 3 dni nerwów.

2. Multisite (WordPress Network). Multisite ma osobne tabele dla każdego site, własny routing przez wp-config.php (`SUBDOMAIN_INSTALL`, `DOMAIN_CURRENT_SITE`), shared users. Większość pluginów migracyjnych ma z tym problem albo wymaga premium. Manual migration to 3–8 godzin pracy.

3. Wysokie ryzyko biznesowe. Strona generuje ponad 5000 zł dziennie? Każdy błąd = wymierna strata. Nie testuj na takim środowisku samodzielnie pierwszy raz.

4. Headless setup, custom REST API, JAMstack. Migracja WordPress jako backend dla Next.js / Gatsby wymaga zsynchronizowania nie tylko WP, ale też deployment frontu, CDN cache invalidation, webhook reconfiguracji.

5. Po prostu nie czujesz się pewnie. Brzmi miękko, ale to najczęstszy realny powód, dla którego ludzie psują migracje – robią to "po godzinach", piątkowy wieczór, bez backupu, bo "to przecież proste".

Cennik migracji w Polsce (2026):

Tańsza alternatywa: wybierz hosting, który robi migrację gratis. CyberFolks przenosi nawet sklepy WooCommerce w cenie pakietu – ich zespół ma doświadczenie z setkami migracji miesięcznie. Porównanie hostingów pod kątem migracji znajdziesz w najlepszy hosting WordPress 2026 i hosting dla WooCommerce – co wybrać.

Jeśli twoja strona jest kluczowa dla biznesu i nie chcesz ryzykować, zadzwoń do nas: +48 604 939 140. Robimy migracje od 2008 roku, średnio jedna w tygodniu, bez utraty pozycji w Google. Skontaktuj się przez formularz lub zobacz nasze usługi WordPress i strony internetowe. Sprawdź też naszą ofertę audytu cyfrowego – pomożemy ocenić ryzyka migracji przed startem.

Wiele z tych problemów można rozwiązać samodzielnie – ale gdy brakuje czasu, narzędzi lub utknąłeś na etapie diagnozy, warto zlecić pracę zespołowi który robi to codziennie. W KC Mobile zajmujemy się tym od lat.

Zobacz powiązane usługi i materiały:

• wdrożenie WordPress
• strona na WordPressie
• najlepszy hosting WordPress
• PHP memory limit WordPress
• biały ekran śmierci (WSOD)

Jeśli opis w tym wpisie nie dotyczy dokładnie Twojej sytuacji, napisz do nas – odpowiadamy w ciągu 24 godzin roboczych.