Zablokowano z powodu nieautoryzowanego żądania (401)

TL;DR — „Blocked due to unauthorized request (401)” oznacza, że Googlebot próbował odczytać stronę, ale poproszono go o zalogowanie. Google nie ma hasła do Twojej witryny, więc rezygnuje, a strony nie można zindeksować. Jeśli chcesz, aby ta strona znalazła się w Google, coś blokuje ją niepotrzebnie — zwykle pozostała ochrona logowaniem, hasło witryny stagingowej albo reguła bezpieczeństwa, która przez pomyłkę blokuje Google. Jeśli strona ma być prywatna, jest to normalne i niczego nie trzeba naprawiać.

Co oznacza ten status

Etykieta tego raportu oznacza, że Google otrzymał odpowiedź autoryzacji HTTP 401 dla adresu URL. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Google traktuje trwałą odpowiedź 4xx inną niż 429 jako niedostępną treść na potrzeby indeksowania. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Gdy w raporcie indeksowania stron Google Search Console widzisz „Blocked due to unauthorized request (401)”, oznacza to: Googlebot próbował pobrać adres URL, a serwer odpowiedział kodem HTTP 401, czyli „wymagane jest uwierzytelnienie” — w praktyce „musisz się zalogować”.

Googlebot nie ma nazwy użytkownika ani hasła do Twojej witryny i nigdy ich nie będzie miał. Gdy więc strona wymaga logowania, Googlebot nie może wejść, przeczytać treści ani jej zindeksować. Jeśli strona była wcześniej w Google, a potem zaczęła zwracać 401, Google z czasem usunie ją z wyników.

Czy to problem?

To zależy od tego, czy chcesz, aby ta strona była w Google:

• Chcesz ją zindeksować → tak, to problem. Coś stawia ścianę logowania przed stroną, która powinna być publiczna. Musisz ustalić, co ją blokuje, i otworzyć dostęp.
• Strona jest prywatna lub stagingowa → nie, wszystko działa zgodnie z zamiarem. 401 to właściwy sposób na utrzymanie prywatnego obszaru poza Google i nie należy osłabiać tej bramki tylko po to, aby usunąć ten wiersz z raportu. Sprawdź jedynie, czy ten adres URL w ogóle powinien być linkowany, umieszczony w mapie witryny lub zgłoszony w tej usłudze Search Console.

„Ale ta strona ładuje się u mnie bez problemu!”

To najczęstsze źródło nieporozumień. Otwierasz adres URL w przeglądarce i działa — jak więc Google może twierdzić, że jest zablokowany? Ponieważ jesteś zalogowany (albo Twój firmowy adres IP jest na liście dozwolonych), a Googlebot nie jest. Widzisz stronę za bramką, podczas gdy Googlebot trafia na bramkę. Aby zobaczyć to, co widzi Google, przetestuj stronę jako anonimowy użytkownik — karta Advanced pokaże, jak to zrobić.

Co zwykle jest przyczyną

• Witryna stagingowa lub testowa pozostawiona za hasłem.
• Ochrona logowaniem przypadkowo pozostawiona na sekcji, która powinna być publiczna.
• Narzędzie bezpieczeństwa lub CDN (np. Cloudflare) przez pomyłkę blokujący Googlebota.
• Prawdziwa ściana logowania na treści, które miały być ograniczone do użytkowników (np. tylko dla członków).

Chcesz poznać rzeczywiste kroki diagnostyczne, różnicę między 401 a 403 oraz dokładne metody naprawy? Przejdź do karty Advanced.

TL;DR — „Blocked due to unauthorized request (401)” oznacza, że Googlebot otrzymał HTTP 401 (Unauthorized) — bramkę uwierzytelniania, której nie może przejść. Google nigdy nie podaje danych uwierzytelniających, więc nie widzi treści: strona nie zostanie zindeksowana, a wcześniej zindeksowany adres URL z czasem wypadnie z indeksu. 401 a 403, precyzyjnie według RFC 9110: 401 oznacza brak prawidłowych danych uwierzytelniających (nie wysłano ich albo serwer je odrzucił), a 403 — że serwer zrozumiał żądanie, lecz odmówił jego realizacji z powodów, które nie zawsze dotyczą danych uwierzytelniających. Google traktuje wszystkie 4xx poza 429 tak samo dla indeksowania, więc skutek jest taki sam, ale przyczyna i naprawa zależą od rodzaju strony: usuń wymaganie autoryzacji z przypadkowo zablokowanej strony publicznej; przepuść zweryfikowanego Googlebota przez IP/odwrotny DNS (nigdy przez łatwy do podrobienia user-agent), gdy blokuje go ochrona botów; zachowaj uwierzytelnianie dla rzeczywiście prywatnej treści lub stagingu; użyj danych strukturalnych paywalla Google zamiast ogólnego 401 dla indeksowalnej treści subskrypcyjnej. „U mnie działa” to pułapka — jesteś uwierzytelniony, a Googlebot nie. Nie używaj 401/403 do ograniczania crawlowania. Diagnozuj jako bot (URL Inspection Live Test, curl -I) — brak nagłówka WWW-Authenticate oznacza wadliwą odpowiedź, a nie dowodzi, że jej źródłem jest WAF. Live Test i Validate Fix potwierdzają dostęp, nie indeksowanie, a Google nie opublikował harmonogramu ponowień.

Co Google naprawdę komunikuje

Etykieta Page Indexing podaje odpowiedź zaobserwowaną przez Google, ale nie wskazuje, która reguła uwierzytelniania, CDN-u lub aplikacji ją wygenerowała. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Mechanizm indeksowania wynika z udokumentowanego przez Google traktowania odpowiedzi 4xx. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

Status pochodzi bezpośrednio z kodu odpowiedzi serwera. Googlebot zażądał adresu URL i otrzymał HTTP 401, czyli status „Unauthorized” — strona znajduje się za bramką uwierzytelniania (HTTP Basic Auth, ścianą logowania lub regułą kontroli dostępu). Własna definicja Google w raporcie Page Indexing mówi, że strona została zablokowana przed Googlebotem przez żądanie autoryzacji; jeśli chcesz ją zindeksować, musisz albo usunąć wymaganie autoryzacji, albo przepuścić Googlebota po zweryfikowaniu jego tożsamości.

W moim własnym tekście Wpływ kodów statusu HTTP na SEO opisuję 401 jako sytuację, w której klient nie zidentyfikował się ani nie zweryfikował, gdy było to potrzebne — to użyteczny model mentalny, ale nie pełna definicja protokołu. Dokładna reguła z RFC 9110 brzmi: żądaniu brakuje prawidłowych danych uwierzytelniających do zasobu, a 401 może nastąpić również po odrzuceniu danych przez serwer. 401 nie zawsze oznacza więc, że Googlebot (albo przeglądarka) nie wysłał niczego — tylko że przedstawione dane nie były prawidłowe. Praktyczny skutek dla Googlebota jest taki sam: nie ma on danych, które mógłby zaoferować, więc nie przechodzi przez bramkę.

Co Google robi z kodem 401

Nic dobrego, jeśli zależało Ci na indeksowaniu strony. Dokumentacja Google dotycząca statusów HTTP wyraźnie mówi, że wszystkie błędy 4xx poza 429 są traktowane tak samo — crawlery informują kolejny system przetwarzania, że treść nie istnieje. 401 w praktyce przekazuje Google komunikat „tej strony tu nie ma”. Konsekwencje są następujące:

• Strona nie zostanie zindeksowana. Google nie zobaczyło treści, więc nie ma czego indeksować.
• Wcześniej zindeksowana strona wypadnie z indeksu. Nie jest to wyjątkowe zachowanie kodu 401 — dotyczy całej rodziny 4xx. Jak piszę w tekście Ahrefs o statusach HTTP, “4xxs will cause pages to drop from the index.” (tłumaczenie) «Kody 4xx powodują wypadanie stron z indeksu.» Jeśli strona wcześniej zindeksowana przez Google zacznie zwracać 401, kolejne crawle doprowadzą z czasem do usunięcia adresu URL.
• Nie ogranicza to crawlowania. Google mówi wprost: nie używaj statusów 401 i 403 do ograniczania tempa crawlowania. 4xx (poza 429) nie wpływa na tempo, więc 401 nie jest pokrętłem „zwolnij” — do tego służą 503 i 429.

Jednej rzeczy nie zamierzam Ci obiecywać: konkretnego harmonogramu ponowień. Google ponownie crawluje strony z czasem, ale dokumentacja nie publikuje gwarantowanego planu „Googlebot ponowi próbę 401 co N dni”, więc nie będę go udawać. Traktuj ponowny crawl jak coś, co nastąpi kiedyś, a nie jak stoper.

401 a 403 i inne 4xx — różnica, która ma znaczenie

To rozróżnienie jest w większości tekstów zacierane, a właśnie ono daje tu największą wartość. Dla indeksowania Google traktuje 401 i 403 identycznie (zasada 4xx poza 429). Przyczyna i naprawa są jednak różne, ponieważ kody oznaczają różne rzeczy:

• 401 Unauthorized według definicji RFC 9110 — żądaniu brakuje prawidłowych danych uwierzytelniających do zasobu. Obejmuje to dwa przypadki: nie wysłano żadnych danych albo dane wysłano, lecz serwer je odrzucił. Zgodna odpowiedź 401 musi zawierać nagłówek WWW-Authenticate z co najmniej jednym wyzwaniem. Moje krótkie ujęcie — „klient nie zidentyfikował się ani nie zweryfikował, gdy było to potrzebne” — jest użytecznym skrótem typowego przypadku, ale nie pełną definicją.
• 403 Forbidden według tego samego RFC — serwer zrozumiał żądanie, ale odmawia jego realizacji. Dane uwierzytelniające są jedną z możliwych przyczyn, lecz specyfikacja wyraźnie dopuszcza odmowę z powodów „niezwiązanych z danymi uwierzytelniającymi”. 403 nie zawsze oznacza więc „klient jest znany/uwierzytelniony, ale nie ma uprawnień” — to częsty wzorzec, nie gwarancja. W raporcie Page Indexing Google 403 dla Googlebota, który nigdy nie wysyła danych uwierzytelniających, zwykle oznacza błędną odpowiedź serwera — często źle skonfigurowaną zaporę, WAF albo regułę botów. Istnieje osobny status Blocked due to access forbidden (403), a ścieżka diagnozy w dużej mierze się pokrywa.

Praktyczny skrót nadal pomaga w triage: 401 ≈ „bramka uwierzytelniania, której nie zdjąłem” (witryna stagingowa lub pozostawione HTTP auth), a 403 ≈ „reguła bezpieczeństwa błędnie blokująca Googlebota”. Skutek indeksowania jest ten sam, a przyczyna inna — nie traktuj jednak żadnego skrótu jako granicy protokołu. Tabela decyzyjna znajduje się w karcie Cheat Sheets.

Dlaczego widzisz ten status — typowe przyczyny

Na stronie, którą rzeczywiście chcesz zindeksować, kod 401 prawie zawsze wynika z jednej z następujących przyczyn:

• Witryna stagingowa lub deweloperska za Basic Auth. Zabezpieczyłeś środowisko stagingowe hasłem (słusznie), ale Google w jakiś sposób odkrył adres URL — przez link wewnętrzny, mapę witryny albo ujawnione odwołanie — i teraz raportuje 401. Jeśli adres stagingowy rzeczywiście nie powinien być publiczny, jest to oczekiwane (zobacz sekcję o celowym 401).
• Przypadkowe HTTP auth na publicznej sekcji. Reguła .htpasswd, wtyczka „coming soon” albo bramka trybu konserwacji została pozostawiona na katalogu, który powinien być już aktywny.
• WAF / CDN / lista dozwolonych adresów IP blokująca Googlebota. To podstępny przypadek. Cloudflare, Akamai, Sucuri albo lista geograficzna zwraca 401 (lub 403) adresom IP Googlebota, a ludziom obsługuje stronę normalnie. Strona „działa dla wszystkich”, bo osoby testujące korzystają z dozwolonego adresu IP.
• Ściana logowania na treści subskrypcyjnej lub za paywallem, którą chcesz indeksować. Ogólny 401 całkowicie odcina Googlebota — naprawą nie jest osłabienie bramki, lecz wspierane przez Google dane strukturalne paywalla (zobacz czwartą gałąź poniżej).

Jak diagnozować — testuj jak bot, nie jak przeglądarka

Największa pułapka brzmi „u mnie działa”. Oczywiście, że działa — jesteś uwierzytelniony, Twój adres IP znajduje się na liście dozwolonych albo przeglądarka ma ciasteczko sesji. Googlebot nie ma niczego z tego. Diagnozuj więc jak bot:

• URL Inspection → Live Test (GSC). To najbliższy odpowiednik podglądu odpowiedzi, którą otrzymuje Googlebot. Uruchom test dla danego adresu URL; jeśli pobranie kończy się niepowodzeniem z powodu autoryzacji, potwierdzasz, że 401 jest rzeczywisty i powtarzalny.

• curl -I w kontekście bez uwierzytelnienia. Zażądaj adresu URL bez ciasteczek i danych uwierzytelniających, a następnie odczytaj wiersz statusu:

  curl -I https://www.example.com/page/
  # Look for:  HTTP/1.1 401 Unauthorized
  # and a WWW-Authenticate: header confirming an auth gate

  Jeśli curl (który nie wysyła sesji ani danych auth) otrzymuje 401, a przeglądarka 200, ta różnica jest błędem — przeglądarka jest uwierzytelniona, a Googlebot nie. RFC 9110 wymaga, aby zgodna odpowiedź 401 zawierała nagłówek WWW-Authenticate; jego obecność potwierdza prawdziwe wyzwanie uwierzytelniania. Brak nagłówka nie rozstrzyga jednak sprawy: oznacza, że odpowiedź jest wadliwa lub niepełna, ale nie wskazuje warstwy, która ją wygenerowała. Nie zakładaj od razu, że „to musi być WAF”.

• Sprawdź, czy blokada zależy od IP. Jeśli curl z Twojego komputera zwraca 200, ale Live Test GSC się nie udaje, jest to sygnał, że liczy się adres źródłowy albo routing. Potwierdź to, porównując logi krawędzi/CDN-u, originu, aplikacji i dostawcy tożsamości, zanim nazwiesz przyczyną WAF. Żądanie HEAD (wysyłane przez curl -I) może też być obsługiwane lub cachowane inaczej niż GET, więc sprawdź również anonimowy GET.

Jak to naprawić — cztery gałęzie zależne od rodzaju strony

Nie ma jednej naprawy — są cztery, a wybranie niewłaściwej albo ujawni treść, którą chcesz chronić, albo pozostawi indeksowalną stronę trwale zablokowaną. Zanim zmienisz konfigurację, przypisz adres URL do jednej z tych kategorii:

1. Rzeczywiście prywatna lub stagingowa treść → zachowaj uwierzytelnianie i niczego nie zmieniaj. Jeśli adres URL naprawdę nie powinien być publiczny, 401 działa zgodnie z zamiarem — uwierzytelnianie po stronie serwera to prawidłowy, rekomendowany przez Google sposób ukrycia treści przed wszystkimi, także przed Googlebotem. John Mueller podkreślał to w kontekście witryn stagingowych: właściwym sposobem ukrycia witryny jest autoryzacja po stronie serwera, przez IP, ciasteczko albo zwykłe uwierzytelnianie serwera, tak aby zwykli użytkownicy — a więc także Googlebot — nie mogli zobaczyć treści. Nie dodawaj Googlebota do wyjątków bramki chroniącej rzeczywiście prywatną treść tylko po to, aby usunąć ten wiersz z raportu; zniweczyłoby to sens bramki. Naprawa dotyczy tu higieny odkrywania, nie dostępu: potwierdź, że adres URL nie jest linkowany, umieszczany w mapie witryny ani zgłaszany w tej usłudze Search Console, i pozostaw uwierzytelnianie.

2. Publiczna strona przypadkowo zablokowana → usuń wymaganie autoryzacji. Jeśli strona powinna być indeksowana, a bramka jest pozostałością — Basic Auth, ścianą logowania lub wtyczką trybu konserwacji — wyłącz ją dla tej ścieżki. To prosty przypadek: gdy anonimowe żądanie otrzyma 200, Googlebot może wejść na stronę.

3. Publiczna strona błędnie blokowana przez ochronę botów → dopuść zweryfikowanego Googlebota, nie sam ciąg user-agenta. Gdy WAF, CDN albo lista adresów IP odrzuca Googlebota na stronie, która ma być publiczna, dodaj wyjątek dla zweryfikowanego Googlebota na podstawie IP / odwrotnego DNS. Ciąg user-agenta można banalnie podrobić — każdy może twierdzić, że jest Googlebotem. Zalecana przez Google ścieżka to sprawdzenie crawlera według opublikowanych zakresów IP albo przez kontrolę odwrotnego, a następnie prostego DNS i przepuszczenie dopiero tak potwierdzonych żądań. Nie usuwasz reguły bezpieczeństwa; tworzysz w niej zweryfikowany wyjątek. Aby usunąć fałszywy alarm:

• Ustal, która reguła zwraca Googlebotowi 401/403 (Cloudflare Firewall Events, logi Akamai/Sucuri albo własne logi edge/originu/aplikacji).
• Dodaj do listy dozwolonych zweryfikowane zakresy IP Google (albo kategorię bota), zamiast całkowicie wyłączać ochronę.
• Ponownie wykonuj URL Inspection Live Test, aż Google będzie mógł pobrać stronę.

4. Treść subskrypcyjna lub za paywallem, którą chcesz indeksować → w ogóle nie używaj ogólnego 401. Jeśli strona jest ograniczona rejestracją lub subskrypcją, ale chcesz, aby można ją było znaleźć w wyszukiwarce, twardy 401 jest niewłaściwym narzędziem niezależnie od przyczyny — Googlebot nadal nie może jej pobrać. Google opisuje wspieraną implementację paywalla: udostępnij stronę z odpowiednimi danymi strukturalnymi treści za paywallem (isAccessibleForFree, hasPart i powiązane właściwości), aby Google mogło indeksować bezpłatny fragment podglądu bez otwierania całej treści. To zmiana znaczników i odpowiedzi serwera, a nie zmiana bramki uwierzytelniania.

Zweryfikuj naprawę i ustaw właściwe oczekiwania

Gdy rzeczywiście otworzysz stronę (i potwierdzisz przez curl/Live Test, że nieuwierzytelnione żądanie zwraca 200), precyzyjnie określ, co potwierdza każdy krok:

• Live Test potwierdza dostęp, nie indeksowanie. Dokumentacja Google dotycząca URL Inspection mówi, że test na żywo potwierdza tylko, czy Google-InspectionTool może obecnie uzyskać dostęp do strony i ją przetworzyć — nie istnieje test gwarantujący późniejsze umieszczenie strony w indeksie ani w wynikach wyszukiwania. Udany Live Test oznacza, że bramka jest otwarta, ale nie obiecuje dalszego przebiegu.
• Validate Fix jest opcjonalne, nie obowiązkowe. Google aktualizuje liczbę problemów, gdy ponownie crawluje stronę, niezależnie od tego, czy klikniesz Validate Fix. Używaj go do własnego śledzenia prawdziwej poprawki — nie uruchamiaj walidacji dla adresu, który ma pozostać prywatny, i nie traktuj jej jako sposobu na przyspieszenie ponownego indeksowania.
• Nie oczekuj natychmiastowego ponownego indeksowania. Ponowny crawl i indeksowanie wymagają czasu, a jak wspomniano wyżej, nie będę cytować nieopublikowanego harmonogramu ponowień. Monitoruj rzeczywisty stan indeksu i widoczność w wyszukiwarce oddzielnie od statusu raportu; ani Live Test, ani Validate Fix nie gwarantują wyboru kanonicznego ani pojawienia się w wynikach.
• Mit, który warto odrzucić: 401 w GSC nie jest karą ani działaniem ręcznym. To status dostępu crawlera. Nie obniża pozycji innych stron i nie „czarnolistuje” witryny — tylko utrzymuje zablokowaną stronę poza indeksem.

Gdzie znajduje się ten status

To jeden ze statusów HTTP w raporcie Page Indexing — jego odpowiednikami są między innymi Blocked due to access forbidden (403), pozostałe statusy 4xx i 404 oraz status błędu serwera 5xx. Sam raport i sposób czytania tabeli „Why pages aren’t indexed” opisuje centrum raportu Page Indexing. Mechanizmy leżące u podstaw — sposób pobierania strony przez Googlebota i znaczenie kodów statusu — omówiono w sekcjach crawling i indexing.

Podsumowanie AI

Skrócona wersja karty Advanced:

• Co to jest. Status Page Indexing w GSC oznaczający, że Googlebot otrzymał HTTP 401 (Unauthorized) — bramkę uwierzytelniania, której nie może przejść. Google nie podaje danych logowania, więc nie widzi treści.
• Co robi Google. Strona nie jest indeksowana; wcześniej zindeksowany adres URL zwracający 401 z czasem wypada z indeksu. Wszystkie 4xx poza 429 są traktowane tak samo — Google otrzymuje informację, że „treść nie istnieje”. 4xx nie wpływa na tempo crawlowania, więc nie używaj 401/403 do ograniczania Googlebota.
• 401 a 403, precyzyjnie. Według RFC 9110 401 oznacza brak prawidłowych danych uwierzytelniających (nie wysłano ich albo je odrzucono), a 403 — że serwer zrozumiał żądanie, lecz odmówił z powodów, które nie zawsze dotyczą uwierzytelniania. „401 = bramka auth, 403 = reguła bezpieczeństwa błędnie blokująca Googlebota” to użyteczny skrót triage, ale nie pełna reguła protokołu.
• Typowe przyczyny (na stronach, które mają być indeksowane): witryna stagingowa za Basic Auth, przypadkowe HTTP auth na publicznej sekcji, WAF/CDN/lista IP wykluczająca Googlebota albo ściana logowania na treści subskrypcyjnej lub za paywallem.
• „U mnie działa” to pułapka. Jesteś uwierzytelniony albo masz dozwolony adres IP, a Googlebot nie. Diagnozuj jak bot: URL Inspection Live Test i curl -I (bez ciasteczek i auth) — 401 tam potwierdza problem. Nagłówek WWW-Authenticate potwierdza prawdziwą bramkę (RFC 9110 wymaga go przy zgodnym 401); jego brak oznacza tylko wadliwą odpowiedź — przed wskazaniem WAF sprawdź logi edge, originu, aplikacji i dostawcy tożsamości.
• Naprawa zależy od rodzaju strony. Przypadkowo zablokowana strona publiczna → usuń wymaganie autoryzacji. Fałszywa blokada publicznej strony przez ochronę botów → dopuść zweryfikowanego Googlebota przez IP/odwrotny DNS, nigdy przez łatwy do podrobienia user-agent i bez wyłączania całej reguły. Treść rzeczywiście prywatna/stagingowa → zachowaj uwierzytelnianie; nie otwieraj jej tylko dla raportu, lecz uporządkuj odkrywanie (mapy, linki, właściwość). Indeksowalny paywall → użyj danych strukturalnych paywalla Google.
• Waliduj i czekaj bez obietnic. Live Test potwierdza bieżący dostęp, nie indeksowanie. Validate Fix jest opcjonalne, a Google aktualizuje licznik przy kolejnym crawl. Ponowne indeksowanie wymaga czasu, nie ma opublikowanego harmonogramu ponowień, a żaden z tych kroków nie gwarantuje indeksu, kanonicznego adresu ani widoczności. 401 nie jest karą.

Oficjalna dokumentacja

Dokumentacja źródeł pierwotnych dotycząca wyszukiwarek.

Google

• Raport Page Indexing — sam raport i definicja statusu „Blocked due to unauthorized request (401)” (wraz z odpowiednikiem 403 i innymi statusami HTTP).
• Wpływ statusów HTTP oraz błędów sieci i DNS na wyszukiwarkę Google — co Googlebot robi z 401: traktowanie 4xx poza 429 oraz zasada „nie używaj 401/403 do ograniczania tempa crawlowania”.
• Weryfikowanie Googlebota i innych crawlerów Google — zalecany sposób dodania Googlebota do listy dozwolonych: weryfikacja przez IP/odwrotny DNS, nie przez ciąg user-agenta.
• Zakresy IP Googlebota (googlebot.json) — opublikowane zakresy IP, które można dopuścić przez WAF/CDN.

Bing / Microsoft

• Pomoc Bing Webmaster Tools — Bing nie pokazuje identycznej etykiety statusu, ale adres URL zwracający 401/403 jest podobnie niedostępny i nie zostanie zindeksowany; bingbot również musi mieć anonimowy dostęp do strony, a dla tego samego rodzaju wyjątku publikuje weryfikowane zakresy IP i weryfikację przez odwrotny DNS.

Cytaty ze źródła

Wypowiedzi zapisane w źródłach. Każdy link prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google — znaczenie statusu 401 (raport Page Indexing)

• “The page was blocked to Googlebot by a request for authorization (401 response). If you do want Googlebot to be able to index this page, either remove authorization requirements for this page, or else allow Googlebot to access your pages by verifying its identity.” (tłumaczenie) «Strona została zablokowana dla Googlebota przez żądanie autoryzacji (odpowiedź 401). Jeśli chcesz, aby Googlebot mógł ją zindeksować, usuń wymagania autoryzacji dla tej strony albo zezwól Googlebotowi na dostęp po zweryfikowaniu jego tożsamości.» — Pomoc Google Search Console, Raport Page Indexing. Przejdź do cytatu

Google — co Googlebot robi z kodem 401 (dokumentacja statusów HTTP)

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (tłumaczenie) «Wszystkie błędy 4xx, z wyjątkiem 429, są traktowane tak samo: crawlery Google informują kolejny system przetwarzania, że treść nie istnieje.» — Dokumentacja Google Search Central. Przejdź do cytatu
• “Don’t use 401 and 403 status codes for limiting the crawl rate.” (tłumaczenie) «Nie używaj kodów statusu 401 i 403 do ograniczania tempa crawlowania.» Przejdź do cytatu

Patrick Stox — moje definicje 401/403 i wpływ 4xx na indeks,

• “The client hasn’t identified or verified itself when needed.” (tłumaczenie) «Klient nie zidentyfikował się ani nie zweryfikował, gdy było to potrzebne.» (401) — Patrick Stox, Wpływ kodów statusu HTTP na SEO, Ahrefs. Przejdź do cytatu
• “The client is known but doesn’t have access rights.” (tłumaczenie) «Klient jest znany, ale nie ma praw dostępu.» (403) Przejdź do cytatu
• “4xxs will cause pages to drop from the index.” (tłumaczenie) «Kody 4xx spowodują wypadanie stron z indeksu.» Przejdź do cytatu

John Mueller, Google — uwierzytelnianie po stronie serwera jako właściwa bramka witryny

• “Ideally, what you would want to do is provide some kind of server side authentication on the server so that normal users when they go there they would get blocked from being able to see the content; that would include GoogleBot.” (tłumaczenie) «Najlepiej byłoby zapewnić na serwerze uwierzytelnianie po stronie serwera, aby zwykli użytkownicy po wejściu byli blokowani przed zobaczeniem treści; dotyczy to również GoogleBota.» (Webmaster Hangout, 25 września 2019 r., przekazane przez Search Engine Journal.) Przeczytaj omówienie

Lista kontrolna diagnozy i naprawy 401

Uruchom ją, gdy GSC zgłosi status „Blocked due to unauthorized request (401)”:

• Najpierw ustal cel — czy naprawdę chcesz indeksować ten adres URL? Jeśli treść jest rzeczywiście prywatna lub stagingowa, 401 jest prawidłowy; przejdź do ostatniego punktu. Jeśli chcesz indeksować treść subskrypcyjną lub za paywallem, pomiń kroki usuwania autoryzacji i użyj naprawy z danymi strukturalnymi paywalla.
• Odtwórz problem jak bot — uruchom URL Inspection → Live Test dla adresu URL i potwierdź błąd autoryzacji (nie ufaj zalogowanej przeglądarce).
• curl -I bez ciasteczek i danych uwierzytelniających — potwierdź 401 i sprawdź nagłówek WWW-Authenticate. 401 w tym teście przy 200 w przeglądarce jest błędem. Nagłówek potwierdza prawdziwą bramkę auth; jego brak wskazuje wadliwą odpowiedź, nie warstwę, która ją wygenerowała.
• Ustal, co blokuje — sprawdź logi edge/CDN-u, originu, aplikacji i dostawcy tożsamości, aby rozróżnić Basic Auth (.htpasswd), wtyczkę trybu konserwacji/„coming soon”, ścianę logowania lub regułę WAF/CDN/listy IP.
• Jeśli to WAF/CDN — sprawdź zdarzenia zapory pod kątem reguły blokującej Google; dodaj zweryfikowane zakresy IP Googlebota do listy dozwolonych, zamiast wyłączać ochronę.
• Wybierz właściwą naprawę — usuń wymaganie auth z przypadkowo zablokowanej strony publicznej albo dopuść zweryfikowanego Googlebota przez IP / odwrotny DNS (nigdy przez łatwy do podrobienia user-agent) w przypadku fałszywej blokady botów. Nigdy nie przepuszczaj Googlebota przez bramkę chroniącą rzeczywiście prywatną treść.
• Sprawdź ponownie — nieuwierzytelnione curl -I zwraca teraz 200, a URL Inspection Live Test może pobrać stronę.
• Validate Fix (opcjonalnie) w raporcie Page Indexing i ponownie sprawdź przykładowy adres URL — Google i tak aktualizuje licznik przy kolejnym crawl; udany Live Test potwierdza dostęp, nie indeksowanie.
• Ustaw oczekiwania — ponowny crawl i indeksowanie wymagają czasu; nie ma gwarantowanego harmonogramu ponowień ani gwarancji indeksowania lub widoczności. To nie jest kara.
• Jeśli blokada jest celowa — potwierdź, że stagingowy/prywatny adres URL nie powinien należeć do tej właściwości (przestań go linkować/zgłaszać) i pozostaw bramkę.

401 a 403 i inne 4xx — ściąga

Co naprawdę oznacza każdy kod (i jaka jest typowa przyczyna)

Jak Google traktuje te kody podczas indeksowania

Mapa naprawy

Dwie oficjalne naprawy publicznej strony błędnie zablokowanej (według sformułowania Google)

1. Usuń wymaganie autoryzacji dla strony.
2. Przepuść Googlebota, weryfikując jego tożsamość — dodaj do listy dozwolonych przez IP / odwrotny DNS, nie przez (łatwy do podrobienia) ciąg user-agenta.

Żadna z tych metod nie dotyczy rzeczywiście prywatnej lub stagingowej treści (zachowaj bramkę) ani indeksowalnej treści za paywallem (użyj znaczników paywalla zamiast otwierania bramki).

Modele mentalne

1. Bramka a treść. 401 nie jest problemem treści — Googlebot nigdy do niej nie dotarł. To problem bramki. Nie edytujesz więc strony; zmieniasz zachowanie bramki wobec nieuwierzytelnionego bota. Zawsze rozdzielaj pytania „czy strona jest dobra?” i „czy Googlebot może przejść przez drzwi?”.

2. Intencja decyduje o wszystkim. Przed każdą naprawą odpowiedz na jedno pytanie: czy ten adres URL powinien być indeksowany? Jeśli tak, 401 jest błędną konfiguracją do usunięcia. Jeśli nie, 401 działa zgodnie z zamiarem, a prawdziwe pytanie brzmi, dlaczego adres URL w ogóle znalazł się w tej właściwości Search Console. Nie naprawiaj 401, który spełnia swoje zadanie.

3. Testuj jak bot, nie jak siebie. „U mnie działa” to domyślny błąd oceny. Masz sesję, ciasteczko i dozwolony adres IP. Googlebot nie ma niczego z tego. Każda diagnoza zaczyna się od usunięcia tych ułatwień — curl -I bez danych uwierzytelniających albo URL Inspection Live Test.

4. 401 a 403 — ten sam skutek, inne drzwi. Dla indeksowania są identyczne (4xx poza 429). Według RFC 401 oznacza brak prawidłowych danych (nie wysłano ich albo je odrzucono), a 403 — że serwer zrozumiał żądanie, lecz odmówił z powodów, które mogą, ale nie muszą, dotyczyć uwierzytelniania. Traktuj „401 = kontrolowana przeze mnie bramka auth, 403 = błędnie działająca reguła bezpieczeństwa” jako praktyczny skrót triage, nie granicę protokołu — jest użyteczny, ale prawdziwe znaczenie określa RFC. Diagnozuj drzwi: 401 → sprawdź auth/staging; 403 → sprawdź WAF/zaporę.

5. Weryfikuj bota, nie ufaj nazwie. Naprawa, która później mści się najbardziej, to „dodaj user-agenta Googlebota do listy”. Ten ciąg może podać każdy. Trwała metoda to tożsamość potwierdzona przez IP / odwrotny DNS — przepuszczasz bota, o którym możesz udowodnić, że jest Googlebotem, a nie tego, który tylko tak twierdzi.

Diagnozowanie 401: celowa bramka czy błędna konfiguracja?

Pierwszy rozwidlenie dotyczy intencji, nie technologii — zanim zmienisz konfigurację, ustal, czy adres URL powinien być indeksowany. Gdy potwierdzisz prawdziwą błędną konfigurację, drugie rozwidlenie odpowiada na pytanie, czy to zapomniana ściana logowania, czy WAF/CDN przypadkiem blokuje Googlebota. Przejdź przez drzewo.

Śledź pulę 401, nie tylko jej istnienie

Jedną liczbą wartą obserwowania jest liczba adresów URL w wierszu „Blocked due to unauthorized request (401)” raportu Page Indexing w czasie, a nie tylko samo istnienie wiersza — pojedynczy zrzut nie pokaże, czy rozwiązujesz problem, czy gromadzisz kolejne zablokowane adresy.

Liczba adresów w puli 401 w czasie

• Metryka — Liczba adresów URL w wierszu „Blocked due to unauthorized request (401)” raportu Page Indexing GSC, śledzona tydzień po tygodniu.
• Co mówi — Czy naprawa zadziałała i czy pojawiają się nowe 401. Po usunięciu wymagania auth albo dopuszczeniu zweryfikowanego Googlebota liczba powinna zbliżać się do zera dla naprawionych adresów. Dla adresów celowo chronionych (staging, prywatne sekcje) powinna pozostać płaska — wzrost zwykle oznacza, że nowe adresy stagingowe/prywatne są przez pomyłkę linkowane lub dodawane do mapy w tej właściwości.
• Jak pobrać — raport Page Indexing GSC przefiltrowany do wiersza 401; pojedyncze adresy sprawdzaj przez URL Inspection → Live Test, aby potwierdzić, że nie oglądasz starego zrzutu.
• Punkt odniesienia / realistyczny zakres — Nie ma uniwersalnego celu — wszystko zależy od liczby stron, które celowo chronisz. Uczciwy próg to zero 401 wśród adresów, które chcesz indeksować, i płaska (nie rosnąca) liczba dla adresów świadomie pozostawionych za auth. Ustal własny stan bazowy, zanim ocenisz kierunek trendu.
• Częstotliwość — Co tydzień bezpośrednio po naprawie, aż liczba się ustabilizuje; później raz w miesiącu jako kontrola regresji.

Runbook: diagnozuj, napraw, zweryfikuj

Procedura 401 to krótka, uporządkowana pętla — nie przechodź od razu do „napraw”, zanim nie potwierdzisz intencji i nie odtworzysz blokady jako bot.

1. Najpierw ustal intencję. Czy ten adres URL rzeczywiście powinien być indeksowany? Jeśli treść jest rzeczywiście prywatna lub stagingowa, zatrzymaj się — 401 jest prawidłowy, a jedynym dalszym krokiem jest upewnienie się, że adres nie jest linkowany ani umieszczany w mapie tej właściwości; nie osłabiaj bramki. Jeśli chcesz indeksować treść subskrypcyjną lub za paywallem, przejdź do naprawy z danymi strukturalnymi paywalla, zamiast dotykać bramki auth.

2. Odtwórz problem jak bot, nie jak siebie. Uruchom URL Inspection → Live Test w GSC, a osobno zażądaj adresu URL przez curl -I, bez ciasteczek i danych uwierzytelniających. Jeśli curl dostaje 401, a zalogowana przeglądarka 200, ta różnica jest błędem — jesteś uwierzytelniony lub masz dozwolone IP, a Googlebot nie.

3. Ustal bramkę. Sprawdź, czy anonimowa odpowiedź zawiera nagłówek WWW-Authenticate — zgodny 401 musi go zawierać, więc obecność potwierdza prawdziwą bramkę auth (Basic Auth, ścianę logowania, tryb konserwacji). Brak nie wskazuje przyczyny; oznacza wadliwą odpowiedź, dlatego porównaj logi edge/CDN-u, originu, aplikacji i dostawcy tożsamości, zanim uznasz, że winny jest WAF/CDN albo lista dozwolonych adresów.

4. Napraw według przyczyny. Bramka auth na przypadkowo publicznej stronie → usuń wymaganie autoryzacji dla tej ścieżki. Reguła WAF/CDN błędnie blokująca publiczną stronę → dodaj w zaporze zweryfikowanego Googlebota przez IP lub odwrotny DNS, nigdy wyłącznie przez łatwy do podrobienia user-agent. Nie otwieraj bramki Googlebotowi, jeśli chroni rzeczywiście prywatną treść.

5. Zweryfikuj. Ponownie uruchom anonimowe curl -I i potwierdź, że zwraca teraz 200. Validate Fix w raporcie Page Indexing służy tylko do opcjonalnego śledzenia — Google i tak aktualizuje licznik przy następnym crawl — a Live Test URL Inspection potwierdza wyłącznie bieżący dostęp Google-InspectionTool, nie to, że strona zostanie zindeksowana.

6. Ustaw oczekiwania i zakończ. Ponowny crawl i indeksowanie wymagają czasu; nie ma opublikowanego harmonogramu ponowień, a ani Live Test, ani Validate Fix nie gwarantują indeksowania ani widoczności. Nie „naprawiaj” tego samego adresu dwa razy podczas oczekiwania. Jeśli liczba w puli 401 w GSC nie spada po kilku tygodniach, wróć do kroku 2 i ponownie odtwórz problem, zamiast zgadywać nową przyczynę.

Gotowe do użycia prompty AI

Prompty do skopiowania i wklejenia, które pomagają sklasyfikować 401 na podstawie surowego wyniku diagnostyki. Ułatwiają szybki triage prawdopodobnej przyczyny — przed jakąkolwiek zmianą zawsze potwierdź wniosek w rzeczywistej konfiguracji serwera lub zapory.

Klasyfikacja prawdopodobnej przyczyny na podstawie wyniku curl

I'm diagnosing a "Blocked due to unauthorized request (401)" status in Google
Search Console. Below is the raw output of an unauthenticated request to the
URL (curl -I, no cookies, no credentials). Based on this output alone,
classify the most likely cause as one of: (1) staging/dev site behind Basic
Auth, (2) accidental HTTP auth or maintenance-mode gate left on a public
section, (3) WAF/CDN/IP-allowlist blocking Googlebot, (4) a login wall on
content that's meant to be gated. Explain which specific header or detail in
the output pointed you to that answer, and tell me what's missing if you
can't tell for sure.

CURL OUTPUT:
[paste]

Klasyfikacja przyczyny na podstawie wiersza logu WAF/zapory

I'm investigating why Googlebot is getting a 401 or 403 on a page I want
indexed. Below is a log line (or a few) from my WAF/CDN showing a blocked
request. Tell me whether this looks like a bot-identity rule (blocking by
user-agent or IP range), a rate-limit/challenge rule, or something else, and
what I'd need to allowlist — by IP range or reverse-DNS — to let verified
Googlebot through without disabling the rule entirely.

LOG LINE(S):
[paste]

Kontrola poprawki przed wdrożeniem

I'm about to remove an authorization requirement from a URL that's currently
returning 401 to Googlebot, because I want it indexed. Here's a short
description of the current gate and what I'm about to change: [describe].
Point out anything I might be missing — e.g. whether this could accidentally
expose a section I meant to keep private, or whether I should allowlist
verified Googlebot instead of removing the auth requirement outright.

Sprawdź się: „Blocked due to unauthorized request (401)”

Pięć pytań o znaczenie 401, różnicę między 401 a 403 oraz diagnozowanie i naprawę problemu. Wybierz odpowiedź przy każdym pytaniu, a potem sprawdź wynik.

Odtwórz 401 jako anonimowe żądanie

Cel tych testów jest taki sam jak w karcie Advanced: Twoja przeglądarka jest uwierzytelniona, a Googlebot nie. Usuń wszystkie ciasteczka i dane uwierzytelniające, aby sprawdzić, co naprawdę otrzymuje anonimowy klient.

macOS / Linux

# Fetch headers only, with no cookies and no credentials
curl -sI https://www.example.com/page/
# Look for:
#   HTTP/1.1 401 Unauthorized
#   WWW-Authenticate: Basic realm="..."   <- confirms a real auth gate

Windows (PowerShell)

# -SkipHttpErrorCheck so PowerShell shows the 401 instead of throwing
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Head `
  -SkipHttpErrorCheck | Select-Object StatusCode, Headers
# Check the Headers output for WWW-Authenticate

Jeśli wynik to 401 z nagłówkiem WWW-Authenticate, potwierdzasz prawdziwą bramkę uwierzytelniania (Basic Auth, ścianę logowania) — RFC 9110 wymaga, aby zgodny 401 wysyłał ten nagłówek. Jeśli wynik to 401/403 bez nagłówka WWW-Authenticate, odpowiedź jest wadliwa lub niepełna, ale nie wiadomo, która warstwa ją wygenerowała — sam brak nagłówka nie dowodzi, że winny jest WAF lub CDN. Jeśli blokada występuje również wyłącznie poza Twoją siecią, zależność od IP mocniej wskazuje na regułę WAF/CDN/listy IP; potwierdź ją w logach zapory/CDN-u, przetestuj inną sieć albo użyj URL Inspection Live Test GSC, który żąda strony jak Googlebot.

Sprawdź, czy bot naprawdę jest Googlebotem (zanim dodasz go do wyjątków)

Zanim otworzysz regułę WAF, aby przepuścić żądanie „Googlebota”, potwierdź, że adres IP rzeczywiście należy do Google — wiele żądań podszywa się pod user-agenta.

macOS / Linux

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

Jeśli odwrotne wyszukiwanie nie kończy się domeną Google albo wyszukiwanie do przodu nie zwraca tego samego adresu IP, nie dodawaj go do listy dozwolonych — to nie jest Googlebot. Możesz też sprawdzić adres IP względem opublikowanych zakresów Google (googlebot.json) albo zweryfikować go bezpośrednio za pomocą narzędzia Googlebot Verifier. Dodawaj wyjątki na podstawie potwierdzonej tożsamości, nigdy wyłącznie na podstawie user-agenta.

Narzędzia do diagnozowania i naprawy 401

• HTTP Status Checker — wklej adres URL (albo partię adresów), aby potwierdzić kod statusu, zobaczyć pełny łańcuch odpowiedzi i wykryć przekierowanie przed bramką auth.
• Googlebot Verifier — sprawdź, czy adres IP podający się za Googlebota jest prawdziwy (opublikowane zakresy IP i potwierdzenie odwrotnym DNS), zanim dodasz go do wyjątków WAF-u lub zapory.
• Google Search Console — URL Inspection → Live Test — najbliższy sposób sprawdzenia dokładnej odpowiedzi otrzymywanej obecnie przez Googlebota, w tym tego, czy blokuje go autoryzacja.
• curl -I — najszybszy sposób zażądania adresu bez ciasteczek i danych auth oraz odczytania surowego statusu i nagłówków, w tym WWW-Authenticate.
• Dziennik zdarzeń zapory WAF/CDN (Cloudflare, Akamai, Sucuri itd.) — znajdź konkretną regułę zwracającą Googlebotowi 401/403 dla jego zakresów IP.

Udowodnij, że poprawka rzeczywiście działa

Po usunięciu wymagania auth albo dopuszczeniu zweryfikowanego Googlebota te kontrole odróżniają „konfiguracja się zmieniła” od „Google rzeczywiście może teraz wejść na stronę”. Uruchom je w tej kolejności.

Test 1 — Anonimowe żądanie zwraca teraz 200

• Test do wykonania — Uruchom curl -I bez ciasteczek i danych uwierzytelniających dla danego adresu URL (albo sprawdź go przez HTTP Status Checker).
• Oczekiwany wynik — Wiersz statusu brzmi HTTP/1.1 200 OK i nie ma nagłówka WWW-Authenticate.
• Interpretacja niepowodzenia — Nadal 401 oznacza, że wymaganie auth nie zostało naprawdę usunięte dla tej ścieżki albo testujesz niewłaściwy adres URL/środowisko. 403 zamiast 401 oznacza zamianę jednej bramki na inną — sprawdź regułę WAF/CDN.
• Okno monitorowania — Natychmiast — serwer odpowiada po wejściu zmiany na produkcję.
• Warunek wycofania — Jeśli usunięcie bramki ujawni treść, która miała pozostać prywatna, natychmiast przywróć auth i dopuść zweryfikowanego Googlebota przez IP/odwrotny DNS.

Test 2 — Google potwierdza, że może teraz dotrzeć do strony

• Test do wykonania — Uruchom URL Inspection → Test Live URL w Google Search Console dla danego adresu URL.
• Oczekiwany wynik — Test na żywo kończy się powodzeniem i pokazuje treść strony — nie ma zgłoszenia błędu autoryzacji. Potwierdza to, że Google-InspectionTool może obecnie pobrać i przetworzyć stronę; jest to wynik dostępu, nie gwarancja indeksowania. Dokumentacja Google wyjaśnia, że Live Test nie sprawdza wszystkich warunków indeksowania, a udany test nie gwarantuje obecności w indeksie.
• Interpretacja niepowodzenia — Jeśli Live Test nadal zgłasza blokadę autoryzacji po udanym anonimowym curl, podejrzewaj regułę zależną od zakresów IP Googlebota (problem listy WAF/CDN), nie ogólną bramkę auth.
• Okno monitorowania — Od natychmiast do kilku minut po wdrożeniu poprawki.
• Warunek wycofania — Nie dotyczy — to test tylko do odczytu; jeśli nadal się nie udaje, wróć do gałęzi niepowodzenia Testu 1, zamiast coś wycofywać.

Test 3 — Status 401 znika z raportu Page Indexing

• Test do wykonania — Użyj Validate Fix (opcjonalnie — Google aktualizuje licznik przy kolejnym crawl niezależnie od tego) dla problemu „Blocked due to unauthorized request (401)” w raporcie Page Indexing i obserwuj liczbę w puli przez następne tygodnie (zobacz kartę How to Measure).
• Oczekiwany wynik — Adres URL opuszcza pulę 401, a jeśli był wcześniej zindeksowany, z czasem wraca do indeksu. Ani Validate Fix, ani udany Live Test nie gwarantują indeksowania, wyboru kanonicznego ani widoczności — śledź rzeczywisty stan indeksu i wyniki wyszukiwania osobno.
• Interpretacja niepowodzenia — Nie ma opublikowanego harmonogramu ponowień, więc powolnej walidacji nie uznawaj za nowy błąd. Jeśli liczba w puli 401 nie spada przez kilka tygodni, powtórz Test 1, aby potwierdzić, że poprawka nadal działa (wdrożenie lub cache CDN-u może po cichu przywrócić bramkę).
• Okno monitorowania — Od kilku dni do kilku tygodni, śledzone przez liczbę w puli 401.
• Warunek wycofania — Wróć do samej bramki tylko wtedy, gdy Test 1 znów zacznie się nie udawać — nie ścigaj opóźnień raportu Page Indexing.

Dziennik zmian