„Strona zablokowana z powodu zabronionego dostępu (błąd 403)”. Co blokuje Google?

W raporcie Google Search Console pojawia się wiersz „Strona zablokowana z powodu zabronionego dostępu (błąd 403)”, a obok niego liczba adresów, których Google nie zindeksował. Właściciel firmy otwiera te same adresy w przeglądarce i widzi poprawnie działającą stronę. To typowy obraz tego problemu: serwer wpuszcza ludzi, a robotowi Google odpowiada odmową.

Ten tekst jest przeznaczony dla osób, które prowadzą stronę firmową lub sklep i chcą samodzielnie ustalić, co zatrzymuje Googlebota. Nie trzeba być programistą, choć w kilku miejscach przyda się dostęp do panelu hostingu i do plików strony.

Po lekturze będzie wiadomo, jak odczytać komunikat, jak sprawdzić, czy blokada nadal trwa, w której warstwie strony jej szukać, jak ją zdjąć bez osłabiania zabezpieczeń i jak potwierdzić w Search Console, że Google znowu pobiera strony.

Co oznacza ten komunikat i gdzie go szukać w Search Console?

Kod 403 to odpowiedź serwera, która znaczy: żądanie zostało zrozumiane, ale dostęp do tego adresu jest zabroniony. Serwer nie mówi, że strony nie ma (to byłby kod 404), ani że uległ awarii (kody z grupy 5xx). Mówi, że tego konkretnego gościa nie wpuści.

Pomoc Search Console opisuje ten stan krótko: błąd 403 oznacza, że klient podał dane logowania, ale nie uzyskał dostępu. Googlebot nigdy nie podaje danych logowania, więc z punktu widzenia Google serwer zwraca ten błąd nieprawidłowo. Skutek jest jeden: strona nie zostanie zindeksowana.

Komunikat znajduje się w raporcie „Indeksowanie stron”, w tabeli „Dlaczego strony nie są indeksowane”. Po kliknięciu wiersza z nazwą problemu otwiera się strona ze szczegółami: wykres pokazujący, od kiedy problem występuje, oraz lista przykładowych adresów. Ta lista ma ograniczenie do 1000 wierszy, więc przy dużym serwisie pokazuje tylko część adresów.

W tabeli jest też kolumna „Źródło”. Przy błędzie 403 widnieje w niej wartość „Witryna”, co oznacza, że przyczyna leży po stronie serwisu i właściciel może ją usunąć. Google niczego tu nie naprawi za właściciela strony.

Kiedy błąd 403 szkodzi widoczności, a kiedy można go zostawić?

Nie każdy adres z tej listy wymaga naprawy. Najpierw trzeba przejrzeć przykładowe adresy i podzielić je na dwie grupy: strony, które powinny być w Google, oraz adresy, których w wynikach wyszukiwania nikt nie chce oglądać.

Do pierwszej grupy należą strona główna, oferty, kategorie i produkty sklepu, wpisy na blogu, strona kontaktowa. Jeżeli Googlebot dostaje przy nich kod 403, sprawa jest pilna. Z dokumentacji Google wynika, że adresy zwracające błędy z grupy 4xx nie są przetwarzane, a te, które były już w indeksie, zostają z niego usunięte. Strona, która wczoraj przynosiła zapytania, po pewnym czasie przestaje się wyświetlać.

Druga grupa to między innymi:

• adresy panelu administracyjnego i logowania,
• katalogi techniczne bez własnej strony startowej, na przykład foldery z plikami wtyczek lub kopii,
• strefy dla zalogowanych klientów, koszyk, konto użytkownika,
• pliki, do których dostęp celowo ograniczono.

Przy takich adresach kod 403 jest poprawnym zachowaniem serwera i nie obniża oceny reszty serwisu. Warto jedynie ustalić, skąd Google je zna. Zwykle prowadzą do nich linki w treści albo wpisy w mapie witryny. Adresów, które mają pozostać zamknięte, nie umieszcza się w mapie witryny, a odnośniki do nich najlepiej usunąć z publicznych stron.

Jeżeli robot ma w ogóle nie zaglądać do zamkniętej części serwisu, lepszym narzędziem niż odmowa 403 jest reguła w pliku robots.txt. Sposób pisania takich reguł opisałem we wpisie o tym, jak ustawić plik robots.txt.

Jak sprawdzić, co w tej chwili dostaje Googlebot?

Raport „Indeksowanie stron” pokazuje stan z dnia ostatniej wizyty robota. Blokada mogła trwać kilka godzin i dawno zniknąć albo trwa do dziś. Zanim zacznie się cokolwiek zmieniać, trzeba to rozstrzygnąć testem na żywo.

1. W Search Console należy otworzyć raport „Indeksowanie stron” i kliknąć wiersz „Strona zablokowana z powodu zabronionego dostępu (błąd 403)”.
2. Na liście przykładów trzeba wskazać adres ważnej strony i kliknąć przy nim ikonę lupy, która otwiera narzędzie do sprawdzania adresów URL. Ten sam efekt daje wklejenie adresu w pole wyszukiwania na górze panelu.
3. Pierwszy ekran pokazuje dane z indeksu Google, czyli stan zapamiętany przy ostatnim pobraniu. W sekcji dotyczącej indeksowania strony widać datę ostatniego pobrania i pole „Pobranie strony”.
4. Następnie należy uruchomić test wersji opublikowanej. Pomoc Google opisuje ten przycisk jako „Sprawdź URL wersji opublikowanej”. Test trwa zwykle do kilku minut.
5. Po zakończeniu testu trzeba ponownie odczytać pole „Pobranie strony”. Wartość „Udało się” oznacza, że Google pobrał stronę w tej chwili. Wartość „Niepowodzenie” z dopiskiem o zabronionym dostępie oznacza, że blokada nadal działa.
6. Jeżeli test się powiódł, warto kliknąć „Wyświetl przetestowaną stronę” i otworzyć kartę „Zrzut ekranu”. Zrzut pokazuje, czy Google widzi pełną stronę, a nie na przykład ekran z zadaniem weryfikacyjnym dla robotów.

Test należy powtórzyć na trzech lub czterech adresach różnego rodzaju: stronie głównej, wpisie, produkcie. Jeśli blokada dotyczy tylko jednej grupy adresów, od razu zawęża to poszukiwania.

Ważna uwaga: test wersji opublikowanej wykonuje robot o nazwie Google-InspectionTool, a nie zwykły Googlebot. Zdarza się, że zapora przepuszcza jeden z nich, a zatrzymuje drugi. Dlatego wynik testu trzeba zestawić z drugim źródłem, czyli raportem „Statystyki indeksowania”.

Co pokazuje raport „Statystyki indeksowania”?

Raport otwiera się z poziomu „Ustawienia”, a następnie „Statystyki indeksowania”. Jest dostępny dla usług obejmujących całą domenę lub adres najwyższego poziomu. Pokazuje faktyczne żądania robotów Google z ostatnich 90 dni.

W tabeli z odpowiedziami serwera żądania są pogrupowane według rodzaju odpowiedzi. Po kliknięciu wiersza z błędami po stronie klienta widać przykładowe adresy z datą i godziną żądania. To bezcenna informacja: dokładna godzina pozwala potem odnaleźć to samo żądanie w dzienniku serwera lub w dzienniku zapory.

Skąd bierze się odpowiedź 403? Sześć miejsc, w których powstaje blokada

Żądanie robota przechodzi przez kilka warstw, zanim dotrze do treści. Każda z nich może odpowiedzieć odmową. Z mojej praktyki wynika, że przyczyna prawie zawsze leży w jednej z sześciu poniższych.

Usługa pośrednicząca przed serwerem. Sieć CDN z zaporą aplikacyjną, na przykład Cloudflare, ocenia każde żądanie, zanim trafi ono na hosting. Reguła blokująca kraje, wysoki poziom ochrony przed botami albo własna reguła napisana zbyt szeroko potrafią zatrzymać Googlebota.

Zapora na hostingu. Wielu dostawców hostingu ma własne filtry ruchu, które działają niezależnie od ustawień klienta. Bywają zaostrzane po atakach na inne strony z tego samego serwera. Właściciel strony często nie wie, że taki filtr istnieje.

Wtyczka zabezpieczająca w systemie strony. W WordPressie wtyczki tego typu mają limity liczby żądań, listy zablokowanych adresów IP, blokady krajów i ochronę przed robotami. Googlebot odwiedza stronę często i z wielu adresów, więc łatwo przekracza limit ustawiony z myślą o zwykłym gościu.

Plik .htaccess lub konfiguracja serwera. Wystarczy jeden wiersz z odmową dla zakresu adresów IP albo dla nazwy robota, wklejony kiedyś z internetowej listy „złych botów”. Takie listy bywają nieprecyzyjne i obejmują także roboty wyszukiwarek.

Uprawnienia plików i katalogów. Serwer odpowiada kodem 403 także wtedy, gdy nie ma prawa odczytać pliku albo gdy adres wskazuje katalog bez pliku startowego, a wyświetlanie listy plików jest wyłączone. Ta przyczyna dotyka wszystkich odwiedzających, nie tylko robota.

Blokada geograficzna. Googlebot łączy się głównie z adresów IP w Stanach Zjednoczonych. Sklep, który „dla bezpieczeństwa” przyjmuje ruch wyłącznie z Polski, odcina w ten sposób także Google. Taką blokadę trzeba uzupełnić wyjątkiem dla zweryfikowanych robotów wyszukiwarek albo zastąpić ochroną, która ocenia zachowanie gościa, a nie jego lokalizację.

Osobną kategorią jest celowe spowalnianie robota. Zdarza się, że serwer lub wtyczka przy dużym obciążeniu odpowiada kodem 403 zamiast kodu przeznaczonego do tego celu. Dokumentacja Google wprost zaleca, aby nie używać kodów 401 i 403 do ograniczania szybkości indeksowania. Do sygnalizowania przeciążenia służą kody 500, 503 i 429, które Google traktuje jako prośbę o chwilowe zwolnienie tempa, a nie jako informację, że treści nie ma.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: ustalę, która warstwa odpowiada robotowi Google kodem 403, zdejmę blokadę i doprowadzę do ponownego pobrania stron.

Jak ustalić, która warstwa blokuje robota?

Zgadywanie i wyłączanie zabezpieczeń po kolei jest najgorszą metodą, ponieważ na czas prób strona zostaje bez ochrony. Lepiej przejść od zewnątrz do środka i na każdym etapie szukać konkretnego śladu zablokowanego żądania.

1. Zebranie danych wyjściowych. Z raportu „Statystyki indeksowania” należy zanotować dwa lub trzy zablokowane adresy wraz z datą i godziną żądania.
2. Sprawdzenie strony w oknie incognito przeglądarki, bez logowania. Jeżeli zwykły gość także widzi komunikat o braku dostępu, przyczyną są uprawnienia plików, brak pliku startowego albo reguła obejmująca wszystkich. Wtedy można od razu przejść do części o pliku .htaccess i uprawnieniach.
3. Ustalenie, czy przed serwerem działa usługa pośrednicząca. Jeżeli domena jest podpięta do sieci CDN z zaporą, w jej panelu należy otworzyć dziennik zdarzeń zabezpieczeń i przefiltrować go po godzinie żądania oraz po nazwie klienta zawierającej słowo Googlebot. Wpis w dzienniku wskazuje regułę, która zatrzymała żądanie.
4. Przejrzenie dziennika wtyczki zabezpieczającej w systemie strony. Wtyczki tego rodzaju prowadzą listę zablokowanych żądań z adresem IP, powodem blokady i godziną.
5. Otwarcie dziennika dostępu serwera w panelu hostingu. Należy wyszukać w nim wiersze ze słowem Googlebot i kodem 403. Jeżeli takie wiersze są, żądanie dotarło do serwera i zostało odrzucone przez serwer, plik .htaccess albo system strony. Jeżeli ich nie ma, żądanie zatrzymała warstwa przed serwerem.
6. Gdy żaden dziennik nie pokazuje blokady, a Search Console nadal ją zgłasza, pozostaje filtr po stronie dostawcy hostingu. Wtedy potrzebne jest zgłoszenie do pomocy technicznej, którego wzór znajduje się niżej.

Czy test z własnego komputera jest wiarygodny?

Popularna metoda polega na wysłaniu żądania, które przedstawia się jako Googlebot. Osoba obeznana z wierszem poleceń może użyć takiego polecenia, podstawiając własny adres:

curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://www.example.com/

W pierwszym wierszu odpowiedzi widać kod, na przykład 200 lub 403. Ten test wykrywa jednak tylko blokady oparte na nazwie robota. Nie pokaże blokady zakresu adresów IP ani blokady kraju, ponieważ żądanie wychodzi z polskiego łącza.

Jest też druga pułapka. Dobrze ustawiona zapora odrzuca żądania, które podają się za Googlebota, a przychodzą spoza sieci Google. Kod 403 w takim teście może więc oznaczać, że zabezpieczenie działa prawidłowo. Rozstrzygający jest zawsze test wersji opublikowanej w Search Console, a nie próba z własnego komputera.

Jak napisać zgłoszenie do dostawcy hostingu?

Pomoc techniczna odpowiada szybciej, gdy dostaje konkret. W zgłoszeniu można wykorzystać poniższą treść, uzupełniając dane w nawiasach:

„Search Console zgłasza dla domeny [nazwa domeny] błąd 403 przy żądaniach Googlebota. Przykładowy adres: [adres strony], data i godzina żądania: [z raportu Statystyki indeksowania]. W dzienniku dostępu konta nie widzę tego żądania albo widzę je z kodem 403. Proszę o sprawdzenie, czy zapora serwera lub filtr ruchu blokuje adresy IP robotów Google, oraz o dodanie ich do listy dozwolonych.”

Jak odblokować Googlebota we wtyczce, zaporze i usłudze CDN?

Zasada jest wspólna dla wszystkich narzędzi: nie wyłącza się całej ochrony, tylko poprawia tę jedną regułę, którą wskazał dziennik. Każdą zmianę należy wprowadzać pojedynczo i po każdej powtarzać test wersji opublikowanej.

Wtyczka zabezpieczająca w WordPressie

W ustawieniach wtyczki trzeba odszukać cztery obszary: listę zablokowanych adresów IP, limity liczby żądań, blokadę krajów oraz opcje dotyczące robotów. Nazwy tych miejsc różnią się między wtyczkami, dlatego warto otworzyć dokumentację używanego narzędzia i wyszukać w niej słowo Googlebot.

Na liście zablokowanych adresów należy poszukać zakresów należących do Google i je usunąć. W limitach żądań większość wtyczek ma osobne ustawienie dla zweryfikowanych robotów wyszukiwarek, które pozwala traktować je łagodniej niż nieznane programy. Jeżeli wtyczka ma opcję natychmiastowego blokowania fałszywych robotów Google, trzeba sprawdzić w jej dzienniku, czy nie uznaje za fałszywe także prawdziwych wizyt.

Gdy dziennik wtyczki nic nie pokazuje, dopuszczalny jest krótki test: wyłączenie wtyczki na kilka minut, uruchomienie testu wersji opublikowanej i ponowne włączenie. Uprzedzam, że w tym czasie strona jest słabiej chroniona, dlatego test wykonuje się raz, w spokojnej porze, i nie zostawia się wtyczki wyłączonej na dłużej.

Zapora i ochrona przed botami w usłudze CDN

W panelu usługi należy przejrzeć własne reguły zapory, reguły ograniczające liczbę żądań, ustawienia ochrony przed botami oraz blokady krajów. Szczególnej uwagi wymagają reguły z akcją blokowania lub z zadaniem weryfikacyjnym. Robot nie rozwiąże zadania przeznaczonego dla człowieka, więc dla Google taka reguła oznacza to samo co odmowa.

Dokumentacja Cloudflare ostrzega, że własne reguły oparte na adresie, ścieżce, kraju lub numerze sieci mogą niezamierzenie blokować znane roboty i szkodzić widoczności strony. Rozwiązaniem jest wyjątek dla zweryfikowanych robotów. W Cloudflare służy do tego pole „Known Bots”, zapisywane w wyrażeniu reguły jako cf.client.bot. Regułę blokującą uzupełnia się warunkiem, że nie dotyczy ona znanych robotów, albo tworzy się osobną regułę z akcją pominięcia i umieszcza ją wyżej na liście.

Jak naprawić plik .htaccess i uprawnienia plików?

Plik .htaccess znajduje się w głównym katalogu strony na serwerach Apache i LiteSpeed. Otwiera się go menedżerem plików w panelu hostingu albo programem FTP. Przed jakąkolwiek zmianą należy pobrać jego kopię na dysk. Jeden błędny znak w tym pliku potrafi wyłączyć całą stronę, a kopia pozwala wrócić do poprzedniego stanu w kilkanaście sekund. Zasady bezpiecznej pracy z tym plikiem opisałem przy okazji wpisu o przekierowaniach 301 w pliku .htaccess.

W pliku trzeba poszukać trzech rodzajów wpisów. Pierwszy to odmowa dla adresów IP. W starszym zapisie wygląda tak:

Deny from 66.249.

W nowszym zapisie ten sam skutek daje wiersz:

Require not ip 66.249.

Zakres zaczynający się od 66.249 należy do adresów, z których korzysta Googlebot. Aktualne zakresy Google publikuje w plikach z listami adresów, między innymi w pliku common-crawlers.json, więc każdy podejrzany wiersz można z nimi porównać.

Drugi rodzaj to blokada po nazwie robota. Zwykle składa się z warunku i reguły:

RewriteCond %{HTTP_USER_AGENT} (googlebot|bingbot|crawler|spider) [NC]
RewriteRule .* - [F,L]

Litera F w nawiasie kwadratowym oznacza właśnie odpowiedź 403. Jeżeli w nawiasie okrągłym występuje nazwa Googlebot albo ogólne słowa w rodzaju „bot”, „crawler” czy „spider”, reguła obejmuje także robota Google. Podobnie działają wiersze zaczynające się od SetEnvIfNoCase User-Agent, po których następuje odmowa dla oznaczonych żądań.

Trzeci rodzaj to ochrona katalogu hasłem albo odmowa dla wszystkich, pozostawiona po pracach nad stroną. Taki wpis bywa też w osobnym pliku .htaccess wewnątrz podkatalogu, dlatego przy blokadzie obejmującej jedną część serwisu trzeba zajrzeć również tam.

Znaleziony wiersz najlepiej najpierw wyłączyć, stawiając na jego początku znak #, zapisać plik i sprawdzić, czy strona działa. Dopiero po udanym teście w Search Console wiersz usuwa się na stałe. Na serwerach Nginx pliku .htaccess nie ma, a analogiczne reguły znajdują się w konfiguracji serwera, do której dostęp ma zwykle tylko administrator lub dostawca hostingu.

Uprawnienia i brak pliku startowego

Jeżeli kod 403 widzi także zwykły gość, należy sprawdzić uprawnienia w menedżerze plików. Na większości hostingów katalogi mają uprawnienia 755, a pliki 644. Wartości bardziej restrykcyjne, ustawione ręcznie lub przez wtyczkę, mogą odebrać serwerowi prawo odczytu. W razie wątpliwości właściwe wartości dla danego serwera podaje dostawca hostingu.

Jak odróżnić prawdziwego Googlebota od programu, który się pod niego podszywa?

Część blokad jest uzasadniona. Wiele programów zbierających treści przedstawia się jako Googlebot, licząc na łagodniejsze traktowanie. Zanim adres IP trafi na listę dozwolonych albo zostanie z niej usunięty, należy sprawdzić, do kogo naprawdę należy.

Google opisuje dwie metody. Pierwsza, ręczna, wymaga wiersza poleceń i sprawdza się przy pojedynczych adresach z dziennika.

1. Z dziennika serwera należy skopiować adres IP żądania, które przedstawiło się jako Googlebot.
2. W wierszu poleceń wpisuje się polecenie host z tym adresem, na przykład host 66.249.66.1. Jest to odwrotne wyszukiwanie DNS, które zamienia adres IP na nazwę.
3. Otrzymana nazwa powinna kończyć się na googlebot.com, google.com lub googleusercontent.com. Inna końcówka oznacza, że żądanie nie pochodzi od Google.
4. Następnie wpisuje się polecenie host z otrzymaną nazwą, na przykład host crawl-66-249-66-1.googlebot.com.
5. Wynik powinien wskazać ten sam adres IP, który był w dzienniku. Dopiero zgodność w obie strony potwierdza, że to prawdziwy robot Google.

Druga metoda polega na porównaniu adresu z listami zakresów IP, które Google udostępnia publicznie. Osobne listy obejmują popularne roboty, takie jak Googlebot, roboty specjalne, na przykład AdsBot, oraz narzędzia uruchamiane na żądanie użytkownika. Ta metoda nadaje się do automatyzacji i z niej korzystają zapory oraz usługi CDN, gdy same oznaczają roboty jako zweryfikowane.

Jak zgłosić poprawkę do Google i po czym poznać, że zadziałała?

Po zdjęciu blokady nie trzeba czekać bezczynnie, aż robot sam wróci. Search Console pozwala poprosić o sprawdzenie naprawy, a wcześniej samodzielnie upewnić się, że strony są już dostępne.

1. Na dwóch lub trzech adresach z listy należy ponownie uruchomić test wersji opublikowanej w narzędziu do sprawdzania adresów URL. Pole „Pobranie strony” powinno pokazać wartość „Udało się”.
2. Dla najważniejszych stron można w tym samym miejscu kliknąć „Poproś o zindeksowanie”. Obowiązuje dzienny limit takich próśb, dlatego używa się ich tylko dla kilku adresów o największym znaczeniu.
3. Następnie trzeba wrócić do raportu „Indeksowanie stron”, kliknąć wiersz z błędem 403 i na stronie szczegółów wybrać „Sprawdź poprawkę”.
4. Przycisku nie klika się ponownie, dopóki weryfikacja nie zakończy się powodzeniem lub niepowodzeniem. Postęp widać w historii weryfikacji, a Google wysyła też powiadomienia na adres e-mail.
5. Po kilku dniach warto zajrzeć do raportu „Statystyki indeksowania” i sprawdzić, czy liczba odpowiedzi z błędami po stronie klienta spada, a liczba poprawnych odpowiedzi rośnie.

Według pomocy Google weryfikacja trwa zwykle do 2 tygodni, a w niektórych przypadkach znacznie dłużej. Zaraz po kliknięciu Search Console sprawdza kilka stron. Jeżeli na którejś nadal znajdzie błąd, weryfikacja kończy się od razu i stan się nie zmienia. Jeżeli próbka jest czysta, stan zmienia się na „Rozpoczęto”, a po sprawdzeniu wszystkich znanych adresów na „Powodzenie”.

Jedna rzecz bywa myląca. Jeżeli raport jest przefiltrowany według konkretnej mapy witryny, weryfikacja obejmie tylko adresy z tej mapy. Przed kliknięciem „Sprawdź poprawkę” filtr powinien być ustawiony na wszystkie znane strony, chyba że zawężenie jest zamierzone.

Sam powrót stron do wyników wyszukiwania następuje stopniowo, bo adresy muszą zostać ponownie pobrane i ocenione. Jak sprawdzić stan indeksu krok po kroku, opisałem we wpisie o tym, co zrobić, gdy strona zniknęła z Google.

Co zrobić, gdy weryfikacja kończy się niepowodzeniem albo błąd wraca?

Stan „Niepowodzenie” oznacza, że Google nadal trafił na kod 403 przy części adresów. Na stronie szczegółów należy kliknąć „Sprawdź szczegóły” i przejrzeć adresy, na których weryfikacja się zatrzymała. Zwykle układają się we wzór.

Jeżeli błąd dotyczy jednego rodzaju adresów, na przykład tylko stron z parametrami albo tylko jednego katalogu, w grze jest reguła obejmująca ten wzorzec lub osobny plik .htaccess w podkatalogu. Jeżeli błąd pojawia się losowo na różnych stronach, przyczyną jest najczęściej limit liczby żądań: robot przez chwilę pobiera strony poprawnie, przekracza próg i dostaje odmowę.

Gdy błąd znika i wraca falami o podobnych porach, warto porównać godziny z raportu „Statystyki indeksowania” z porami zadań wykonywanych na serwerze, takich jak kopie zapasowe czy masowe importy. Przeciążony serwer lub jego zapora mogą w tych chwilach odrzucać część ruchu. Jeżeli obok kodu 403 w raporcie widać także błędy z grupy 5xx, pomocny będzie wpis o tym, jak ustalić przyczynę błędu serwera 5xx.

Po usunięciu pozostałych blokad na stronie szczegółów problemu wybiera się „Rozpocznij nową weryfikację”.

Jakich błędów unikać przy zdejmowaniu blokady?

Większość kłopotów, które widzę przy tym problemie, nie wynika z samej blokady, tylko z pochopnych prób jej usunięcia. Oto działania, od których radzę się powstrzymać:

• Wyłączenie zapory lub wtyczki zabezpieczającej na stałe. Strona bez ochrony szybko staje się celem ataków, a skutki włamania są dla widoczności gorsze niż błąd 403.
• Przepuszczanie każdego żądania z nazwą Googlebot. Nazwę da się podrobić, dlatego wyjątek musi opierać się na weryfikacji adresu.
• Zastąpienie odmowy 403 blokadą w pliku robots.txt dla stron, które mają być widoczne w Google. Robot przestanie zgłaszać błąd, ale strony nadal nie będą pobierane.
• Pokazywanie robotowi innej treści niż ludziom, aby obejść własne zabezpieczenia. Jest to niezgodne z zasadami Google i grozi konsekwencjami dla całej witryny.
• Edycja pliku .htaccess bez kopii oraz wprowadzanie kilku zmian jednocześnie. Po takiej serii poprawek nie wiadomo, która pomogła, a która coś zepsuła.
• Wielokrotne klikanie „Sprawdź poprawkę” przed zakończeniem weryfikacji. Nie przyspiesza to sprawdzania.

Najczęstsze pytania

Czy błąd 403 w Search Console oznacza karę od Google?

Nie. To informacja techniczna o odpowiedzi serwera, a nie ocena jakości strony ani ręczne działanie. Google informuje jedynie, że nie mógł pobrać adresu, więc nie ma czego zindeksować. Po przywróceniu dostępu strony wracają do normalnego obiegu bez żadnego odwołania.

Strona otwiera się w przeglądarce bez problemu. Dlaczego Google widzi odmowę?

Ponieważ zabezpieczenia oceniają gościa po adresie IP, kraju, nazwie programu i liczbie żądań. Robot Google różni się od zwykłego odwiedzającego w każdym z tych punktów: łączy się z zagranicznych adresów, przedstawia się jako robot i pobiera wiele stron w krótkim czasie. Reguła, która nie dotyka klienta w Polsce, może dotyczyć właśnie jego.

Jak szybko strony z błędem 403 wypadają z wyników wyszukiwania?

Google nie podaje konkretnego terminu. Dokumentacja mówi, że zaindeksowane adresy zwracające błąd z grupy 4xx są usuwane z indeksu, a robot odwiedza je coraz rzadziej. W praktyce krótka, kilkugodzinna blokada zwykle nie zostawia śladu, natomiast blokada trwająca dłużej stopniowo usuwa kolejne strony, zaczynając od tych odwiedzanych najczęściej.

Czy wystarczy poprosić o zindeksowanie, żeby błąd zniknął?

Nie, dopóki blokada trwa. Prośba o zindeksowanie uruchamia krótki test dostępności i przy odmowie 403 strona nie trafi do kolejki. Najpierw trzeba usunąć przyczynę, potwierdzić to testem wersji opublikowanej i dopiero wtedy zgłosić adres.

Błąd dotyczy tylko adresów panelu i katalogów technicznych. Czy trzeba coś robić?

Nie trzeba ich odblokowywać. Odmowa dostępu do panelu administracyjnego lub katalogu z plikami jest prawidłowa. Warto jedynie usunąć takie adresy z mapy witryny i z linków na publicznych stronach, aby robot nie tracił na nie czasu, a raport nie był zaśmiecony.

Czym różni się ten komunikat od błędu 401?

Kod 401 oznacza, że serwer żąda logowania, na przykład przez okno z hasłem ustawione na czas budowy strony. W Search Console odpowiada mu osobny wiersz „Strona zablokowana z powodu nieautoryzowanego żądania (401)”. Kod 403 to odmowa bez pytania o hasło. Dla Google skutek jest ten sam: strona nie zostaje zindeksowana.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Błąd 403 potrafi zabrać kilka wieczorów, zwłaszcza gdy blokują dwie warstwy naraz, a dostęp do części ustawień ma tylko dostawca hostingu. Chętnie przejmę to w całości. Sprawdzę w Search Console, których stron dotyczy problem, odnajdę w dziennikach regułę, która zatrzymuje robota Google, poprawię ją tak, aby zabezpieczenia strony pozostały szczelne, a na koniec zgłoszę poprawkę i dopilnuję, żeby strony wróciły do indeksu.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widzę po pierwszym sprawdzeniu i co proponuję zrobić dalej.