Jeżeli strona główna WordPressa działa, ale wpisy, podstrony albo produkty zwracają 404 Not Found, problem często nie dotyczy samej treści. Serwer odbiera żądanie, lecz nie przekazuje go do WordPressa w sposób zgodny z jego strukturą adresów.
Taki objaw często pojawia się po migracji, zmianie konfiguracji serwera, przeniesieniu strony między Apache i NGINX albo edycji ustawień bezpośrednich odnośników.
Gdy homepage działa, a przyjazne URL-e nie, najpierw sprawdź mechanizm rewrite. Nie zaczynaj od odtwarzania bazy ani ponownej instalacji WordPressa.
Dlaczego strona główna może działać, a podstrony zwracać 404?
Żądanie do strony głównej zwykle trafia bezpośrednio do głównego pliku aplikacji. Adres taki jak:
https://example.pl/oferta/wymaga natomiast prawidłowego routingu. Serwer powinien rozpoznać, że nie chodzi o fizyczny katalog /oferta/, i przekazać żądanie do WordPressa, który dopiero ustala, jaka treść odpowiada temu URL-owi.
Jeżeli mechanizm rewrite nie działa, serwer może szukać fizycznego pliku lub katalogu, nie znaleźć go i zwrócić 404, mimo że odpowiednia strona nadal istnieje w bazie WordPressa.
| Objaw | Pierwszy trop |
|---|---|
| Homepage działa, wszystkie przyjazne URL-e zwracają 404 | Rewrite rules / konfiguracja serwera |
| 404 pojawiło się bezpośrednio po migracji | Różnice Apache/NGINX, .htaccess, document root |
| Nie działa tylko jedna podstrona | Slug, status treści, konflikt nazw lub pojedynczy redirect |
| Po ponownym zapisie permalinków wszystko wraca | Nieaktualne reguły rewrite WordPressa |
Zacznij od ustawień bezpośrednich odnośników
WordPress przechowuje wybraną strukturę permalinków i na jej podstawie buduje reguły potrzebne do interpretacji przyjaznych adresów.
Jeżeli problem pojawił się po migracji albo zmianie konfiguracji, jednym z pierwszych bezpiecznych testów jest wejście do:
Ustawienia → Bezpośrednie odnośniki
i ponowne zapisanie bieżącej struktury bez jej zmieniania.
Ponowny zapis permalinków odświeża wewnętrzne reguły rewrite WordPressa. Na Apache WordPress może również zaktualizować sekcję swoich reguł w .htaccess, jeśli plik jest zapisywalny. Nie konfiguruje natomiast automatycznie routingu NGINX.
Nie należy więc traktować tego jako magicznej naprawy. Jeżeli problem leży w konfiguracji standalone NGINX, niedozwolonym .htaccess albo złym document root, ponowny zapis permalinków nie usunie rzeczywistej przyczyny.
Na Apache sprawdź .htaccess i możliwość używania mod_rewrite
Na typowej instalacji WordPressa działającej pod Apache reguły permalinków mogą znajdować się w .htaccess. Ich zadaniem jest skierowanie żądań, które nie odpowiadają istniejącym plikom i katalogom, do index.php.
Problem po migracji może wynikać z tego, że:
.htaccessnie został skopiowany,- plik został nadpisany inną wersją,
- serwer nie pozwala stosować potrzebnych dyrektyw w
.htaccess, - mod_rewrite nie jest dostępny albo nie działa w oczekiwanym kontekście,
- reguły znajdują się w niewłaściwym katalogu.
Na Apache samo istnienie .htaccess nie wystarcza — konfiguracja serwera musi zezwalać na użycie dyrektyw rewrite w tym katalogu, np. przez odpowiednie AllowOverride FileInfo albo równoważnie precyzyjną konfigurację.
Jeżeli edycja .htaccess bezpośrednio poprzedzała awarię, zacznij od porównania z ostatnią działającą wersją. Nie kasuj całego pliku tylko po to, żeby „sprawdzić, czy pomoże”, jeśli zawiera także inne potrzebne reguły.
Warto też pamiętać, że WordPress może pokazać informację o konieczności ręcznego skopiowania reguł, jeśli nie może sam zapisać pliku.
Na standalone NGINX nie szukaj rozwiązania w .htaccess
Sam NGINX nie interpretuje .htaccess; jego routing definiuje się w konfiguracji serwera. Trzeba jednak najpierw ustalić architekturę hostingu, ponieważ NGINX może działać jako reverse proxy przed Apache — wtedy .htaccess backendu nadal może mieć znaczenie.
Dlatego migracja z hostingu Apache na środowisko standalone NGINX może dać charakterystyczny efekt: pliki statyczne i homepage działają, ale przyjazne adresy WordPressa zwracają 404.
Typowa logika konfiguracji standalone NGINX polega na sprawdzeniu, czy żądany plik lub katalog rzeczywiście istnieje, a jeśli nie — przekazaniu żądania do index.php wraz z parametrami.
Nie kopiuj jednak w ciemno przypadkowego bloku NGINX znalezionego w internecie. Hosting zarządzany może generować konfigurację automatycznie, używać reverse proxy albo mieć dodatkową warstwę cache. W takim przypadku poprawka powinna być wykonana w miejscu przewidzianym przez operatora.
Po migracji sprawdź document root i miejsce instalacji WordPressa
Rewrite może być poprawny, ale kierować do niewłaściwego katalogu.
Przykład: WordPress został przeniesiony do:
/public_html/ale vhost nadal wskazuje inny document root albo aplikacja faktycznie znajduje się w podkatalogu. Wtedy reguła może przekazywać żądania do innego index.php niż oczekiwany.
Przy migracji sprawdź więc razem:
- document root domeny,
- faktyczne położenie
index.php, - miejsce, w którym działa rewrite,
WP_HOMEiWP_SITEURL, jeśli zostały ustawione ręcznie.
Jeżeli WordPress celowo znajduje się w osobnym katalogu, konfiguracja może być poprawnie bardziej złożona. Nie należy automatycznie przenosić plików tylko dlatego, że document root i katalog rdzenia nie są identyczne.
Jeżeli 404 dotyczy tylko jednego URL-a, nie zaczynaj od rewrite całej witryny
Gdy większość permalinków działa, a 404 pojawia się tylko dla jednej strony, problem globalnych reguł rewrite jest mniej prawdopodobny.
Sprawdź wtedy przede wszystkim:
- czy treść nadal jest opublikowana,
- czy jej slug jest dokładnie taki, jak w otwieranym URL-u,
- czy nie zmieniono struktury adresu,
- czy nie istnieje konflikt z innym typem treści albo taksonomią,
- czy plugin nie przejmuje tego adresu,
- czy nie działa redirect prowadzący do nieistniejącego celu.
Po zmianie sluga stary URL może po prostu przestać istnieć. W takim przypadku właściwym rozwiązaniem może być przekierowanie ze starego adresu, a nie naprawa konfiguracji serwera.
404 z WordPressa i 404 z serwera to cenna różnica
Dwie strony błędu z kodem 404 mogą wyglądać podobnie, ale powstawać na różnych etapach.
Jeżeli widzisz normalny szablon 404 swojego WordPressa, żądanie najprawdopodobniej dotarło już do aplikacji, a WordPress nie znalazł odpowiadającej mu treści.
Jeżeli odpowiedź jest prostą stroną błędu Apache, NGINX albo hostingu, problem może występować wcześniej — zanim żądanie zostanie przekazane do WordPressa.
To nie jest reguła absolutna, bo hosting może mieć własne strony błędów albo proxy zmieniające odpowiedzi, ale jest bardzo użytecznym pierwszym rozróżnieniem.
Przy bardziej złożonej diagnozie pomocne są także logi. Zobacz jak czytać error_log i debug.log w WordPressie.
Bezpieczna procedura diagnozy podstron 404
- Sprawdź, czy homepage działa.
- Przetestuj kilka różnych podstron i wpisów.
- Ustal, czy problem jest globalny czy dotyczy jednego URL-a.
- Ponownie zapisz obecną strukturę permalinków.
- Na Apache sprawdź .htaccess i reguły rewrite.
- Ustal, czy NGINX działa samodzielnie, czy jako reverse proxy przed Apache.
- Na standalone NGINX sprawdź routing do index.php zamiast .htaccess.
- Po migracji potwierdź document root i faktyczne położenie WordPressa.
- Jeżeli 404 dotyczy jednego adresu, sprawdź slug, status treści i konflikty routingu.
- Po każdej zmianie testuj te same URL-e.
Jeżeli problem pojawił się bezpośrednio po zmianie hostingu, pomocna może być również diagnostyka domeny przed migracją, ale dopiero po potwierdzeniu, że sam DNS kieruje już ruch do właściwego serwera.
Najważniejsze wnioski
- homepage działająca przy 404 na podstronach często wskazuje problem z routingiem lub rewrite;
- ponowny zapis permalinków odświeża reguły WordPressa, ale nie konfiguruje routingu NGINX;
- na Apache WordPress może aktualizować swoją sekcję reguł w
.htaccess, jeśli plik jest zapisywalny; - Apache wymaga, aby odpowiednie dyrektywy rewrite były dozwolone w danym katalogu;
- standalone NGINX nie interpretuje
.htaccess, ale w układzie NGINX→Apache plik backendu nadal może mieć znaczenie; - po migracji trzeba sprawdzić nie tylko rewrite, ale również document root;
- pojedynczy URL 404 wymaga innej diagnozy niż awaria wszystkich permalinków;
- szablon 404 WordPressa może wskazywać, że request dotarł już do aplikacji;
- najbezpieczniejsza naprawa usuwa błąd routingu w warstwie, w której faktycznie powstał.
Źródła
- WordPress Developer Resources — Web server — konfiguracja serwerów dla WordPressa.
- WordPress Developer Resources — Apache HTTPD — WordPress i konfiguracja Apache.
- WordPress Developer Resources — Nginx — standalone NGINX oraz układy proxy przed Apache.
- WordPress Developer Resources — flush_rewrite_rules() — odświeżanie reguł rewrite.
- WordPress Developer Resources — WP_Rewrite::flush_rules() — hard flush i zapis reguł do plików konfiguracyjnych tam, gdzie WordPress to obsługuje.
- WordPress Developer Resources — WP_Rewrite — mechanizm permalinków i rewrite WordPressa.
- Apache HTTP Server — URL Rewriting Guide — mod_rewrite i przetwarzanie adresów.
- Apache HTTP Server — AllowOverride — dopuszczanie klas dyrektyw, w tym FileInfo, w
.htaccess.