.htaccess jest plikiem konfiguracji używanym przez Apache i zgodne serwery. WordPress wykorzystuje go m.in. do „ładnych” permalinków. Może też zawierać przekierowania, blokady dostępu i reguły bezpieczeństwa. Na Nginx ten plik nie jest interpretowany, dlatego kopiowanie porad .htaccess na serwer Nginx nie daje efektu — reguły muszą trafić do konfiguracji vhosta.
Szybka odpowiedź
Jeśli po edycji .htaccess strona zaczęła zwracać 500, przywróć kopię pliku i sprawdź error log Apache. Jeśli problemem są 404 na podstronach, wygeneruj standardowe reguły WordPressa przez zapis ustawień permalinków lub porównaj blok BEGIN WordPress z prawidłową konfiguracją. Własne reguły trzymaj poza blokiem, który WordPress może nadpisywać.
Co WordPress zapisuje w .htaccess
Na typowej instalacji Apache WordPress utrzymuje reguły rewrite kierujące żądania do index.php, gdy nie odpowiadają istniejącym plikom lub katalogom. Dzięki temu /oferta/ może być obsłużona przez aplikację mimo braku fizycznego katalogu oferta. Usunięcie tych reguł często daje 404 na wszystkich podstronach poza stroną główną.
Dlaczego błędna dyrektywa daje 500
Apache czyta .htaccess podczas obsługi żądania. Literówka, niedozwolona dyrektywa albo moduł, którego serwer nie obsługuje, może przerwać przetwarzanie i zwrócić 500. Error log zwykle podaje nazwę problematycznej dyrektywy oraz plik. To kolejny przypadek, w którym log jest szybszy niż eksperymenty.
Własne reguły poza blokiem WordPressa
WordPress oznacza swój fragment komentarzami # BEGIN WordPress i # END WordPress. Kod wewnątrz może zostać odtworzony przy zmianie permalinków. Jeśli dodajesz trwałe zabezpieczenie albo redirect, umieść je świadomie poza automatycznie zarządzanym fragmentem i trzymaj konfigurację w kopii lub repozytorium.
Wtyczki potrafią modyfikować .htaccess
Cache, bezpieczeństwo i przekierowania mogą dopisywać własne sekcje. Przy kilku narzędziach plik robi się trudny do utrzymania. Zamiast kolejnej reguły sprawdź, czy dana funkcja nie jest już realizowana na CDN lub serwerze. Dublowanie kompresji, redirectów i blokad zwiększa ryzyko konfliktu.
Na Nginx szukaj gdzie indziej
Nginx nie używa .htaccess. Reguły są zwykle zapisane w centralnej konfiguracji serwera. Jeśli poradnik mówi „dodaj do .htaccess”, a Twoja strona stoi na Nginx, przepisanie tekstu 1:1 nie zadziała. Trzeba przetłumaczyć intencję reguły na składnię i model Nginx.
Jak potwierdzić, że naprawa naprawdę działa?
Po zmianie .htaccess przetestuj bezpośrednio stronę główną, podstronę, plik statyczny, wp-admin i co najmniej jedno przekierowanie. Następnie zapisz ustawienia permalinków w panelu i sprawdź, czy własne reguły nadal istnieją. Jeśli zniknęły, były umieszczone w bloku, którym zarządza WordPress. To dobry test na przyszłą odporność konfiguracji.
Co obserwować po zmianie?
Przejrzyj error log Apache po kilku minutach normalnego ruchu. Nawet jeśli 500 zniknął, warningi o niedozwolonych dyrektywach lub pętlach rewrite mogą wskazywać na problem, który ujawni się dla innych URL-i. W Nginx analogiczne zmiany trzymaj w plikach konfiguracyjnych i zawsze testuj składnię przed reloadem.
Kiedy przekazać temat dalej?
Eskaluj, gdy .htaccess zawiera rozbudowane reguły security/cache/redirectów z kilku wtyczek i nikt nie wie, które są aktualne. Wtedy lepiej uporządkować odpowiedzialność między serwerem i WordPressem niż dokładać następny warunek na końcu pliku.
Praktyczny scenariusz diagnostyczny
Jeżeli po edycji .htaccess cała strona zwraca 500, pierwszym krokiem jest przywrócenie ostatniej znanej dobrej wersji, a nie dopisywanie kolejnych reguł. Następnie wprowadzaj zmianę pojedynczo i sprawdzaj składnię. W WordPressie typowym obszarem jest blok rewrite dla „ładnych” permalinków, ale w tym samym pliku bywają też reguły cache, bezpieczeństwa i przekierowań. Kolejność ma znaczenie. Na Nginx plik .htaccess w ogóle nie steruje serwerem, więc poradnik polecający edycję tego pliku może być całkowicie nietrafiony. Zawsze zacznij od ustalenia, jaki serwer WWW faktycznie obsługuje domenę. Dopiero potem decyduj, czy zmiana należy do .htaccess, konfiguracji vhostu, CDN czy samego WordPressa.
Bezpieczna kolejność działań
- Zrób kopię aktualnego
.htaccess. - Sprawdź typ serwera WWW: Apache czy Nginx.
- Przy 500 zajrzyj do error logu przed dalszą edycją.
- Przy 404 zweryfikuj standardowy blok rewrite WordPressa.
- Przenieś własne trwałe reguły poza blok zarządzany przez WordPress.
- Po zmianie przetestuj stronę główną, podstrony, wp-admin i redirecty.
Czego nie robić
Nie wklejaj kilkudziesięciu „optymalizacyjnych” reguł z przypadkowego poradnika bez sprawdzenia modułów serwera. Nie ustawiaj zabezpieczeń, których później nikt nie potrafi zidentyfikować podczas awarii.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli .htaccess rozrósł się przez lata i powoduje konflikty, możemy uporządkować reguły, przenieść odpowiednie zabezpieczenia na serwer i zostawić WordPressowi tylko to, czego naprawdę potrzebuje.
Źródła techniczne
Najczęściej zadawane pytania
Czy WordPress potrzebuje .htaccess na Nginx?
Nie. Nginx nie interpretuje tego pliku; odpowiednie reguły muszą być w konfiguracji serwera.
Czy można usunąć .htaccess?
Na Apache może to zepsuć permalinki i inne reguły. Lepiej zachować kopię i odtworzyć standardowy blok WordPressa.
Czy WordPress nadpisuje cały plik?
Zwykle zarządza blokiem pomiędzy znacznikami BEGIN/END WordPress. Własne reguły warto umieszczać poza nim.
Czy .htaccess może powodować 403?
Tak. Reguły dostępu mogą zabraniać wejścia do określonych ścieżek lub plików.