Plik robots.txt to jeden z tych elementów technicznego SEO, który przez większość czasu działa w tle, niezauważony, dopóki ktoś przypadkowo nie wprowadzi w nim zmiany blokującej dostęp do części serwisu.
Problem w tym, że skutki takiego błędu rzadko są natychmiastowe i widoczne – strony nie znikają z indeksu z dnia na dzień, tylko stopniowo przestają być odwiedzane przez robota, a ich pozycje w wynikach wyszukiwania cichnie się pogarszają, zanim ktokolwiek skojarzy to z jedną linijką w pliku konfiguracyjnym.
Sam plik robots.txt jest prosty w swojej konstrukcji, co paradoksalnie zwiększa ryzyko błędów – łatwo wprowadzić regułę szerszą niż zamierzona, zwłaszcza przy korzystaniu z symboli wieloznacznych czy kopiowaniu konfiguracji z innego projektu bez pełnego zrozumienia, co dokładnie ona blokuje.
Czym różni się blokada w robots.txt od tagu noindex
To rozróżnienie bywa mylące nawet dla osób zajmujących się SEO od dłuższego czasu. Wpis w pliku robots.txt uniemożliwia robotowi pobranie treści strony – Googlebot w ogóle nie odwiedza takiego adresu. Tag noindex umieszczony w kodzie strony działa inaczej: robot odwiedza stronę, odczytuje jej zawartość, ale świadomie nie dodaje jej do indeksu na podstawie tej właśnie instrukcji.
Konsekwencja tej różnicy jest istotna praktycznie: jeśli strona ma jednocześnie blokadę w robots.txt i tag noindex, Google nigdy nie zobaczy tego tagu, ponieważ w ogóle nie ma dostępu do treści strony. W takiej sytuacji adres może paradoksalnie nadal pojawiać się w wynikach wyszukiwania – bez opisu, jedynie jako sam URL – ponieważ Google wie o jego istnieniu z innych źródeł (np. linków), ale nie może zweryfikować jego zawartości.
Najczęstsze błędy konfiguracyjne
- Blokada całego serwisu pozostawiona po wdrożeniu wersji testowej – reguła
Disallow: /skopiowana z serwera deweloperskiego i zapomniana po przeniesieniu strony na produkcję, blokująca kompletnie cały serwis. - Zbyt szerokie reguły z symbolami wieloznacznymi – wzorzec zaprojektowany, by zablokować jeden konkretny katalog, przez nieprecyzyjne użycie znaku
*blokuje przy okazji zupełnie niepowiązane, wartościowe podstrony. - Zablokowanie zasobów potrzebnych do renderowania strony – blokada katalogów z plikami CSS lub JavaScript sprawia, że Google nie jest w stanie poprawnie wyrenderować i ocenić strony, nawet jeśli sam adres HTML pozostaje dostępny.
- Sprzeczne reguły dla różnych robotów – osobne wpisy dla różnych user-agentów, które z czasem stają się niespójne i trudne do przewidzenia bez dokładnej analizy całego pliku.
- Brak aktualizacji po zmianie struktury serwisu – reguły odnoszące się do katalogów lub adresów, które od dawna nie istnieją w obecnej strukturze, obok brakujących reguł dla nowych sekcji serwisu.
Jak sprawdzić, czy problem dotyczy Twojego serwisu
Podstawowym narzędziem diagnostycznym jest tester pliku robots.txt dostępny w Google Search Console, pozwalający sprawdzić, czy konkretny adres URL jest blokowany, i który dokładnie wiersz reguły za to odpowiada. Warto też okresowo przeglądać sam plik ręcznie, szczególnie po większych zmianach na stronie czy migracji serwisu – to moment, w którym najczęściej dochodzi do przypadkowego pozostawienia reguł nieadekwatnych do nowej struktury.
Przy większych serwisach samo sprawdzenie pliku nie zawsze wystarcza, ponieważ efekt blokady bywa widoczny dopiero w statusie indeksacji konkretnych grup adresów URL. Pomocne bywa wtedy porównanie listy adresów zablokowanych przez robots.txt z listą adresów faktycznie brakujących w indeksie – jeśli te dwie listy w dużej mierze się pokrywają, to silny sygnał, że problem leży właśnie w konfiguracji pliku.
Rola stałego monitoringu po wprowadzeniu zmian
Zmiana w pliku robots.txt to jedna z tych modyfikacji, które wywołują skutki rozłożone w czasie – nie da się ich w pełni ocenić od razu po wdrożeniu. Dlatego dobrą praktyką jest sprawdzenie statusu indeksacji kluczowych grup adresów zarówno przed, jak i po każdej zmianie w konfiguracji pliku. Przy niewielkiej liczbie podstron wystarczy ręczna kontrola przez operator site:, natomiast przy większej skali – tysiącach adresów rozłożonych na wiele kategorii i szablonów – wygodniej sprawdza się skorzystanie z narzędzi automatyzujących ten proces, takich jak IndexChecker, IndexCheckr, IndexChecker.io czy DupliChecker, dostępnych na rynku jako uzupełnienie standardowych raportów Search Console.
Praktyczny wniosek
Plik robots.txt bywa traktowany jako element konfigurowany raz i zapominany, tymczasem w praktyce zasługuje na taką samą regularną uwagę jak mapa sitemap czy tagi kanoniczne. Pojedyncza, pozornie niewinna reguła potrafi po cichu ograniczyć widoczność całych sekcji serwisu, a jej skutki ujawniają się dopiero wtedy, gdy ktoś zada sobie trud, żeby połączyć spadek ruchu z konkretnym wierszem w pliku konfiguracyjnym.