Robots.txt – do czego służy i jakich błędów unikać przy jego tworzeniu?

Spis treści:

• Co to jest robots.txt?
• Jakie roboty czytają plik robots.txt?
• Po co stosować plik robots.txt?
• Podstawowe dyrektywy w robots.txt: user-agent, allow i disallow
• Błędy w robots.txt i ich konsekwencje
• Czy tworząc plik robots.txt trzeba uważać na jego wielkość?
• Czy blokada stron w robots.txt jest wystarczająca?
• Co oprócz pliku robots.txt?
• Robots.txt - podsumowanie

Co to jest robots.txt?

Plik robots.txt służy do przekazywania robotom wyszukiwarek oraz programów crawlujących stronę informacji o tym, co powinny robić na stronie, a czego nie. Dyrektywy wysyłane są za pomocą standardu Robots Exclusion Protocol, choć należy przy tym zaznaczyć, że część wyszukiwarek deklaruje uwzględnianie niestandardowych zapisów. Do podstawowych zapisów należą komunikaty, których fragmentów strony roboty nie powinny czytać, choć możliwych zastosowań pliku robots.txt jest więcej.

Historia protokołu Robots Exclusion 

Protokół Robots Exclusion Protocol powstał dosłownie ćwierć wieku temu, w lutym 1994 – i od tego czasu niewiele się w nim zmieniło, jeśli nie liczyć zaistnienia wspomnianych już niestandardowych zapisów. Ponieważ w czasach jego „młodości” na rynku funkcjonowało wiele wyszukiwarek (dość wspomnieć AltaVistę, HotBota, Lycosa, czy InfoSeeka – a lista była przecież znacznie dłuższa), szybko stał się nieoficjalnym standardem. Tu jednak należy wspomnieć, że standardem o tyle nietypowym, że zapis ten tak naprawdę był i jest sugestią, której boty często nie respektują lub respektują ją tylko częściowo.

Co ciekawe, w lipcu 2019 Google – którego boty również nie zawsze w pełni stosują się do dyrektyw zapisanych w plikach robots.txt – zaproponowało, żeby uznać Robots Exclusion Protocol za standard oficjalny. Czy obecnie może to cokolwiek zmienić w sposobie stosowania robots.txt? Teoretycznie nie. Jednak być może spowoduje to dyskusje na temat wprowadzenia nowych zapisów, które mogłyby pomóc w sprawniejszym „sterowaniu” robotami wyszukiwarek.

Jakie roboty czytają plik robots.txt?

Plik robots.txt z założenia przeznaczony jest dla wszystkich automatów wchodzących na stronę. Dotyczy to nie tylko najbardziej oczywistych z punktu widzenia SEO robotów wyszukiwarek. Botami, do których adresowane są dyrektywy tego pliku, są także automaty archiwizujące Internet (takie jak Web Archive), programy pobierające witrynę na dysk lokalny (np. HTTrack Website Copier), narzędzia do analizy strony (w tym narzędzia SEO, takie jak chociażby Xenu, ale też boty Mejestic SEO i Ahrefs) itp.

Oczywiście łatwo się przy tym domyślić, iż w wielu przypadkach twórcy nie powinni przejmować się dyrektywami. Z drugiej strony część robotów pozwala swoim użytkownikom samodzielnie wybrać, czy mają stosować się do wykrytych dyrektyw.

Po co stosować plik robots.txt?

To podstawowe pytanie, jakie warto sobie zadać – zwłaszcza w kontekście parokrotnie już wspomnianej informacji, że z respektowaniem zapisów w pliku robots.txt bywa różnie. Odpowiedź jest prosta: zawsze lepsza jest niewielka kontrola nad robotami niż jej brak. A co można dzięki temu zyskać? Przede wszystkim niedopuszczenie automatów do przeglądania tych sekcji serwisu, do których zaglądać z różnych przyczyn nie powinny i wskazywanie im miejsc, których odwiedziny są jak najbardziej wskazane.

Blokada konkretnych obszarów strony może być istotna z różnych przyczyn:

• Kwestie bezpieczeństwa – być może po prostu nie chcesz, aby roboty (albo też przypadkowi użytkownicy korzystający później z zasobów zaindeksowanych przez roboty) mogły zbyt łatwo dostać się do sekcji, do których nie powinny mieć dostępu.
• Zabezpieczenie przed duplicate contentem – jeżeli na stronie istnieje spora ilość wewnętrznie powielonej treści, a jednocześnie schemat adresów URL pozwala na jej jasne zidentyfikowanie, za pomocą pliku robots.txt można dać wyszukiwarkom sygnał, że tej części witryny nie powinny śledzić.
• Oszczędność transferu – za pomocą zapisów robots.txt można próbować usunąć ze ścieżek, którymi wędrują roboty, całe podkatalogi lub konkretne rodzaje plików – chociażby folder zawierający grafiki lub ich wysokoformatowe wersje. W przypadku niektórych serwisów oszczędność transferu może być znacząca.
• Zabezpieczenia contentu przed „wypłynięciem” na zewnątrz – zauważ, że zasugerowane powyżej zabezpieczenie folderu z grafikami w dużym formacie może posłużyć też i temu, aby w wyszukiwarce grafik prezentować jedynie mniejsze wersje. Może to mieć spore znaczenie w przypadku np. banków zdjęć (choć nie tylko).
• Optymalizacja crawl budgetu – choć wymieniam go na końcu listy, zdecydowanie nie jest to rzecz błaha. Im większy serwis, tym większy nacisk należy kłaść na optymalizację ścieżek, po których wędrują boty indeksujące wyszukiwarek. Blokując w robots.txt nieistotne dla SEO obszary serwisu, po prostu zwiększasz prawdopodobieństwo, że roboty będą wędrowały tam, gdzie powinny.

Podstawowe dyrektywy w robots.txt: user-agent, allow i disallow

Przejdźmy do sedna, czyli do tego, jak powinien wyglądać plik robots.txt. Z definicji powinien to być plik tekstowy umieszczony w głównym katalogu serwisu, którego dotyczy. Jego główne, najczęściej spotykane dyrektywy to user-agent, allow i disallow. Za pomocą pierwszej możemy określić, do jakich botów adresujemy daną regułę. Z kolei dwie pozostałe wskazują na to, do jakich obszarów robot powinien mieć dostęp i gdzie nie jest mile widziany.

Warto przy tym pamiętać, że plik robots.txt obsługuje zmienną w postaci gwiazdki (*), a ścieżki plików, których dotyczy dana komenda, zawsze powinny być wypełnione czymkolwiek, chociażby rozpoczynającym je slashem (/). Ewentualny brak wypełnienia spowoduje zignorowanie pola.

Przykładem dobrego wypełnienia może być zapis:

User-agent: *
Allow: /

– czyli zadeklarowanie, że wszystkie roboty mogą indeksować całość witryny. Analogicznie zapis:

User-agent: *
Disallow: /img/

– oznacza zakazanie dostępu do katalogu /img/.

Z kolei zapis:

User-agent: *
Disallow:

– nie oznacza nic, ze względu na brak zadeklarowanej ścieżki po dyrektywie disallow.

Oczywiście w jednym pliku robots.txt może się znaleźć więcej pól allow i disallow. Przykład? Proszę bardzo:

User-agent: *
Allow: /
Disallow: /img/
Disallow: /panel/

– czyli zgoda na odwiedzanie przez roboty całego serwisu z wyjątkiem folderów /img/ oraz /panel/.

Należy przy tym wszystkim dodać, że same dyrektywy mogą dotyczyć nie tylko całych katalogów, lecz również pojedynczych plików.

Kolejność dyrektyw allow i disallow w robots.txt

Jeżeli może zaistnieć problem z interpretacją dyrektyw allow i disallow, na przykład wtedy, gdy chcesz zakazać robotom wstępu do jakiegoś katalogu, ale zrobić wyjątek dla konkretnego podkatalogu, pamiętaj, że dyrektywy dopuszczające powinny znaleźć się powyżej zakazujących – na przykład w ten sposób:

User-agent: *
Allow: /
Allow: /img/miniatury/
Disallow: /img/

User-agent: Ahrefsbot
Disallow: /

User-agent: MJ12bot
Disallow: /

W powyższym przykładzie od razu pokazałem także przypadek, gdy dla niektórych botów zastosowano odrębne reguły – wówczas w ten sposób „prosimy” roboty serwisów Ahrefs i Majestic SEO, żeby nie wędrowały po stronie.

Dyrektywa sitemap

Oprócz „zaproszeń” i sugerowania omijania katalogów, plik robots.txt może posłużyć także do wskazywania robotom umiejscowienia mapy strony. Służy do tego dyrektywa sitemap, po której umieszcza się pełną ścieżkę mapy. Przykładowa forma zapisu wygląda następująco:

Sitemap: http://www.domena.com/mapastrony.xml

Oczywiście map można wskazać więcej, co może być przydatne w przypadku bardzo rozbudowanych witryn.

Dyrektywa crawl-delay

W przypadku bardzo dużych witryn często pojawia się dylemat – z jednej strony ich właścicielom może zależeć na indeksacji całości, z drugiej nadmierna aktywność botów wyszukiwarek może zużywać całkiem sporo transferu i obciążać serwer ciągle nowymi zapytaniami. Pomysłem na rozwiązanie tego problemu było wprowadzenie do użycia niestandardowej dyrektywy crawl-delay.

Zapis ten służy do informowania robotów, że nie powinny pobierać nowych plików częściej niż co x sekund, co przekłada się na rozciągniecie pracy robota w czasie. Przykładowy zapis to:

User-agent: *
Crawl-delay: 2

– czyli pobieranie kolejnych dokumentów co dwie sekundy.

Warto mieć na względzie, że większość wyszukiwarek dość swobodnie traktuje ten zapis, często po prostu go ignorując. Google przez jakiś czas komunikowało nieistotność tej dyrektywy, by w końcu, w lipcu 2019 roku, oficjalnie ogłosić, że jej nie wspiera. Bing deklaruje, że zapis jest czytany przez BingBota, przy czym jego wartość powinna mieścić się pomiędzy 1 a 30. Dyrektywa teoretycznie jest wspierana także przez Yandex, choć z jej respektowaniem w praktyce bywa różnie.

Co ciekawe, czeska wyszukiwarka Seznam sugeruje używanie innej dyrektywy, a mianowicie request-rate i przydzielanie mu wartości na zasadzie podania liczby dokumentów, slasha oraz czasu w postaci liczby i jednostki (s jako sekundy, m jako minuty, h jako godziny i d jako dni, za każdy razem bez spacji po liczbie). Przykładem tego rodzaju zapisu może być:

User-agent: SeznamBot
Request-rate: 500/1h

bądź:

User-agent: SeznamBot
Request-rate: 100/20m

Sam Seznam deklaruje, że dyrektywa nie powinna nakazywać wolniejszej indeksacji, niż 1 dokument na każde 10 sekund.

Dyrektywa clean-param

Bardzo ciekawą dyrektywą, niestety będącą ogólnym standardem, jest clean-param. Dyrektywa ta jest czytana przez boty wyszukiwarki Yandex i pozwalają ignorować konkretne parametry przypisane do adresów we wskazanych ścieżkach.

Jak to wygląda w praktyce? Załóżmy, że w obrębie Twojej strony istnieją adresy:

domena.com/katalog/strona?tlo=1&id=3
domena.com/katalog/strona?tlo=2&id=3
domena.com/katalog/strona?tlo=3&id=3

Co, jeśli zmienna „tlo” modyfikuje jedynie wygląd strony, która cały czas ma tę samą zawartość? W takich przypadkach Yandex proponuje zastosować właśnie parametr clean-param. Odpowiedni zapis może wyglądać tak:

User-agent: Yandex
Clean-param: tlo /katalog/

– co oznacza, że wszystkie trzy adresy podane we wcześniejszym przykładzie będą odczytywane jako:

domena.com/katalog/strona?id=3

Jak widać, ta dyrektywa jest o tyle wygodniejsza, że można ją ograniczyć do konkretnych katalogów.

Dyrektywa host

Wśród niestandardowych dyrektyw robots.txt wymieniana jest także komenda host. Ignorowana przez większość wyszukiwarek, przez jakiś czas była wspominana na stronach pomocy Yandeksa, choć obecnie jej opis już stamtąd zniknął.

Komenda host służy (a może raczej służyła?) do wskazywania preferowanej domeny w przypadku posiadania kilku mirrorów znajdujących się pod różnymi adresami. Co istotne, w jednym pliku robots.txt powinna znajdować się maksymalnie jedna dyrektywa host (w przypadku umieszczenia większej jej liczby, kolejne są ignorowane), a zapis domeny znajdującej się po komendzie host nie może zawierać błędów, ani numerów portów.

Przykład:

Host: domena.com

Niestety nie wiem, czy komenda dalej funkcjonuje, mogę jednak przypuszczać, znając pomysłowość pozycjonerów, że kusiła jedynie do rozmaitych eksperymentów z umieszczaniem jej na niekoniecznie tych domenach, na których znaleźć się powinna. Na pocieszenie dla „zwykłych webmasterów” należy wspomnieć, iż sam Yandex, gdy jeszcze wspominał na swoich stronach o tej dyrektywie, przedstawiał ją jako „sugestię” dla robotów – a więc nie traktował jej obligatoryjnie.

Błędy w robots.txt i ich konsekwencje

Choć zawartość pliku robots.txt może posłużyć do „dogadania” się z robotami wyszukiwarek, równie dobrze może sprawić, że napytasz biedy swojej stronie. Jak? Ano, wykluczając z wyszukiwania tę zawartość, która w indeksie powinna się pojawić. Efektem może być znaczna utrata widoczności w wynikach wyszukiwania. Zwłaszcza w przypadku rozbudowanych plików robots.txt, posiadających wiele wpisów do różnych podkatalogów, łatwo popełnić gdzieś po drodze błąd i wykluczyć zbyt wiele sekcji strony.

Drugi poważny błąd to objęcie dyrektywą disallow wszystkich obrazków, stylów CSS oraz plików Java Script. Pozornie może się wydawać, że to dobre posunięcie, rzeczywistość jest jednak nieco inna z dwóch powodów. Po pierwsze, w wielu przypadkach warto znaleźć się w wynikach wyszukiwania grafik (choć oczywiście można tu zakazywać dostępu do np. wersji w większym formacie, o czym wspominałem już wcześniej).

Drugi powód jest jednak bardziej istotny, a jest nim renderowanie strony przez Google Bota. Jeżeli nie dopuścisz bota do plików istotnych dla uzyskania końcowego wyglądu strony, wyrenderuje ją bez nich, co w niektórych przypadkach może sprawić, że z jego punktu widzenia będzie ona niepełna – a to może wpłynąć na ranking.

Czy tworząc plik robots.txt trzeba uważać na jego wielkość?

Swego czasu jeden z googlersów, John Mueller, stwierdził na swoim profilu Google+, że maksymalna wielkość pliku robots.txt to 500 KB. Tym samym można uznać, że problem jest abstrakcyjny, ponieważ aż taka rozbudowa listy dyrektyw byłaby absurdalna. Warto jednak dążyć do tego, aby nawet krótki plik robots.txt nie rozrastał się nadmiernie i po prostu zachował czytelność dla… człowieka, któremu przyjdzie jego przeglądnięcie i ewentualne uzupełnienie lub modyfikacja.

Ponadto trzeba też pamiętać, że mowa tu tylko o wartości akceptowanej przez Google Bota – w przypadku innych wyszukiwarek limit wielkości pliku robots.txt może być różny.

Czy blokada stron w robots.txt jest wystarczająca?

Niestety nie. Po pierwsze, roboty głównych wyszukiwarek nie zawsze respektują zakazy (nie wspominając już o tym, jak do nich podchodzi część narzędzi). Po drugie, nawet po odczytaniu zakazu Google może wejść na stronę i dodać ją do indeksu, uwzględniając jedynie jej tytuł (TITLE) i adres URL, a całość wzbogacając czasami informacją „W przypadku tej strony informacje nie są dostępne.”

Nadal więc jest możliwe trafienie na tę stronę z poziomu wyszukiwarki, choć to raczej mało prawdopodobne. Co więcej, boty nadal przechodzą przez takie strony po kolejnych odnośnikach, mimo że nie przekazują już link juice, a w ich rankingu nie są uwzględniane dane wynikające z ich treści.

Co oprócz pliku robots.txt?

Jeżeli zależy Ci na wyłączeniu konkretnych fragmentów strony z indeksów wyszukiwarek, zawsze możesz dodatkowo wspomóc się meta znacznikiem robots umieszczonym w sekcji <HEAD> poszczególnych podstron:

<meta name="robots" content="noindex, nofollow" />

– co nadal nie jest metodą zapewniającą stuprocentowy sukces (a w dodatku jest mniej wygodna), ale stanowi dodatkowy sygnał dla botów.

Co jednak, jeżeli chcesz całkowicie zablokować dostęp botom i przypadkowym osobom? W takiej sytuacji zamiast metod biernych, obliczonych na to, że nikt się do danego miejsca nie doklika, znacznie lepiej po prostu objąć daną sekcję strony ochroną za pomocą hasła (chociażby nałożonego za pomocą htaccess).

Teoretycznie można sięgać też po półśrodki, na przykład w postaci zablokowania dostępu dla wywołań z określonych adresów i klas IP (tych używanych przez boty wyszukiwarek), ale w praktyce wystarczyłoby przegapić część adresów i problem dalej by istniał – a to prowadzi nas ponownie do wniosku, że pełnym zabezpieczeniem będzie właśnie wymuszenie autoryzacji.

Robots.txt - podsumowanie

Na koniec pozostaje jedynie wrócić do kwestii konsekwencji ewentualnych błędów w uzupełnianiu pliku robots.txt. Cokolwiek się tam wpisuje, warto pamiętać, jakie mogą być tego efekty i… co to ma na celu. Gdy chcemy coś wyindeksować, zwróćmy uwagę, czy nie pociągnie to za sobą efektów ubocznych (patrz przykład z utrudnieniem renderowania strony przez Google Bota). Z kolei, jeśli zależy nam na kwestiach bezpieczeństwa, pamiętajmy, że wykluczenie z indeksacji przez Google nadal nie blokuje dostępu automatom scrapującym.

Jeśli jeszcze czujesz niedosyt wiedzy... możesz zapoznać się z pozostałymi artykułami na temat pozycjonowania stron w naszej Bazie wiedzy.