Jak działa robots.txt

Plik leży zawsze w katalogu głównym domeny i tylko tam. Nie działa umieszczony w podkatalogu, a każda subdomena potrzebuje własnego pliku — to pierwsza rzecz, o którą pytam, gdy serwis rozdziela sklep i bloga na osobne adresy.

Zawartość to zbiór grup reguł. Każda grupa zaczyna się od wskazania robota, do którego się odnosi, a potem zawiera reguły dopuszczające lub blokujące ścieżki. Robot czyta plik przed pobraniem strony i stosuje wyłącznie tę grupę, która najlepiej do niego pasuje — jeśli istnieje grupa dedykowana dla robota Google, to grupa ogólna zostanie przez niego zignorowana w całości. Ta zasada jest nieoczywista i odpowiada za dużą część niezamierzonych skutków.

Reguły dopasowują początek ścieżki, obsługują gwiazdkę jako dowolny ciąg znaków i znak dolara jako oznaczenie końca adresu. Przy sprzecznych regułach wygrywa ta bardziej szczegółowa, czyli dłuższa — nie ta, która jest wyżej w pliku.

Rzecz do zapamiętania: to jest instrukcja dobrowolna. Roboty wyszukiwarek jej przestrzegają, skanery szukające podatności nie mają takiego obowiązku i zwykle go nie mają w praktyce.

Czego robots.txt nie potrafi

Trzy nieporozumienia wracają regularnie.

Pierwsze: blokada nie usuwa adresu z wyników wyszukiwania. Jeśli do zablokowanego adresu prowadzą linki, Google może go pokazać w wynikach bez opisu, wyłącznie na podstawie tekstów odnośników. Do wykluczenia z indeksu służy znacznik noindex, a ten musi być odczytany — czyli adres nie może być zablokowany. Te dwa mechanizmy trzeba stosować rozdzielnie i to najczęstszy błąd koncepcyjny, jaki spotykam w audytach.

Drugie: robots.txt nie chroni danych. Plik jest publiczny, każdy może go otworzyć. Wypisanie w nim ścieżki do katalogu administracyjnego to nie zabezpieczenie, a wskazówka dla kogoś, kto szuka słabych punktów.

Trzecie: blokada nie usuwa problemu duplikacji treści z punktu widzenia sygnałów rankingowych. Jeśli chcesz scalić sygnały z dwóch adresów, potrzebujesz adresu kanonicznego. Zablokowany duplikat po prostu nie zostanie odwiedzony, ale nie odda niczego wersji właściwej.

Co warto tam umieścić

Dla większości stron sensowny plik jest bardzo krótki i to jest w porządku. Nie ma nagrody za długość.

• Adres mapy witryny — jedna linia, która nie zależy od żadnej grupy reguł i pomaga robotom znaleźć punkt wejścia.

• Blokada wyszukiwania wewnętrznego — adresy z zapytaniami użytkowników nie mają wartości i potrafią mnożyć się bez ograniczeń.

• Blokada koszyka i procesu zamówienia — nie ma powodu, żeby robot pobierał te ścieżki.

• Blokada parametrów sortowania i tych filtrów, które nie mają wartości wyszukiwawczej — w dużym sklepie to najbardziej opłacalna reguła w całym pliku.

• Blokada plików generowanych automatycznie, na przykład wersji roboczych i eksportów.

Czego natomiast nie blokuję nigdy: plików ze stylami i skryptami. Google renderuje strony i potrzebuje ich, żeby ocenić układ, wersję mobilną i dostępność treści. Blokada katalogu z zasobami szablonu to relikt sprzed lat, który dziś realnie szkodzi.

Błędy, które kosztują najwięcej

Zestawiłem je w kolejności od najbardziej kosztownych.

Blokada całego serwisu zostawiona po wdrożeniu. Jedna linia zabraniająca dostępu do wszystkiego. Efekt widać w Search Console w ciągu kilku dni, a odbudowa pozycji zajmuje znacznie dłużej niż samo wyindeksowanie. Sprawdzenie tego pliku to obowiązkowy punkt każdego uruchomienia strony.

Blokada zasobów niezbędnych do renderowania. Objawia się dziwnymi wynikami w narzędziach oceny strony i różnicą między tym, co widzi użytkownik, a tym, co pobiera robot.

Sprzeczność z mapą witryny. Mapa zawiera adresy, które plik blokuje. Search Console to raportuje, ale trzeba tam zajrzeć.

Reguły dla nieistniejących wzorców. Nieszkodliwe, ale świadczą o tym, że plik nie był weryfikowany od dawna — a to zwykle znaczy, że nie odpowiada już strukturze serwisu.

Grupa dedykowana dla robota Google zawierająca mniej reguł niż grupa ogólna. Ktoś chciał doprecyzować, a w efekcie zniósł wszystkie blokady, bo grupa ogólna przestała obowiązywać.

Jak to testować

Nie wprowadzam zmian w tym pliku bez sprawdzenia i nie sprawdzam „na oko”, bo składnia bywa myląca przy gwiazdkach.

W Search Console jest narzędzie, które pokazuje aktualnie pobraną wersję pliku i pozwala sprawdzić konkretny adres pod kątem reguł. To podstawowe narzędzie weryfikacji i wystarcza w większości przypadków. Warto wpisywać tam adresy z obu grup: te, które mają być dostępne, i te, które mają być zablokowane. Test tylko w jedną stronę wyłapuje połowę pomyłek.

Przy większym serwisie po zmianie przechodzę crawlerem po strukturze i porównuję liczbę adresów dostępnych przed i po. Nagły spadek o kilkadziesiąt procent oznacza, że reguła jest szersza, niż zamierzałem.

Sprawdzam też, czy plik odpowiada kodem 200 i ma typ zawartości tekstowej. Plik zwracający błąd serwera bywa interpretowany tak, jakby całe pobieranie było zabronione, co jest jednym z bardziej podstępnych scenariuszy — sam plik istnieje, treść jest poprawna, a mimo to serwis przestaje być odwiedzany.

Higiena na dłużej

Ten plik ma tę nieprzyjemną cechę, że zmienia go wiele osób i mało kto to notuje. Wtyczki potrafią dopisywać reguły same, a przy migracjach jest kopiowany razem z resztą serwera.

Robię więc trzy rzeczy. Trzymam kopię aktualnej wersji poza serwerem, żeby móc porównać stan po każdym wdrożeniu. Dopisuję krótki komentarz nad każdą blokadą wyjaśniający, po co ona jest — po roku nikt tego nie pamięta, w tym ja. I dodaję sprawdzenie tego pliku do listy kontrolnej wdrożeniowej razem z certyfikatem i przekierowaniami.

To niewielki nakład pracy, a chroni przed jednym z niewielu błędów SEO, które potrafią zadziałać natychmiast i na całym serwisie jednocześnie.