Wszystkie podstrony pokazują 404, a strona główna działa

Strona główna ładuje się bez problemu. Klikasz w menu — „Nie znaleziono strony”. Wchodzisz na wpis blogowy — to samo. Panel administracyjny działa, treści są na miejscu, wszystko wygląda normalnie od środka.

Ta kombinacja jest bardzo charakterystyczna i zawęża diagnozę praktycznie do jednej rzeczy: serwer nie wie, że ma przekazywać żądania do WordPressa.

Dlaczego strona główna to wyjątek

Warto zrozumieć mechanizm, bo wtedy naprawa staje się oczywista.

Strona główna to fizyczny plik — index.php w katalogu głównym. Serwer go widzi i uruchamia, więc działa.

Podstrony fizycznie nie istnieją. Nie ma katalogu kontakt ani pliku naprawa-wordpressa.html. Kiedy ktoś wchodzi na twojadomena.pl/kontakt/, serwer musi wiedzieć, że zamiast szukać takiego katalogu ma przekazać żądanie do index.php, a WordPress dopiero wtedy sprawdzi w bazie, co pod tym adresem ma pokazać.

Za to przekazywanie odpowiadają reguły przepisywania. Na Apache siedzą w pliku .htaccess, na nginx w konfiguracji serwera. Jeśli ich nie ma albo są uszkodzone, serwer bierze adres literalnie, nie znajduje takiego katalogu i uczciwie zwraca 404.

Naprawa, która działa w większości przypadków

Zaloguj się do panelu, wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij Zapisz zmiany. Nie zmieniaj przy tym żadnej opcji.

To wystarcza, bo zapis tej strony każe WordPressowi przegenerować reguły w .htaccess. Brzmi absurdalnie prosto, ale to standardowa procedura, nie sztuczka.

Jeśli nic się nie zmieniło, WordPress prawdopodobnie nie ma prawa zapisu do tego pliku. Sprawdź przez FTP, czy .htaccess w katalogu głównym istnieje i czy ma uprawnienia 644. Gdyby go nie było, utwórz go i wklej standardową zawartość:

# 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

Jeśli WordPress stoi w podkatalogu, na przykład w /blog/, zamień RewriteBase / na RewriteBase /blog/ i analogicznie w ostatniej regule.

Gdy hosting działa na nginx

Na nginx plik .htaccess nie robi nic — jest po prostu ignorowany. Reguły muszą być w konfiguracji serwera, do której zwykle nie masz dostępu.

Poznasz to po tym, że mimo poprawnego .htaccess nadal masz 404. Wtedy zostaje napisać do hostingu z prośbą o dodanie standardowej reguły dla WordPressa:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Każdy dostawca oferujący hosting pod WordPressa zna tę regułę i doda ją bez dyskusji. Część paneli ma nawet przełącznik „obsługa przyjaznych adresów”.

Jeśli 404 pojawiło się po migracji

Bardzo częsty moment. Po przeniesieniu na nowy serwer plik .htaccess często nie trafia do paczki, bo zaczyna się od kropki, a wiele programów FTP domyślnie ukrywa takie pliki.

Sprawdź więc najpierw, czy w ogóle tam jest. Włącz w kliencie FTP pokazywanie plików ukrytych.

Przy okazji migracji warto sprawdzić dwie inne rzeczy: czy w bazie adres strony zgadza się z nowym adresem oraz czy nie masz przypadkiem starych, twardych przekierowań. Jeśli po przenosinach dochodzą do tego problemy z logowaniem, opisaliśmy je osobno w tekście o utracie dostępu do panelu.

Sytuacje, które wyglądają podobnie, ale to nie to samo

404 tylko na jednej podstronie. Wtedy problem nie jest w regułach, tylko w tej konkretnej treści. Sprawdź, czy wpis nie został przeniesiony do kosza, czy nie ma statusu szkicu i czy nie ma dwóch treści z tym samym adresem.

404 tylko na wpisach blogowych, strony działają. Zwykle konflikt adresów: strona i kategoria mają ten sam slug, albo w strukturze odnośników brakuje elementu odróżniającego wpisy od stron.

404 na obrazkach i plikach. To już nie reguły przepisywania, a uprawnienia albo brakujące pliki w wp-content/uploads.

404 na /wp-admin. Odwrotna sytuacja — tam plik istnieje, więc jeśli dostajesz 404, sprawdź raczej błąd 403, bo wtyczki bezpieczeństwa czasem maskują blokadę jako „nie znaleziono”.

Nie zostawiaj tego na później

Ta awaria jest wyjątkowo groźna dla widoczności w Google, bo strona nie wygląda na zepsutą. Ładuje się, zwraca kod 200 na stronie głównej, więc monitoring uptime milczy. Tymczasem roboty wyszukiwarek dostają 404 na wszystkim, co mają w indeksie, i po kilku dniach zaczynają te adresy usuwać.

Jeśli więc trafisz na to po weekendzie, sprawdź potem w Search Console raport indeksowania. Odzyskanie pozycji po masowym wypadnięciu z indeksu trwa dłużej niż sama naprawa.

Ile to zajmuje

Kliknięcie „Zapisz zmiany” w odnośnikach — minuta. Odtworzenie .htaccess przez FTP — pięć minut. Sprawa z nginx zależy od czasu reakcji hostingu.

To jedna z tych awarii, którą naprawdę warto spróbować naprawić samodzielnie, bo pierwszy krok jest banalny. Zlecaj, jeśli nie masz dostępu do panelu ani FTP, albo jeśli po odtworzeniu reguł 404 nadal wraca — wtedy powód jest głębiej i trzeba czytać konfigurację serwera.

Ten poradnik dotyczy sytuacji, w której 404 zwracają wszystkie podstrony naraz. Jeśli nie działa pojedynczy adres, brakuje obrazków albo chcesz wyłapać martwe linki na całej stronie — przeczytaj szerszy poradnik o błędzie 404 w WordPressie.

---

Nie chcesz grzebać w konfiguracji serwera? Naprawimy to — diagnoza bezpłatna, odpowiedź w ciągu dwóch godzin. Sprawdzimy też, czy awaria nie zdążyła odbić się na indeksowaniu w Google. Rozliczenie godzinowe od 120 zł netto, płatność po wykonaniu.