Zablokowana przez plik robots.txt: co oznacza ten stan w Search Console i jak go naprawić

Stan zablokowana przez plik robots.txt pojawia się w raporcie indeksowania stron w Google Search Console, wśród powodów, dla których strony nie są zindeksowane. Dokumentacja raportu indeksowania stron opisuje go jednym zdaniem: strona została zablokowana przez plik robots.txt witryny. Za tym zdaniem kryją się dwie bardzo różne sytuacje, zdrowa i przypadkowa blokada, a do tego mylący krewny: „Zindeksowana, mimo że zablokowana przez plik robots.txt”. Ten przewodnik pokazuje, jak je odróżnić i naprawić każdą z nich, niczego przy tym nie psując. Jeśli sam plik jest dla Ciebie nowością, zacznij od naszej definicji robots.txt.

Co oznacza „Zablokowana przez plik robots.txt” w Search Console?

Plik robots.txt znajduje się w katalogu głównym hosta (przyklad.pl/robots.txt) i mówi robotom, które ścieżki mogą pobierać. Gdy Googlebot znajdzie URL, przez link lub mapę witryny, najpierw sprawdza ten plik. Jeśli reguła Disallow pasuje do ścieżki dla jego user-agenta, nie pobiera strony. Search Console umieszcza wtedy URL w kategorii „Zablokowana przez plik robots.txt”.

Wynikają z tego dwie konsekwencje. Google nie widzi treści, tytułu, linków wewnętrznych ani metatagów strony. A skoro nigdy jej nie czyta, nie widzi też tagu noindex. Stan figuruje wśród powodów braku indeksowania i dla większości witryn ma charakter informacyjny: sam Google zauważa, że adresy zablokowane przez robots.txt są najpewniej blokowane celowo.

Problem zaczyna się, gdy na liście są strony, które chcesz widzieć w Google: karty produktów, artykuły, kategorie albo cała witryna po migracji. Wtedy blokada jest bezpośrednią przyczyną tego, że strona nie pojawia się w Google, i jednym z problemów technicznych, które naprawia się najszybciej.

„Zablokowana przez plik robots.txt” czy „Zindeksowana, mimo blokady”?

Drugi stan wygląda na sprzeczny i to on najbardziej niepokoi właścicieli witryn. Wprowadzenie Google do pliku robots.txt wyjaśnia: robots.txt nie służy do wykluczania strony z Google. Jeśli inne strony linkują do zablokowanego adresu, Google może zindeksować sam URL bez jego skanowania. Wynik pokazuje wtedy adres bez opisu, bo Google nigdy nie przeczytał tekstu.

Kluczowe jest, by najpierw zdecydować, czego chcesz dla każdego URL: zindeksowany czy niezindeksowany. Robots.txt odpowiada na inne pytanie (skanowany czy nieskanowany), a mieszanie tych dwóch kwestii jest źródłem większości błędów.

Dlaczego Twoje strony są blokowane przez robots.txt?

Większość przypadkowych blokad ma kilka przyczyn. Sprawdź je w tej kolejności:

• Reguła ze środowiska testowego trafia na produkcję. Disallow: / chroni wersję testową, a potem wchodzi razem z wdrożeniem i blokuje wszystko.
• Ustawienie CMS. WordPress ma opcję „Proś wyszukiwarki o nieindeksowanie tej witryny”; inne platformy mają podobne przełączniki, które zmieniają robots.txt lub dodają nagłówki.
• Zbyt szeroka reguła. Disallow: /p blokuje /produkty/ i /ceny/ tak samo jak /p/. Reguły robots.txt dotyczą początku ścieżki.
• Symbole wieloznaczne. * oznacza dowolny ciąg znaków, a $ koniec adresu. Disallow: /*? blokuje każdy URL z parametrem, w tym strony paginacji lub filtrów, które chcesz mieć w indeksie.
• Zablokowane zasoby. Zablokowanie /assets/ lub /wp-includes/ ukrywa CSS i JavaScript potrzebne Google do wyrenderowania strony, co pogarsza zrozumienie treści.
• Migracja. Ścieżki się zmieniają, stary robots.txt zostaje albo nowy hosting serwuje własny plik domyślny.
• Niewłaściwy host. Każda subdomena i każdy protokół ma własny plik: reguły z www.przyklad.pl nie dotyczą sklep.przyklad.pl.

Pamiętaj, że Google stosuje najbardziej szczegółową regułę (najdłuższą pasującą ścieżkę), a gdy reguły Allow i Disallow są równie szczegółowe, wygrywa mniej restrykcyjna. Celowane Allow: /blog/ może więc ponownie otworzyć katalog objęty szerszą blokadą.

Jak naprawić „Zablokowana przez plik robots.txt” krok po kroku

1. Wyeksportuj dotknięte adresy URL

W Google Search Console otwórz Indeksowanie, potem Strony, i kliknij wiersz „Zablokowana przez plik robots.txt”. Wyeksportuj listę i posortuj według katalogów. Zwykle w ciągu minuty widać wzorzec: jeden katalog, jeden parametr, jedna subdomena.

2. Oddziel blokady celowe od błędów

Oznacz każdy wzorzec jako „zostawić zablokowane” albo „powinno być w Google”. Koszyki, proces zamówienia, konta klientów, wyniki wyszukiwania wewnętrznego i panele administracyjne trafiają do pierwszej grupy. Wszystko, co odpowiada na zapytanie, zdobywa linki lub jest w Twojej mapie witryny XML, do drugiej. URL, który jest jednocześnie w mapie witryny i zablokowany, to sprzeczność do rozwiązania.

3. Znajdź pasującą regułę

Otwórz narzędzie do sprawdzania adresów URL dla przykładowego adresu: pokazuje, czy skanowanie jest dozwolone. Potem przeczytaj plik na serwerze albo wklej URL do naszego darmowego testera robots.txt, aby zobaczyć, która linia go blokuje i dla jakiego user-agenta.

4. Zmień plik

Usuń lub zawęź regułę albo dodaj bardziej szczegółowe Allow. Wprowadź minimalną zmianę i przetestuj ją zarówno na URL, który ma zostać odblokowany, jak i na takim, który musi pozostać zablokowany. Jeśli plik jest chaotyczny, zbuduj czystą wersję w naszym generatorze robots.txt i porównaj przed publikacją.

5. Pozwól Google przeczytać nowy plik

Zgodnie ze specyfikacją robots.txt Google zwykle przechowuje plik w pamięci podręcznej do 24 godzin. Aby to przyspieszyć, otwórz Ustawienia, a potem raport robots.txt w Search Console (dostępny dla usług na poziomie domeny), i poproś o ponowne pobranie pliku. Następnie w narzędziu do sprawdzania adresów URL poproś o zindeksowanie najważniejszych odblokowanych adresów.

6. Zweryfikuj i monitoruj

Kliknij „Sprawdź poprawkę” na stronie problemu. Weryfikacja może potrwać od kilku dni do kilku tygodni, a nowe adresy są sprawdzane w miarę ponownego skanowania. Nasz przewodnik po indeksowaniu w Google wyjaśnia, co dzieje się po skanowaniu, gdy Google decyduje, czy strona zasługuje na pozostanie w indeksie.

Jak naprawić „Zindeksowana, mimo że zablokowana przez plik robots.txt”

Rozwiązanie zależy od tego, czego chcesz dla strony:

1. Chcesz, żeby strona była w Google. Usuń blokadę. Google przeskanuje stronę, przeczyta treść i pokaże zwykły wynik z tytułem i opisem.
2. Nie chcesz, żeby strona była w Google. Również usuń blokadę, a potem dodaj <meta name="robots" content="noindex"> w sekcji head lub nagłówek HTTP X-Robots-Tag: noindex dla plików PDF i innych. Gdy Google ponownie przeskanuje stronę i ją usunie, możesz ją znów zablokować, jeśli liczy się wolumen skanowania, choć większość witryn nigdy tego nie potrzebuje. Nasza definicja noindex opisuje dostępne opcje.
3. Strona nie powinna być publiczna. Zabezpiecz ją hasłem albo usuń (404 lub 410). Ani robots.txt, ani noindex nie są zabezpieczeniem.

Przy nawigacji fasetowej z tysiącami adresów filtrów blokada w robots.txt może pozostać właściwym narzędziem do oszczędzania budżetu indeksowania. Ostrzeżenie „Zindeksowana, mimo blokady” przy kilku z tych adresów jest wtedy do przyjęcia, o ile kanoniczne wersje kategorii są skanowalne i zindeksowane.

Jak sprawdzić, czy poprawka zadziałała

Trzy sygnały potwierdzają skuteczną poprawkę. Sprawdzenie aktywnego adresu URL pokazuje „Skanowanie dozwolone: tak”. Liczba zablokowanych stron w raporcie indeksowania spada w kolejnych tygodniach. A odblokowane strony zaczynają zbierać wyświetlenia w raporcie Skuteczność. Szybki test w naszym narzędziu do sprawdzania indeksowalności wyłapie też inne przeszkody, które często idą w parze z błędami robots.txt: zapomniany noindex, błędny tag kanoniczny lub przekierowanie.

Monitorowanie ma znaczenie, bo te błędy wracają. Aktualizacja motywu, wtyczka albo skrypt wdrożeniowy mogą nadpisać robots.txt bez niczyjej wiedzy. Obserwowanie stron, których kliknięcia i wyświetlenia nagle spadają, to najszybszy sygnał ostrzegawczy.

Panel GEO / SEO Sorank łączy się z Search Console i pokazuje te rosnące i spadające strony w jednym widoku. Blokadę wprowadzoną przy wdrożeniu widać wtedy jako grupę spadających adresów, a nie jako powolną, niewyjaśnioną utratę ruchu.

Robots.txt, roboty AI i GEO

Robots.txt ma dziś drugą publiczność: roboty asystentów AI. OpenAI, Anthropic, Perplexity i Google publikują własne user-agenty (GPTBot i OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended), które respektują robots.txt. Reguła przeznaczona dla jednego z nich albo ogólna blokada User-agent: * decyduje, czy ChatGPT, Claude lub Perplexity mogą czytać Twoje strony, gdy szukają w sieci materiału do odpowiedzi.

Obowiązuje ta sama logika co w przypadku Google: zdecyduj dla każdego bota, czego chcesz. Blokowanie robotów treningowych przy jednoczesnym dopuszczeniu robotów wyszukujących to częsty kompromis, a nasz przewodnik po robots.txt dla robotów AI wymienia user-agenty i reguły dla każdego z nich. Hasło w słowniku o robotach AI wyjaśnia, który bot co robi.

Aby zobaczyć skutki tych decyzji, śledź prompty ważne dla Twojej firmy. Śledzenie wzmianek w AI w Sorank pokazuje, czy ChatGPT, Gemini lub Claude cytują Twoją witrynę i których konkurentów cytują zamiast niej.

Zasada do zapamiętania

Robots.txt decyduje, co roboty mogą czytać; noindex decyduje, co mogą pokazać wyniki wyszukiwania. Blokuj tylko obszary bez wartości wyszukiwania, nigdy nie blokuj strony, którą chcesz zindeksować lub usunąć z indeksu, i sprawdzaj raport indeksowania stron po każdej migracji i każdym wdrożeniu. Większość problemów „zablokowana przez plik robots.txt” rozwiązuje się w kilka minut, gdy znajdziesz winną regułę, a panel Search Console w Sorank pomaga wychwycić kolejny przypadek, zanim zacznie kosztować ruch.