Błąd 404 w WordPressie — jak naprawić podstrony i permalinki?

Jeżeli strona główna WordPressa działa, ale wpisy i podstrony zwracają 404, częstą przyczyną są reguły przyjaznych adresów. Nie każda 404 jest jednak problemem permalinków. Adres mógł być błędny, treść usunięta, slug zmieniony, strona nieopublikowana albo żądanie mogło trafić do niewłaściwej instalacji.

Krótka odpowiedź: sprawdź, czy treść istnieje i jest opublikowana, porównaj dokładny slug oraz przetestuj kilka różnych podstron. Jeżeli wszystkie przyjazne adresy zwracają 404, a wariant ?p=ID działa, odśwież reguły w Ustawienia → Bezpośrednie odnośniki i sprawdź konfigurację Apache/LiteSpeed. Na Nginx naprawa wymaga konfiguracji serwera, nie .htaccess. Nie zmieniaj struktury URL-i tylko po to, żeby „przeliczyć” reguły; zmiana działających adresów wymaga mapy i przekierowań.

Najpierw ustal, jaka to 404

Zbierz cztery informacje:

• pełny problematyczny URL;
• status HTTP, a nie tylko tekst na ekranie;
• czy treść istnieje w panelu i ma status „opublikowano”;
• czy błąd dotyczy jednego adresu, jednego typu treści czy wszystkich podstron.

Testuj również losowy, na pewno nieistniejący adres. Powinien otrzymać prawdziwy status 404. Jeżeli pokazuje stronę błędu, ale zwraca 200, masz osobny problem soft 404.

Scenariusz 1: jedna konkretna strona zwraca 404

Najpierw sprawdź treść, nie serwer:

1. Czy wpis istnieje w koszu?
2. Czy jest szkicem, prywatny albo zaplanowany?
3. Czy slug w panelu odpowiada URL-owi?
4. Czy rodzic strony nie zmienił jej adresu?
5. Czy ten sam slug nie jest używany przez inną treść, kategorię lub regułę?
6. Czy w adresie nie ma literówki, dodatkowego segmentu lub złego języka?

Jeżeli adres wcześniej działał i został świadomie zmieniony, przywróć go albo dodaj 301 do najbliższego odpowiednika. Nie przekierowuj automatycznie wszystkiego do strony głównej.

Scenariusz 2: strona główna działa, wszystkie podstrony mają 404

To klasyczny objaw braku lub nieskuteczności reguł rewrite. WordPress przechowuje strukturę permalinków w bazie, ale serwer musi skierować pasujące żądania do index.php.

W panelu otwórz Ustawienia → Bezpośrednie odnośniki. Samo odwiedzenie ekranu wywołuje odświeżenie reguł WordPressa; dokumentacja zaznacza, że nie trzeba zapisywać ustawień tylko w tym celu. Jeżeli rzeczywiście zmieniasz ustawienie, zapisz je świadomie.

Po operacji sprawdź:

• jeden wpis;
• jedną stronę;
• archiwum, jeśli jest używane;
• losowy nieistniejący URL;
• status i ewentualne przekierowania.

Nie zmieniaj struktury permalinków bez planu

Przełączenie z /nazwa-wpisu/ na adres zawierający datę albo odwrotnie zmienia publiczne URL-e. Stare linki, zakładki i wyniki wyszukiwarki mogą wtedy prowadzić do 404.

Jeśli struktura ma się zmienić biznesowo:

• wyeksportuj listę obecnych adresów;
• przygotuj mapę stary–nowy;
• wdroż 301 dla dokładnych odpowiedników;
• zaktualizuj linki wewnętrzne i mapę XML;
• przetestuj pełne łańcuchy;
• monitoruj 404 po publikacji.

Odświeżenie reguł i zmiana struktury URL to dwie różne operacje.

Apache i LiteSpeed: sprawdź .htaccess

Na typowej instalacji w katalogu głównym WordPressa znajduje się blok zarządzany przez WordPress. Jeżeli plik jest zapisywalny, system może go zaktualizować. Jeżeli nie, ekran permalinków może pokazać reguły do ręcznego wstawienia.

Przed edycją:

1. pobierz kopię .htaccess;
2. pokaż pliki ukryte w menedżerze lub SFTP;
3. sprawdź, czy edytujesz katalog właściwej domeny;
4. zachowaj własne przekierowania i zabezpieczenia poza blokiem WordPressa;
5. porównaj log błędów po jednym żądaniu.

Nie kopiuj reguł z przypadkowej strony. Instalacja w podkatalogu, Multisite i konfiguracja z proxy mogą wymagać innego układu.

Apache przetworzy RewriteRule w .htaccess tylko wtedy, gdy konfiguracja serwera na to pozwala, m.in. przez odpowiedni AllowOverride. Jeżeli plik wygląda poprawnie, ale jest ignorowany, potrzebna może być zmiana po stronie hostingu.

Nginx: .htaccess nie bierze udziału

Nginx nie czyta .htaccess. Odwiedzanie ekranu permalinków nie naprawi brakującej reguły w konfiguracji serwera. Administrator powinien sprawdzić przekazanie nieistniejących ścieżek do WordPressa zgodnie z układem hostingu.

Nie wklejaj konfiguracji Apache do panelu Nginx. Najpierw ustal realny serwer WWW — nagłówek odpowiedzi może być zmieniony przez CDN, więc w razie wątpliwości sprawdź panel lub zapytaj operatora.

Konflikt wtyczki, typu treści lub slugu

Jeśli 404 obejmuje tylko niestandardowy typ treści, kategorię albo endpoint, sprawdź rejestrację rewrite rules przez odpowiedzialną wtyczkę lub motyw. Zapis permalinków może tymczasowo odświeżyć reguły, ale nie usunie błędu kodu, który rejestruje je w niewłaściwej kolejności.

Na stagingu:

• porównaj stan przed i po ostatniej aktualizacji;
• sprawdź konflikt slugów;
• aktywuj motyw bazowy tylko w kontrolowanym teście;
• wyłączaj po jednym podejrzanym komponencie;
• nie testuj wyłączania wtyczek odpowiedzialnych za sprzedaż na żywej stronie.

Błędny katalog docelowy domeny

Po migracji domena może prowadzić do starego katalogu albo innej instalacji. Strona główna bywa wtedy przechwytywana przez plik statyczny, podczas gdy podstrony nie istnieją.

Sprawdź DocumentRoot, obecność właściwego index.php, adres witryny i adres WordPressa oraz to, czy testujesz właściwe środowisko. Zmiany DNS mogą też sprawić, że różni użytkownicy trafiają chwilowo do różnych serwerów.

Checklista bezpiecznej diagnozy

• ☐ Potwierdzono prawdziwy status 404.
• ☐ Treść istnieje i jest opublikowana.
• ☐ Slug oraz hierarchia są poprawne.
• ☐ Określono zakres błędu na kilku URL-ach.
• ☐ Nie zmieniono struktury permalinków bez mapy.
• ☐ Odświeżono reguły WordPressa.
• ☐ Sprawdzono właściwy serwer WWW.
• ☐ Zachowano kopię .htaccess lub konfiguracji.
• ☐ Sprawdzono log w czasie jednego żądania.
• ☐ Przetestowano stronę istniejącą i losową nieistniejącą.

Prawidłowa naprawa przywraca istniejące strony, ale pozostawia rzeczywiście nieistniejącym adresom status 404. Celem nie jest usunięcie wszystkich 404 z internetu — tylko odróżnienie brakujących zasobów od błędnej obsługi adresów, które powinny działać.