Instalacja WordPress – najczęstsze błędy i ich rozwiązania

Błąd podczas instalacji lub konfiguracji WordPressa zwykle nie oznacza utraty całej strony. Najbezpieczniejsza kolejność działania to: rozpoznanie objawu, wykonanie kopii zapasowej, włączenie WP_DEBUG i dopiero potem zmiana plików, wtyczek albo ustawień serwera.

Jak szybko rozpoznać problem?

Objaw często wskazuje, gdzie szukać przyczyny. Błąd aplikacji WordPress może wynikać z wtyczki lub motywu, natomiast błąd serwera częściej wiąże się z PHP, plikiem .htaccess, limitami hostingu albo uprawnieniami do plików.

Objaw	Prawdopodobna przyczyna	Pierwszy krok
Biały ekran śmierci	Konflikt wtyczki lub motywu, błąd PHP, zbyt niski limit pamięci	Włącz WP_DEBUG i tymczasowo wyłącz wtyczki
500 Internal Server Error	Uszkodzony `.htaccess`, niezgodna wersja PHP, błąd dodatku	Zmień nazwę `.htaccess` i sprawdź logi
Błąd połączenia z bazą danych	Nieprawidłowe dane w `wp-config.php` lub niedostępny serwer bazy	Sprawdź DB_NAME, DB_USER, DB_PASSWORD i DB_HOST
Błąd 404 na podstronach	Nieprawidłowe bezpośrednie odnośniki albo brak reguł w `.htaccess`	Zapisz ponownie ustawienia bezpośrednich odnośników
Błąd 403 Forbidden	Nieprawidłowe uprawnienia plików lub blokada po stronie serwera	Sprawdź CHMOD i logi serwera

Co zrobić przed rozpoczęciem naprawy?

Nie edytuj plików WordPressa bez kopii zapasowej. Przygotuj kopię zarówno plików strony, jak i bazy danych MySQL. Sama kopia plików nie wystarczy, ponieważ wpisy, strony, ustawienia i część danych wtyczek znajduje się w bazie.

Przed zmianami sprawdź też, czy masz dostęp do panelu hostingu, FTP oraz narzędzia do zarządzania bazą danych. Przed rozpoczęciem naprawy upewnij się, że:

pobrałeś kopię bazy danych MySQL
pobrałeś pliki WordPressa przez FTP lub menedżer plików hostingu
zapisałeś osobną kopię pliku, który zamierzasz edytować
masz dane dostępu do FTP i panelu hostingowego
znasz lokalizację katalogu instalacji WordPressa

Jeżeli problem pojawił się po aktualizacji, nie przywracaj od razu całej witryny. Najpierw zapisz komunikat błędu i ustal, czy wskazuje on konkretną wtyczkę, motyw albo plik.

Naprawa najczęstszych błędów krok po kroku

1. Włącz tryb debugowania w WordPressie

WP_DEBUG zapisuje błędy PHP i WordPressa, dzięki czemu można ustalić, który plik lub dodatek powoduje awarię. Przed zmianą pobierz plik wp-config.php na komputer. Otwórz go w katalogu głównym instalacji i znajdź miejsce przed komentarzem That’s all, stop editing!. Dodaj lub zmień ustawienia:

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

Błędy zostaną zapisane w pliku wp-content/debug.log. Nie wyświetlaj szczegółowych komunikatów na publicznej stronie, ponieważ mogą ujawnić ścieżki plików i dane konfiguracyjne. Po zakończeniu diagnostyki wyłącz debugowanie albo ustaw WP_DEBUG na false.

2. Wyłącz wtyczki przez FTP

Jeśli nie możesz wejść do panelu administracyjnego, wyłączenie wtyczek przez FTP pozwala sprawdzić, czy przyczyną jest konflikt dodatków. Wykonaj następujące czynności:

Połącz się z serwerem przez klienta FTP.
Otwórz katalog wp-content.
Zmień nazwę folderu plugins na plugins.old.
Odśwież stronę i spróbuj zalogować się do panelu.
Jeśli witryna działa, przywróć nazwę plugins i włączaj dodatki pojedynczo.

Zmiana nazwy katalogu nie usuwa wtyczek. WordPress nie może ich załadować, więc tymczasowo je dezaktywuje. Gdy znajdziesz wadliwy dodatek, pozostaw go wyłączonego i sprawdź jego aktualizację, wymagania PHP albo zgodność z używanym motywem.

3. Sprawdź motyw

Jeśli wyłączenie wtyczek nie pomogło, problem może znajdować się w aktywnym motywie. Zapisz jego kopię, a następnie zmień nazwę katalogu motywu w wp-content/themes, na przykład z nazwa-motywu na nazwa-motywu.old. WordPress spróbuje uruchomić dostępny motyw domyślny.

Jeżeli po tej zmianie strona zacznie działać, sprawdź plik functions.php, ostatnio dodany kod oraz zgodność motywu z bieżącą wersją PHP i WordPressa. Nie wprowadzaj zmian bezpośrednio w motywie nadrzędnym, jeśli możesz użyć motywu potomnego. Aktualizacja może nadpisać takie modyfikacje.

4. Odśwież plik .htaccess

Uszkodzony .htaccess często powoduje błąd 500, pętle przekierowań albo błąd 404 na podstronach. Przez FTP zmień nazwę pliku na .htaccess.old. Jeśli strona odzyska działanie, zaloguj się do panelu WordPress i przejdź do Ustawienia → Bezpośrednie odnośniki. Nie zmieniaj ustawień, tylko kliknij „Zapisz zmiany”. WordPress wygeneruje reguły ponownie.

Jeśli nie masz dostępu do panelu, utwórz nowy plik .htaccess w katalogu głównym i wstaw podstawowe reguły dla instalacji w głównym katalogu domeny:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Reguły mogą wymagać zmiany, jeśli WordPress działa w podkatalogu albo hosting stosuje własną konfigurację. Nie kopiuj bezpośrednio ustawień z innej witryny bez sprawdzenia jej struktury.

5. Sprawdź limit pamięci PHP

Komunikat Allowed memory size exhausted, biały ekran lub błąd 500 mogą oznaczać wyczerpanie pamięci przydzielonej skryptom PHP. W pliku wp-config.php można spotkać ustawienie:

define( 'WP_MEMORY_LIMIT', '256M' );

Podana wartość jest przykładowa i nie musi być dostępna na każdym hostingu. Ostateczny limit zależy od konfiguracji serwera. Jeśli zmiana nie działa, sprawdź ustawienia PHP w panelu hostingu lub skontaktuj się z administratorem.

Notatka techniczna: nie zwiększaj limitów w ciemno. Jeśli błąd pojawił się po instalacji konkretnej wtyczki, większa ilość pamięci może tylko ukryć konflikt, a nie usunąć jego przyczynę.

Co sprawdzić, gdy podstawowe działania nie pomogły?

Jeśli WordPress nadal nie działa, rozdziel problem aplikacji od problemu serwera. WP_DEBUG pokazuje błędy WordPressa i PHP, ale dodatkowych informacji może dostarczyć serwerowy plik error.log. W panelu hostingu znajdziesz go zwykle w sekcji logów, choć nazwa i lokalizacja zależą od dostawcy.

Sprawdź kolejno:

czy wersja PHP jest zgodna z aktualnymi wymaganiami używanej wersji WordPressa, motywu i wtyczek
czy log błędów wskazuje konkretny plik, funkcję lub dodatek
czy pliki i katalogi mają prawidłowe uprawnienia, ponieważ błędny CHMOD może wywołać 403 lub uniemożliwić zapis
czy na serwerze nie ma podejrzanych plików, przekierowań albo innych oznak infekcji
czy podstawowe pliki WordPressa nie są uszkodzone i czy można je ponownie przesłać z zaufanego pakietu

WP-CLI może przyspieszyć diagnostykę osobom korzystającym z SSH, ale nie jest konieczne. W większości przypadków wystarczą FTP, panel hostingu, logi i ostrożna edycja wp-config.php. Przy podejrzeniu włamania, powtarzających się infekcjach lub niejasnych logach nie nadpisuj pochopnie plików. Najpierw zachowaj kopię i zleć analizę osobie, która zajmuje się administracją WordPressa.

Jak ograniczyć ryzyko kolejnych awarii?

Stabilność strony zależy nie tylko od samej instalacji. Regularnie aktualizuj WordPressa, motyw i wtyczki, ale przed większą aktualizacją wykonuj kopię plików i bazy. Wtyczki oraz motywy pobieraj z oficjalnego repozytorium lub wiarygodnego źródła. Pirackie paczki mogą zawierać zmodyfikowany kod, infekcje albo uszkodzone pliki.

Ogranicz liczbę dodatków do tych, których rzeczywiście potrzebujesz. Każda wtyczka zwiększa liczbę zależności i może wejść w konflikt z innym komponentem. Sprawdzaj też, czy kopia zapasowa faktycznie pozwala odtworzyć stronę, zamiast zakładać, że sam komunikat o jej wykonaniu oznacza poprawny backup.

Najważniejsza zasada brzmi prosto: najpierw kopia, potem logi i izolowanie przyczyny. Dzięki temu większość błędów WordPressa można naprawić bez resetowania całej witryny.