Plik .htaccess może zatrzymać część niepożądanych żądań jeszcze przed uruchomieniem WordPressa, ale jedna literówka potrafi wywołać błąd 500 i wyłączyć całą stronę. Dlatego przed każdą zmianą wykonaj kopię pliku i zapewnij sobie dostęp przez FTP lub Menedżer plików.
Strona nie działa po edycji .htaccess – co zrobić?
Jeżeli po zapisaniu zmian widzisz komunikat „500 Internal Server Error”, biały ekran albo strona przestała odpowiadać, nie próbuj od razu zmieniać kolejnych reguł. Najpierw odłącz uszkodzoną konfigurację.
Ostrzeżenie: zmiana nazwy pliku przywróci dostęp tylko wtedy, gdy przyczyną problemu jest .htaccess. Jeśli witryna nadal nie działa, błąd może dotyczyć PHP, wtyczki, uprawnień albo konfiguracji serwera.
Procedura awaryjna wygląda następująco:
- Połącz się z serwerem przez FTP lub otwórz Menedżer plików w panelu hostingu.
- Przejdź do głównego katalogu instalacji WordPressa, w którym znajduje się plik
.htaccess. - Zmień jego nazwę na
.htaccess_old. Nie usuwaj go, ponieważ może zawierać reguły potrzebne stronie. - Odśwież witrynę i sprawdź także panel administracyjny.
- Jeżeli strona zaczęła działać, przejrzyj uszkodzony plik i odtwórz konfigurację etapami albo wygeneruj nowy plik przez ustawienia bezpośrednich odnośników w WordPressie.
Gdy podejrzewasz wtyczkę bezpieczeństwa, możesz również tymczasowo zmienić nazwę jej katalogu w wp-content/plugins/. W przypadku Solid Security katalog może nosić nazwę better-wp-security. Zmiana nazwy, na przykład na better-wp-security_OFF, dezaktywuje wtyczkę bez dostępu do kokpitu.
Jak zabezpieczyć WordPress za pomocą .htaccess?
Plik .htaccess jest konfiguracją używaną przez serwer Apache. Działa przed uruchomieniem kodu WordPressa, więc może ograniczyć dostęp do wybranych katalogów lub plików. Poniższe reguły zapisuj ostrożnie, najlepiej w kopii roboczej, a po każdej zmianie wykonuj test.
Ograniczenie dostępu do wp-admin po adresie IP
Jeżeli panel administracyjny jest używany ze stałego adresu IP, możesz ograniczyć dostęp do katalogu /wp-admin. Utwórz w nim plik .htaccess z regułami dla Apache 2.4+:
Require all denied
Require ip 203.0.113.10Dyrektywa Require all denied blokuje dostęp wszystkim, a Require ip otwiera go dla wskazanego adresu. Zastąp 203.0.113.10 własnym adresem IP.
To rozwiązanie nie sprawdzi się dobrze przy zmiennym adresie IP. Po jego zmianie możesz zablokować również własny dostęp. W takim przypadku trzeba aktualizować regułę albo zastosować dodatkową autoryzację.
Podwójna autoryzacja przez .htpasswd
Basic Authentication dodaje drugie okno logowania przed właściwym logowaniem WordPressa. Dane tej autoryzacji przechowuje plik .htpasswd, w którym hasło nie powinno być zapisane w formie jawnej. Plik utwórz poza publicznie dostępnym katalogiem, jeśli hosting na to pozwala.
Przykładowa konfiguracja w /wp-admin/.htaccess:
AuthType Basic
AuthName "Panel administracyjny"
AuthUserFile /home/uzytkownik/.htpasswd
Require valid-userAuthType Basic włącza autoryzację Basic, AuthName określa komunikat okna logowania, AuthUserFile wskazuje pełną ścieżkę do pliku z użytkownikami, a Require valid-user dopuszcza osoby znajdujące się w tym pliku.
Ścieżka w AuthUserFile zależy od hostingu. Nie kopiuj jej bez sprawdzenia. Hasło do .htpasswd wygeneruj narzędziem dostarczonym przez hosting lub poleceniem htpasswd na serwerze.
Blokada XML-RPC
Jeżeli nie korzystasz z aplikacji lub integracji wymagających xmlrpc.php, możesz zablokować dostęp do tego pliku:
<Files "xmlrpc.php">
Require all denied
</Files>Znacznik Files wybiera plik xmlrpc.php, a Require all denied odrzuca wszystkie żądania. XML-RPC bywa wykorzystywany do prób uwierzytelniania typu Brute Force, ale jego blokada może przerwać działanie niektórych integracji. Po wdrożeniu sprawdź funkcje zewnętrzne, aplikacje mobilne i systemy publikacji.
| Metoda | Zastosowanie | Poziom ochrony |
|---|---|---|
| Ograniczenie IP | Panel dostępny tylko z określonej sieci lub adresu | Wysoki przy stałym IP |
| BasicAuth i .htpasswd | Dodatkowe logowanie przed wp-admin | Wysoki |
| Blokada XML-RPC | Ograniczenie nieużywanego punktu dostępu | Uzupełniający |
Jak zarządzać .htaccess bez ryzyka awarii?
Ręczna edycja daje pełną kontrolę, ale wymaga znajomości ścieżek, składni i sposobu odzyskania dostępu. Wtyczki bezpieczeństwa, takie jak Solid Security, mogą automatycznie dopisywać reguły do .htaccess. Jest to wygodne, lecz kilka funkcji zapisujących pliki jednocześnie może prowadzić do konfliktów. Problem może pojawić się także po przerwaniu zapisu przez niski PHP Time Limit lub chwilowe przeciążenie serwera.
Przed wdrożeniem zmian trzymaj się kilku zasad:
- Wykonuj kopię pliku .htaccess i całej strony przed zmianami.
- Włączaj reguły pojedynczo, aby łatwo ustalić przyczynę błędu.
- Testuj w trybie incognito, ponieważ aktywna sesja administratora może ukryć problem.
- Ogranicz automatyczny zapis wtyczek, gdy hosting niestabilnie obsługuje modyfikacje plików.
- Sprawdzaj logi serwera, gdy pojawi się błąd 500 lub 403.
Nie każdy serwer korzysta z Apache. Nginx nie obsługuje pliku .htaccess, więc przedstawione reguły nie zadziałają w takim środowisku. W razie wątpliwości sprawdź typ serwera u dostawcy hostingu.
Kontrola po zmianach
Przed uznaniem konfiguracji za zakończoną sprawdź następujące punkty:
- Kopia zapasowa pliku i możliwość połączenia przez FTP lub Menedżer plików.
- Działanie strony głównej oraz panelu wp-admin w oknie incognito.
- Logowanie z dozwolonego adresu IP i odrzucanie połączeń z innych adresów, jeśli używasz blokady IP.
- Działanie integracji zależnych od XML-RPC, jeśli plik został zablokowany.
- Logi serwera po zapisaniu zmian.
Jeśli po zmianie nazwy .htaccess na .htaccess_old strona nadal zwraca błąd, nie przywracaj w ciemno kolejnych reguł. Sprawdź logi hostingu lub skontaktuj się z administratorem serwera, ponieważ przyczyna może leżeć poza tym plikiem.
