Robots.txt disallow: najczęstsze błędy, które kosztują widoczność

Plik robots.txt ma kilka linijek. Mało kto go czyta po wdrożeniu strony, bo „działa i tyle”. Problem zaczyna się wtedy, gdy nikt nie sprawdza, co ten plik faktycznie mówi robotom Google. Wystarczy jedna reguła Disallow: / przeniesiona z wersji testowej na produkcję i strona znika z crawla na tygodnie, nawet jeśli nikt nie zauważy tego od razu w ruchu.

W tym artykule nie ma teorii składni. Jest zestaw sytuacji, które realnie się zdarzają w projektach na Payload CMS, Next.js i w starszych systemach, oraz sposób, jak je wychwycić zanim zaszkodzą pozycjom.

Czym robots.txt naprawdę jest, a czym nie jest

Robots.txt to plik tekstowy w katalogu głównym domeny. Mówi robotom wyszukiwarek, które ścieżki mogą odwiedzać, a których nie powinny crawlować. To wszystko. Plik nie decyduje o tym, czy adres trafi do indeksu Google. To częste nieporozumienie i warto je rozbić od razu.

Disallow blokuje crawlowanie, czyli odwiedzanie i pobieranie treści strony przez robota. Nie blokuje indeksowania. Jeśli adres jest znany Google z innych źródeł, na przykład z linków wewnętrznych albo z linków z innych domen, może trafić do indeksu bez tytułu i opisu, z samym adresem URL. To gorszy efekt niż brak strony w wynikach, bo generuje słaby, pusty snippet.

Żeby faktycznie usunąć stronę z indeksu, potrzebny jest tag meta name=„robots” content=„noindex” albo nagłówek HTTP X-Robots-Tag. Trzeba tu pamiętać o kluczowej zasadzie: jeśli zablokujesz adres przez Disallow, robot Google tam nie wejdzie, więc nigdy nie przeczyta tagu noindex. Aby wyindeksować stronę, najpierw musisz zezwolić na jej crawlowanie. Disallow i noindex to dwa różne mechanizmy, a ich błędne łączenie to źródło połowy problemów opisanych dalej.

Disallow: / czyli klasyk po migracji

Najczęstsza i najbardziej kosztowna wpadka. Wersja deweloperska albo staging ma w robots.txt regułę blokującą całą witrynę dla wszystkich robotów. To standard, bo nikt nie chce, żeby Google indeksował kopię testową ze starymi cenami czy niedokończonymi treściami. Problem zaczyna się w dniu wdrożenia, gdy ten sam plik trafia razem z resztą kodu na produkcję i nikt go nie zmienia.

Skutek jest brutalny. Googlebot dostaje sygnał, że ma zignorować całą domenę. Nie od razu wypada z indeksu, ale crawl spada do zera, nowe treści nie są odwiedzane, a po pewnym czasie zaczynają wypadać strony, które wcześniej były w wynikach. W Search Console pojawia się komunikat o zablokowanych adresach w raporcie indeksowania, tylko trzeba tam zajrzeć, żeby to zauważyć.

Przy wdrożeniach na Payload CMS i Next.js ten błąd bywa jeszcze łatwiejszy do popełnienia, bo plik robots.txt często generuje się dynamicznie na podstawie zmiennej środowiskowej. Jeśli zmienna odróżniająca środowisko testowe od produkcyjnego nie jest ustawiona poprawnie na serwerze produkcyjnym, aplikacja może serwować tę samą, restrykcyjną wersję pliku niezależnie od domeny.

Jak to sprawdzić w 30 sekund

• Wejść na adres domena.pl/robots.txt bezpośrednio w przeglądarce, nie przez panel.
• Sprawdzić, czy w sekcji dla User-agent: * nie ma samotnej reguły Disallow: / bez żadnych wyjątków.
• Porównać zawartość pliku na produkcji z zawartością na środowisku testowym, jeśli takie istnieje równolegle.
• Zrobić to po każdym większym wdrożeniu, nie tylko po migracji domeny.

Zła mapa strony w dyrektywie Sitemap

Plik robots.txt często zawiera linię wskazującą lokalizację mapy strony, na przykład Sitemap: https://domena.pl/sitemap.xml. To wygodne, bo roboty od razu wiedzą, gdzie szukać listy adresów. Problem zaczyna się, gdy ta linia wskazuje na starą domenę po migracji, na protokół http zamiast https, albo na adres, który po zmianie struktury URL już nie istnieje i zwraca błąd 404.

To nie zawali całej witryny jak Disallow: /, ale utrudnia robotom efektywne odkrywanie nowych i zmienionych adresów. W praktyce oznacza to wolniejsze indeksowanie nowych treści i dłuższe utrzymywanie się starych, nieaktualnych adresów w wynikach.

Druga odmiana tego błędu to mapa strony, która zawiera adresy zablokowane tą samą regułą Disallow kawałek wyżej. To sprzeczny sygnał: mapa mówi „te adresy są ważne, odwiedź je”, a Disallow mówi „nie wchodź tutaj”. Google w takich przypadkach zwykle honoruje Disallow, więc mapa staje się częściowo bezużyteczna.

Zablokowany staging widoczny w wynikach

Odwrotność pierwszego problemu. Środowisko testowe, zamiast mieć własny, restrykcyjny robots.txt, dziedziczy plik z produkcji albo nie ma go wcale. Subdomena typu staging.domena.pl albo test.domena.pl zostaje odkryta przez roboty, zaindeksowana i zaczyna konkurować w wynikach z właściwą domeną, czasem z identyczną albo bardzo podobną treścią.

To tworzy problem treści zduplikowanej na poziomie całej witryny. Google musi decydować, która wersja jest „prawdziwa”, i nie zawsze wybiera właściwą. Rozwiązanie jest proste w teorii: środowisko testowe wymaga absolutnej izolacji od wyszukiwarek, a do tego sam plik robots.txt nie wystarczy, bo zablokowana strona nadal może trafić do indeksu jako pusty wynik. Najskuteczniejszą i w 100% pewną metodą jest ochrona hasłem na poziomie serwera (Basic Auth) lub odcięcie dostępu po IP. W praktyce ten krok najczęściej ląduje na liście „zrobimy to później” i tam zostaje.

Wielkość liter, trailing slash i inne drobiazgi, które nie są drobiazgami

Roboty wyszukiwarek w większości rozróżniają wielkość liter w ścieżkach podanych w dyrektywach. Reguła Disallow: /Panel/ nie zablokuje ścieżki /panel/, jeśli różni się tylko wielkością liter. To błąd, który wygląda niewinnie w pliku, a w praktyce nie blokuje nic z tego, co miało być zablokowane.

Podobnie ze ukośnikiem na końcu adresu. Disallow: /katalog blokuje wszystko, co zaczyna się od tego ciągu znaków, włącznie z /katalog-inny/ albo /katalog2.html. Disallow: /katalog/ blokuje tylko to, co jest wewnątrz tego katalogu. To pozornie kosmetyczna różnica, która w rozbudowanej strukturze URL potrafi zablokować albo odblokować znacznie więcej niż zakładano.

Trzeci klasyk to plik robots.txt umieszczony tylko w katalogu głównym głównej domeny, przy jednoczesnym pominięciu subdomen. Sklep na sklep.domena.pl i blog na blog.domena.pl to dla robotów dwa osobne serwisy. Każdy wymaga własnego pliku, jeśli ma być inaczej traktowany niż domena główna.

Blokowanie zasobów, których Google potrzebuje do renderowania

Współczesne strony, zwłaszcza budowane na Next.js, często ładują część treści przez JavaScript. Jeśli plik robots.txt blokuje katalogi ze skryptami JS albo arkuszami CSS, Googlebot może zrenderować stronę inaczej niż widzi ją użytkownik. W skrajnych przypadkach robot nie widzi treści głównej, formularza albo nawigacji, bo elementy odpowiedzialne za ich wyświetlenie są zablokowane.

To błąd, który łatwo przeoczyć, bo strona „wygląda dobrze” dla człowieka w przeglądarce. Warto raz na jakiś czas sprawdzić, jak wygląda zrenderowana wersja strony z perspektywy robota, a nie tylko czy plik robots.txt zawiera poprawną składnię. Poprawna składnia i poprawny efekt to dwie różne rzeczy.

Kiedy grzebanie w robots.txt nie ma sensu

Nie każda strona potrzebuje rozbudowanego pliku robots.txt. Mała witryna wizytówkowa, kilka podstron, brak paneli logowania i wersji testowych dostępnych publicznie, brak parametrów URL generujących duplikaty. W takim przypadku minimalna wersja pliku, ewentualnie z jedną linią wskazującą mapę strony, wystarcza w pełni. Dorzucanie dyrektyw „na wszelki wypadek” zwiększa ryzyko błędu bez żadnego realnego zysku.

Sensowny budżet czasu na audyt i naprawę robots.txt przy średniej wielkości serwisie firmowym to zwykle kilka godzin pracy specjalisty: sprawdzenie pliku, porównanie z mapą strony, weryfikacja renderowania kluczowych podstron, poprawki i ponowna weryfikacja po wdrożeniu. Przy sklepie z rozbudowaną strukturą kategorii, filtrów i parametrów URL ten czas rośnie, bo trzeba przemyśleć, które kombinacje adresów mają sens dla robotów, a które generują tylko duplikaty do przekopania.

Jak wychwycić błąd przed wdrożeniem, nie po

Najprostszy proces, który działa niezależnie od wielkości firmy: przed każdym wdrożeniem na produkcję ktoś fizycznie otwiera adres domena.pl/robots.txt i czyta go od góry do dołu. Nie skanuje wzrokiem, czyta. Sprawdza, czy reguły odpowiadają aktualnej strukturze strony, czy mapa strony wskazuje właściwy adres, czy nie ma pozostałości po środowisku testowym.

Drugi krok to monitorowanie raportu indeksowania w Search Console po każdej większej zmianie. Nagły spadek liczby zaindeksowanych stron albo wzrost liczby adresów oznaczonych jako zablokowane przez robots.txt to sygnał do sprawdzenia pliku, zanim problem urośnie.

Trzeci element, rzadziej stosowany, ale wartościowy przy serwisach na headless CMS: trzymanie logiki generowania robots.txt jako części kolekcji konfiguracyjnej, a nie statycznego pliku wgrywanego ręcznie na serwer. Wtedy zmiana środowiska (deweloperskie, testowe, produkcyjne) automatycznie wpływa na treść pliku bez ręcznej edycji, co redukuje ryzyko błędu ludzkiego przy wdrożeniu.

FAQ

Czy Disallow w robots.txt usuwa stronę z wyników Google?

Nie. Disallow blokuje crawlowanie, nie indeksowanie. Adres może pozostać w indeksie bez tytułu i opisu, jeśli Google znał go z innych źródeł, na przykład z linków. Do usunięcia z indeksu potrzebny jest tag noindex albo odpowiedni nagłówek HTTP.

Jak sprawdzić, czy mój plik robots.txt blokuje coś ważnego?

Najprościej wejść na adres domena.pl/robots.txt i przeczytać reguły linia po linii, sprawdzając każdą ścieżkę Disallow względem realnej struktury URL serwisu. Warto też porównać listę adresów w mapie strony z regułami blokującymi, żeby wykluczyć sprzeczność między nimi.

Czy każda subdomena potrzebuje własnego pliku robots.txt?

Tak, jeśli ma być traktowana inaczej niż domena główna. Roboty wyszukiwarek traktują subdomeny jako osobne serwisy. Brak pliku na subdomenie testowej to częsty powód, dla którego wersja deweloperska strony pojawia się w wynikach wyszukiwania.

Co jest gorsze: brak pliku robots.txt czy błędny plik robots.txt?

Brak pliku oznacza domyślny dostęp dla wszystkich robotów do całej witryny, co w większości przypadków jest neutralne. Błędny plik, na przykład z pozostałą po migracji regułą Disallow: /, aktywnie blokuje crawl całej domeny. W praktyce brak pliku jest bezpieczniejszy niż plik napisany bez zrozumienia konsekwencji.