Strona nie pozwala wgrać motywu, plik jest za duży. Wyszukiwarki indeksują strony serwisowe, których nie powinno być w wynikach. W logach serwera widoczne są próby dostępu do wp-config.php z obcych adresów IP. Trzy problemy, a rozwiązanie jedno: plik .htaccess, który już znajduje się w katalogu głównym Pana/Pani witryny WordPress.

Z pewnością widział go Pan/Pani podczas konfigurowania przyjaznych linków. Jednak możliwości .htaccess na tym się nie kończą: zarządza on dostępem, bezpieczeństwem, przekierowaniami i limitami przesyłania na poziomie serwera. I, w przeciwieństwie do wtyczek bezpieczeństwa, nie obciąża PHP.

Poniżej przedstawiamy cztery praktyczne scenariusze, z którymi spotyka się każdy administrator WordPress. Każdemu towarzyszy gotowy kod, wyjaśnienie i wskazówka, gdzie dokładnie go wstawić. Kod został przepisany pod Apache 2.4 (aktualna wersja na rok 2026), ale każdy fragment zawiera blok zgodności z Apache 2.2, aby nie musiał się Pan/Pani zastanawiać, czy zadziała on na Pana/Pani hostingu.

💡 Szybki przegląd:

• Zwiększ limit przesyłania plików przez .htaccess i .user.ini dla PHP-FPM.
• Zamknij witrynę przed indeksowaniem przez wyszukiwarki na poziomie serwera.
• Wyłącz przeglądanie katalogów jednym wierszem.
• Chroń wp-config.php przed bezpośrednim dostępem nowoczesną składnią Apache 2.4.

1. Zwiększamy maksymalny rozmiar przesyłanych plików

Próbuje Pan/Pani zainstalować motyw lub wtyczkę, a WordPress wyświetla błąd: „The uploaded file exceeds the upload_max_filesize directive in php.ini". Domyślny limit u wielu hostingodawców, 2 MB lub 8 MB, jest zbyt mały dla archiwum motywu.

Nie można edytować php.ini na hostingu współdzielonym. Jeśli jednak Apache działa z modułem mod_php, limit podnosi się bezpośrednio z .htaccess. Proszę otworzyć plik w katalogu głównym witryny (przez FTP lub menedżer plików hostingu) i dodać na końcu:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

Pierwsza dyrektywa określa maksymalny rozmiar żądania POST, druga, maksymalny rozmiar pojedynczego przesyłanego pliku. Obie wartości powinny być zgodne lub post_max_size powinno być nieco większe.

Proszę sprawdzić wynik: proszę wejść do panelu administracyjnego WordPress, Media → Dodaj nowe. Na dole wyświetli się aktualny limit.

Ważne: jeśli hosting został przeniesiony na PHP-FPM (a takich jest większość w 2026 roku), dyrektywy php_value w .htaccess nie zadziałają. Proszę sprawdzić: Narzędzia → Kondycja witryny → Informacje → Serwer. W wierszu „Server architecture" proszę szukać wzmianki o FPM. Dla takiego hostingu limit zmienia się przez plik .user.ini w katalogu głównym witryny:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Format jak w php.ini, ze znakami równości zamiast php_value. Zmiany są stosowane natychmiast, ponowne uruchomienie serwera nie jest potrzebne. Jeśli plik .user.ini nie istnieje w katalogu głównym, proszę go utworzyć.

2. Zamykamy witrynę przed indeksowaniem przez wyszukiwarki

Sytuacja: witryna testowa na subdomenie, kopia stagingowa lub strona docelowa, która nie powinna trafić do wyników Google i Yandex. Prosty plik robots.txt z Disallow: / wyszukiwarki mogą zignorować: jest to zalecenie, a nie zakaz.

Niezawodny sposób to zablokowanie robotów na poziomie serwera. Klasyczne podejście przez SetEnvIfNoCase działa w Apache 2.4 przez moduł zgodności mod_access_compat, ale jest ono uznawane za przestarzałe. Nowoczesna metoda to przekierowanie botów z pustym User-Agent przez mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Co tu się dzieje: RewriteCond sprawdza User-Agent każdego żądania. Po wykryciu słów kluczowych bot, spider, crawler lub scanner (wielkość liter nie ma znaczenia, flaga [NC]) serwer zwraca 403 Forbidden (flaga [F]).

Cztery wzorce wystarczą, aby objąć wszystkie główne wyszukiwarki: Googlebot, YandexBot, Bingbot, Yahoo Slurp i dziesiątki mniej znanych. Wyliczanie każdego bota osobno jest bezcelowe: sam Google ma kilkadziesiąt wariantów User-Agent dla różnych usług (wyszukiwarka, obrazy, wideo, AdsBot).

Chce Pan/Pani zamknąć witrynę tylko przed Yandexem, a Google pozostawić? Proszę zawęzić wzorzec:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Symbol ^ oznacza „początek ciągu". Bez niego reguła objęłaby również te boty, u których yandex występuje w środku User-Agent.

Ważne: jeśli WordPress już używa mod_rewrite do przyjaznych linków, blok RewriteEngine On już istnieje w .htaccess. Nie trzeba go duplikować, proszę po prostu dodać nowe RewriteCond i RewriteRule po istniejących regułach WordPress, ale przed znacznikiem zamykającym </IfModule>.

Po zmianach proszę sprawdzić .htaccess pod kątem błędów: literówka w dyrektywach i witryna przestanie działać z błędem 500. Składnię można sprawdzić walidatorem online lub poleceniem apachectl configtest (dostępnym nie u wszystkich hostingodawców). Przed edycją koniecznie proszę pobrać kopię zapasową bieżącego .htaccess.

3. Wyłączamy przeglądanie katalogów

Proszę wejść na swoją witrynę pod adresem /wp-content/uploads/. Jeśli zamiast błędu 403 widzi Pan/Pani listę plików, ma Pan/Pani włączone przeglądanie katalogów. To luka: każdy może poznać strukturę folderów, znaleźć wrażliwą wtyczkę lub odczytać przesłany dokument PDF.

Wyłącza się to jednym wierszem w .htaccess:

1
Options -Indexes

Proszę dodać go na początku pliku, przed regułami WordPress. Teraz przy próbie otwarcia katalogu bez pliku indeksu serwer zwróci 403 Forbidden.

Na większości nowoczesnych hostingów ta opcja jest domyślnie włączona, ale proszę sprawdzić, zwłaszcza jeśli witryna była przenoszona między serwerami lub pracuje Pan/Pani z VPS, gdzie Apache był konfigurowany ręcznie.

4. Chronimy wp-config.php przed bezpośrednim dostępem

wp-config.php to najważniejszy plik WordPress. Znajdują się w nim klucze bezpieczeństwa, prefiks tabel i dane dostępowe do bazy danych: nazwa BD, użytkownik, hasło, host.

Sam plik jest napisany w PHP i przy bezpośrednim otwarciu w przeglądarce zwraca pustą stronę, silnik WordPress go nie wykonuje. Jeśli jednak na serwerze tymczasowo wyłączy się przetwarzanie PHP (awaria konfiguracji, aktualizacja modułu), zawartość wp-config.php może zostać udostępniona jako zwykły tekst. Wraz z hasłem do bazy danych.

Zamykamy dostęp przez .htaccess. Większość artykułów w internecie proponuje przestarzałą składnię Apache 2.2, która nie działa w Apache 2.4.6 i nowszych. Oto nowoczesny wariant z kompatybilnością wsteczną:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

Blok IfModule sprawdza obecność modułu mod_authz_core (wprowadzonego w Apache 2.4.6). Jeśli modułu nie ma, stosowana jest składnia 2.2. Jeśli jest, nowoczesna dyrektywa Require all denied. Jeden kod działa na obu wersjach Apache.

Po dodaniu reguł każde żądanie do wp-config.php przez przeglądarkę otrzyma 403 Forbidden, nawet jeśli procesor PHP nie działa. WordPress odwołuje się do pliku bezpośrednio przez system plików, więc reguła nie wpływa na działanie witryny.

To samo podejście ma zastosowanie do każdego poufnego pliku: proszę zastąpić wp-config.php nazwą potrzebnego pliku, na przykład phpinfo.php lub .env.

⁉️🤔 Często zadawane pytania

Czy można w ogóle obejść się bez.htaccess** w WordPress?**

Tak, jeśli witryna działa na Nginx, a nie na Apache. Nginx nie obsługuje .htaccess, wszystkie reguły są definiowane w konfiguracji serwera (nginx.conf lub plik w sites-available/). Na hostingach współdzielonych prawie zawsze jest Apache i .htaccess jest dostępny. Na VPS z Nginx reguły przenosi się do sekcji server {}: składnia jest inna, ale logika ta sama. Na przykład odpowiednik Options -Indexes w Nginx to autoindex off;.

Co zrobić, jeśli po zmianie.htaccess witryna przestała działać z błędem 500?

Należy natychmiast przywrócić kopię zapasową .htaccess, którą zrobił Pan/Pani przed edycją (zrobił ją Pan/Pani?). Proszę połączyć się przez FTP, usunąć zmieniony .htaccess i wgrać zapisany oryginał. Witryna natychmiast ożyje. Błąd 500 po edycji .htaccess prawie zawsze jest spowodowany literówką w dyrektywie lub konstrukcją, której nie obsługuje Pana/Pani wersja Apache.

Dlaczego php_value w.htaccess nie działa na moim hostingu?

Najprawdopodobniej hosting używa PHP-FPM zamiast mod_php. Proszę sprawdzić: Narzędzia → Kondycja witryny → Informacje → Serwer. Jeśli w wierszu „Server architecture" wskazano FPM, php_value w .htaccess jest ignorowane. Proszę użyć pliku .user.ini w katalogu głównym witryny (patrz rozdział 1) lub skontaktować się z pomocą techniczną hostingu. Na VPS limity zmienia się w puli PHP-FPM (www.conf), ale wymaga to dostępu do konfiguracji serwera.

Jak sprawdzić, czy.htaccess rzeczywiście działa?

Najprostszy test to reguła z rozdziału 3 (Options -Indexes). Proszę wejść na /wp-content/uploads/ przed i po dodaniu. Była lista plików, pojawił się błąd 403? Plik działa. Inny sposób: proszę dodać w .htaccess wiersz z jawnym błędem składniowym i otworzyć witrynę. Błąd 500 potwierdzi, że Apache czyta .htaccess. Natychmiast po sprawdzeniu proszę usunąć testowy wiersz.

Czy bezpiecznie jest używać kodu z artykułu na działającej witrynie?

Tak, wszystkie podane fragmenty zostały przetestowane na Apache 2.4 (aktualna wersja na rok 2026) i zawierają bloki zgodności z Apache 2.2. Jedyny obowiązkowy warunek: przed jakąkolwiek edycją .htaccess proszę pobrać bieżącą wersję pliku na komputer. Pięciosekundowa operacja oszczędza godziny przywracania w przypadku literówki. I proszę nie edytować .htaccess przez wtyczki, tylko przez FTP lub menedżer plików hostingu: wtyczka może dodać znaki ucieczki, które zepsują składnię.

Czym podejście do ochrony wp-config.php w artykule różni się od tego, co piszą na innych stronach?

Większość artykułów kopiuje składnię Apache 2.2: Order allow,deny i Deny from all. Te dyrektywy należą do modułu mod_access_compat, który został uznany za przestarzały w Apache 2.4 i może być wyłączony na nowoczesnych serwerach. Nasz fragment używa Require all denied z modułu mod_authz_core, to aktualny standard dla Apache 2.4.6 i nowszych. Jednocześnie blok <IfModule> zachowuje funkcjonalność na starych serwerach.

Co umieścić w konfiguracji.htaccess od razu

Plik .htaccess to kompaktowe, ale potężne narzędzie. Z czterech opisanych technik dwie zamykają luki przy minimalnym wysiłku: wyłączenie przeglądania katalogów i ochrona wp-config.php. To jeden wiersz i jeden blok kodu, które można dodać od razu, nie wpływają one na działanie witryny.

Zwiększenie limitu przesyłania pomaga za każdym razem, gdy WordPress odmawia wgrania motywu lub wtyczki. A blokowanie indeksowania na poziomie serwera to ostatnia linia obrony dla zamkniętych i testowych witryn.

Proszę przechowywać kopię zapasową .htaccess przed każdą edycją. Błąd w składni natychmiastowo kładzie witrynę i równie natychmiastowo jest naprawiany, jeśli kopia jest pod ręką. Dzięki tej zasadzie .htaccess zmienia się z przerażającego pliku w narzędzie pracy.