Wchodzą Państwo na stronę, klikają link do świeżego artykułu, a zamiast tekstu widnieje biała strona z komunikatem „404 Page Not Found". Znajomy widok.

Bezpośrednie odnośniki WordPress są skonstruowane prosto, ale psują się z przerażającą łatwością. Jedna wadliwa wtyczka, nieudana aktualizacja lub przypadkowa zmiana .htaccess i cała witryna zamienia się w kolekcję uszkodzonych adresów URL. Według danych z oficjalnego forum wsparcia WordPress błędy struktury bezpośrednich odnośników należą do pięciu najczęstszych zgłoszeń.

Poniżej znajduje się algorytm diagnostyki i naprawy: od szybkiego resetowania ustawień po ręczną edycję konfiguracji serwera. Każdy krok został sprawdzony na rzeczywistych witrynach. Proszę odwołać panikę.

💡 Szybki przegląd:

• Proszę zresetować ustawienia bezpośrednich odnośników w panelu administracyjnym jednym kliknięciem; w przypadku większości witryn problem znika natychmiast
• Jeśli reset nie przyniósł rezultatu, proszę zmienić nazwę pliku .htaccess i zresetować ustawienia ponownie: WordPress utworzy czysty plik z poprawnymi regułami rewrite
• Proszę sprawdzić wtyczki metodą eliminacji: dezaktywować wszystkie razem i włączać pojedynczo po każdym resecie odnośników
• Na serwerze Apache proszę ręcznie włączyć mod_rewrite i dodać AllowOverride All w konfiguracji wirtualnego hosta

Dlaczego bezpośrednie odnośniki WordPress przestają działać

Bezpośredni odnośnik to niezmienny adres URL wpisu, strony lub kategorii. WordPress przechowuje strukturę bezpośrednich odnośników w bazie danych i udostępnia „ładne" adresy URL za pośrednictwem modułu mod_rewrite serwera Apache. Przerwa w dowolnym ogniwie tego łańcucha skutkuje błędem 404.

Instalacja nowej wtyczki. Niektóre wtyczki ingerują w mechanizm tworzenia adresów URL: nadpisują .htaccess, dodają własne reguły przekierowań lub wchodzą w konflikt z już aktywnymi rozszerzeniami. Wtyczki SEO, rozwiązania do cachowania i wtyczki bezpieczeństwa znajdują się w strefie szczególnego ryzyka, ponieważ wszystkie one pracują z adresami URL na niskim poziomie.

Aktualizacja rdzenia, motywu lub wtyczek. Duża aktualizacja WordPress lub zmiana wersji PHP na hostingu sprawiają, że stare wtyczki stają się niekompatybilne. Rezultatem jest konflikt, który niszczy reguły rewrite. Nie można pomijać aktualizacji bezpieczeństwa, ale przed każdą dużą aktualizacją należy wykonać kopię zapasową i sprawdzić kompatybilność na kopii stagingowej.

Przeniesienie witryny na nową domenę lub serwer. Migracja WordPress to jedna z najczęstszych przyczyn uszkodzonych odnośników. Zmieniają się ścieżki bezwzględne, dane zserializowane w bazie danych oraz ustawienia serwera. Nawet dodanie certyfikatu SSL po przenosinach może zepsuć bezpośrednie odnośniki, ponieważ wymaga poprawek w .htaccess dla przekierowania HTTP→HTTPS. Jeśli niedawno przenosili Państwo instalację WordPress do podkatalogu, proszę sprawdzić strukturę bezpośrednich odnośników natychmiast po migracji.

Przywracanie kopii zapasowej. Przywrócenie witryny z kopii zapasowej czasami wskrzesza również stare problemy. Jeśli kopia zapasowa została wykonana przed skonfigurowaniem bezpośrednich odnośników, błędy 404 powracają. Nawet zaawansowane wtyczki do tworzenia kopii zapasowych nie gwarantują idealnego przywrócenia reguł rewrite po skomplikowanych migracjach.

Uszkodzenie pliku .htaccess. Plik .htaccess jest łącznikiem między WordPress a Apache. Przechowuje dyrektywy mod_rewrite odpowiedzialne za „ładne" adresy URL. Wtyczka dopisuje śmieci, przypadkowo usuwają Państwo plik przez FTP, a niektóre panele hostingowe resetują go podczas zmiany ustawień. Bez działającego .htaccess bezpośrednie odnośniki zamieniają się w ?p=123.

Jak naprawić niedziałające bezpośrednie odnośniki: instrukcja krok po kroku

Przyczyny zostały omówione, przechodzimy do rozwiązań. Proszę postępować po kolei: każdy kolejny krok należy stosować tylko wtedy, gdy poprzedni nie zadziałał.

Krok 1. Zresetować ustawienia bezpośrednich odnośników

Najszybszy i najbezpieczniejszy sposób. WordPress przechowuje strukturę bezpośrednich odnośników w bazie danych, a podczas zapisywania ustawień ponownie generuje reguły rewrite. Ten proces deweloperzy nazywają „flush rewrite rules".

Proszę zalogować się do panelu administracyjnego, przejść do Ustawienia → Bezpośrednie odnośniki:

Proszę tymczasowo przełączyć się na dowolną inną strukturę, na przykład „Zwykły" zamiast „Nazwa wpisu", i kliknąć Zapisz zmiany. Następnie proszę przywrócić pierwotny wariant i zapisać ponownie. Nie ma potrzeby zmieniać ustawień na stałe: istotny jest sam fakt zapisania, który zmusza WordPress do przebudowania reguł.

Proszę ponownie załadować witrynę i sprawdzić, czy wpisy się otwierają. Zadziałało? Problem rozwiązany. Jeśli nie, przechodzimy dalej.

Krok 2. Sprawdzić i ponownie utworzyć plik.htaccess

Jeśli reset nie pomógł, źródło problemu prawie na pewno leży w .htaccess. Plik znajduje się w katalogu głównym witryny, w tym samym miejscu co wp-config.php oraz foldery wp-content, wp-includes.

Proszę połączyć się z serwerem przez FTP (FileZilla, WinSCP) lub menedżer plików w panelu hostingowym:

Znajdź .htaccess, kliknij prawym przyciskiem myszy i zmień nazwę na .htaccess_old. Nie usuwaj pliku, w środku mogą znajdować się krytyczne reguły, takie jak przekierowanie HTTP→HTTPS lub ustawienia kompresji:

Po zmianie nazwy WordPress przestaje widzieć stary plik. Proszę wejść do panelu administracyjnego i zresetować bezpośrednie odnośniki, tak jak w Kroku 1, system utworzy nowy, czysty .htaccess z poprawnymi regułami rewrite. Stary plik proszę pozostawić jako kopię zapasową.

Krok 3. Znaleźć konfliktową wtyczkę

Problem pojawił się po zainstalowaniu konkretnej wtyczki? Proszę ją dezaktywować i ponownie zresetować bezpośrednie odnośniki, najprawdopodobniej to wystarczy.

Gdy winowajca jest nieznany, proszę działać metodą eliminacji:

Proszę dezaktywować wszystkie wtyczki jednocześnie. Zresetować bezpośrednie odnośniki. Sprawdzić witrynę: jeśli zadziałała, problem tkwi w jednej z wtyczek. Proszę włączać je pojedynczo, po każdej resetując ustawienia i sprawdzając witrynę. Wtyczka, po której aktywacji odnośniki znów się psują, jest przyczyną.

Znalezioną konfliktową wtyczkę proszę zastąpić alternatywą z katalogu WordPress.org. O problemie proszę powiadomić dewelopera: często wiedzą oni o niekompatybilności i mogą podpowiedzieć obejście.

Krok 4. Skonfigurować serwer: AllowOverride oraz mod_rewrite

Poprzednie kroki nie pomogły, a korzystają Państwo z Apache, problem może leżeć w ustawieniach wirtualnego hosta.

Najpierw proszę się upewnić, że moduł mod_rewrite jest włączony. To on przekształca „ładne" adresy URL na zrozumiałe dla WordPressa zapytania. Proszę sprawdzić i aktywować go komendą:

1
sudo a2enmod rewrite

Jeśli moduł był już włączony, pojawi się ostrzeżenie, to normalne. Teraz proszę zrestartować Apache:

1
sudo systemctl restart apache2

Na CentOS/RHEL komenda restartu różni się:

1
sudo systemctl restart httpd

Drugi obowiązkowy komponent, dyrektywa AllowOverride All. Pozwala ona plikowi .htaccess nadpisywać konfigurację serwera w obrębie katalogu witryny. Proszę otworzyć plik konfiguracyjny Apache: na Ubuntu jest to /etc/apache2/sites-available/ваш-сайт.conf, na CentOS, /etc/httpd/conf/httpd.conf. Proszę znaleźć sekcję <Directory> i doprowadzić ją do następującej postaci:

1
<Directory /var/www/ваш-сайт/>
2
    AllowOverride All
3
</Directory>

Ścieżkę /var/www/ваш-сайт/ proszę zastąpić rzeczywistą ścieżką do folderu głównego WordPress na Państwa serwerze. Po poprawce proszę zrestartować Apache powyższą komendą, a następnie zresetować bezpośrednie odnośniki w panelu administracyjnym.

Te dwie czynności serwerowe, AllowOverride All plus mod_rewrite, zamykają praktycznie wszystkie pozostałe scenariusze awarii bezpośrednich odnośników na Apache.

Wideo: krok po kroku przywracanie bezpośrednich odnośników

Jeśli wygodniej jest Państwu oglądać niż czytać, oto krótki poradnik pokazujący cały proces od resetowania ustawień permalinków do przywracania .htaccess na rzeczywistej witrynie:

⁉️🤔 Często zadawane pytania

Dlaczego po zresetowaniu bezpośrednich odnośników błąd 404 nadal występuje?

Resetowanie przez panel administracyjny nadpisuje reguły rewrite w bazie danych. Jeśli jednak plik .htaccess jest fizycznie niedostępny do zapisu lub ma nieprawidłowe uprawnienia, WordPress nie zaktualizuje go na serwerze. Proszę sprawdzić uprawnienia: zazwyczaj wymagane jest 755 dla katalogów i 644 dla plików. Proszę również upewnić się, że .htaccess istnieje fizycznie: po zmianie nazwy w Kroku 2 WordPress tworzy nowy podczas następnego resetowania. Samo resetowanie nie zmienia adresów URL istniejących wpisów i nie psuje indeksowania.

Czy można po prostu usunąć.htaccess?

Nie. Bez .htaccess na serwerze Apache WordPress wraca do „prostych" odnośników w postaci ?p=123, co jest nieestetyczne i szkodzi SEO. Prawidłowa kolejność: zmienić nazwę starego pliku, zachowując kopię zapasową, a następnie zresetować ustawienia bezpośrednich odnośników w panelu administracyjnym. WordPress utworzy nowy .htaccess automatycznie. Nigdy nie należy usuwać pliku bez możliwości przywrócenia: mogą się w nim znajdować krytyczne reguły przekierowań HTTP→HTTPS lub ustawienia kompresji.

Co zrobić, jeśli strona działa na Nginx?

Na Nginx nie ma pliku .htaccess, wszystkie reguły rewrite są zapisywane w konfiguracji serwera. Standardowy blok dla WordPressa: location / { try_files $uri $uri/ /index.php?$args; }. Proszę sprawdzić plik konfiguracyjny strony (zazwyczaj /etc/nginx/sites-available/ваш-сайт), dodać ten blok do sekcji server i przeładować Nginx: sudo systemctl reload nginx. Kroki 1 i 3, resetowanie odnośników i sprawdzanie wtyczek, działają dla Nginx tak samo jak dla Apache.

Która wtyczka najczęściej psuje bezpośrednie odnośniki?

Statystycznie prowadzą wtyczki SEO, które bezpośrednio manipulują adresami URL, oraz rozwiązania do cache'owania: tworzą one statyczne kopie stron i mogą „zapamiętać" uszkodzoną wersję. Na trzecim miejscu są wtyczki bezpieczeństwa, które modyfikują .htaccess w celu blokowania podejrzanych żądań. Po wyłączeniu wtyczki cache'owania należy koniecznie wyczyścić pamięć podręczną przeglądarki lub otworzyć stronę w trybie incognito, ponieważ statyczna, zcache'owana wersja z 404 może być wyświetlana nawet po naprawieniu problemu.

Czy trzeba sprawdzać integralność bazy danych?

W rzadkich przypadkach przyczyną jest uszkodzona tabela wp_options, w której przechowywane są ustawienia bezpośrednich odnośników. Jeśli żadna z opisanych metod nie pomogła, proszę zalogować się do phpMyAdmin, znaleźć tabelę wp_options i sprawdzić wpis z option_name = 'rewrite_rules'. Jeśli wartość wygląda jak śmieci lub uszkodzony zserializowany obiekt, proszę usunąć ten wpis, a następnie zresetować ustawienia bezpośrednich odnośników w panelu administracyjnym. WordPress odtworzy reguły rewrite od nowa. Większość użytkowników nie będzie potrzebować tego kroku: przeważająca większość problemów jest rozwiązywana metodami 1-3.

Co zrobić, jeśli nic nie pomogło

Przeszliśmy drogę od prostego resetowania ustawień do konfiguracji serwerowej Apache i Nginx. W przypadku zdecydowanej większości stron jeden z tych metod rozwiązuje problem.

Jeśli błędy 404 nadal występują, proszę skontaktować się z pomocą techniczną hostingu. Proszę opisać problem i wymienić kroki, które już Państwo wykonali. Często przyczyna leży w specyfice środowiska hostingowego: wyłączony mod_rewrite na poziomie dostawcy, niestandardowa konfiguracja PHP-FPM lub niestandardowe reguły firewalla blokujące żądania do index.php. Dział wsparcia hostingu widzi część serwerową, która jest przed Państwem ukryta, i rozwiązuje takie problemy w ciągu minut.

Główna zasada, którą warto zapamiętać: resetowanie bezpośrednich odnośników → zmiana nazwy.htaccess → ponowne resetowanie. Ta dwuetapowa sekwencja naprawia większość przypadków i nie wymaga ani specjalistycznej wiedzy, ani dostępu do serwera. Proszę zacząć od niej następnym razem, a najprawdopodobniej dalsze kroki nie będą potrzebne.