Jak naprawić nieprawidłowe działanie rewrite rules w WordPress

Wprowadzenie do problemu z regułami rewrite

Rewrite rules w WordPress pozwalają dopasować czytelny adres, np. /moja-strona/, do zapytania obsługiwanego przez WordPress. Serwer musi najpierw przekazać odpowiednie żądanie do aplikacji. Przepisywanie adresu nie jest tym samym co przekierowanie przeglądarki na inny adres.

Jeśli strona główna działa, a wpisy zwracają 404, sprawdź obie warstwy: konfigurację serwera i reguły WordPressa. Ten sam objaw może mieć też inną przyczynę.

Przyczyny problemów z rewrite rules

• Nieaktualne reguły WordPressa po zmianie wtyczki, motywu lub rejestracji typu treści.
• Brak właściwego przekazania żądania do WordPressa w Apache albo Nginx.
• Konflikt reguł wtyczki, motywu lub konfiguracji serwera; znaczenie ma również kolejność dopasowania.
• Zmiana struktury adresów bez przekierowania starych URL-i albo nieistniejąca lub nieopublikowana treść.
• Cache serwera, wtyczki lub CDN pokazujący starszą odpowiedź.

Identyfikacja problemów z przekierowaniami

Zapisz przykładowy adres, kod odpowiedzi, godzinę testu i ostatnie zmiany. Sprawdź stronę główną, kilka istniejących wpisów i archiwum. Porównaj niedziałający adres z adresem otwartym przez panel edycji. Jeśli znasz ID opublikowanego wpisu, sprawdź także /?p=123, podstawiając właściwe ID. Działanie tego adresu przy błędzie wersji przyjaznej wskazuje na routing, ale nie określa jeszcze miejsca usterki.

Pętla przekierowań wymaga osobnego sprawdzenia: porównaj adresy WordPressa, HTTPS i reguły przekierowań na serwerze, w CDN oraz we wtyczkach. Nie zakładaj, że winny jest plik .htaccess.

Metody diagnozowania reguł rewrite

1. Ustal, czy żądanie obsługuje Apache, sam Nginx czy Nginx przed Apache. Na hostingu zapytaj administratora.
2. W narzędziach przeglądarki otwórz zakładkę Network i sprawdź kod odpowiedzi oraz kolejne nagłówki Location. Błąd 404 może pochodzić z serwera, CDN lub WordPressa.
3. Sprawdź logi właściwej domeny w czasie testu. Nie włączaj publicznego wyświetlania błędów ani nie umieszczaj na serwerze publicznego pliku z phpinfo().
4. Jeśli masz WP-CLI, użyj wp rewrite list w katalogu instalacji, aby obejrzeć reguły i ich kolejność. W Multisite wskaż właściwą witrynę przez --url=https://przyklad.pl/.
5. Sprawdź, czy problem dotyczy tylko jednego typu treści lub pojawił się po konkretnej aktualizacji. Wyczyść właściwe warstwy cache po zmianie i powtórz test.

Naprawa reguł rewrite w .htaccess

Ta sekcja dotyczy Apache, który faktycznie odczytuje .htaccess. Przed edycją wykonaj kopię pliku poza katalogiem dostępnym z sieci i sprawdź możliwość jej przywrócenia. Plik może zawierać reguły ochrony, przekierowania i ustawienia innych aplikacji: nie usuwaj go ani nie zmieniaj jego nazwy na działającej stronie tylko po to, by sprawdzić efekt.

Najpierw zapisz istniejące ustawienia bezpośrednich odnośników. Jeżeli WordPress nie może zapisać pliku, może pokazać reguły do ręcznego wprowadzenia. Porównaj blok między znacznikami # BEGIN WordPress i # END WordPress, pozostawiając pozostałe reguły. Poniżej przykład dla pojedynczej instalacji w katalogu głównym domeny, nie dla Multisite ani instalacji w podkatalogu:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Nie kopiuj przykładu w ciemno: położenie WordPressa, Multisite i reguły wtyczek mogą wymagać innej konfiguracji. Sprawdź właściciela i uprawnienia zgodnie z hostingiem; nie zmieniaj ich automatycznie na www-data ani nie nadaj szerokiego prawa zapisu. Jeśli po zmianie pojawi się błąd 500, przywróć kopię i sprawdź log domeny.

Regeneracja permalinków

W panelu wybierz Ustawienia → Bezpośrednie odnośniki i kliknij Zapisz zmiany, nie zmieniając struktury. Odświeża to reguły WordPressa; nie naprawi jednak brakującej konfiguracji Nginx ani błędnego adresu. Nie przełączaj struktury na „Prosty” i z powrotem tylko w celu regeneracji: taka zmiana może wpłynąć na publiczne adresy i cache.

Alternatywnie, po wykonaniu kopii i upewnieniu się, że załadowane są właściwe wtyczki i motyw, uruchom z katalogu instalacji jako uprawniony użytkownik:

wp rewrite flush

To domyślnie odświeżenie reguł w bazie, bez zapisu .htaccess. Opcja --hard ma dodatkowe wymagania dotyczące Apache i dotyczy pojedynczej instalacji; szczegóły podaje dokumentacja WP-CLI. W Multisite wskaż właściwą witrynę opcją --url. Nie usuwaj ręcznie opcji permalinków z bazy i nie uruchamiaj flush_rewrite_rules() przy każdym żądaniu — jest kosztowne.

Konfiguracja serwera (Apache/Nginx)

Apache

Administrator powinien sprawdzić moduł mod_rewrite, konfigurację właściwego virtual hosta i to, czy dyrektywa AllowOverride dopuszcza odczyt odpowiednich reguł z .htaccess. Na serwerze współdzielonym nie włączaj modułów ani nie restartuj usługi samodzielnie — zmiana może dotyczyć wielu domen.

Nginx

Samodzielny Nginx nie czyta .htaccess. Dla pojedynczego WordPressa w katalogu głównym typowy fragment konfiguracji lokalizacji wygląda tak:

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

To tylko fragment, nie kompletna konfiguracja PHP ani zabezpieczeń. Nie zastępuj nim istniejącego bloku bez analizy innych lokalizacji. Instalacja w podkatalogu lub Multisite wymaga dopasowania. Administrator powinien sprawdzić konfigurację właściwej domeny, wykonać test składni nginx -t i zastosować zmianę zgodnie z procedurą hostingu. W układzie Nginx jako proxy przed Apache sprawdź obie warstwy. Zobacz dokumentację WordPressa dla Nginx.

Rozwiązywanie konfliktów z wtyczkami

Najbezpieczniej odtworzyć problem na kopii testowej. Zacznij od wtyczki lub motywu zmienionego przed awarią. Wyłączaj podejrzane komponenty pojedynczo i po każdej zmianie sprawdzaj ten sam adres. Zapisz wynik oraz wcześniejszy stan, aby móc go przywrócić. Wyłączenie wtyczki sklepu, płatności lub zabezpieczeń na stronie produkcyjnej może przerwać jej działanie lub osłabić ochronę.

Jeśli problem dotyczy własnego typu treści albo reguły dodanej przez kod, sprawdź, czy kod rejestruje ją również podczas odświeżania permalinków oraz czy bardziej ogólna reguła nie przechwytuje adresu wcześniej. Po poprawce odśwież reguły jednorazowo. Dokumentacja opisuje add_rewrite_rule() i kolejność dopasowania.

Testowanie poprawności działania

• Sprawdź stronę główną, istniejący wpis, stronę, archiwum i adres, który wcześniej zwracał błąd.
• W Network sprawdź docelowy URL i kody odpowiedzi, także dla starych adresów po celowej zmianie struktury. Unikaj pętli i zbędnych łańcuchów przekierowań.
• Przetestuj ważne dla witryny adresy, np. wyszukiwanie, stronicowanie, REST API oraz koszyk i płatności — bez wykonywania rzeczywistych transakcji testowych na produkcji.
• Po wyczyszczeniu odpowiedniego cache sprawdź wynik ponownie i obserwuj logi domeny. Nie przesyłaj prywatnych reguł ani adresów z tokenami do publicznych testerów.

Zapobieganie problemom w przyszłości

Przed aktualizacją lub edycją konfiguracji zachowaj kopię plików i bazy oraz sprawdź procedurę przywracania. Dokumentuj niestandardowe reguły i ich kolejność, a zmiany testuj na kopii. Po zmianie adresów zaplanuj przekierowania starych URL-i i sprawdź je po wdrożeniu.

Podsumowanie

Zacznij od ustalenia, które adresy zawodzą i która warstwa zwraca błąd. Następnie zapisz istniejące permalinki, sprawdź konfigurację serwera i ewentualne konflikty. Nie zastępuj całego .htaccess ani konfiguracji serwera przykładem z poradnika.

Najczęstsze pytania o rewrite rules w WordPress

Jakie są objawy problemów z regułami rewrite w WordPress?

Typowy objaw to działająca strona główna i błędy 404 na istniejących podstronach. Sam błąd 404 nie przesądza jednak o przyczynie: treść może być niedostępna, a adres błędny.

Czy problemy z rewrite rules mogą wpłynąć na SEO?

Tak. Jeśli wyszukiwarka nie może dotrzeć do istniejących treści lub trafia na pętle przekierowań, może mieć problem z ich indeksowaniem. Sprawdź rzeczywiste adresy i kody odpowiedzi po naprawie.

Jak sprawdzić, czy mod_rewrite jest aktywny na Apache?

Administrator może sprawdzić listę modułów poleceniem apache2ctl -M. Na hostingu współdzielonym poproś o sprawdzenie dostawcę. Sam moduł nie wystarczy, jeśli konfiguracja nie pozwala na reguły w .htaccess.

Czy przyjazne adresy działają bez mod_rewrite?

Tak, na przykład na Nginx po odpowiedniej konfiguracji serwera. WordPress obsługuje też adresy z index.php, jeśli serwer obsługuje PATHINFO.

Czy zapisanie bezpośrednich odnośników zawsze odtworzy .htaccess?

Nie. Zapis odświeża reguły WordPressa, ale zapis pliku zależy między innymi od konfiguracji serwera i uprawnień. WordPress może zamiast tego wyświetlić reguły do ręcznego wprowadzenia.

Czy Nginx korzysta z .htaccess?

Nie. Samodzielny Nginx ignoruje .htaccess; odpowiednie reguły ustawia administrator w konfiguracji serwera. Jeśli Nginx działa jako proxy przed Apache, należy sprawdzić konfigurację obu warstw.