Jak poprawnie skonfigurować plik .htaccess w WordPress – bezpieczeństwo i wydajność 2025

Czym jest plik .htaccess i jak działa w WordPressie?

Plik .htaccess pozwala ustawić część konfiguracji Apache dla katalogu i jego podkatalogów. WordPress używa go przede wszystkim do obsługi przyjaznych adresów. Można w nim dodać także wybrane reguły dostępu, przekierowania czy ustawienia pamięci przeglądarki, o ile hosting na to pozwala.

Nginx nie czyta .htaccess. Jeżeli stoi przed Apache jako reverse proxy, Apache zastosuje reguły tylko do żądań, które do niego dotrą. Pliki obsługiwane bezpośrednio przez Nginx wymagają ustawień w Nginx. Nagłówek odpowiedzi Server nie wystarczy, by ustalić całą drogę żądania — sprawdź konfigurację hostingu.

Przykłady poniżej dotyczą Apache 2.4 i pojedynczej instalacji WordPressa w katalogu głównym domeny. To nie jest gotowa konfiguracja dla multisite ani instalacji w podkatalogu. Przed zmianą zrób kopię poza katalogiem publicznym i upewnij się, że możesz ją przywrócić przez SFTP lub panel hostingu.

Domyślna konfiguracja WordPressa

Typowy blok dla pojedynczej instalacji w katalogu głównym wygląda tak:

# 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

Jeśli żądanie nie wskazuje istniejącego pliku ani katalogu, Apache przekazuje je wewnętrznie do index.php. Reguła z HTTP_AUTHORIZATION przekazuje nagłówek autoryzacji do środowiska PHP. WordPress może nadpisać zawartość między znacznikami BEGIN i END; własne reguły umieszczaj poza tym blokiem. Nie zastępuj nim w ciemno reguł multisite, podkatalogu ani istniejących ustawień wtyczek.

Po migracji w panelu Ustawienia → Bezpośrednie odnośniki zapisz obecną strukturę bez jej zmiany. Jeśli plik nie jest zapisywalny, WordPress może wymagać ręcznego uzupełnienia reguł. Apache potrzebuje także mod_rewrite i odpowiednich ustawień AllowOverride; poproś hosting o ich sprawdzenie.

Wydajność: kompresja i cache przeglądarki

Kompresja GZIP

Najpierw sprawdź w narzędziach deweloperskich przeglądarki nagłówek Content-Encoding: kompresję może już zapewniać Nginx lub CDN. Jeżeli nie, a hosting udostępnia mod_deflate, dla plików tekstowych można użyć:

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json
</IfModule>

Rozmiar oszczędności zależy od treści. Obrazy JPEG, WebP i inne już skompresowane formaty zwykle nie zyskają na GZIP. Kompresja odpowiedzi HTTPS zawierających jednocześnie sekrety i dane kontrolowane przez użytkownika może zwiększać ryzyko ataku BREACH; jej zakres dla dynamicznych stron ustal z administratorem.

Expires i Cache-Control

Cache przeglądarki ogranicza ponowne pobieranie zasobów, ale zbyt długi czas może utrzymać stary wygląd strony. Przykład dla statycznych CSS i JavaScript, jeśli dostępny jest mod_expires:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Sprawdź rzeczywiste nagłówki odpowiedzi, także na CDN. Nie dokładaj sprzecznych reguł do ustawień wtyczki lub serwera. Długi czas cache i immutable stosuj tylko do plików, których adres zmienia się po zmianie zawartości. Nie ustawiaj publicznego cache dla stron konta, koszyka, zamówienia ani innych spersonalizowanych odpowiedzi. Nie wyłączaj ETag bez sprawdzenia istniejącej strategii cache.

Bezpieczeństwo przez .htaccess

Ochrona wp-config.php

Plik zawiera dane dostępowe. Dla Apache 2.4 możesz dodać poza blokiem WordPressa:

<Files "wp-config.php">
    Require all denied
</Files>

Sprawdź z zewnątrz, czy żądanie kończy się odmową dostępu, nie ujawniając zawartości. Reguła nie zabezpieczy pliku serwowanego z pominięciem Apache. Składnia Require wymaga odpowiedniego modułu i zgody hostingu; starsze serwery wymagają osobnej konfiguracji.

Logowanie, XML-RPC i katalogi

Ograniczenie po IP tylko pliku wp-login.php nie jest blokadą całego wp-admin. Stałe IP, VPN, proxy i integracje mogą zmieniać sposób identyfikacji klienta. Zanim ustawisz blokadę, przygotuj alternatywny dostęp i sprawdź adres widziany przez serwer.

XML-RPC bywa celem prób logowania, ale korzystają z niego niektóre aplikacje i integracje. Nie blokuj xmlrpc.php bez sprawdzenia zależności. W pierwszej kolejności stosuj aktualizacje, silne hasła, MFA i ograniczanie prób logowania na odpowiedniej warstwie.

Listowanie katalogów można wyłączyć dyrektywą Options -Indexes, jeśli hosting pozwala na zmianę tej opcji. Nie wyłącza to dostępu do plików o znanych adresach i nie zastępuje właściwych uprawnień.

SEO, HTTPS i przekierowania

Ustal jedną wersję domeny i jeden mechanizm przekierowania — w CDN, serwerze albo wtyczce. Najpierw sprawdź certyfikat dla używanych nazw, adresy WordPressa i reguły proxy. Przy HTTPS kończonym na proxy Apache może widzieć połączenie jako HTTP; prosta reguła sprawdzająca %{HTTPS} może wtedy utworzyć pętlę. Nie ufaj nagłówkom przekazywanym przez klienta bez konfiguracji zaufanego proxy.

Przekierowania testuj początkowo kodem 302, a po sprawdzeniu zmień na 301. Dla przeniesionej strony kieruj stary adres do jego rzeczywistego odpowiednika, zachowując potrzebne parametry. Unikaj łańcuchów przekierowań i używania niezweryfikowanego nagłówka Host jako celu.

Wersja z ukośnikiem lub bez niego nie jest uniwersalnie lepsza dla SEO. Zachowaj istniejącą strukturę odnośników WordPressa oraz spójne linki i adresy kanoniczne; nie usuwaj ukośników masową regułą bez planu migracji.

Boty, spam i hotlinking

Blokada po User-Agent jest łatwa do obejścia i może zatrzymać użyteczne narzędzia. Przy dużym ruchu sprawdź logi, adresy, ścieżki i częstotliwość żądań, a następnie rozważ limity na poziomie serwera lub usługi ochronnej. Sam .htaccess nie gwarantuje ochrony przed przeciążeniem.

Hotlinking oznacza osadzanie plików z Twojej witryny na innych stronach. Filtr oparty na Referer nie jest pewnym zabezpieczeniem: nagłówek może być pusty lub sfałszowany, a blokada może zepsuć podglądy i integracje. Wprowadzaj ją tylko po pomiarze problemu i testach, nie blokując przy okazji CSS ani JavaScript.

Najczęstsze błędy

• Pętla przekierowań: porównaj kolejne nagłówki Location i znajdź warstwy, które przekierowują ruch. Sama flaga [L] nie usuwa konfliktu między żądaniami.
• Błąd 500: przywróć kopię i zajrzyj do logu Apache. Przyczyną może być składnia, brak modułu albo dyrektywa niedozwolona przez AllowOverride.
• 404 po migracji: sprawdź katalog instalacji, reguły właściwe dla serwera i ustawienia bezpośrednich odnośników. Nie wklejaj reguł dla katalogu głównego do instalacji w podkatalogu.
• Konflikt wtyczek: porównaj aktualny plik z kopią i sprawdź, która wtyczka zarządza daną regułą. Nie usuwaj jej bloku bez sprawdzenia skutków.

Jak bezpiecznie testować i przywracać zmiany?

1. Sprawdź serwer obsługujący poszczególne żądania oraz dostępność modułów i dyrektyw. Zapisz kopię oryginalnego pliku poza webrootem, z zachowaniem uprawnień i właściciela.
2. Jeśli masz staging o podobnej konfiguracji, wprowadzaj po jednej zmianie. Miej przygotowany dostęp przez SFTP lub panel do przywrócenia kopii po błędzie 500.
3. Sprawdź stronę główną, podstrony, logowanie, REST API i używane integracje. W sklepie sprawdź również koszyk i zamówienie bez wykonywania prawdziwej płatności.
4. Sprawdź nagłówki i przekierowania, np. curl -I https://example.com/ oraz curl -I -L --max-redirs 5 http://example.com/, zastępując domenę własną. Test HEAD nie zastępuje sprawdzenia zwykłych żądań i działania w przeglądarce.
5. W razie błędu przywróć kopię, sprawdź log serwera i powtórz test. Nie wklejaj prawdziwego pliku z adresami IP lub innymi wrażliwymi danymi do publicznych testerów online.

Zmiany w .htaccess Apache odczytuje przy kolejnych żądaniach; restart zwykle nie jest potrzebny. Zmiana głównej konfiguracji serwera to inna operacja i wymaga procedury administratora.

Przykładowy zestaw reguł

Ten niewielki przykład dotyczy tylko Apache 2.4, gdy wszystkie chronione żądania trafiają do Apache i hosting dopuszcza użyte dyrektywy. Dodaj go przed istniejącym blokiem WordPressa, nie zastępując pozostałej konfiguracji. To nie jest kompletny plik ani gwarancja bezpieczeństwa:

# Ochrona wp-config.php w Apache 2.4
<Files "wp-config.php">
    Require all denied
</Files>

# Kompresja tekstu, jeśli mod_deflate jest dostępny
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain text/css application/javascript
</IfModule>

IfModule pomija sekcję przy braku modułu, więc brak błędu nie oznacza, że kompresja działa. Sprawdź odpowiedzi z zewnątrz oraz ustawienia serwera i CDN.

Podsumowanie

Nie zaczynaj od kopiowania dużego zestawu reguł. Ustal, który serwer obsługuje żądanie, zachowaj kopię, dodaj tylko potrzebną zmianę i sprawdź jej efekt. Cache, przekierowania oraz ochrona plików muszą działać razem z konfiguracją hostingu i używanymi wtyczkami.

Dokumentacja: WordPress: Apache i .htaccess oraz Apache: konfiguracja .htaccess.

Najczęściej zadawane pytania

Czy .htaccess działa na serwerze Nginx?

Nginx nie odczytuje .htaccess. Jeśli działa jako proxy przed Apache, reguły Apache mogą dotyczyć żądań przekazanych do Apache, ale nie plików obsłużonych bezpośrednio przez Nginx.

Jakie uprawnienia ustawić dla pliku .htaccess?

Często stosuje się 644, ale właściwe uprawnienia i właściciel zależą od hostingu. Serwer musi móc odczytać plik, a dostęp do zapisu powinny mieć tylko uprawnione konta. Nie ustawiaj 777.

Co zrobić, gdy .htaccess nie działa po migracji?

Sprawdź, który serwer obsługuje dane żądanie, położenie pliku, uprawnienia, AllowOverride i dostępność potrzebnych modułów Apache. Na Nginx reguły trzeba skonfigurować osobno.

Jak włączyć kompresję GZIP w .htaccess?

Na Apache można użyć mod_deflate dla treści tekstowych, jeśli hosting pozwala na te dyrektywy. Najpierw sprawdź, czy kompresji nie zapewnia już serwer pośredniczący lub CDN.

Jak zabezpieczyć plik wp-config.php przed dostępem?

Na Apache 2.4 można ograniczyć dostęp dyrektywą Require all denied w sekcji Files. Sprawdź również ochronę na Nginx lub CDN, jeśli obsługuje żądania przed Apache.

Jak wymusić przekierowanie z HTTP na HTTPS?

Najlepiej zrobić to w jednej warstwie serwera lub CDN, po sprawdzeniu certyfikatu i konfiguracji proxy. Przekierowanie przetestuj najpierw jako 302, a po weryfikacji zmień na 301.

Co zrobić, jeśli po edycji .htaccess pojawi się błąd 500?

Przywróć kopię pliku przez SFTP lub panel hostingu i sprawdź log błędów Apache. Przyczyną może być literówka, niedostępny moduł albo dyrektywa niedozwolona przez hosting.