Błąd 403 Forbidden w WordPressie — jak naprawić? 10 przyczyn i rozwiązania

Błąd 403 Forbidden w WordPressie oznacza, że serwer odmawia dostępu do strony lub pliku — najczęściej przez błędne reguły w .htaccess, nieprawidłowe uprawnienia plików, wtyczkę bezpieczeństwa albo zaporę na hostingu lub w Cloudflare. Aby go naprawić, najpierw ustal, gdzie występuje (cała strona, panel wp-admin, jeden adres), a potem po kolei: wygeneruj nowy .htaccess, ustaw uprawnienia 755 dla katalogów i 644 dla plików, wyłącz wtyczki i sprawdź log błędów serwera.

Poniżej znajdziesz 10 najczęstszych przyczyn wraz z instrukcjami — od najprostszych do tych, przy których potrzebna będzie pomoc hostingu.

Szybka diagnoza: gdzie pojawia się 403

Zakres problemu bardzo zawęża listę podejrzanych:

Kod odpowiedzi łatwo sprawdzić z terminala, bez wpływu cache przeglądarki:

curl -I https://example.com/
curl -I https://example.com/wp-admin/

1. Uszkodzony lub błędny plik .htaccess

Plik .htaccess w głównym katalogu WordPressa zawiera reguły przepisywania adresów, a często także dopiski wtyczek (cache, bezpieczeństwo, przekierowania). Jedna błędna linia, np. Deny from all lub źle napisana reguła blokująca, wystarczy do wywołania 403.

1. Połącz się z serwerem przez FTP/SFTP lub menedżer plików w panelu hostingu (włącz pokazywanie plików ukrytych).
2. Zmień nazwę pliku .htaccess na .htaccess-stary.
3. Sprawdź stronę. Jeśli działa, zaloguj się do kokpitu i przejdź do Ustawienia → Bezpośrednie odnośniki → kliknij Zapisz zmiany. WordPress utworzy nowy plik.

Jeśli plik nie powstanie automatycznie, utwórz go ręcznie z domyślną zawartością:

# 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

Potem możesz porównać stary plik z nowym i przywrócić tylko potrzebne fragmenty (np. reguły wtyczki cache). Pamiętaj też o plikach .htaccess w podkatalogach, np. wp-admin czy wp-content/uploads.

2. Nieprawidłowe uprawnienia lub właściciel plików

Serwer WWW musi móc odczytać pliki i wejść do katalogów. Standardowe uprawnienia dla WordPressa:

• katalogi: 755,
• pliki: 644,
• wp-config.php: 640 lub 600 (jeśli hosting na to pozwala; w razie błędu wróć do 644).

W kliencie FTP (np. FileZilla) zaznacz katalog, kliknij prawym przyciskiem Uprawnienia pliku, wpisz wartość i wybierz zastosowanie rekurencyjne osobno dla katalogów i dla plików. Przy dostępie SSH zrobisz to szybciej:

cd /sciezka/do/wordpressa
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Po przenosinach strony między serwerami częstym problemem jest też zły właściciel plików (np. pliki rozpakowane jako root). Na własnym serwerze popraw go poleceniem chown -R na użytkownika, pod którym działa PHP; na hostingu współdzielonym poproś o to wsparcie techniczne.

Uwaga: Nigdy nie ustawiaj uprawnień 777, nawet „na chwilę”. To pozwala każdemu procesowi na serwerze zapisywać pliki Twojej strony, a część hostingów wręcz blokuje wykonywanie takich plików, co skończy się kolejnym błędem.

3. Domena wskazuje na zły katalog lub brakuje pliku index

Jeśli domena w panelu hostingu jest przypisana do pustego katalogu albo do katalogu bez pliku index.php, a serwer ma wyłączone listowanie katalogów (Options -Indexes), zobaczysz 403 zamiast strony. Zdarza się to po przenosinach, zmianie katalogu instalacji lub dodaniu domeny jako aliasu.

Sprawdź w panelu hostingu, do jakiego katalogu kieruje domena (np. public_html lub domains/example.com/public_html) i czy w nim leżą pliki WordPressa z index.php.

4. Wtyczka bezpieczeństwa lub inna wtyczka

Wtyczki bezpieczeństwa (np. Wordfence, Solid Security, All-In-One Security) potrafią zablokować adres IP, kraj, nietypowe zapytania lub dostęp do REST API. Inne wtyczki też mogą dopisać reguły do .htaccess.

Jeśli masz dostęp do kokpitu: Wtyczki → Zainstalowane wtyczki, zaznacz wszystkie, z menu akcji grupowych wybierz Wyłącz i sprawdź stronę. Potem włączaj je pojedynczo.

Jeśli kokpit zwraca 403:

1. Przez FTP przejdź do wp-content.
2. Zmień nazwę katalogu plugins na plugins-off — WordPress wyłączy wszystkie wtyczki.
3. Jeśli strona działa, przywróć nazwę plugins i wyłączaj wtyczki pojedynczo, zmieniając nazwy ich katalogów.

Z WP-CLI wystarczy jedno polecenie: wp plugin deactivate --all. Wtyczki bezpieczeństwa mogą też zostawić własne reguły w .htaccess lub w pliku .user.ini (opcja auto_prepend_file) — po ich wyłączeniu sprawdź oba pliki.

Podobnie sprawdź motyw: przełącz go na domyślny (np. Twenty Twenty-Five). Jeśli szukasz nowego, sprawdzonego motywu, zajrzyj do zestawienia najlepszych motywów WordPress.

5. Twój adres IP jest zablokowany

Jeśli strona działa na telefonie z wyłączonym Wi-Fi, a z Twojej sieci zwraca 403, adres IP trafił na listę blokad. Przyczyną bywa kilka nieudanych logowań, zbyt wiele żądań (np. przy imporcie) albo automatyczna lista blokad hostingu (fail2ban, CSF).

• we wtyczce bezpieczeństwa usuń swój adres z listy zablokowanych (lub dodaj do zaufanych),
• na hostingu poproś wsparcie o odblokowanie IP, podając adres i godzinę wystąpienia błędu,
• sprawdź, czy w .htaccess w katalogu wp-admin nie ma reguł Require ip, które przestały pasować po zmianie adresu przez operatora.

Ograniczenia dostępu do panelu po IP i hasłem mają sens, ale trzeba je dobrze skonfigurować — opisaliśmy to w poradniku jak zabezpieczyć stronę www hasłem i w tekście o ukrywaniu wp-admin.

6. ModSecurity na hostingu blokuje zapis wpisu lub upload

Typowy objaw: strona działa, ale przy zapisie wpisu edytor pokazuje „Aktualizacja nie powiodła się”, a w narzędziach deweloperskich przeglądarki (karta Sieć) widać odpowiedź 403 na żądanie do REST API. Najczęściej zapora aplikacyjna serwera uznała treść — fragment kodu, iframe, słowa typowe dla ataków SQL — za próbę ataku.

1. Otwórz log błędów w panelu hostingu (w cPanelu: Metryki → Błędy, w innych panelach: „Logi”, „Dziennik błędów”).
2. Znajdź wpis z godziny błędu zawierający ModSecurity i identyfikator reguły (id "...").
3. Poproś hosting o wyłączenie tej konkretnej reguły dla Twojej domeny lub ścieżki — a nie całej zapory.

Jak działają takie zapory i skąd biorą się fałszywe alarmy, wyjaśniamy w artykule Co to jest WAF.

7. Zablokowane REST API lub wygasła sesja

Edytor blokowy komunikuje się z WordPressem przez REST API (/wp-json/). Jeśli wtyczka wyłączyła REST API dla niezalogowanych w zbyt agresywny sposób, albo sesja wygasła, zapisywanie zwraca 403 z kodem rest_cookie_invalid_nonce lub rest_forbidden. Wyloguj się, wyczyść ciasteczka domeny, zaloguj ponownie i sprawdź ustawienia wtyczek ograniczających REST API.

8. Blokada w Cloudflare lub innym CDN

Jeśli strona błędu ma logo Cloudflare i identyfikator Ray ID, żądanie zatrzymało się w Cloudflare i nigdy nie dotarło do serwera. W panelu Cloudflare przejdź do Security → Events (Zdarzenia zabezpieczeń), wyszukaj Ray ID i sprawdź, która reguła zablokowała ruch: reguła własna, zarządzana reguła WAF, blokada kraju czy ochrona przed botami. Dodaj wyjątek dla konkretnej ścieżki lub swojego adresu zamiast wyłączać całą ochronę.

9. Celowa ochrona plików i hotlinking

Nie każdy 403 jest błędem. WooCommerce chroni pliki produktów do pobrania w katalogu wp-content/uploads/woocommerce_uploads, więc bezpośredni link do pliku zwraca 403 — klient dostaje plik przez specjalny link do pobrania. Jeśli prowadzisz sklep z produktami cyfrowymi na WordPressie, to zamierzone działanie.

Podobnie ochrona przed hotlinkingiem w panelu hostingu lub CDN blokuje wyświetlanie Twoich obrazków na innych stronach. Jeśli 403 pojawia się na obrazkach w Twojej własnej witrynie (np. po zmianie domeny lub dodaniu www), dopisz właściwą domenę do listy dozwolonych.

10. Infekcja złośliwym oprogramowaniem

Złośliwy kod potrafi dopisać do .htaccess reguły, które przekierowują lub blokują ruch, albo zmienić uprawnienia plików. Sygnały ostrzegawcze: nieznane pliki PHP w wp-content/uploads, nowi administratorzy, dziwne przekierowania z wyszukiwarki.

1. Uruchom skaner w panelu hostingu (wiele firm udostępnia go bezpłatnie) lub skaner wtyczki bezpieczeństwa.
2. Porównaj pliki rdzenia z oryginałem: wp core verify-checksums i wp plugin verify-checksums --all w WP-CLI.
3. Przywróć czystą kopię zapasową, zaktualizuj WordPressa, wtyczki i motyw, zmień wszystkie hasła (kokpit, FTP, baza danych, panel hostingu) i klucze w wp-config.php.

Co zrobić, jeśli nic nie pomogło

Przejdź listę jeszcze raz w tej kolejności:

1. Kod odpowiedzi sprawdzony przez curl -I i z innej sieci (telefon na danych komórkowych).
2. .htaccess w katalogu głównym i podkatalogach — tymczasowo zmienione nazwy.
3. Uprawnienia 755/644 i poprawny właściciel plików.
4. Wtyczki wyłączone przez zmianę nazwy katalogu plugins, motyw zmieniony na domyślny.
5. Log błędów serwera przejrzany pod kątem ModSecurity i blokad IP.
6. Zdarzenia w Cloudflare/CDN sprawdzone po Ray ID.

Jeśli problem nie znika, włącz tryb debugowania WordPressa i napisz do wsparcia hostingu. Podaj dokładny adres, godzinę błędu, swój adres IP i opis kroków, które już wykonałeś — to znacznie skraca czas odpowiedzi.