Błąd strony po przeniesieniu WordPressa: jak znaleźć przyczynę i naprawić problem

Gdy WordPress po migracji wyświetla błąd krytyczny, zachowaj aktualny stan plików i bazy, a dopiero potem szukaj przyczyny. Ponowienie migracji może nadpisać dane potrzebne do ustalenia, czy problem dotyczy transferu, konfiguracji czy kodu.

Zapisz dokładny komunikat, godzinę wystąpienia błędu, adres strony i ostatnią czynność przed awarią. Sprawdź, czy błąd pojawia się na stronie głównej, w `/wp-admin`, na konkretnej podstronie, czy dopiero po wysłaniu formularza albo dodaniu produktu do koszyka.

Zabezpiecz osobno katalog instalacji WordPressa i eksport bazy z panelu hostingu lub phpMyAdmin. Jeśli poprzedni serwer nadal działa, nie usuwaj jego plików ani bazy, dopóki nowa instalacja nie przejdzie testów. W sklepie uwzględnij zamówienia, które mogły wpłynąć po wykonaniu kopii migracyjnej.

Zacznij od logów, a nie od losowej zmiany ustawień. Panel hostingu zwykle udostępnia log PHP w sekcji domeny lub logów, a WordPress może zapisywać błędy w `wp-content/debug.log` po włączeniu `WP_DEBUG_LOG`. Włączenie logowania wymaga konfiguracji `WP_DEBUG` i `WP_DEBUG_LOG`, a `WP_DEBUG_DISPLAY` powinno pozostać ustawione na `false`, żeby błędy nie pojawiały się odwiedzającym.

Plik `debug.log` może zawierać ścieżki serwera, fragmenty zapytań lub inne wrażliwe informacje, dlatego ogranicz do niego dostęp HTTP i udostępniaj go wyłącznie uprawnionemu administratorowi. Po diagnozie wyłącz debugowanie oraz usuń plik albo zabezpiecz go zgodnie z konfiguracją hostingu. Komunikat `There has been a critical error on your website` jest ogólny; szczegółowego błędu szukaj w logu PHP lub wiadomości administracyjnej WordPressa.

Objaw po migracji wskazuje pierwszy obszar kontroli, ale log lub test w konkretnym miejscu potwierdza przyczynę. Tabela pomaga wybrać kontrolę początkową bez zmieniania kilku elementów naraz.

Błąd połączenia z bazą kieruje do kontroli `DB_NAME`, `DB_USER`, `DB_PASSWORD` i `DB_HOST` w `wp-config.php`. `$table_prefix` określa prefiks tabel, z których korzysta WordPress po połączeniu z bazą; błędny prefiks może uniemożliwić znalezienie tabel, ale sam nie powoduje błędu logowania do serwera bazy.

Błąd 500 i biały ekran częściej wymagają sprawdzenia PHP, logów, `.htaccess` oraz aktywnego motywu lub wtyczki. Brak zdjęć wskazuje na nieprzeniesiony katalog albo odwołania do starego adresu.

Wniosek: dopasuj pierwszą kontrolę do objawu, zmieniaj jeden element naraz i zapisuj wynik. Jeśli log wskazuje plik konkretnej wtyczki, najpierw sprawdź tę wtyczkę.

Dane połączenia z bazą sprawdzisz w `wp-config.php`, a adresy `home` i `siteurl` najczęściej w tabeli opcji bazy lub w Ustawienia > Ogólne. Stałe `WP_HOME` i `WP_SITEURL` zdefiniowane w `wp-config.php` mogą nadpisać wartości adresów zapisane w bazie.

W pliku `wp-config.php` sprawdź `DB_NAME`, `DB_USER`, `DB_PASSWORD` i `DB_HOST`, a następnie porównaj je z danymi nowej bazy w panelu hostingu. Operator może zmienić nazwę bazy, użytkownika lub adres serwera bazy podczas przenosin. Nie wklejaj haseł do publicznego zgłoszenia ani logu.

Jeśli panel administracyjny działa, przejdź do Ustawienia > Ogólne i porównaj pola "Adres WordPressa" oraz "Adres witryny". `siteurl` wskazuje adres plików WordPressa, a `home` adres strony widoczny dla odwiedzających; wartości mogą się różnić, gdy pliki systemu znajdują się w osobnym katalogu. Jeśli pola są niedostępne, odczytaj wartości w tabeli opcji bazy, której nazwa zależy od `$table_prefix` i nie musi zaczynać się od `wp_`.

Nie wykonuj globalnego wyszukiwania i zamiany adresów w bazie bez kopii. WordPress lub wtyczki mogą przechowywać wartości serializowane, czyli zapisane razem z informacją o strukturze i długości danych; prosta zamiana tekstu może uszkodzić taką wartość. Użyj narzędzia obsługującego serializację albo zleć zmianę administratorowi, a po operacji sprawdź stronę główną, panel, media i odnośniki.

Poradnik diagnozowania typowych błędów WordPressa pomaga porównać awarię po migracji z innymi objawami. Jeśli nie chcesz samodzielnie zmieniać bazy ani plików serwera, naprawa WordPressa po migracji obejmuje diagnozę przyczyny i przywrócenie działania strony.

Konflikt PHP lub wtyczki potwierdza wpis w logu błędów albo poprawa działania po kontrolowanym wyłączeniu wskazanego elementu. Sama zbieżność awarii z migracją nie dowodzi, że winna jest konkretna wtyczka.

Porównaj wersję PHP i dostępne rozszerzenia na starym oraz nowym hostingu. Ustawień szukaj w panelu hostingu w konfiguracji domeny lub PHP; dokładną ścieżkę i dostępne wersje określa operator. Sprawdź też wymagania aktywnych wtyczek i motywu, ponieważ nowe środowisko może ich nie spełniać.

Jeśli masz dostęp do `/wp-admin`, przejdź do Wtyczki > Zainstalowane wtyczki i wyłącz element wskazany w logu. Gdy panel nie działa, użyj menedżera plików hostingu lub FTP i tymczasowo zmień nazwę katalogu wskazanej wtyczki w `wp-content/plugins`. Zapisz pierwotną nazwę, by móc ją przywrócić.

Gdy nie wiadomo, która wtyczka powoduje błąd, możesz tymczasowo zmienić nazwę całego katalogu `wp-content/plugins`. Ta metoda wyłącza zwykłe wtyczki, więc może zmienić działanie sklepu, formularzy lub cache. Po potwierdzeniu, że strona działa, przywróć nazwę katalogu i aktywuj wtyczki pojedynczo, testując stronę po każdej zmianie. Wtyczki typu must-use mogą znajdować się w `wp-content/mu-plugins` i nie pojawiać się na standardowej liście.

Jeżeli błąd pozostaje po wyłączeniu wtyczek, sprawdź aktywny motyw. Przełącz go na domyślny motyw wyłącznie na kopii lub środowisku testowym, chyba że masz potwierdzenie, że zmiana nie zakłóci obsługi klientów.

Błąd 500 lub biały ekran oznacza, że serwer nie zwrócił prawidłowej strony, a log PHP lub serwera WWW zwykle zawęża przyczynę. Sprawdź wpis z czasu awarii, zanim zmienisz `.htaccess`, limity pamięci albo uprawnienia.

Log może wskazać niezgodną wersję PHP, błąd składni w pliku motywu lub wtyczki, przekroczenie limitu pamięci, niekompletny transfer albo odmowę dostępu do pliku. Jeśli log nie pokazuje szczegółu, przekaż hostingowi domenę, godzinę błędu i ścieżkę strony, na której wystąpił.

Sprawdź, czy transfer objął `wp-admin`, `wp-includes`, `wp-content` i `.htaccess`, jeśli nowy serwer korzysta z tego pliku. Porównaj listę plików na źródle i celu, a brakujące elementy przenieś z kopii. Nie nadpisuj całej instalacji świeżymi plikami, dopóki nie zabezpieczysz `wp-config.php`, motywów, wtyczek i mediów.

Jeśli log wskazuje `.htaccess`, zachowaj kopię i przetestuj podstawowe reguły właściwe dla serwera. Nie kopiuj reguł z przypadkowego poradnika, ponieważ Apache i Nginx używają innych konfiguracji. Błąd uprawnień wymaga sprawdzenia właściciela plików i zaleceń hostingu; masowa zmiana praw na zbyt szerokie może ujawnić pliki lub umożliwić ich modyfikację.

Nie zwiększaj limitu pamięci w ciemno. Najpierw sprawdź komunikat w logu i ustal, czy błąd pojawia się przy konkretnej czynności. Podniesienie limitu może zamaskować błąd kodu albo wyciek pamięci, a wartość wyższa niż limit hostingu nie zmieni warunków działania.

Pętlę przekierowań po migracji naprawisz, ustalając jeden docelowy wariant HTTPS i porównując adresy WordPressa z regułami serwera oraz wtyczek. Mieszana zawartość oznacza, że strona otwiera się przez HTTPS, ale część zasobów nadal ładuje przez HTTP.

Sprawdź kolejno:

• czy certyfikat SSL obejmuje właściwą domenę oraz wariant z `www` lub bez `www`;
• czy `home` i `siteurl` wskazują docelowy protokół i właściwy host;
• czy HTTPS nie jest wymuszany jednocześnie przez kilka wtyczek i konfigurację serwera;
• czy cache przeglądarki, wtyczka cache lub proxy nie przechowują starego przekierowania;
• czy przeglądarka wskazuje zasoby ładowane przez HTTP.

Tabela odpowiada na pytanie, gdzie szukać źródła typowych objawów HTTPS po przeniesieniu. Sprawdź wskazaną warstwę przed czyszczeniem cache.

Wniosek: usuń przyczynę przekierowania przed czyszczeniem cache, bo stary cache może utrudnić ocenę skutku zmiany.

Jeżeli `WP_HOME` lub `WP_SITEURL` znajduje się w `wp-config.php`, panel może nie pozwolić zmienić adresu. Sprawdź stałe, reguły hostingu i ustawienia wtyczek, a po zmianie przetestuj wariant z `www`, bez `www`, logowanie i formularze.

Przywróć kopię, gdy znasz jej datę, zawiera komplet plików i bazy, a aktualny stan nie zawiera danych do zachowania. Zleć diagnozę, gdy kopia jest niepełna, problem obejmuje zamówienia lub dane klientów albo nie wiesz, która zmiana może pogłębić awarię.

Przed przywróceniem porównaj datę kopii z ostatnim poprawnym zapisem w bazie. Ustal, czy od tego czasu pojawiły się zamówienia, konta lub formularze. Kopia samych plików albo samej bazy może nie odtworzyć działającej witryny, jeśli wersje wtyczek, motywu i danych nie są zgodne. Jeśli stary serwer nadal działa, zachowaj go do zakończenia naprawy.

Administratorowi przekaż informacje potrzebne do odtworzenia problemu:

• dokładny komunikat i adres strony, na którym występuje;
• godzinę pierwszego błędu oraz ostatnią zmianę przed awarią;
• informację, czy działają panel, strona główna i poszczególne funkcje;
• wersje PHP na starym i nowym serwerze, jeśli są znane;
• dostępność kopii plików, bazy i poprzedniego hostingu;
• fragment logu z czasu awarii po usunięciu haseł i innych danych wrażliwych.

Z naszych wdrożeń wynika, że sam komunikat widoczny na stronie rzadko wystarcza do bezpiecznej naprawy. Log z właściwego czasu i zachowana kopia pozwalają odróżnić brak pliku od błędu kodu bez kolejnych zmian na ślepo.

Jeśli strona nadal nie działa, zleć diagnozę i naprawę WordPressa, przekazując komunikat, log i informację o dostępnych kopiach. Przy błędzie 500 niezwiązanym z migracją sprawdź też przyczyny i naprawę błędu 500 WordPress.

Migracja jest zakończona poprawnie dopiero wtedy, gdy działają publiczne strony, panel i najważniejsze funkcje biznesowe, a logi nie pokazują nowych błędów. Otworzenie strony głównej nie potwierdza działania formularza, logowania ani koszyka.

Przejdź checklistę po migracji:

• otwórz stronę główną, najważniejsze podstrony i kilka adresów z menu;
• zaloguj się do `/wp-admin` i sprawdź zapis szkicu lub edycję treści;
• wyślij testowy formularz i potwierdź dostarczenie wiadomości;
• sprawdź obrazy, pliki do pobrania i zasoby biblioteki mediów;
• w sklepie dodaj produkt do koszyka i przejdź testową ścieżkę płatności bez rzeczywistego obciążenia;
• sprawdź certyfikat, przekierowania i logi po wykonaniu testów.

Jeśli podstrony zwracają 404, przejdź do Ustawienia > Bezpośrednie odnośniki i zapisz ustawienie, aby WordPress odświeżył reguły. Sprawdź również przekierowania ze starej domeny lub ścieżek, jeśli zmieniły się podczas migracji. Problem występujący po aktualizacji, a nie po transferze, opisuje poradnik WordPress nie działa po aktualizacji.

Zamknij diagnozę dopiero po ponownym przejściu testów po ostatniej zmianie i sprawdzeniu logów. Jeśli błąd wraca, zapisz czynność, która go wywołuje, oraz nowy wpis w logu.

• Błąd 404: co oznacza i jak go naprawić na stronie?
• WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji
• Wtyczki do zarządzania bazą danych WordPress: porównanie i bezpieczny wybór
• Jak skonfigurować reCAPTCHA w formularzach na stronie