Wpisy WordPress zwracają błąd 404, ale strona główna działa

Jeśli strona główna ładuje się bez problemu, ale każdy pojedynczy wpis i strona zwracają błąd 404, to reguły przepisywania adresów URL, na których opiera się WordPress, są niekompletne lub uszkodzone w Twoim pliku .htaccess. Najszybsze rozwiązanie: wejdź w Ustawienia → Bezpośrednie odnośniki w wp-admin i kliknij Zapisz zmiany bez wprowadzania żadnych zmian. To zmusza WordPress do ponownego wygenerowania bloku reguł przepisywania. Jeśli błędy 404 nadal się pojawiają, oznacza to, że Twój plik .htaccess nie jest zapisywalny dla serwera WWW, Apache jest skonfigurowany tak, by go ignorować, albo używasz Nginx (który w ogóle nie korzysta z .htaccess).

Dlaczego strona główna działa, a wpisy nie

Strona główna działa, ponieważ żądanie do / jest obsługiwane bezpośrednio przez index.php w katalogu głównym. Żadne przepisywanie nie jest tu potrzebne.

Żądanie do /2026/moj-wpis/ to co innego. Ta ścieżka nie jest prawdziwym folderem na dysku. Aby WordPress mógł na nią odpowiedzieć, Apache musi wewnętrznie przekierować żądanie do index.php, a WordPress następnie odczytuje REQUEST_URI, porównuje je z regułami przepisywania zapisanymi w opcji rewrite_rules w bazie danych, ustala zmienne zapytania (WP::parse_request()) i ładuje właściwy wpis.

To właśnie przekazanie żądania z Apache do index.php jest tym elementem, który się psuje. Zależy on całkowicie od tego bloku w .htaccess:

# 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

Dwie linie RewriteCond mówią: jeśli żądana ścieżka nie jest prawdziwym plikiem (!-f) ani prawdziwym katalogiem (!-d), przekaż ją do index.php. Usuń ten blok, a Apache będzie szukał dosłownego katalogu /2026/moj-wpis/, nie znajdzie go i zwróci własny błąd 404 — zanim WordPress w ogóle zobaczy żądanie.

Dlaczego WordPress nadpisuje .htaccess przy zapisywaniu bezpośrednich odnośników

To ta część, którą większość poradników pomija. Gdy klikasz Zapisz na ekranie Bezpośrednich odnośników, WordPress wywołuje flush_rewrite_rules(). Na serwerze Apache z zapisywalnym plikiem .htaccess uruchamia to save_mod_rewrite_rules(), które ponownie generuje powyższy blok za pomocą WP_Rewrite::mod_rewrite_rules() i zapisuje go z powrotem przy użyciu insert_with_markers().

insert_with_markers() modyfikuje tylko linie pomiędzy # BEGIN WordPress a # END WordPress. Wszystko poza tymi znacznikami pozostaje nietknięte. Wszystko wewnątrz jest usuwane i zapisywane od nowa. Nowsze wersje WordPressa wypisują nawet ostrzeżenie bezpośrednio w pliku:

Any changes to the directives between these markers will be overwritten.

Zatem stwierdzenie „WordPress nadpisuje mój .htaccess” jest prawdziwe, ale w wąskim zakresie: przepisuje tylko swój własny oznaczony blok i tylko wtedy, gdy plik jest zapisywalny. Jeśli plik nie jest zapisywalny, zapis po cichu nic nie zmienia na dysku. WordPress wyświetla żółty komunikat na ekranie Bezpośrednich odnośników z prośbą o ręczne wklejenie reguł, a jeśli go przeoczysz, Twój blok reguł przepisywania pozostaje niekompletny i każdy wpis nadal zwraca błąd 404.

Jak to naprawić, krok po kroku

1. Zapisz ponownie bezpośrednie odnośniki. Ustawienia → Bezpośrednie odnośniki → Zapisz zmiany. Żadne edycje nie są potrzebne. To ponownie uruchamia odświeżenie i przepisuje blok. Rozwiązuje większość przypadków, w tym nieaktualne reguły po migracji.

2. Sprawdź, czy plik .htaccess istnieje i jest zapisywalny. Znajduje się w tym samym folderze co wp-config.php. To plik ukryty (dotfile), więc włącz „pokaż ukryte pliki” w kliencie FTP albo użyj:

ls -la /path/to/wordpress/.htaccess

Jeśli go brakuje, utwórz go i wklej poprawny blok. Jeśli Twoja instalacja znajduje się w podkatalogu, RewriteBase oraz docelowa ścieżka końcowej reguły przepisywania muszą odpowiadać tej ścieżce — pomyłka w tym miejscu to najczęstszy powód, dla którego ręcznie wklejony blok nadal zwraca 404. Nasz generator .htaccess buduje dokładny blok dla Twojej ścieżki instalacji, więc nie musisz zgadywać.

3. Upewnij się, że Apache ma pozwolenie na odczyt .htaccess. Jeśli host wirtualny ma AllowOverride None, Apache całkowicie ignoruje ten plik, niezależnie od jego zawartości. Potrzebujesz AllowOverride All (albo przynajmniej FileInfo) dla katalogu WordPressa. To ustawienie znajduje się w konfiguracji serwera, a nie w .htaccess, więc wymaga dostępu do serwera:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Upewnij się, że mod_rewrite jest włączony. W Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. W Nginx nie ma pliku .htaccess. Reguły przepisywania trafiają zamiast tego do bloku serwera:

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

Szybka diagnostyka: czyj to błąd 404?

Przyjrzyj się stronie błędu 404. Jeśli jest to niestylizowana strona błędu Apache lub hostingu, to znaczy, że Apache nigdy nie dotarł do WordPressa — to problem z .htaccess lub konfiguracją serwera (kroki 2–4). Jeśli jest to stylizowana strona 404 Twojego szablonu, to WordPress otrzymuje żądanie, ale nie potrafi go dopasować — reguły w bazie danych są nieaktualne, a rozwiązaniem jest ponowne zapisanie bezpośrednich odnośników (krok 1). To jedno rozróżnienie oszczędza większości ludzi godzinę zgadywania.

Czego nie robić

Nie zaczynaj od dezaktywacji wszystkich wtyczek. Czysty objaw „wpisy zwracają 404, strona główna działa” to problem z regułami przepisywania, a nie konflikt wtyczek. Wyłączanie wtyczek to odruchowa odpowiedź na forach i prawie nigdy nie ma to związku z tym problemem.

Nie ustawiaj chmod 777 na pliku .htaccess. WordPress potrzebuje, aby plik był zapisywalny przez użytkownika serwera WWW, co nie jest tym samym co zapisywalny dla wszystkich. 644 z poprawnym właścicielem jest w porządku i bezpieczne; 777 to luka w zabezpieczeniach, która i tak nie naprawi routingu.

Nie wklejaj własnych reguł przepisywania pomiędzy znaczniki # BEGIN WordPress / # END WordPress. Zostaną usunięte przy następnym zapisaniu bezpośrednich odnośników przez kogokolwiek. Umieszczaj własne dyrektywy powyżej linii # BEGIN WordPress.

Nie instaluj WordPressa od nowa. Pliki rdzenia są w porządku. To jeden brakujący blok tekstu, a nie uszkodzona instalacja.

Nie obwiniaj szablonu. Routing bezpośrednich odnośników należy do rdzenia WordPressa. Szablon nie może go zepsuć ani naprawić.

Nadal utknąłeś?

Jeśli ponownie zapisałeś bezpośrednie odnośniki, potwierdziłeś, że blok jest obecny i zapisywalny oraz ustawiłeś AllowOverride All, to pozostaje jeden podejrzany: wtyczka zabezpieczająca lub reguła na poziomie hostingu, która regeneruje lub blokuje .htaccess za Twoimi plecami. Sprawdź znacznik czasu modyfikacji pliku tuż po zapisaniu bezpośrednich odnośników — jeśli się nie zmienił, coś blokuje zapis. Wygeneruj czysty blok za pomocą generatora .htaccess, wklej go i przetestuj ponownie z wymuszonym odświeżeniem.