„Zablokowano z powodu nieautoryzowanego żądania (401)”. Co to oznacza dla strony?

W raporcie indeksowania w Google Search Console pojawia się wiersz „Zablokowano z powodu nieautoryzowanego żądania (401)”, a obok niego liczba adresów. Właściciel firmy widzi słowo „zablokowano” i zakłada, że strona została ukarana albo że ktoś się do niej włamał. W rzeczywistości komunikat mówi o czymś znacznie prostszym: serwer poprosił robota Google o login i hasło, a robot ich nie podał, bo nigdy tego nie robi.

Czasem jest to stan w pełni prawidłowy, na przykład gdy chodzi o panel klienta albo wersję testową serwisu. Czasem jednak oznacza, że ważna podstrona z ofertą jest dla Google niewidoczna, choć w przeglądarce właściciela otwiera się bez przeszkód. Różnica między tymi dwiema sytuacjami decyduje o tym, czy trzeba cokolwiek robić.

Ta instrukcja prowadzi przez cały proces: od odczytania listy adresów w raporcie, przez ustalenie, co dokładnie żąda logowania, po usunięcie blokady i potwierdzenie w Search Console, że Google znów ma dostęp. Po lekturze każdy, kto ma dostęp do panelu strony i do Search Console, powinien samodzielnie rozstrzygnąć, które adresy naprawić, a które świadomie zostawić zamknięte.

Co dokładnie oznacza komunikat o kodzie 401?

Każda odpowiedź serwera zaczyna się od trzycyfrowego kodu. Kod 200 oznacza, że strona została wydana poprawnie. Kod 401 oznacza, że serwer nie wyda treści, dopóki odwiedzający nie potwierdzi swojej tożsamości, zwykle loginem i hasłem. Przeglądarka pokazuje wtedy małe okno z dwoma polami albo stronę z komunikatem o braku autoryzacji.

Googlebot, czyli robot skanujący strony dla wyszukiwarki, nie wypełnia formularzy i nie zna żadnych haseł. Gdy dostaje kod 401, odnotowuje go i odchodzi bez treści. Pomoc Search Console opisuje to jednym zdaniem: strona została zablokowana dla Googlebota przez żądanie autoryzacji. W polskiej wersji pomocy ta pozycja nosi nazwę „Strona zablokowana z powodu nieautoryzowanego żądania (401)”, w samym raporcie bywa wyświetlana krócej, ale chodzi o ten sam stan.

Dla widoczności w wyszukiwarce skutek jest jednoznaczny. Zgodnie z dokumentacją Google adresy zwracające kody z grupy 4xx nie są indeksowane, a te, które były już w indeksie, są z niego usuwane. Google ignoruje też wszelką treść przesłaną razem z takim kodem. Robot będzie jeszcze wracał pod ten adres, ale coraz rzadziej.

Trzeba odróżnić ten komunikat od podobnego, z kodem 403. Kod 401 znaczy „proszę się przedstawić”, kod 403 znaczy „dostęp zabroniony, niezależnie od tego, kto pyta”. Przyczyny i sposoby naprawy częściowo się pokrywają, ale nie są identyczne. Osobno opisałem sytuację, w której raport pokazuje blokadę z powodu zabronionego dostępu (403).

Kiedy ten stan jest prawidłowy, a kiedy wymaga działania?

Sam wiersz w raporcie nie jest błędem do naprawienia za wszelką cenę. Search Console informuje, co robot zastał, a ocena należy do właściciela witryny. Wszystko zależy od odpowiedzi na jedno pytanie: czy dany adres miał być dostępny dla każdego bez logowania?

Jeżeli nie miał, hasło działa dokładnie tak, jak powinno. Dotyczy to między innymi poniższych miejsc.

• Wersja testowa lub robocza serwisu, na której przygotowuje się zmiany przed wdrożeniem.
• Panel klienta, strefa dla zalogowanych, konto w sklepie, zamknięte materiały szkoleniowe.
• Panel administracyjny i adresy techniczne, z których korzysta sam system strony.
• Pliki przeznaczone dla wąskiego grona, na przykład cenniki dla partnerów handlowych.

Działania wymaga sytuacja odwrotna: na liście znajdują się strona główna, podstrony usług, kategorie sklepu, produkty albo wpisy na blogu. To treści, które mają przyciągać klientów z wyszukiwarki, więc żądanie logowania jest w ich przypadku pomyłką w konfiguracji. Im dłużej trwa, tym więcej takich adresów wypada z wyników.

Zdarza się też wariant pośredni. Lista zawiera wyłącznie adresy zamknięte celowo, ale jest ich bardzo dużo i stale przybywa. Wtedy samej blokady nie należy ruszać, natomiast trzeba ustalić, skąd Google bierze te adresy, i ograniczyć ich skanowanie. Opisuję to w dalszej części.

Jak znaleźć w Search Console adresy objęte komunikatem?

Pierwsza czynność to obejrzenie konkretnych adresów. Bez tego każda dalsza decyzja będzie zgadywaniem. Lista znajduje się w raporcie indeksowania stron.

1. Po zalogowaniu do Google Search Console należy wybrać właściwą usługę z listy w lewym górnym rogu.
2. W menu po lewej stronie, w części „Indeksowanie”, trzeba kliknąć pozycję „Strony”.
3. Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Należy odszukać w niej wiersz z kodem 401 i kliknąć go.
4. Otwiera się strona szczegółów z wykresem liczby adresów w czasie oraz tabelą przykładów. Pomoc Google zastrzega, że lista nie musi zawierać wszystkich adresów z tym stanem i jest ograniczona do 1000 wierszy.
5. Listę warto pobrać przyciskiem eksportu w prawym górnym rogu i otworzyć w arkuszu kalkulacyjnym, bo łatwiej wtedy pogrupować adresy.

Na wykresie trzeba zwrócić uwagę na moment, w którym liczba adresów zaczęła rosnąć. Nagły skok jednego dnia zwykle pokrywa się z konkretną zmianą: uruchomieniem nowej wtyczki, przeniesieniem strony na inny serwer, włączeniem zabezpieczenia w panelu hostingu albo publikacją nowej wersji serwisu. Taka zbieżność bardzo skraca poszukiwania.

Adresy z listy najlepiej podzielić na trzy grupy. Pierwsza to strony, które mają być w Google. Druga to miejsca zamknięte celowo. Trzecia to adresy techniczne, których właściciel nie rozpoznaje, często zawierające fragmenty takie jak /wp-json/ albo długie ciągi parametrów. Każda grupa wymaga innego postępowania.

Przy każdym wierszu tabeli dostępna jest ikona sprawdzania, która otwiera dany adres w narzędziu do sprawdzania adresów URL. W wynikach, w części „Indeksowanie stron”, widać datę ostatniego skanowania oraz informację, skąd Google zna ten adres: z mapy witryny czy ze strony odsyłającej. Ta druga informacja przyda się przy porządkowaniu linków.

Skąd bierze się żądanie logowania? Najczęstsze przyczyny

Kod 401 nie pojawia się sam z siebie. Zawsze stoi za nim konkretne ustawienie na jednym z poziomów: serwera, systemu strony, wtyczki albo usługi pośredniczącej w ruchu. Poniżej przyczyny, które w praktyce spotyka się najczęściej.

Hasło na katalog pozostawione po budowie strony

Podczas tworzenia serwisu wykonawca często zabezpiecza całą domenę prostym hasłem na poziomie serwera, żeby nikt postronny nie oglądał niedokończonej pracy. To dobra praktyka. Kłopot zaczyna się wtedy, gdy strona zostaje oficjalnie uruchomiona, a zabezpieczenie zostaje na miejscu w całości albo na części katalogów. Właściciel tego nie zauważa, bo jego przeglądarka dawno zapamiętała hasło.

Wersja testowa, do której Google znalazł drogę

Adresy w rodzaju „test”, „dev” albo „staging” przed nazwą domeny powinny być zamknięte hasłem. Google potrafi je jednak odkryć: przez link pozostawiony w kodzie strony produkcyjnej, przez mapę witryny skopiowaną razem z serwisem albo przez odnośnik z zewnątrz. Robot próbuje wejść, dostaje kod 401 i raportuje go. W tym przypadku blokada jest właściwa, a do poprawy jest tylko źródło linków.

Wtyczka trybu przerwy technicznej lub ograniczenia dostępu

W WordPressie i innych systemach działają wtyczki, które zamykają stronę dla niezalogowanych: tryb konserwacji, strona „wkrótce otwarcie”, ochrona hasłem całej witryny, strefy członkowskie. Część z nich odpowiada kodem 401. Wystarczy, że ktoś włączył taki tryb na czas prac i nie wyłączył go po ich zakończeniu, albo że reguła dostępu objęła więcej podstron, niż planowano.

Adresy techniczne systemu strony

WordPress udostępnia interfejs dla aplikacji pod adresami zaczynającymi się od /wp-json/. Część tych adresów wymaga zalogowania i odpowiada kodem 401. Google trafia na nie, bo odnośniki do nich znajdują się w kodzie każdej podstrony. To normalne zachowanie systemu. Takie adresy nie zawierają treści dla klientów i nie powinny trafiać do wyników wyszukiwania.

Zapora, usługa ochronna albo ustawienie hostingu

Zapory aplikacyjne, sieci dostarczania treści i moduły bezpieczeństwa na serwerze potrafią wymagać dodatkowego potwierdzenia od ruchu, który uznają za podejrzany. Jeżeli reguła jest zbyt szeroka, obejmuje także roboty wyszukiwarek. Zwykli odwiedzający widzą wtedy stronę normalnie, a Googlebot dostaje żądanie autoryzacji. Ten wariant najtrudniej zauważyć, bo w przeglądarce właściciela wszystko wygląda poprawnie.

Treści dla zalogowanych podlinkowane z części publicznej

Sklepy i serwisy z kontami użytkowników mają wiele adresów dostępnych tylko po zalogowaniu: historia zamówień, lista życzeń, pliki do pobrania. Jeżeli prowadzą do nich zwykłe linki z menu albo stopki, robot za nimi podąża. Sam kod 401 jest tu poprawny, ale skala zjawiska bywa duża.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: ustalę, które z adresów na liście powinny być widoczne w Google, znajdę ustawienie żądające logowania i doprowadzę do ponownego zindeksowania tych podstron.

Jak sprawdzić, która przyczyna zachodzi?

Diagnozę zaczyna się od najprostszego testu i przechodzi do dokładniejszych tylko wtedy, gdy poprzedni nie dał odpowiedzi. Do pierwszych trzech czynności wystarczy przeglądarka i dostęp do Search Console.

1. Otwarcie adresu w oknie incognito. Tę metodę wskazuje sama pomoc Google. Tryb prywatny nie korzysta z zapamiętanych haseł ani z aktywnego logowania, więc pokazuje stronę tak, jak widzi ją obcy odwiedzający. Jeżeli pojawia się okno z prośbą o login i hasło albo strona logowania, przyczyna leży w zabezpieczeniu dostępnym dla wszystkich, a nie w regule wymierzonej w roboty.
2. Test w narzędziu do sprawdzania adresów URL. Adres należy wkleić w pole wyszukiwania u góry Search Console i zatwierdzić klawiszem Enter, a następnie kliknąć „Sprawdź URL wersji opublikowanej”. Narzędzie wysyła prawdziwe żądanie z infrastruktury Google i pokazuje, czy strona jest w tej chwili dostępna.
3. Porównanie obu wyników. Strona otwiera się w oknie incognito, a test Google kończy się niepowodzeniem? To wyraźna wskazówka, że blokada dotyczy wybranego ruchu, czyli zapory, usługi ochronnej albo reguły na serwerze.
4. Odczytanie nagłówków odpowiedzi. Osoba, która korzysta z wiersza poleceń, może wpisać curl -I https://adres-strony.pl/podstrona/ i przeczytać pierwsze wiersze odpowiedzi.
5. Przejrzenie dziennika serwera. W panelu hostingu dostępne są logi dostępu. Trzeba odszukać w nich wpisy z kodem 401 i sprawdzić, jakich adresów dotyczą oraz kto o nie pytał.

W wyniku polecenia z punktu czwartego najważniejsze są dwa wiersze. Pierwszy zawiera kod, na przykład HTTP/2 401. Drugi to nagłówek www-authenticate. Jeżeli ma on postać Basic realm="...", hasło zostało założone na poziomie serwera, najczęściej w pliku .htaccess albo w panelu hostingu. Jeżeli nagłówka nie ma, a treść odpowiedzi ma format danych z komunikatem o braku uprawnień, źródłem jest system strony albo wtyczka.

Pomocny bywa także raport „Statystyki indeksowania”, dostępny w Search Console po kliknięciu „Ustawienia”. Pokazuje on odpowiedzi serwera na żądania robota z podziałem na rodzaje, w tym grupę „Brak autoryzacji (401/407)” z przykładowymi adresami. Dzięki temu widać, czy problem dotyczy pojedynczych adresów, czy znacznej części ruchu Googlebota.

Przy wtyczkach skuteczna jest metoda wyłączania po kolei. Należy to robić ostrożnie: przed jakąkolwiek zmianą trzeba mieć aktualną kopię zapasową, a najlepiej testować na kopii serwisu, nie na działającym sklepie w godzinach sprzedaży.

Jak usunąć blokadę, gdy strona ma być widoczna w Google?

Naprawa zależy od tego, co ustaliła diagnoza. Zasada jest wspólna: publiczna podstrona ma odpowiadać kodem 200 każdemu, kto o nią poprosi, bez okna logowania i bez wyjątków dla wybranych odwiedzających.

Hasło założone na serwerze

Na serwerach Apache i LiteSpeed zabezpieczenie hasłem zapisuje się w pliku .htaccess, który leży w głównym katalogu strony albo w chronionym podkatalogu. Odpowiadają za nie wiersze podobne do poniższych.

AuthType Basic
AuthName "Strefa chroniona"
AuthUserFile /sciezka/do/.htpasswd
Require valid-user

Usunięcie tych czterech wierszy wyłącza żądanie hasła dla danego katalogu. Przed edycją trzeba pobrać kopię pliku na dysk, ponieważ jeden błędny znak w .htaccess potrafi unieruchomić całą witrynę. Jeżeli coś pójdzie źle, wystarczy wgrać poprzednią wersję.

Bezpieczniejsza droga prowadzi przez panel hostingu. Większość dostawców ma tam funkcję o nazwie zbliżonej do „Katalogi chronione hasłem” lub „Prywatność katalogów”. Wystarczy odszukać katalog strony i wyłączyć ochronę. Panel sam poprawi plik konfiguracyjny. Na serwerach Nginx odpowiednie ustawienie znajduje się w konfiguracji serwera, do której zwykle ma dostęp tylko administrator, więc zmianę trzeba zlecić obsłudze hostingu.

Wtyczka lub tryb przerwy technicznej

W panelu administracyjnym strony należy przejrzeć listę aktywnych wtyczek pod kątem tych, które ograniczają dostęp. Tryb konserwacji trzeba wyłączyć w ustawieniach wtyczki, a nie tylko zamknąć kartę z komunikatem. W przypadku stref członkowskich trzeba sprawdzić reguły: która kategoria, typ treści albo adres zostały oznaczone jako dostępne wyłącznie po zalogowaniu. Najczęstsza pomyłka to reguła obejmująca cały typ treści zamiast kilku wybranych stron.

Po każdej zmianie należy wyczyścić pamięć podręczną strony i serwera. W przeciwnym razie przez pewien czas odwiedzający i roboty mogą nadal otrzymywać zapisaną wcześniej odpowiedź.

Zapora lub usługa ochronna

W panelu zapory albo sieci dostarczania treści trzeba otworzyć dziennik zdarzeń i odszukać zablokowane żądania z ostatnich dni. Przy każdym widać regułę, która zadziałała. Tę regułę należy złagodzić albo dodać do niej wyjątek dla zweryfikowanych robotów wyszukiwarek. Wiele usług ma gotową kategorię znanych, potwierdzonych robotów, co jest znacznie bezpieczniejsze niż własnoręczne wpisywanie adresów.

Jeżeli właściciel nie ma dostępu do takich ustawień, wystarczy zgłoszenie do obsługi hostingu. Może ono brzmieć tak: Proszę o sprawdzenie, dlaczego serwer odpowiada kodem 401 na żądania Googlebota dla adresu [adres podstrony]. W przeglądarce strona otwiera się poprawnie. Proszę o wskazanie reguły, która wymaga autoryzacji, i o jej wyłączenie dla zweryfikowanych robotów Google.

Mapa witryny i linki wewnętrzne

Po zdjęciu blokady warto upewnić się, że odblokowane adresy są w mapie witryny i że prowadzą do nich linki z innych podstron. Ułatwia to robotowi szybki powrót. Jeżeli przy okazji okaże się, że z wyników zniknęło więcej podstron, niż wynikałoby z raportu, pomoże lista kontrolna z tekstu o tym, co sprawdzić, gdy strona zniknęła z Google.

Co zrobić z adresami, które mają pozostać zamknięte?

Hasła z wersji testowej, panelu klienta czy zamkniętych materiałów nie należy zdejmować tylko po to, żeby wiersz zniknął z raportu. To zabezpieczenie spełnia swoją rolę. Usunięcie go z wersji testowej grozi tym, że Google zindeksuje kopię całego serwisu, a zdjęcie go ze strefy klienta może odsłonić dane, które nie powinny być publiczne.

W takim przypadku komunikat można po prostu przyjąć do wiadomości. Jeżeli jednak adresów jest dużo, warto uporządkować trzy rzeczy.

• Mapa witryny. Powinna zawierać wyłącznie adresy publiczne. Strony wymagające logowania trzeba z niej wykluczyć w ustawieniach wtyczki, która mapę tworzy.
• Linki. Odnośniki do wersji testowej pozostawione w treści albo w szablonie strony produkcyjnej należy poprawić na właściwe adresy.
• Skanowanie. Pomoc Google przy raporcie statystyk indeksowania podpowiada, że strony wymagające autoryzacji można wyłączyć ze skanowania w pliku robots.txt.

Dla strefy klienta odpowiedni wpis w pliku robots.txt może wyglądać tak: Disallow: /panel-klienta/, umieszczony pod wierszem User-agent: *. Nazwę katalogu trzeba oczywiście dopasować do własnego serwisu. Ten plik wymaga uwagi, bo zbyt szeroka reguła odcina robota od całej witryny. Szczegóły opisałem w tekście o tym, jak ustawić plik robots.txt.

Trzeba przy tym rozumieć różnicę między obiema metodami. Plik robots.txt jest prośbą skierowaną do uczciwych robotów i niczego nie chroni. Hasło chroni naprawdę. Dlatego treści poufne zawsze zabezpiecza się logowaniem, a robots.txt służy wyłącznie do tego, żeby robot nie odwiedzał bez potrzeby adresów, do których i tak nie wejdzie.

Gdy adres z zamkniętej strefy był wcześniej publiczny i nadal widnieje w wynikach, można przyspieszyć jego zniknięcie. Służy do tego raport „Usunięcia” w Search Console, w którym na karcie „Tymczasowe usunięcia” klika się „Nowa prośba”. Według pomocy Google taka prośba ukrywa adres na około 6 miesięcy, a w tym czasie hasło lub inna trwała blokada powinny pozostać włączone.

Czy można wpuścić tylko Googlebota, a resztę zostawić za hasłem?

Pomoc Google wymienia dwie drogi: usunięcie wymogu autoryzacji albo zezwolenie Googlebotowi na dostęp po zweryfikowaniu jego tożsamości. Druga droga jest technicznie możliwa, ale wymaga ostrożności. Nazwę robota w żądaniu może wpisać każdy, więc wyjątek oparty wyłącznie na niej otwiera chronioną treść przed każdym, kto się pod Googlebota podszyje.

Google opisuje, jak potwierdzić, że żądanie rzeczywiście pochodzi z jego infrastruktury. Metoda ręczna polega na dwóch zapytaniach do systemu nazw domen.

1. Z dziennika serwera odczytuje się adres IP, z którego przyszło żądanie.
2. W wierszu poleceń wpisuje się host i ten adres, na przykład host 66.249.66.1. Wynik powinien wskazać nazwę kończącą się na googlebot.com, google.com albo googleusercontent.com.
3. Następnie tym samym poleceniem sprawdza się otrzymaną nazwę. Wynik powinien zwrócić ten sam adres IP, który był w dzienniku.

Dla większej liczby żądań Google publikuje listy zakresów adresów IP swoich robotów w plikach, między innymi common-crawlers.json. Zapory i usługi ochronne zwykle korzystają z tych list samodzielnie, dlatego wyjątek najlepiej ustawiać w nich, wybierając gotową kategorię zweryfikowanych robotów.

Trzeba też pamiętać o zasadach wyszukiwarki. Pokazywanie robotowi innej treści niż ludziom, żeby poprawić pozycje, jest przez Google traktowane jako naruszenie zasad dotyczących spamu. Dla treści płatnych i dostępnych w subskrypcji Google przewidział osobne oznaczenia w danych strukturalnych, które pozwalają zgodnie z zasadami poinformować, że część treści jest za barierą. Wdrożenie tego rozwiązania radzę powierzyć osobie z doświadczeniem technicznym. Dla zwykłej strony firmowej prostsza i bezpieczniejsza jest zasada: treść publiczna bez hasła, treść prywatna za hasłem dla wszystkich.

Jak potwierdzić, że naprawa zadziałała?

Po zmianach nie należy czekać biernie na aktualizację raportu. Efekt da się sprawdzić w kilka minut, a następnie zgłosić Google prośbę o ponowną ocenę.

1. Otwarcie naprawionego adresu w oknie incognito. Strona powinna wyświetlić się w całości, bez prośby o hasło.
2. Wklejenie adresu w narzędziu do sprawdzania adresów URL i kliknięcie „Sprawdź URL wersji opublikowanej”. Oczekiwany wynik to informacja „Google ma dostęp do adresu URL”.
3. Kliknięcie „Wyświetl przetestowaną stronę” i obejrzenie karty ze zrzutem ekranu. Ma na niej być widać właściwą treść podstrony, a nie formularz logowania.
4. Kliknięcie „Poproś o zindeksowanie” dla najważniejszych adresów. Google stosuje dzienny limit takich próśb, więc trzeba wykorzystać je na strony o największym znaczeniu dla sprzedaży.
5. Powrót do raportu „Strony”, otwarcie wiersza z kodem 401 i kliknięcie „Sprawdź poprawkę”.

Ostatni krok uruchamia weryfikację wszystkich adresów z listy. Search Console od razu sprawdza kilka przykładowych stron. Jeżeli na którejś nadal znajdzie ten sam stan, weryfikacja kończy się natychmiast, dlatego przycisk klika się dopiero po naprawieniu wszystkich adresów, które miały zostać naprawione. Pomoc Google prosi też, żeby nie klikać go ponownie, dopóki weryfikacja się nie zakończy.

Według dokumentacji weryfikacja zajmuje zazwyczaj do 2 tygodni, a czasem znacznie dłużej. O jej wyniku Google informuje wiadomością e-mail. Stan „Rozpoczęto” oznacza, że proces trwa i dotąd nie znaleziono kolejnych wystąpień. Stan „Powodzenie” oznacza, że wszystkie znane adresy są już wolne od problemu. Stan „Niepowodzenie” oznacza, że przynajmniej część nadal odpowiada kodem 401.

Jeżeli na liście były zarówno strony do naprawy, jak i miejsca zamknięte celowo, weryfikacja prawdopodobnie zakończy się niepowodzeniem, bo zamknięte adresy dalej żądają hasła. To nie jest powód do niepokoju. Miarą sukcesu jest wtedy to, czy naprawione podstrony wróciły do wyników, co opisałem w tekście o tym, jak sprawdzić, czy Google zaindeksował stronę.

Co zrobić, gdy komunikat nie znika, i jakich błędów unikać?

Jeżeli po kilku tygodniach raport nadal pokazuje naprawione adresy, najpierw trzeba spojrzeć na datę ostatniego skanowania przy konkretnym adresie. Google podkreśla w pomocy, że wpis często dotyczy wizyty robota sprzed naprawy. Wtedy wystarczy poczekać na kolejne skanowanie albo ponowić prośbę o zindeksowanie.

Gdy test Google wciąż kończy się kodem 401

Jeśli test wersji opublikowanej nadal pokazuje brak dostępu, a w przeglądarce strona działa, blokada ma drugą warstwę. Typowe miejsca to pamięć podręczna, która przechowuje starą odpowiedź, zapora działająca przed serwerem oraz reguła hostingu niezależna od ustawień strony. Warto też sprawdzić wszystkie warianty adresu: z przedrostkiem „www” i bez niego oraz z ukośnikiem na końcu i bez niego, ponieważ zabezpieczenie bywa założone tylko na jeden z nich.

Pomaga ponowne przejrzenie dziennika serwera z ostatnich dni. Jeżeli wpisy z kodem 401 dla Googlebota przestały się pojawiać, naprawa działa i pozostaje cierpliwość. Jeżeli pojawiają się nadal, dziennik pokaże dokładny adres i godzinę, co wystarczy obsłudze hostingu do wskazania odpowiedzialnej reguły.

Błędy, które pogarszają sytuację

W tej sprawie kilka pomyłek powtarza się szczególnie często. Każda z nich albo niczego nie naprawia, albo tworzy nowy problem.

• Zdjęcie hasła z wersji testowej, żeby „wyczyścić” raport. Skutkiem bywa kopia serwisu w wynikach wyszukiwania.
• Zablokowanie w robots.txt podstron, które mają być w Google. Robot przestaje je odwiedzać, komunikat się zmienia, ale strona nadal nie jest indeksowana.
• Wyjątek dla Googlebota oparty tylko na nazwie robota, bez weryfikacji adresu IP.
• Używanie kodu 401 do spowalniania robota. Dokumentacja Google wprost zaleca, żeby kodów 401 i 403 nie stosować do ograniczania szybkości skanowania.
• Wielokrotne klikanie „Sprawdź poprawkę” w trakcie trwającej weryfikacji.
• Edycja pliku .htaccess bez kopii i bez możliwości szybkiego przywrócenia poprzedniej wersji.

Najczęstsze pytania

Czy kod 401 oznacza karę od Google albo włamanie na stronę?

Nie. Komunikat opisuje wyłącznie odpowiedź serwera na wizytę robota: serwer zażądał logowania. Nie ma związku z ręcznymi działaniami Google ani z oceną jakości witryny. Nie jest też sam w sobie dowodem włamania, choć jeżeli nikt z osób opiekujących się stroną nie zakładał hasła, warto ustalić, kto i kiedy zmienił ustawienia.

Czy takie adresy obniżają pozycje pozostałych podstron?

Adres odpowiadający kodem 401 po prostu nie jest indeksowany, a jeżeli wcześniej był w wynikach, zostaje z nich usunięty. Dokumentacja Google nie opisuje żadnej kary dla reszty serwisu z tego tytułu. Strata jest bezpośrednia: zablokowana podstrona nie wyświetla się w wyszukiwarce i nie przyciąga odwiedzających.

Jak szybko naprawiona strona wróci do wyników?

Google nie podaje gwarantowanego terminu. Pomoc Search Console informuje, że indeksowanie po zgłoszeniu prośby trwa zwykle jeden dzień, ale bywa dłuższe, a samo zgłoszenie nie daje pewności, że strona znajdzie się w indeksie. Weryfikacja poprawki dla całej listy adresów zajmuje zazwyczaj do 2 tygodni.

Dlaczego na liście są adresy zawierające wp-json?

To adresy interfejsu, z którego korzystają aplikacje i wtyczki WordPressa. Część z nich z założenia wymaga zalogowania, a Google trafia na nie przez odnośniki w kodzie strony. Nie zawierają treści przeznaczonej dla klientów, więc ich obecność w tym wierszu raportu jest neutralna i nie wymaga naprawy.

Czy wystarczy poprosić o zindeksowanie bez usuwania hasła?

Nie. Przed dodaniem strony do kolejki Google wykonuje krótki test. Jeżeli test wykaże, że strony nie da się zindeksować, prośba nie zostanie przyjęta. Najpierw trzeba usunąć żądanie logowania, a dopiero potem zgłaszać adres.

Czy lepiej zamknąć wersję testową hasłem, czy plikiem robots.txt?

Hasłem. Plik robots.txt nie chroni treści i nie zapobiega wejściu ludzi ani nieuczciwych robotów, a zablokowany w nim adres może mimo to pojawić się w wynikach bez opisu. Hasło zamyka dostęp skutecznie. Wiersz z kodem 401 w raporcie jest w tym przypadku potwierdzeniem, że zabezpieczenie działa.

Strona w przeglądarce działa poprawnie. Dlaczego Google widzi kod 401?

Są dwa typowe wyjaśnienia. Pierwsze: przeglądarka zapamiętała hasło albo właściciel jest zalogowany, co wyjaśni test w oknie incognito. Drugie: zapora lub usługa ochronna traktuje ruch robotów inaczej niż ruch zwykłych odwiedzających, co pokaże test wersji opublikowanej w Search Console.

Co zrobić, jeśli liczba adresów z kodem 401 stale rośnie?

Rosnąca liczba oznacza, że Google wciąż odkrywa nowe adresy wymagające logowania. Trzeba ustalić ich wspólny wzorzec, na przykład katalog albo parametr w adresie, a potem znaleźć miejsce, z którego prowadzą do nich linki. Najczęściej wystarcza poprawienie szablonu strony, uporządkowanie mapy witryny i wyłączenie zamkniętego katalogu ze skanowania.

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

To zrozumiałe. Kody odpowiedzi serwera, pliki konfiguracyjne i reguły zapory nie są zajęciem, na które osoba prowadząca firmę ma wolne popołudnie. Mogę zająć się tym od początku do końca: przejrzę listę adresów w Search Console, oddzielę strony, które mają być w Google, od tych zamkniętych celowo, ustalę źródło żądania logowania, usunę je albo przekażę obsłudze hostingu dokładną informację, co zmienić, a potem dopilnuję weryfikacji poprawki i powrotu podstron do wyników.

Wystarczy telefon pod numer 533 525 168 albo wiadomość na adres info@lukaszwudyka.pl z adresem strony i krótkim opisem tego, co pokazuje raport. Odpowiem, co da się ustalić od razu i jak będzie wyglądała dalsza praca.