Języki

Kod 403 Forbidden

Co oznacza błąd HTTP 403, jak Google go traktuje (blokada podobna do noindex), jakie są częste przyczyny (kontrola dostępu, blokowanie botów, błędne uprawnienia) oraz jak naprawiać 403 w SEO.

Opublikowano po raz pierwszy: 27 cze 2026 · Ostatnia aktualizacja: 9 sie 2026 · Advanced
Języki
AIAutor:AI v2
1 sygnał dowodowy na tej stronie

403 Forbidden oznacza, że serwer zrozumiał żądanie, ale odmówił jego realizacji — odmowa dostępu nie musi w ogóle dotyczyć danych uwierzytelniających (serwer może nawet wysłać 404, aby ukryć istnienie zabronionego zasobu). To nie 404 („niczego tu nie ma”) ani 401 („najpierw się uwierzytelnij”); 403 to aktywne „nie możesz tego dostać”. W SEO 403 utrzymujący się na stronie, która ma być publiczna, nie pozwala jej trafić do indeksu Google — rezultat podobny do noindex, ale mechanizm inny, bo Google nie może odczytać treści z odpowiedzi 4xx. Ponieważ Googlebot nigdy nie wysyła danych uwierzytelniających, 403 dla niego warto zbadać, zamiast zakładać, że jest zamierzony — częste przyczyny to filtr botów CDN/WAF, blokada IP/user-agenta serwera, wtyczka bezpieczeństwa albo błąd .htaccess/uprawnień, choć brak wiarygodnych danych o częstości. Nigdy nie używaj 403 do ograniczania crawlowania (do tego służą 429/503, tylko przez krótki czas). Najpierw sprawdź intencję: niektóre 403-y (staging, panel administracyjny, treść z dostępem) są poprawne i nie wymagają naprawy. Ważne odwrócenie: 403 na samym robots.txt jest traktowany permisywnie, a 403 na stronie jest twardą blokadą.

TL;DR — 403 oznacza, że serwer zrozumiał żądanie i odmówił dostępu — inaczej niż 404 (usunięto) i 401 (uwierzytelnij się). Dla indeksowania rezultat przypomina noindex: Google nie zindeksuje URL-a 403 ani usunie z indeksu takiego, który był już zindeksowany, choć mechanizm (blokada serwera/CDN-u/WAF-u) nie przypomina znacznika meta. Ponieważ Googlebot nigdy nie wysyła danych uwierzytelniających, 403 dla Googlebota jest niemal zawsze błędną konfiguracją — najczęściej filtrowaniem botów na CDN-ie/WAF-ie (Cloudflare Bot Fight Mode jest częstym sprawcą), blokadą IP/user-agenta serwera, wtyczką bezpieczeństwa albo błędem .htaccess/uprawnień. 403 nie wpływa na tempo crawlowania — nigdy nie używaj go do ograniczania (do tego służą 429/503). Ważny jest też przypadek odwrotny: 403 na samym pliku robots.txt jest traktowany permisywnie, a 403 na stronie jest twardą blokadą.

403 a 401 i 404 — najpierw uporządkuj model mentalny

Te trzy kody są stale mylone, a rozróżnienie napędza całą diagnozę. Podstawowa definicja pochodzi z samej specyfikacji HTTP, RFC 9110 §15.5.4: serwer zrozumiał żądanie i odmawia jego spełnienia. Kilka niuansów z tego samego rozdziału ma większe znaczenie, niż się zwykle zakłada:

  • Odmowa nie musi dotyczyć danych uwierzytelniających. RFC 9110 pozwala zwrócić 403 z powodów niezwiązanych z uwierzytelnianiem — nie dowodzi on uniwersalnie, że żądający jest “known” (tłumaczenie) „znany” ani że w ogóle użyto danych uwierzytelniających. Nie odczytuj każdego 403 jako historii o logowaniu.
  • 403 nie musi przyznawać, że zasób istnieje. Specyfikacja wyraźnie pozwala serwerowi źródłowemu, który chce ukryć, czy zabroniony zasób w ogóle istnieje, odpowiedzieć 404. Działa to też w drugą stronę: 404 nie zawsze oznacza “nothing was ever here” (tłumaczenie) „nigdy niczego tu nie było” — czasami oznacza “there’s something here, but I don’t want you to know about” (tłumaczenie) „coś tu jest, ale nie chcę, żebyś o tym wiedział”.
  • 401 a 403 to nie tylko “weaker vs. stronger.” (tłumaczenie) „słabszy kontra silniejszy”. 401 jest konkretnym challenge’em uwierzytelniania — specyfikacja wymaga nagłówka WWW-Authenticate informującego klienta, jak się uwierzytelnić. 403 nie ma takiego wymogu; to szersza odmowa, która nie obiecuje, że ponowne uwierzytelnienie (tymi samymi albo innymi danymi) coś zmieni. Wersja MDN prostym językiem: 403 jest “similar to 401, except that … authenticating or re-authenticating makes no difference. The request failure is tied to application logic, such as insufficient permissions.” (tłumaczenie) „podobny do 401, z tym że … uwierzytelnienie lub ponowne uwierzytelnienie niczego nie zmienia. Niepowodzenie żądania jest związane z logiką aplikacji, np. niewystarczającymi uprawnieniami.” Evidence for this claim A 403 response means the server understood the request but refuses to fulfill it, and authenticating does not necessarily make a difference. Scope: RFC 9110 defines the protocol semantics; it does not identify the application, firewall, or policy responsible for a specific response. Confidence: high · Verified: IETF: RFC 9110 §15.5.4 — 403 Forbidden
  • 404 Not Found, dla porównania — zwykły przypadek oznacza “there’s nothing here,” (tłumaczenie) „nic tu nie ma”, choć wyżej opisano możliwość ukrywania zasobu.

To rozróżnienie jest jednym z powodów, dla których 403 dla Googlebota warto sprawdzić ponownie, zamiast traktować go jako rutynę. 401 dla bota na stronie tylko dla członków może być prawidłowy — obszar wymaga logowania. 403 dla bota na stronie, która powinna być publiczna, oznacza, że jakaś reguła uznała żądającego za niepożądanego — choć, jak opisano niżej, nadal warto potwierdzić, że strona rzeczywiście miała być publiczna, zanim nazwiesz to błędem.

Jak Google traktuje 403 (rezultat przypomina noindex, ale mechanizm jest inny)

Google zalicza 403 do reszty rodziny 4xx. Dokumentacja Search Central mówi: “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 indeksuje URL-i zwracających kod statusu 4xx, a URL-e już zindeksowane, które zwracają kod 4xx, są usuwane z indeksu.” Oraz: “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.” Google zaznacza też, że częstotliwość crawlowania znanego URL-a stopniowo maleje, im dłużej zwraca on 4xx — jest to efekt dotyczący pojedynczego URL-a, odrębny od ogólnego tempa crawlowania witryny. 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 indexing outcome for persistent 403 responses, not the article's analogy to noindex. Confidence: high · Verified: Google: How HTTP status codes affect Google's crawlers

Rezultat przypomina więc noindex: strona nie trafi do indeksu, a jeśli już w nim jest, z czasem wypadnie. Mechanizm jest jednak rzeczywiście inny, a nie tylko kosmetycznie odmienny: znacznik noindex musi zostać pobrany i odczytany z HTML-a, podczas gdy 403 uniemożliwia Google odczytanie jakiejkolwiek treści — nie ma strony do przetworzenia. Dwie różne ścieżki prowadzą do tego samego braku w wynikach wyszukiwania. Dlatego w moim przewodniku po kodach statusu HTTP opisuję 403 po prostu jako “the client is known but doesn’t have access rights,” (tłumaczenie) „klient jest znany, ale nie ma praw dostępu” i zaznaczam, że takie kody powodują wypadanie stron z indeksu — choć “known” (tłumaczenie) „znany” jest tam skrótem raportowym Google, a nie twierdzeniem, że każdy 403 dotyczy uwierzytelnionego żądającego.

Dlaczego 403 dla Googlebota warto zbadać (nie zawsze jest błędem)

Ta sekcja opiera się na własnym dokumencie pomocy Google dotyczącym indeksowania stron: “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 uzyskał dostępu. Googlebot jednak nigdy nie podaje danych uwierzytelniających, więc serwer nieprawidłowo zwraca ten błąd. Strona nie zostanie zindeksowana.” Czytaj to w kontekście — są to wskazówki dotyczące raportu dla strony, którą Search Console zakłada, że chcesz indeksować, a nie uniwersalne twierdzenie, że każdy 403 dla Googlebota jest błędem. Googlebot się nie uwierzytelnia, więc 403 opisany wyłącznie jako “Twoje dane są niewystarczające” (tłumaczenie) „Twoje dane są niewystarczające” nie pasuje do niego — ale wiele 403-ów nie dotyczy danych uwierzytelniających, a serwer może zgodnie z prawem zdecydować, że Googlebot (albo ktokolwiek inny) nie dostanie zasobu, kropka.

Zanim zaczniesz szukać naprawy: czy ta strona naprawdę ma być publiczna i indeksowalna? Jeśli to staging, panel administracyjny, paywall albo dowolna treść z dostępem, 403 dla Googlebota jest prawidłowy i niczego nie trzeba naprawiać (więcej w sekcji „Kiedy 403 jest w porządku”). Jeśli ma być publiczna, najpewniej patrzysz na regułę, która zadziałała wobec niewłaściwego żądającego — WAF oznaczył crawler jako bota do zablokowania, blokada zakresu IP objęła adresy Google albo domyślna paranoja wtyczki bezpieczeństwa — ale nie mam wiarygodnych danych, jak często każda z tych przyczyn jest rzeczywistym źródłem, więc potraktuj poniższą listę jako kandydatów do sprawdzenia, a nie diagnozę. Wytyczne Google dla strony, która powinna być publiczna: dopuść użytkowników bez logowania albo jawnie zezwól Googlebotowi bez uwierzytelniania (po wcześniejszym potwierdzeniu jego tożsamości — więcej niżej).

403 nie wpływa na tempo crawlowania — nie używaj go do ograniczania

Ludzie czasami sięgają po 403 (albo 404), aby skłonić Googlebota do odpuszczenia przeciążonego serwera. Nie rób tego. Google mówi 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 crawlowania. Kody statusu 4xx, z wyjątkiem 429, nie wpływają na tempo crawlowania.” Warto precyzyjnie określić zakres: Google osobno mówi, że częstotliwość crawlowania pojedynczego znanego URL-a stopniowo maleje, im dłużej zwraca on 4xx — ale nie jest to ograniczanie całej witryny. Jeśli potrzebujesz tego drugiego, 403 nie pomoże.

Gary Illyes napisał o tym cały tekst (Don’t 404 my yum): “All 4xx HTTP status codes (again, except 429) will cause your content to be removed from Google Search.” (tłumaczenie) „Wszystkie kody statusu HTTP 4xx (ponownie z wyjątkiem 429) spowodują usunięcie treści z wyszukiwarki Google.” Właściwą awaryjną dźwignią jest 500, 503 lub 429 zwracany przez krótki czas (godziny, nie dni) — i nawet to nie jest bezwarunkowe: Google ostrzega, że utrzymujące się odpowiedzi 5xx przez wiele dni również grożą wypadnięciem stron z indeksu, więc liczą się zakres i czas trwania, a nie tylko wybrany kod. Relacja Barry’ego Schwartza z wcześniejszego zdarzenia ujęła stawkę dosadnie: witryny “lost load[s] of their pages from our index because they were serving them with a 403 status code instead of a 503.” (tłumaczenie) „straciły mnóstwo stron z naszego indeksu, ponieważ serwowały je z kodem statusu 403 zamiast 503.” 503 jest rozumiany jako tymczasowy, a 403 prowadzi do usunięcia z indeksu.

Pułapka robots.txt: 403 na robots.txt jest permisywny, a nie restrykcyjny

To rozróżnienie pomija prawie każdy konkurencyjny artykuł, a odwraca intuicję. 403 na stronie jest twardą blokadą. Natomiast 403 na samym pliku robots.txt jest traktowany odwrotnie. Specyfikacja robots.txt Google mówi: “Google’s crawlers treat all 4xx errors, except 429, as if a valid robots.txt file didn’t exist. This means that Google assumes that there are no crawl restrictions.” (tłumaczenie) „Crawlery Google traktują wszystkie błędy 4xx, z wyjątkiem 429, tak jakby prawidłowy plik robots.txt nie istniał. Oznacza to, że Google zakłada brak ograniczeń crawlowania.”

Evidence for this claim A 403 on `/robots.txt` is handled differently from a 403 on a page: Google treats a non-429 4xx robots response as if no valid robots file exists and assumes no restrictions from that file. Scope: robots.txt fetch only Confidence: high · Verified: How Google interprets the robots.txt specification

Jeśli więc firewall zacznie zwracać 403 dla robots.txt, Google uzna, że nie masz żadnych reguł, i będzie crawlowć swobodnie — także ścieżki, których nie chcesz udostępniać. Barwna wersja Illyesa: jeśli miałeś regułę blokującą dostęp do swojej “brudnej bielizny”, teraz Googlebot też się o niej dowie. Nie myl „mój robots.txt zwrócił 403” (Google ignoruje teraz Twoje reguły) z „moje strony zwróciły 403” (te URL-e wypadają z indeksu). Skutki są przeciwne, a błędne rozpoznanie przypadku sprawia, że naprawiasz niewłaściwą rzecz.

Jak Bing traktuje 403

Szczerze mówiąc, publiczna dokumentacja Binga dotycząca konkretnie 403 jest skromniejsza niż dokumentacja Google, więc ograniczę zakres zamiast go sztucznie rozbudowywać. Bingbot jest blokowany przez te same mechanizmy co Googlebot — reguły robots.txt, blokady IP/user-agenta na poziomie serwera oraz reguły WAF/firewalla. Bing Webmaster Tools pokazuje błędy crawlowania w alertach dotyczących takich błędów. Praktyczny wniosek jest taki sam w obu wyszukiwarkach: przepuść zweryfikowanego crawlera przez warstwę bezpieczeństwa i sprawdź bota na podstawie opublikowanych zakresów IP oraz odwrotnego DNS, a nie na podstawie samego user-agenta. Traktuj Binga jako przypomnienie, że „napraw Googlebota” nie oznacza automatycznie „napraw wszystkie boty” — po zmianie WAF-u sprawdź narzędzia obu wyszukiwarek.

Najczęstsze przyczyny (bez rankingu — nie mam danych o częstości w różnych witrynach)

Ochrona botów CDN/WAF — najczęściej pomijana przyczyna w istniejących treściach SEO. Od tego zacząłbym sprawdzanie w 2026 roku, choć nie mogę powiedzieć, jak często jest to rzeczywisty winowajca w porównaniu z poniższymi przyczynami. Cloudflare Bot Fight Mode, Super Bot Fight Mode, zarządzane reguły WAF i niestandardowe reguły firewalla rutynowo zwracają 403 Googlebotowi i Bingbotowi jako szkodę uboczną. Wskazówka: blokada jest na brzegu sieci, więc serwer źródłowy i CMS wyglądają zupełnie poprawnie, a GSC nadal pokazuje 403. Sprawdź Security Events w panelu CDN pod kątem wyzwania lub zablokowania crawlera.

2. Blokady IP lub user-agenta na poziomie serwera/hostingu. Niektórzy dostawcy domyślnie blokują według user-agenta albo ograniczają tempo, a zakresy IP zablokowane z myślą o nadużyciach mogą objąć adresy crawlerów.

3. Błędna konfiguracja robots.txt/.htaccess. Pojedyncze Deny from albo zepsuta reguła przepisywania może zabronić dostępu do całego katalogu. (Pamiętaj też o pułapce robots.txt opisanej wyżej.)

4. Wtyczki bezpieczeństwa. Wordfence, iThemes Security i podobne narzędzia mają agresywne ustawienia domyślne blokowania botów, które mogą obejmować prawidłowe crawlery.

5. Ściany logowania / treść uwierzytelniona. Wszystko za uwierzytelnianiem z założenia zwraca botowi odpowiedź odmowną — Googlebot nigdy się nie loguje. Ta przyczyna jest często zamierzona (zobacz ostatnią sekcję).

6. Błędy uprawnień plików/katalogów. Klasyczna przyczyna po stronie administratora serwera. W WordPressie Rank Math dokumentuje rozsądne wartości — katalogi 755/750, pliki 644/640, wp-config.php 400/440 — oraz „regenerate .htaccess” w ustawieniach Permalinks jako częstą naprawę.

7. Złośliwe oprogramowanie / przejęta witryna wstrzykujące złe reguły dostępu oraz 8. blokowanie geograficzne, które przypadkiem obejmuje zakres IP crawlera.

Diagnozowanie 403 — ustal, która warstwa go wystawia

Większość poradników od razu mówi „wyłącz wtyczki”. Prawdziwa umiejętność polega na ustaleniu, która warstwa odrzuca żądanie — a sam kod 403 tego nie mówi; potrzebujesz nagłówków odpowiedzi, logów albo wpisu w zdarzeniach bezpieczeństwa, który rzeczywiście wskaże CDN, WAF, aplikację, hosting, uprawnienia, geografię lub cache, zanim nazwiesz winowajcę. Nie przechodź od razu do „to pewnie WAF” bez dowodów. Tak różni się naprawa w zależności od warstwy:

  1. GSC Page Indexing → „Blocked due to access forbidden (403)”, aby zobaczyć dotknięte URL-e, a następnie URL Inspection → Test Live URL, aby sprawdzić bieżącą odpowiedź.
  2. Odtwórz problem przez curl, zmieniając user-agenty, aby potwierdzić kod faktycznie zwracany przez serwer: 
    # As a generic client
curl -I https://example.com/page/
# Spoofing Googlebot's UA (tests UA-based rules)
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page/
    Jeśli zwykły user-agent przeglądarki dostaje 200, a user-agent Googlebota dostaje 403, znalazłeś regułę user-agenta.
  3. Sprawdź własny status robots.txt (czy on zwraca 403? To inny problem — zobacz wyżej).
  4. Przejrzyj Security Events CDN-u/WAF-u pod kątem wyzwania lub zablokowania crawlera.
  5. Zweryfikuj, czy crawler naprawdę jest Googlebotem, korzystając z odwrotnego i zgodnego DNS-u, a nie z ciągu user-agenta (który łatwo podrobić).
  6. Izoluj problem, wyłączając elementy etapami — po jednej regule WAF-u lub wtyczce — aż 403 zniknie.

Naprawa — dodawaj boty do allowlisty właściwie

Kusząca naprawa polega na dodaniu do allowlisty ciągu user-agenta Googlebota. Nie poprzestawaj na tym — ciągi user-agentów łatwo podrobić, więc allowlista oparta wyłącznie na UA jest luką bezpieczeństwa, która przepuści każdego scrapera podającego się za Googlebota. Prawidłowa weryfikacja wygląda tak:

  • Potwierdź boty przez odwrotny i zgodny DNS albo na podstawie opublikowanych zakresów IP Google/Binga.
  • Większość CDN-ów/WAF-ów oferuje kategorię „verified bots”, która wykonuje tę walidację — wybierz ją zamiast surowej reguły dopuszczającej UA.
  • Napraw konkretną regułę (zarządzaną regułę WAF-u, jedną regułę firewalla albo jedno ustawienie wtyczki), zamiast wyłączać całe zabezpieczenie.
  • Następnie użyj Validate Fix w raporcie Page Indexing GSC, a jeśli sprawa jest pilna, poproś o ponowne indeksowanie przez URL Inspection.

Kiedy 403 jest w porządku — tych przypadków nie „naprawiaj”

Nie każdy 403 jest błędem. 403 jest poprawny i zamierzony dla witryn stagingowych, paneli administracyjnych, prywatnych sekcji członkowskich oraz treści za paywallem/bramką, których nigdy nie chciałeś indeksować. W audycie Ahrefs lub Screaming Frog 403 na takich stronach nie jest problemem — naprawa jest potrzebna tylko wtedy, gdy przypadkiem blokowana jest strona, która ma być publiczna i indeksowalna. Nie „rozwiązuj” odruchowo każdego 403 zgłoszonego przez audyt; najpierw potwierdź, że daną stronę rzeczywiście chcesz mieć w indeksie.

W szerszym obrazie — różnicy między 4xx i 5xx oraz miejscu 403 wśród tych kodów — przeczytaj mój tekst o kodach statusu HTTP i ich wpływie na SEO oraz powiązane pogłębione teksty o 401 Unauthorized i 404 Not Found w tym klastrze.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.