Kod 401 Unauthorized

TL;DR — 401 Unauthorized oznacza, że serwer chce, abyś się zalogował, zanim wyda stronę — dane uwierzytelniające są nieobecne, błędne albo wygasły. Wyszukiwarki nigdy się nie logują, więc jeśli strona zwraca 401 Googlebotowi, Google jej nie widzi i nie umieści w wynikach. Tego właśnie chcesz dla stron prywatnych (staging, tylko dla członków) — problem pojawia się dopiero, gdy 401 dotyczy strony, którą chcesz, aby ludzie znaleźli.

Co oznacza 401

Gdy Twoja przeglądarka (albo crawler wyszukiwarki) prosi serwer o stronę, serwer odpowiada kodem statusu. 401 Unauthorized to sposób serwera na powiedzenie: “I’m not going to show you this until you prove who you are.” (tłumaczenie) „Nie pokażę Ci tego, dopóki nie udowodnisz, kim jesteś.” Wysłane dane uwierzytelniające były nieobecne, nieprawidłowe albo wygasły — musisz się więc zalogować. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

Widziałeś to w działaniu za każdym razem, gdy strona wyświetlała pole nazwy użytkownika i hasła albo przenosiła Cię na ekran logowania. Za kulisami często oznacza to 401.

Dlaczego ma to znaczenie dla SEO

Oto haczyk: Googlebot i Bingbot nigdy się nie logują. Nie mają nazwy użytkownika ani hasła do Twojej witryny i nie wpisują danych w polach logowania. Gdy crawler trafia na 401, po prostu nie może przejść przez bramkę. Dla Google treść tej strony praktycznie nie istnieje.

Praktyczny rezultat:

• Strona zwracająca 401 nie zostanie zindeksowana — nie może pojawić się w wyszukiwarce.
• Strona, która wcześniej zdobywała pozycje, ale teraz zwraca 401, z czasem wypadnie z indeksu. Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Kiedy 401 jest w porządku (a kiedy jest problemem)

401 nie jest automatycznie błędem do naprawy. To właściwa odpowiedź dla stron, które mają być prywatne:

• Dobry 401: witryna stagingowa, obszar tylko dla członków, wewnętrzne narzędzie administracyjne, portal klienta. Chcesz ukryć je przed Google, a ściana logowania to robi.
• Zły 401: wpis blogowy, strona produktu albo landing page, która ma być publiczna, ale nagle żąda logowania — zwykle z powodu źle skonfigurowanej zapory, pozostawionej ochrony hasłem, wygasłego tokena albo konfliktu wtyczki.

Najczęstszy fałszywy alarm brzmi: “ale u mnie działa!” — dzieje się tak, ponieważ jesteś zalogowany, a crawler nie. Aby zobaczyć to, co widzi Googlebot, otwórz stronę w prywatnym/incognito oknie albo użyj narzędzia URL Inspection w Google Search Console.

401 a 403 — szybka wersja

Często zobaczysz 401 wymieniane obok 403 Forbidden. Brzmią podobnie, ale oznaczają coś innego:

• 401 = „Kim jesteś?” Brakuje danych uwierzytelniających — zaloguj się.
• 403 = „Wiem, kim jesteś, ale nie.” Serwer zrozumiał żądanie, ale i tak odmawia dostępu.

Dla Google wynik jest jednak taki sam: żaden z tych kodów nie prowadzi do indeksowania, ponieważ crawler nie może dotrzeć do treści.

Chcesz poznać szczegóły techniczne — dokładny nagłówek, który musi wysłać 401, to, co naprawdę mówią dokumenty Google, oraz sposób naprawy niepożądanego 401? Przejdź do karty Advanced.

TL;DR — 401 Unauthorized to błąd klienta (RFC 9110 §15.5.2, który zastąpił RFC 7235), oznaczający brak prawidłowych danych uwierzytelniających — także danych wysłanych, ale odrzuconych, a nie tylko tych, których nigdy nie wysłano; zgodna z wymaganiami odpowiedź 401 wysyła również nagłówek WWW-Authenticate z nazwą oczekiwanego schematu. Różni się od 403 (odmowy, która nie wymaga takiego challenge i może nie mieć nic wspólnego z danymi uwierzytelniającymi), ale Google traktuje wszystkie kody 4xx poza 429 tak samo dla indeksowania: treść „nie istnieje”, więc nie zostaje zindeksowana, a wcześniej zindeksowane URL-e z czasem wypadają. Zwykły Googlebot nie wysyła danych uwierzytelniających, więc 403 dla Googlebota jest — własnymi słowami Google — zwykle błędną konfiguracją serwera. 401/403 nie wpływają na tempo crawl całej witryny (to powszechnie powtarzany mit), choć pojedynczy URL stale zwracający 4xx jest z czasem crawlowany rzadziej. 401 to poprawny, popierany przez Google sposób ochrony rzeczywiście prywatnej treści; problem pojawia się tylko wtedy, gdy dotyczy strony, którą chcesz zindeksować. W przypadku treści za paywallem istnieje zatwierdzona ścieżka, która nie polega na ogólnym 401.

Czym naprawdę jest 401

401 Unauthorized to odpowiedź z grupy błędów klienta. Definicja MDN jest najczystszym technicznym ujęciem:

“The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource. This status code is sent with an HTTP WWW-Authenticate response header that contains information on the authentication scheme the server expects the client to include to make the request successfully.” (tłumaczenie) „Kod odpowiedzi HTTP 401 Unauthorized oznacza, że żądanie nie powiodło się, ponieważ brakuje prawidłowych danych uwierzytelniających dla żądanego zasobu. Ten kod statusu jest wysyłany z nagłówkiem odpowiedzi HTTP WWW-Authenticate, który zawiera informacje o schemacie uwierzytelniania oczekiwanym przez serwer.”

Z tego fragmentu warto wyciągnąć dwie rzeczy. Po pierwsze, “uwierzytelnianie” oznacza, że żądający nie udowodnił, kim jest. Zwykle chodzi o brakujące, nieprawidłowe albo wygasłe dane — ale 401 może też nastąpić po wysłaniu danych, które zostały odrzucone, więc nie zakładaj „w ogóle nie było nagłówka auth” bez sprawdzenia żądania. Po drugie, zgodny ze specyfikacją 401 musi zawierać nagłówek WWW-Authenticate — zgodnie z RFC 9110 §15.5.2, który zastąpił starszy RFC 7235 — informujący klienta, jakiego schematu lub schematów oczekuje (HTTP Basic Auth, token Bearer, przepływ z ciasteczkiem sesji i inne). Podczas debugowania 401 ten nagłówek jest pierwszą rzeczą do sprawdzenia: czy w ogóle istnieje i jaki schemat nazywa. Evidence for this claim A 401 response means the request lacks valid authentication credentials and the response must include a WWW-Authenticate challenge. Scope: RFC 9110 defines the status semantics and required challenge header; it does not prescribe a site's authentication product or login flow. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.5.2 — 401 Unauthorized

W moim własnym przewodniku po kodach statusu podsumowuję 401 słowami: “the client hasn’t identified or verified itself when needed.” (tłumaczenie) „klient nie zidentyfikował się ani nie zweryfikował, gdy było to potrzebne.” Na tym polega cała idea — nikt jeszcze nie powiedział, kim jest.

401 a 403 Forbidden — różnica, która ma znaczenie

Tu większość osób zaczyna się gubić, więc ujmijmy to ostro. W jednym wierszu:

• 401 = “Kim jesteś?” — dane uwierzytelniające są brakujące albo nieprawidłowe; uwierzytelnij się i spróbuj ponownie.
• 403 = „Wiem, kim jesteś, ale nie.” — żądanie zostało zrozumiane, lecz dostęp jest odmówiony niezależnie od danych uwierzytelniających.

MDN przedstawia tę samą różnicę:

“A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (tłumaczenie) „401 Unauthorized jest podobny do odpowiedzi 403 Forbidden, z tą różnicą, że 403 jest zwracane, gdy żądanie zawiera prawidłowe dane uwierzytelniające, ale klient nie ma uprawnień do wykonania określonej czynności.”

Własnym przewodniku rysuję tę samą granicę: 401 to “the client hasn’t identified or verified itself when needed” (tłumaczenie) „klient nie zidentyfikował się ani nie zweryfikował, gdy było to potrzebne”, a 403 to “the client is known but doesn’t have access rights” (tłumaczenie) „klient jest znany, ale nie ma praw dostępu”. Uwierzytelnianie kontra autoryzacja.

Ten skrót jest niezawodny, ale oto ostrzejszy test protokołu, jeśli musisz wybrać między kodami w kodzie albo regule WAF: 401 wymaga challenge WWW-Authenticate — RFC 9110 oznacza to jako MUST — podczas gdy 403 go nie wymaga, ponieważ odmowa 403 może wynikać z powodów niemających nic wspólnego z danymi uwierzytelniającymi (blokada IP, reguła uprawnień, polityka limitu). Samo pytanie “czy dane były obecne?” nie wystarcza do rozróżnienia — 401 może nastąpić po odrzuconych danych, nie tylko po ich braku. Gdy wybierasz kod odpowiedzi, zapytaj raczej: czy wysyłam challenge uwierzytelniania (401), czy płaską odmowę (403)?

Oto mniej oczywisty zwrot SEO, który wynika z własnego stanowiska Google dotyczącego 403. Zwykły Googlebot nigdy nie wysyła danych uwierzytelniających. Dlatego 403 wysłużony konkretnie Googlebotowi jest — własnymi słowami Google — błędem serwera:

“HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (tłumaczenie) „HTTP 403 oznacza, że user-agent podał dane uwierzytelniające, ale nie przyznano mu dostępu. Googlebot jednak nigdy nie podaje danych uwierzytelniających, więc serwer nieprawidłowo zwraca ten błąd. Strona nie zostanie zindeksowana.”

To użyteczna wskazówka diagnostyczna. 401 dla Googlebota może być celowy (strona jest z założenia chroniona). 403 dla Googlebota zwykle wskazuje na błędną konfigurację — Googlebot nie wysłał danych, więc nic nie powinno wywoływać odpowiedzi “odmowa danych” dla tego klienta. Jeśli widzisz 403 na stronach, do których Googlebot powinien dotrzeć, najpierw podejrzewaj konfigurację CDN-u, WAF-u albo serwera. (Opis dotyczy zwykłych crawlerów Google. Google dokumentuje specjalne crawlery i fetchery uruchamiane przez użytkownika jako osobne kategorie z własnym zachowaniem, więc nie zakładaj bez sprawdzenia, że reguła „nigdy nie wysyła danych” dotyczy każdej integracji produktu Google.)

Ostatni wiersz jest najważniejszy: dla indeksowania Google traktuje je identycznie.

Jak Google traktuje strony 401

Dokumentacja Google o kodach statusu HTTP bez ogródek opisuje całą rodzinę 4xx:

“Google doesn’t use the content from URLs that return 4xx status codes. If a URL was previously used but is now returning 4xx status code, Google systems will stop using the URL over time. In the case of Google Search, Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (tłumaczenie) „Google nie używa treści z URL-i zwracających kody statusu 4xx. Jeśli URL był wcześniej używany, ale teraz zwraca kod 4xx, systemy Google z czasem przestaną go używać. W wyszukiwarce Google nie indeksuje URL-i zwracających kod statusu 4xx, a URL-e już zindeksowane i zwracające kod 4xx są usuwane z indeksu.” Evidence for this claim Google does not index 4xx URLs and removes already-indexed 4xx URLs over time. Scope: Google's crawler documentation supports the Search indexing outcome for 401 responses; it does not address access decisions for private users. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

401 nie jest szczególnym przypadkiem w tej rodzinie. W tabeli dokumentu 401 (unauthorized) i 403 (forbidden) są osobnymi wierszami z jednym wspólnym wyjaśnieniem:

“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, poza 429, są traktowane tak samo: crawlery Google informują następny system przetwarzania, że treść nie istnieje.”

Wynik jest więc binarny, a nie degradacyjny. Strona z 401 nie “rank lower” (tłumaczenie) „zajmuje niższą pozycję” — w ogóle nie jest indeksowana albo zostaje całkowicie usunięta, jeśli była wcześniej zindeksowana. Nie istnieje częściowa kara. Zgadza się to z podstawową tezą mojego przewodnika: kody tego typu spowodują wypadanie stron z indeksu. Ten artykuł jest pogłębieniem dotyczącym 401.

Jeden niuans dotyczy czasu: usunięcie następuje „z czasem”, a nie przy pierwszym błędnym pobraniu. Dokumentacja Google opisuje proces stopniowy, a system crawl historycznie tolerował krótkotrwałe błędy, zanim uznał URL za rzeczywiście zniknięty.

Mit tempa crawl — 401 NIE ogranicza crawlowania

Ten temat myli wiele skądinąd dobrych artykułów, więc powiem to precyzyjnie. 401 (ani 403) nie spowalnia tempa crawl Google. Google mówi to wprost:

“Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tłumaczenie) „Nie używaj kodów statusu 401 i 403 do ograniczania tempa crawl. Kody statusu 4xx, poza 429, nie wpływają na tempo crawl.”

To ważne, bo zobaczysz rady, że chronienie stron przez 401 “oszczędza budżet crawl” albo go „marnuje” — obie interpretacje są błędne. Tylko 429 (oraz sygnały w stylu 5xx, takie jak 503) mówią Googlebotowi, aby zwolnił. 401 nie jest przepustnicą; dla indeksowania to po prostu sygnał „treść nie istnieje”. Jeśli naprawdę chcesz tymczasowo spowolnić crawl, użyj 429/503, nie 401/403.

Jedna uwaga o zakresie, ponieważ te dwa twierdzenia łatwo pomylić: „brak wpływu na tempo crawl” dotyczy ogólnego tempa crawl Twojej witryny. Osobno Google mówi, że pojedynczy URL stale zwracający 4xx jest z czasem crawlowany rzadziej — jego częstotliwość ponawiania stopniowo spada. To różne zakresy: budżet crawl całej witryny nie jest ograniczany, ale konkretny URL stale zwracający 401 jest sprawdzany rzadziej, gdy Google obniża jego priorytet.

Warto znać także szczególny przypadek: 401 na zwykłej stronie i 401 na samym /robots.txt nie są obsługiwane tak samo. Jeśli plik robots.txt zwraca nie-429 4xx (w tym 401), Google traktuje to tak, jakby robots.txt w ogóle nie istniał — zakłada brak ograniczeń crawl z tego pliku, a nie niedostępność całej witryny. Nie umieszczaj /robots.txt za tą samą ścianą uwierzytelniania co stron prywatnych.

Czy 401 zawsze jest problemem? Nie.

401 jest błędem tylko wtedy, gdy nieumyślnie pojawia się na stronie, która ma być publiczna. Gdy strona jest naprawdę prywatna, 401 jest właściwym sposobem wykluczenia jej z wyszukiwania — i właśnie to zaleca Google. John Mueller ujął to jasno (przekazane przez Search Engine Journal): idealnym podejściem jest uwierzytelnianie po stronie serwera, które blokuje zwykłych użytkowników przed zobaczeniem treści — “that would include GoogleBot” (tłumaczenie) „to obejmowałoby GoogleBota”. (Przekazane przez Search Engine Journal z hangoutu Google z 2019 roku; traktuj jako dokładnie sparafrazowaną wypowiedź przedstawiciela, a nie zweryfikowany fragment dosłowny.)

Uwierzytelnianie po stronie serwera (które powoduje 401) jest zalecanym przez niego mechanizmem ukrywania treści niepublicznych — wyprzedza robots.txt właśnie dlatego, że rzeczywiście blokuje dostęp, a nie tylko prosi boty, aby nie wchodziły.

Schemat decyzji jest prosty:

• Powinno pozostać za 401: środowiska stagingowe, obszary tylko dla członków, narzędzia wewnętrzne, wszystko, co jest rzeczywiście prywatne. Działa zgodnie z projektem. Nie “naprawiaj” tego.
• Wymaga naprawy: publiczna, indeksowalna strona, która przypadkowo zwraca 401 — fałszywie dodatnia reguła CDN/WAF, pozostawiony Basic Auth, wygasły token albo konflikt wtyczki/middleware.

Konsekwencje SEO i pułapka „u mnie działa”

Praktyczne tryby awarii:

• Strony, które chcesz zindeksować, pozostają niewidoczne do usunięcia bramki.
• Strony, które wcześniej zdobywały pozycje, znikają po rozpoczęciu zwracania 401.
• Pułapka „u mnie działa”: osoba testująca jest uwierzytelniona, zalogowana albo korzysta z dozwolonego IP — crawler nie. Własna wskazówka Google dla przypadku 401 brzmi: “You can verify this error by visiting the page in incognito mode.” (tłumaczenie) „Możesz zweryfikować ten błąd, odwiedzając stronę w trybie incognito.” Jeszcze lepiej przetestuj dostęp anonimowy przez curl -I https://example.com/page albo użyj URL Inspection / Live Test w Search Console.

Jeśli musisz przepuścić prawdziwego crawlera, weryfikuj go przez IP / reverse-DNS, nigdy tylko na podstawie łańcucha user-agenta — łańcuchy user-agenta można banalnie sfałszować, więc dodanie “Googlebot” do allowlisty po nazwie to luka bezpieczeństwa, a nie poprawka.

A co z treścią za paywallem albo tylko dla subskrybentów?

Ogólny 401 dla wszystkich (w tym Googlebota) nie jest jedyną możliwością, jeśli chcesz, aby chroniona treść nadal mogła zdobywać pozycje. Google wspiera indeksowanie treści za paywallem przez dane strukturalne isAccessibleForFree, połączone z udzieleniem dostępu specjalnym tożsamościom crawlerów Google dla treści subskrybentów/użytkowników zarejestrowanych. Sens tego oznaczenia jest następujący:

“This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (tłumaczenie) „Te dane strukturalne pomagają Google odróżnić treść za paywallem od cloakingu, który narusza zasady dotyczące spamu.”

Wbudowane ostrzeżenie brzmi: ciche serwowanie pełnej treści tylko Googlebotowi, bez ujawnienia tego w danych strukturalnych, jest cloakingiem — ryzykiem naruszenia zasad dotyczących spamu. Jeśli chcesz indeksować treść chronioną, zrób to zatwierdzoną drogą (oznaczenie + dostęp crawlera), a nie cichym obejściem.

Jak naprawić niepożądany 401

1. Potwierdź, że rzeczywiście jest niepożądany. Czy strona ma być publiczna? Jeśli to staging albo obszar tylko dla członków, nie ma czego naprawiać.
2. Usuń wymóg uwierzytelniania na stronach publicznych — usuń pozostawiony Basic Auth (.htaccess/nginx), napraw wygasłe tokeny, rozwiąż konflikty wtyczek/middleware.
3. Sprawdź CDN/WAF — i nie zakładaj, że już wiesz, która warstwa wydała 401. Odpowiedź (oraz jej nagłówek WWW-Authenticate) mówi, że nastąpił challenge; nie mówi, skąd pochodzi — aplikacja, proxy tożsamości/uwierzytelniania, CDN lub reguły zarządzania botami WAF oraz serwer origin mogą go wszystkie wygenerować. Częstą przyczyną są fałszywe alarmy reguł zarządzania botami na brzegu; sprawdź logi na każdej warstwie i zweryfikuj Googlebota przez reverse DNS, zanim dodasz go do allowlisty.
4. Przepuszczaj zweryfikowane crawlery przez IP/reverse-DNS, nie przez user-agent.
5. Nie sięgaj po 401, aby wyindeksować stronę, którą możesz udostępnić publicznie — użyj noindex (przy dozwolonym crawlowaniu). Ściana logowania służy treści, która musi być naprawdę prywatna.
6. Zweryfikuj poprawkę przez Live Test w URL Inspection — ale traktuj wynik jako potwierdzenie bieżącego pobrania, a nie gwarancję. Google nie zobowiązuje się do określonego czasu ponownego crawl, ponownego indeksowania ani odzyskania pozycji po naprawie 401; pozytywny Live Test pokazuje, że bieżące pobranie Google przeszło, a nie że zaplanowane crawlowanie albo indeksowanie już nadążyło. Daj temu czas i ponownie sprawdź raport Page Indexing, zamiast oczekiwać natychmiastowego odwrócenia skutków.

Pełny workflow diagnoza–naprawa–walidacja w Google Search Console dla konkretnego statusu Page Indexing “Blocked due to unauthorized request (401)” znajdziesz w osobnym artykule towarzyszącym — ten tekst pozostaje na poziomie protokołu i koncepcji.

Bing

Bing działa funkcjonalnie tak samo: URL zwracający 401 (albo 403) Bingbotowi jest niedostępny i nie zostanie zindeksowany. Bingbot potrzebuje dostępu anonimowego tak samo jak Googlebot; weryfikuj go na podstawie opublikowanych zakresów IP, aby dodać go do allowlisty, a nie na podstawie user-agenta.

Podsumowanie AI

Skrócona wersja wariantu Advanced:

• 401 = brakujące, nieprawidłowe albo odrzucone dane uwierzytelniające („kim jesteś?”). RFC 9110 §15.5.2 (który zastąpił RFC 7235) wymaga nagłówka WWW-Authenticate z nazwą schematu, którego klient powinien użyć — a 401 nie dowodzi, że danych w ogóle nie wysłano; może nastąpić po ich wysłaniu i odrzuceniu.
• 401 a 403, niezawodny test: 401 wymaga challenge WWW-Authenticate; 403 nie, bo odmowa 403 może nie mieć nic wspólnego z danymi (blokada IP, reguła uprawnień, limit). Ponieważ zwykły Googlebot nigdy nie wysyła danych, 403 dla Googlebota jest według Google zwykle błędną konfiguracją serwera — Google osobno opisuje inne tożsamości crawlerów/fetcherów, więc nie uogólniaj tego na każdego klienta Google.
• Wynik indeksowania jest identyczny: Google traktuje wszystkie 4xx poza 429 tak samo — treść „nie istnieje”, więc nie jest indeksowana, a wcześniej zindeksowane URL-e z czasem wypadają. To wynik binarny, nie degradacja.
• Brak wpływu na tempo crawl całej witryny, ale częstotliwość pojedynczego URL-a spada: 401/403 nie ograniczają ogólnego tempa crawl — robią to tylko sygnały 429/5xx. Osobno pojedynczy URL stale zwracający 4xx jest z czasem crawlowany rzadziej. Pamiętaj też: 401 na /robots.txt jest traktowane jak „robots.txt nie istnieje”, a nie jak blokada.
• 401 często jest poprawny: uwierzytelnianie po stronie serwera to zalecany przez Google sposób ukrywania stron stagingowych/członkowskich/prywatnych. Problem pojawia się dopiero, gdy dotyczy strony, którą chcesz zindeksować — a sama odpowiedź nie mówi, która warstwa (aplikacja, proxy tożsamości, CDN/WAF, origin) ją wygenerowała.
• Pułapka „u mnie działa”: jesteś uwierzytelniony, crawler nie. Testuj w trybie incognito, przez curl -I albo URL Inspection — zaliczony Live Test potwierdza tylko bieżące pobranie, nie gwarantowany czas ponownego crawl/odzyskania.
• Paywalle: użyj oznaczenia isAccessibleForFree + dostępu crawlera, a nie ogólnego 401. Ciche serwowanie pełnej treści Googlebotowi jest cloakingiem.
• Naprawa: usuń wymóg auth / weryfikuj crawlery przez IP/reverse-DNS (nigdy user-agent) / użyj noindex, a nie 401, aby wyindeksować stronę, którą możesz udostępnić publicznie.

Dokumentacja oficjalna

Dokumentacja źródłowa Google i specyfikacji HTTP.

Google

• Jak kody statusu HTTP, błędy sieci i DNS wpływają na wyszukiwarkę Google — obsługa 4xx, reguła „traktowane tak samo” oraz ostrzeżenie o tempie crawl.
• Raport Page Indexing — definicje statusów „Blocked due to unauthorized request (401)” i „Blocked due to access forbidden (403)”.
• Dane strukturalne treści subskrypcyjnej i za paywallem — isAccessibleForFree i zatwierdzona alternatywa dla ogólnego 401.
• Weryfikowanie Googlebota i innych crawlerów Google — weryfikuj przez IP/reverse-DNS, nie user-agent, zanim dodasz do allowlisty.

Standardy / materiały referencyjne

• RFC 9110 §15.5.2 — HTTP Semantics: 401 Unauthorized — aktualna specyfikacja 401 i WWW-Authenticate (zastępuje RFC 7235).
• MDN — 401 Unauthorized — techniczna definicja dla deweloperów (materiał wtórny, niezwiązany bezpośrednio z SEO).

Cytaty ze źródła

Wypowiedzi zapisane w źródłach. Każdy link prowadzi bezpośrednio do miejsca z cytowanym fragmentem na stronie źródłowej.

Google — obsługa 4xx (w tym 401)

• “Google doesn’t use the content from URLs that return 4xx status codes… Google doesn’t index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index.” (tłumaczenie) „Google nie używa treści z URL-i zwracających kody statusu 4xx… Google nie indeksuje URL-i zwracających kod statusu 4xx, a URL-e już zindeksowane i zwracające kod 4xx są usuwane z indeksu.” — dokumentacja Google Search Central. Przejdź do cytatu
• “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, poza 429, są traktowane tak samo: crawlery Google informują następny system przetwarzania, że treść nie istnieje.” Przejdź do cytatu
• “Don’t use 401 and 403 status codes for limiting the crawl rate. The 4xx status codes, except 429, have no effect on crawl rate.” (tłumaczenie) „Kodów statusu 401 i 403 nie należy traktować jako sposobu spowalniania robota. Poza wyjątkiem 429 odpowiedzi z klasy 4xx nie zmieniają częstotliwości crawlowania.” Przejdź do cytatu

Google — Search Console Help, wpisy 401 i 403

• “The page was blocked to Googlebot by a request for authorization (401 response)… You can verify this error by visiting the page in incognito mode.” (tłumaczenie) „Strona została zablokowana dla Googlebota przez żądanie autoryzacji (odpowiedź 401)… Możesz zweryfikować ten błąd, odwiedzając stronę w trybie incognito.” — pomoc Google Search Console, raport Page Indexing. Przejdź do cytatu
• “HTTP 403 means that the user agent provided credentials, but was not granted access. However, Googlebot never provides credentials, so your server is returning this error incorrectly. The page will not be indexed.” (tłumaczenie) „Ten komunikat oznacza, że klient przesłał dane dostępowe, lecz odmówiono mu dostępu. Robot Google ich nie przesyła, więc taka odpowiedź serwera jest nieprawidłowa, a strona nie znajdzie się w indeksie.” Przejdź do cytatu

Google — treść za paywallem

• “This structured data helps Google differentiate paywalled content from the practice of cloaking, which violates spam policies.” (tłumaczenie) „Te dane strukturalne pomagają Google odróżnić treść za paywallem od cloakingu, który narusza zasady dotyczące spamu.” — dokumentacja Google Search Central. Przejdź do cytatu

MDN — definicja techniczna

• “The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.” (tłumaczenie) „Kod odpowiedzi błędu klienta HTTP 401 Unauthorized oznacza, że żądanie nie powiodło się, ponieważ brakuje prawidłowych danych uwierzytelniających dla żądanego zasobu.” — MDN Web Docs (wtórne źródło techniczne, niezwiązane bezpośrednio z SEO). Przejdź do cytatu
• “A 401 Unauthorized is similar to the 403 Forbidden response, except that a 403 is returned when a request contains valid credentials, but the client does not have permissions to perform a certain action.” (tłumaczenie) „401 Unauthorized jest podobny do odpowiedzi 403 Forbidden, z tą różnicą, że 403 jest zwracane, gdy żądanie zawiera prawidłowe dane uwierzytelniające, ale klient nie ma uprawnień do wykonania określonej czynności.” Przejdź do cytatu

John Mueller, Google (przekazane przez Search Engine Journal)

• O ukrywaniu treści niepublicznych: uwierzytelnianie po stronie serwera, które blokuje zwykłych użytkowników przed zobaczeniem treści — “that would include GoogleBot” (tłumaczenie) „to obejmowałoby GoogleBota” — jest idealnym podejściem. Relacja Search Engine Journal z hangoutu Google z 2019 roku; jest to wierna parafraza wypowiedzi przedstawiciela, a nie potwierdzony zapis słowo w słowo.

401 a 403 — co właściwie widzę i czy muszę to naprawić?

Czytelnicy mają w praktyce dwa pytania: czy to 401, czy 403? oraz czy to problem? Kliknij, aby je rozstrzygnąć.

Prompt: zdiagnozuj niezamierzony 401

Wklej anonimowe nagłówki odpowiedzi jednego dotkniętego URL-a oraz odpowiednią konfigurację auth, CDN-u albo middleware. Najpierw usuń tokeny, ciasteczka i sekrety.

Diagnose why this public URL returns HTTP 401 to an unauthenticated client. Check for
a valid WWW-Authenticate challenge, separate origin authentication from CDN/WAF and
application middleware, and distinguish an intentional private gate from a public-page
regression. Return: evidence, likely issuing layer, minimum safe fix, and exact
anonymous validation requests. Do not recommend user-agent-only bot allowlisting.

[PASTE SANITIZED HEADERS, LOG EVENT, AND CONFIG]

Prompt: sprawdź wyjątek uwierzytelniania

Review this proposed crawler-access rule for a gated site. Identify whether it relies
only on a spoofable user-agent, whether crawler identity is verified by published IP
ranges or reverse-and-forward DNS, and whether serving different content would create
a cloaking risk. Give a least-privilege alternative and a rollback test.

[PASTE SANITIZED RULE]

Shell: sprawdź anonimowy challenge

Uruchom to w terminalu bez ciasteczek przeglądarki ani danych uwierzytelniających.

URL='https://example.com/private'
curl -sS -D - -o /dev/null "$URL"

W przypadku prawdziwego 401 sprawdź WWW-Authenticate. Publiczny URL zwracający anonimowo 401, ale 200 w zalogowanej przeglądarce, to opisana wyżej pułapka stanu uwierzytelnienia.

PowerShell: sprawdź tę samą anonimową odpowiedź

$response = Invoke-WebRequest -Uri 'https://example.com/private' -SkipHttpErrorCheck
$response.StatusCode
$response.Headers['WWW-Authenticate']

Shell: porównaj zwykły i deklarowany user-agent bota

URL='https://example.com/page'
curl -sS -o /dev/null -w 'generic %{http_code}\n' "$URL"
curl -sS -o /dev/null -w 'claimed-bot %{http_code}\n' -A 'Googlebot' "$URL"

Porównanie może ujawnić regułę user-agenta, ale nie weryfikuje Googlebota; dowolny klient może wysłać taki ciąg. Przed zmianą reguł dostępu potwierdź rzeczywisty ruch crawlera osobno, przez IP albo reverse-and-forward DNS.

Narzędzia do znalezienia warstwy zwracającej 401

• Bulk HTTP Status Code Checker: potwierdź, które publiczne URL-e zwracają 401 bez sesji przeglądarki, i wyeksportuj dotknięty zestaw.
• HTTP Header Checker: sprawdź WWW-Authenticate, nagłówki cache/CDN i przeskoki przekierowań, aby znaleźć wskazówki dotyczące warstwy wydającej odpowiedź.
• Googlebot Verifier: zweryfikuj dowody dotyczące IP crawlera przed utworzeniem wyjątku dostępu; sam user-agent niczego nie dowodzi.
• URL Inspection w Search Console, Live Test: potwierdź, co może pobrać aktywne pobranie Google po poprawce.
• Zdarzenia bezpieczeństwa CDN/WAF i logi origin: połącz identyfikator żądania i czas, aby ustalić, czy 401 wygenerował brzeg, aplikacja czy origin.

Sprawdź się: 401 Unauthorized

Pięć krótkich pytań o znaczenie 401 i sposób obsługi tego kodu przez wyszukiwarki. Wybierz odpowiedź przy każdym, a potem sprawdź wynik.

Dziennik zmian