Jak przenieść WordPressa na inny serwer? Poradnik

Przeniesienie WordPressa na inny serwer nie musi oznaczać długiej przerwy w działaniu strony ani ryzyka utraty danych. Wystarczy dobrze przygotować kopię plików i bazy danych, a następnie poprawnie skonfigurować wszystko na nowym hostingu. W kolejnych krokach przejdziemy przez cały proces tak, aby zmiana serwera była możliwie bezbolesna.

Jak przygotować stronę WordPress do przeniesienia na inny serwer?

Dobre przygotowanie strony przed przeniesieniem często decyduje o tym, czy migracja zajmie 20 minut, czy kilka godzin walki z błędami. Przygotowanie w praktyce oznacza przede wszystkim uporządkowanie tego, co już jest, oraz sprawdzenie, czy nowy serwer „udźwignie” aktualną stronę. Dzięki temu kopia zapasowa będzie lżejsza, a samo przenoszenie mniej stresujące, nawet jeśli strona ma kilkaset wpisów i działa na niej kilka wtyczek.

Na początku przydaje się krótkie „sprzątanie” WordPressa. Usunięcie nieużywanych wtyczek i motywów zmniejsza liczbę plików, które trzeba skopiować, czasem nawet o kilkadziesiąt megabajtów. Pomaga też aktualizacja systemu, motywu i wtyczek do najnowszych wersji, żeby po zmianie serwera nie zderzyć się z błędami, które już dawno zostały poprawione przez twórców. Dobrze też zerknąć, czy na stronie nie ma wiszących szkiców, starych wersji wpisów i ogromnego kosza w bibliotece mediów – ich usunięcie potrafi skrócić czas tworzenia kopii zapasowej o kilka minut.

Równolegle dobrze jest sprawdzić kilka kluczowych kwestii po stronie hostingu. Przydaje się krótka checklista, która pozwala upewnić się, że nowy serwer jest odpowiednio przygotowany:

• Wersja PHP na nowym serwerze zgodna z wymaganiami używanej wersji WordPressa oraz wtyczek (informacja zwykle jest w panelu hostingu).
• Limit pamięci PHP (memory_limit) ustawiony na rozsądnym poziomie, np. 256 MB dla typowej strony z kilkoma wtyczkami i motywem premium.
• Limit czasu wykonywania skryptów (max_execution_time) na poziomie umożliwiającym import większej bazy, np. 120 sekund.
• Dostęp do panelu zarządzania bazą danych (np. phpMyAdmin) oraz możliwość tworzenia nowych baz i użytkowników z uprawnieniami.
• Informacja o ścieżkach i danych dostępowych do FTP lub SFTP, razem z portem i rodzajem połączenia.

Takie techniczne rozeznanie przed migracją pozwala uniknąć sytuacji, w której połowa procesu się udaje, a w pewnym momencie wszystko zatrzymuje się na zbyt niskim limicie czasu lub pamięci. Przy okazji daje to szansę na ocenę, czy nowy serwer faktycznie będzie wygodniejszy i szybszy, czy tylko tańszy w abonamencie.

Na koniec przydaje się przygotowanie lokalnych notatek: zapisanie adresów URL paneli, danych logowania, prefiksu tabel w bazie (domyślnie „wp_”) oraz ewentualnych niestandardowych ustawień, np. wymuszonego HTTPS. Zebranie tych informacji wcześniej sprawia, że samo przenoszenie przebiega płynniej, bez nerwowego przekopywania się przez maile od hostingu czy stare pliki konfiguracyjne.

Jak poprawnie wykonać kopię plików WordPressa i bazy danych?

Bez świeżej kopii zapasowej migrowanie WordPressa przypomina przeprowadzkę bez kartonów – niby się da, ale stres niepotrzebnie rośnie. Najpierw potrzebne jest pełne archiwum plików strony, a potem zrzut (eksport) bazy danych, bo to właśnie tam zapisane są wpisy, strony, komentarze i większość ustawień. Dzięki temu w razie pomyłki można w kilka minut cofnąć zmiany i przywrócić stronę do działania.

Pliki WordPressa najczęściej kopiuje się przez FTP (np. FileZilla) lub przez menedżer plików w panelu hostingu. Po połączeniu z serwerem wystarczy pobrać na dysk lokalny cały katalog, w którym jest strona – zwykle jest to public_html lub www – razem z ukrytymi plikami, takimi jak .htaccess. Przy średniej stronie, ważącej około 1–2 GB, pobieranie może potrwać od kilku do kilkunastu minut, zależnie od łącza. Najwrażliwszym elementem jest katalog wp-content, bo tam znajdują się motywy, wtyczki i wszystkie wgrane media, więc przy ewentualnych problemach z miejscem na dysku można sprawdzić przede wszystkim jego rozmiar.

Baza danych wymaga osobnego zabezpieczenia. Najprostszą drogą jest narzędzie phpMyAdmin w panelu hostingu: po wybraniu odpowiedniej bazy (jej nazwa zwykle jest podana w pliku wp-config.php) używa się opcji eksportu i zapisuje plik .sql na komputerze. Dla większych baz, mających na przykład ponad 100 MB, przydaje się zaznaczenie kompresji do formatu .zip, dzięki czemu plik pobiera się szybciej i zajmuje mniej miejsca. Niektórzy korzystają z wtyczek backupowych, ale niezależna kopia z panelu hostingu daje większą kontrolę, bo nie zależy od działania samego WordPressa. Po wykonaniu obu kopii – plików i bazy – bezpieczniej jest przechować je w dwóch miejscach, na przykład na komputerze i w chmurze, tak aby przenosiny nie były jedyną szansą na odzyskanie strony.

Jak utworzyć nową bazę danych i użytkownika na nowym serwerze?

Nowa baza danych i użytkownik na docelowym serwerze to coś w rodzaju nowego „mieszkania” dla Twojej strony – bez tego WordPress po prostu nie będzie miał się gdzie podłączyć. Na szczęście ten etap zwykle zajmuje kilka minut i da się go przejść spokojnie, nawet jeśli panel hostingowy wygląda na pierwszy rzut oka jak kokpit samolotu. Najczęściej wszystko odbywa się w jednym miejscu: w panelu hostingu, w sekcji związanej z bazami danych (zwykle nazywa się „MySQL”, „Bazy danych” albo „Databases”).

Po zalogowaniu do panelu hostingu pojawia się opcja utworzenia nowej bazy danych. W tym miejscu podaje się jej nazwę (dobrze, jeśli da się ją skojarzyć z projektem, np. „blog_wp” zamiast losowych znaków) oraz wybiera kodowanie znaków. Dla WordPressa w 2025 roku standardem jest „utf8mb4” z porównywaniem „utf8mb4_unicode_ci” lub zbliżonym – to pomaga uniknąć problemów z polskimi znakami i emoji. Po zapisaniu ustawień nowa baza pojawia się zazwyczaj na liście po kilku sekundach i od razu można do niej przypisać użytkownika.

Tworzenie użytkownika bazy zwykle polega na nadaniu loginu, hasła i określeniu uprawnień. Hasło dobrze, by miało przynajmniej 12–16 znaków i mieszało litery, cyfry i symbole, bo te dane będą później wpisane w pliku konfiguracyjnym WordPressa. W panelu hostingu często od razu znajduje się wygodna opcja „przypisz użytkownika do bazy” i nadanie mu pełnych praw (SELECT, INSERT, UPDATE, DELETE itd.), tak aby WordPress mógł swobodnie odczytywać i zapisywać dane. Po zapisaniu ustawień dobrze jest od razu zanotować: nazwę bazy, nazwę użytkownika, hasło oraz adres serwera bazy (często „localhost”, ale nie zawsze), bo te cztery informacje będą kluczowe przy dalszej konfiguracji.

Jak wgrać pliki WordPressa na nowy serwer i zaimportować bazę danych?

Pliki strony i baza danych to dwa elementy, które razem tworzą działający WordPress. Po przygotowaniu kopii przychodzi moment, kiedy trzeba je przenieść na nowy serwer: najpierw wgrywa się pliki, a potem importuje bazę. Dobrze przeprowadzony proces sprawia, że po kilku minutach lub kilkudziesięciu (w zależności od wielkości strony, np. 300 MB vs 3 GB) serwis może działać niemal identycznie jak na poprzednim hostingu.

Samo wgrywanie plików zwykle odbywa się przez klienta FTP (np. FileZilla) albo przez menedżer plików w panelu hostingu. Po połączeniu z nowym serwerem można skopiować wszystkie pliki WordPressa do katalogu przypisanego do domeny, najczęściej jest to folder o nazwie podobnej do public_html lub httpdocs. W przypadku mniejszych stron cały proces wgrywania zamyka się czasem w 5–10 minutach, przy większych serwisach z tysiącami zdjęć zajmuje to dłużej. W tle warto mieć otwarte stare konto hostingowe, żeby w razie wątpliwości szybko porównać strukturę katalogów i upewnić się, że nic nie zostało pominięte.

Import bazy danych wygląda nieco inaczej, bo odbywa się zwykle przez panel narzędzia takiego jak phpMyAdmin. Po zalogowaniu się na nowy serwer i wybraniu świeżo utworzonej bazy można użyć zakładki „Import”, wskazać plik z kopią (najczęściej z rozszerzeniem .sql) i uruchomić proces. Przy bazach o rozmiarze kilkudziesięciu megabajtów import trwa zazwyczaj kilkanaście sekund, większe zrzuty mogą wymagać zwiększenia limitów w panelu lub kontaktu z supportem hostingu. Pomaga obserwowanie komunikatów po zakończeniu, bo jeden czerwony błąd na liście potrafi później przełożyć się na „białą stronę” zamiast działającej witryny.

W praktyce przy przenoszeniu plików i importowaniu bazy przydaje się kilka prostych zasad, które ułatwiają życie na każdym etapie:

• Sprawdzenie, czy na nowym serwerze znajduje się tylko jedna, świeża kopia plików WordPressa, bez starych katalogów typu old_site lub backup, które mogą wprowadzać zamieszanie.
• Podzielenie bardzo dużej kopii bazy danych (np. powyżej 100–150 MB) na mniejsze pliki, jeśli panel hostingu ma niski limit importu, co zmniejsza ryzyko przerwania procesu.
• Zwrócenie uwagi, aby wersja PHP na nowym serwerze była zgodna z używaną wersją WordPressa i wtyczek, ponieważ zbyt stara lub zbyt nowa wersja potrafi generować błędy już po wgraniu wszystkich danych.

Dzięki takiemu podejściu całe przenoszenie przypomina bardziej spokojną przeprowadzkę niż nerwową akcję ratunkową. Dobrze jest też po zakończeniu wgrywania plików i importu bazy zachować kopie źródłowe przez minimum kilka dni, na wypadek gdyby po pierwszych testach pojawiła się potrzeba cofnięcia pojedynczej zmiany lub przywrócenia jednego konkretnego elementu strony.

Jak zmienić dane dostępu do bazy w pliku wp-config.php po przeniesieniu?

Po przeniesieniu strony na nowy serwer WordPress zwykle przestaje działać nie dlatego, że „coś się zepsuło”, ale dlatego, że nadal próbuje łączyć się ze starą bazą danych. Kluczowym krokiem jest więc zaktualizowanie danych dostępowych w pliku wp-config.php. To właśnie tam, w jednym niewielkim fragmencie kodu, zapisane są informacje o nazwie bazy, użytkowniku, haśle i adresie serwera bazy – bez nich WordPress po prostu nie wie, skąd ma pobrać treści.

Po wgraniu plików na nowy serwer zwykle wystarczy otworzyć plik wp-config.php w edytorze plików w panelu hostingu lub przez FTP i znaleźć blok z definicjami DB_NAME, DB_USER, DB_PASSWORD i DB_HOST. Do tych czterech miejsc trzeba przepisać dane z nowego hostingu: dokładną nazwę bazy, nazwę użytkownika, hasło oraz adres serwera bazy (czasem jest to „localhost”, czasem konkretny adres, np. w stylu mysql123.nazwahostingu.pl). W praktyce cała operacja zajmuje 2–5 minut, ale dobrze, jeśli robi się to uważnie, litera po literze – jedno brakujące podkreślenie lub spacja potrafią zablokować działanie strony.

Po zapisaniu zmian i odświeżeniu strony w przeglądarce można sprawdzić, czy WordPress prawidłowo łączy się z bazą. Jeśli zamiast strony pojawia się komunikat o błędzie połączenia z bazą, najczęściej oznacza to literówkę w nazwie bazy lub użytkownika, błędne hasło albo niepoprawny DB_HOST. Pomaga wówczas porównanie wpisów w wp-config.php z danymi z panelu hostingu znak po znaku. Gdy wszystko zacznie działać, dobrze jest zostawić sobie gdzieś te dane w bezpiecznym miejscu, żeby przy kolejnej migracji (albo zmianie hasła do bazy) móc szybko wrócić do sprawdzonej konfiguracji.

Jak zaktualizować adresy URL strony i strukturę linków po migracji WordPressa?

Po migracji WordPressa na nowy serwer strona może wyglądać poprawnie, ale „w środku” wciąż trzymać się starego adresu. Skutki bywają dość prozaiczne: część linków prowadzi donikąd, grafiki się nie ładują, a panel logowania pokazuje błąd. Aktualizacja adresów URL i struktury linków to ten etap, który porządkuje cały bałagan po przeprowadzce – trochę jak zmiana adresu w banku, u lekarza i na poczcie, żeby wszystkie listy wiedziały, gdzie trafić.

Podstawą jest zmiana głównego adresu witryny i adresu WordPressa w panelu: w ustawieniach ogólnych powinien pojawić się już nowy URL z poprawnym protokołem (http/https). To jednak zwykle dopiero połowa pracy. W bazie danych mogą być zapisane setki odwołań do starej domeny, na przykład w treści wpisów, polach ACF czy ustawieniach buildera. Ręczne poprawianie byłoby męczącym zajęciem na kilka wieczorów, dlatego stosuje się narzędzia typu „search and replace” (wyszukaj i zamień w bazie), które w kilka minut podmieniają stary adres na nowy we wszystkich tabelach. Dobrą praktyką jest wykonanie dodatkowej kopii bazy tuż przed takim automatycznym przeszukiwaniem, żeby w razie pomyłki dało się szybko wrócić do poprzedniego stanu.

Po zmianie adresów przychodzi czas na same linki. Jeśli podczas migracji zmieniła się struktura permalinków (czyli format adresów wpisów, np. z „?p=123” na „/blog/tytul-wpisu/”), przydatne jest przejście do ustawień bezpośrednich odnośników i ponowne ich zapisanie. Taki prosty krok często regeneruje plik .htaccess i usuwa błędy 404. Gdy adresy mocno się zmieniły, opłaca się też rozważyć przekierowania 301 ze starych URL-i na nowe. Można do tego użyć wtyczki SEO albo osobnej wtyczki do redirectów, dzięki czemu ruch z wyszukiwarki i starych zakładek użytkowników nie „rozsypuje się” po drodze. Dla uporządkowania pracy przydaje się krótka lista kontrolna:

• sprawdzenie i zapisanie nowych adresów WordPressa i strony w ustawieniach ogólnych,
• globalna podmiana starych adresów na nowe w bazie danych za pomocą sprawdzonego narzędzia,
• ponowne zapisanie struktury linków w ustawieniach bezpośrednich odnośników,
• dodanie przekierowań 301 dla kluczowych starych URL-i, zwłaszcza wysoko pozycjonowanych podstron,
• krótkie sprawdzenie losowych wpisów i mediów, czy linki i obrazki otwierają się poprawnie.

Taka sekwencja kroków sprawia, że nowy serwer nie jest już tylko kopią starej strony, ale w pełni działającą witryną z poprawnymi adresami. Przeglądarka, wyszukiwarki i użytkownicy „wiedzą”, gdzie czego szukać, a przeniesiony WordPress zachowuje się tak, jakby zawsze był na tym serwerze.

Jak przetestować działanie strony po przeniesieniu i usunąć typowe błędy?

Po przeniesieniu WordPressa na nowy serwer strona może na pierwszy rzut oka działać poprawnie, a mimo to w tle pojawiają się drobne błędy. Dlatego przydatne jest krótkie „tour de site”: sprawdzenie strony głównej, kilku podstron, koszyka czy formularzy kontaktowych, zanim wszystko zostanie uznane za zakończone. Taki test zajmuje zwykle od 15 do 30 minut, a pozwala szybciej wychwycić kłopoty z linkami, obrazkami czy logowaniem do panelu.

Dla porządku przydaje się prosta checklista, która prowadzi krok po kroku przez najczęstsze problemy pojawiające się po migracji. Poniżej znajduje się zestawienie typowych objawów, możliwych przyczyn i szybkich sposobów naprawy.

Po takim przeglądzie dobrze jest jeszcze raz wejść na stronę z innej przeglądarki lub urządzenia i zobaczyć, czy wszystko ładuje się w czasie krótszym niż kilka sekund oraz czy nie pojawiają się dziwne komunikaty. Jeśli strona jest sklepem lub zawiera formularze, przydaje się wykonanie jednego testowego zamówienia lub wysłanie wiadomości, tak jak zrobiłby to zwykły użytkownik. Dzięki temu nowy serwer ma szansę „przejść chrzest bojowy”, zanim strona zacznie działać pod pełnym ruchem.