Strona zablokowana z powodu zabronionego dostępu (błąd 403)

Co oznacza ten status

Google wyjaśnia, że kod 403 oznacza odmowę dostępu po podaniu danych logowania, a skoro Googlebot nigdy ich nie podaje, serwer zwraca ten kod nieprawidłowo (raport Indeksowanie stron). Jako rozwiązanie Google podaje dwie opcje: wpuścić użytkowników niezalogowanych albo zezwolić na żądania Googlebota bez uwierzytelniania, po zweryfikowaniu jego tożsamości.

Według dokumentacji (jak kody HTTP wpływają na roboty Google) treść zwrócona z 403 jest ignorowana, zindeksowane adresy są usuwane z indeksu, a kodów 401 i 403 nie wolno używać do ograniczania tempa skanowania. Pozostałe kody opisuje hasło o kodach odpowiedzi HTTP.

Najczęstsze przyczyny

Zapora aplikacyjna (WAF)

Reguła w Cloudflare albo ModSecurity, która odrzuca żądania bez typowych nagłówków przeglądarki albo zbyt częste. Googlebot wysyła wiele żądań z jednego zakresu IP, więc reguły „za dużo żądań z jednego adresu” biorą go za atak.

Blokada geograficzna

Sklep sprzedaje tylko w Polsce, więc administrator zablokował ruch spoza kraju. Dokumentacja Google (tymczasowe wstrzymanie witryny) mówi, że skanowanie odbywa się zwykle z terenu Stanów Zjednoczonych, a blokada tego kraju odcina wyszukiwarkę od witryny.

Ochrona przed botami

Usługi anty-botowe i wtyczki bezpieczeństwa w CMS porównują klienta z listą „dobrych botów”. Nieaktualna lista albo literówka w nazwie i Googlebot dostaje 403.

Uprawnienia plików i katalogów na serwerze

Po wdrożeniu katalog nie ma prawa odczytu dla użytkownika serwera WWW albo brakuje pliku indeksu. Apache i Nginx zwracają wtedy 403 dla wszystkich, nie tylko dla robota.

Reguła w .htaccess albo konfiguracji serwera

Dyrektywy Deny from albo Require ip ograniczające dostęp do adresów biura, zostawione po testach. Zespół widzi stronę, nikt inny nie.

Jak to potwierdzić

Uruchom test wersji opublikowanej i sprawdź pole „Pobranie strony” w sekcji Dostępność (narzędzie do sprawdzania adresów URL).

Potem z terminala:

• curl -I https://example.com/strona/ - czy 403 dostaje każdy klient, co wskazuje na uprawnienia albo regułę serwera,
• curl -I -A "Googlebot/2.1" https://example.com/strona/ - czy sama nazwa klienta wywołuje blokadę.

Nagłówek cf-ray w odpowiedzi wskazuje Cloudflare. Przy blokadzie geograficznej test z polskiego adresu przejdzie, a test wersji opublikowanej nie, bo wychodzi z zagranicy.

W logach znajdź wpisy 403 z czasu skanowania. Adres IP zweryfikuj zgodnie z dokumentacją (weryfikacja żądań Googlebota): odwrotne DNS ma wskazać nazwę w domenie googlebot.com albo google.com, a zwykłe DNS tej nazwy ma wrócić do tego samego IP. Google ostrzega, że nazwę klienta Googlebota często fałszują inne roboty (Googlebot), więc wyjątki w zaporze buduj po IP, nie po nazwie.

Jeśli adres przekierowuje, 403 może zwracać dopiero cel, co pokaże sprawdzarka przekierowań. Z kolei sprawdzarka robots.txt potwierdzi, czy sam plik odpowiada 200.

Jak to naprawić

1. WAF: znajdź w logu zapory regułę, która odrzuciła żądanie, i dodaj wyjątek dla zweryfikowanych zakresów IP Google.
2. Blokada geograficzna: pokaż użytkownikom spoza Polski ograniczoną wersję strony z kodem 200 albo dodaj wyjątek dla zakresów Google.
3. Ochrona przed botami: zaktualizuj listę dozwolonych robotów i weryfikuj je po odwrotnym DNS, nie po nazwie.
4. Uprawnienia: katalogi 755, pliki 644, właściciel zgodny z użytkownikiem serwera WWW. Dodaj plik indeksu tam, gdzie go brakuje.
5. Konfiguracja serwera: usuń dyrektywy Deny from i Require ip z .htaccess albo bloków location w Nginx. Przeładuj serwer i powtórz curl -I.
6. Po naprawie uruchom test wersji opublikowanej dla kilku adresów i kliknij „Sprawdź poprawkę”.

Kiedy to w porządku, a kiedy działać

Plik robots.txt z kodem 403 nie zatrzyma Googlebota. Według specyfikacji (jak Google interpretuje robots.txt) błędy 4xx poza 429 Google traktuje tak, jakby pliku nie było, i skanuje bez ograniczeń. Zasady działania pliku opisuje hasło o robots.txt.

Kod 403 łatwo pomylić z błędem 401, czyli prośbą o logowanie. Pozostałe kody z tej rodziny trafiają do statusu inny błąd 4xx.

Jak pilnować na co dzień

IndexRise co noc sprawdza kod odpowiedzi każdej monitorowanej strony. Kod 403 na adresie, który poprzednio odpowiadał 200, to zdarzenie krytyczne, potwierdzane w kolejnym sprawdzeniu, bo nowa reguła w zaporze potrafi wyciąć całą domenę w jeden wieczór. Odróżniamy „strona odpowiedziała 403” od „nie udało się sprawdzić”, czyli przekroczonego czasu albo błędu DNS: pierwsze wymaga zmiany konfiguracji, drugie kontaktu z hostingiem. Sprawdzane elementy wymienia lista funkcji.