Najważniejsze wnioski w pigułce
Składnia i standard
- Robots.txt powinien być zgodny ze standardem RFC 9309, którego przestrzega Google.
- Parser Google rozpoznaje cztery reguły:
user-agent,allow,disallowisitemap. - Linie, których parser nie rozumie, są po cichu pomijane, bez żadnego ostrzeżenia.
- Komentarze zaczynające się od
#są ignorowane, ale nadmiar „ozdobników” niepotrzebnie zwiększa rozmiar pliku.
Emoji i znaki narodowe
- Według Google token user-agent może zawierać tylko litery i myślniki, więc emoji i znaki spoza alfabetu angielskiego w nazwie bota nie zadziałają.
- Googlebot sam koduje polskie znaki i emoji w ścieżkach, ale starsze lub inne crawlery mogą sobie z nimi nie poradzić.
- Bezpieczna praktyka to zapis ścieżek w formie percent-encoding.
Boty AI i bezpieczeństwo
- Robots.txt steruje wyłącznie dostępem do stron, a nie tym, co firma robi z pobranymi już danymi.
- Aby zablokować konkretnego crawlera AI, trzeba wskazać jego oficjalny token user-agent.
- Robots.txt nie jest zabezpieczeniem. To prośba, którą respektują tylko „dobrze wychowane” boty.
Skąd ta lekcja o robots.txt
Gary Illyes i Cherry Prommawin z Google opublikowali drugi odcinek serii wideo „Non-Canonical Cabinet”, zatytułowany „What can you actually put in a robots.txt?”. Seria odpowiada na nietypowe pytania, które zespół zbiera podczas wydarzeń branżowych. Tym razem dotyczyły one tego, jak bardzo można „udziwnić” plik robots.txt: czy wolno w nim używać emoji, znaków narodowych i czy da się nim zakazać trenowania modeli AI. Odcinek ma lekką formę, ale wnioski są bardzo konkretne i warto je potraktować jako checklistę do audytu technicznego.
Punkt wyjścia jest prosty. Robots.txt to zwykły plik tekstowy w katalogu głównym domeny, który przed wejściem na stronę sprawdzają Googlebot i inne przestrzegające zasad boty. Działanie pliku i jego miejsce w strategii SEO opisaliśmy szerzej w artykule o tym, jak skonfigurować plik robots.txt pod SEO . Nowy materiał Google dotyczy jednak szczegółów, na których najczęściej wykładają się nawet doświadczone zespoły.
Cztery reguły i ciche pomijanie błędów
Google przypomina, że plik powinien być zgodny z RFC 9309, a parser czyta go linia po linii. Rozpoznaje tylko cztery reguły: user-agent, allow, disallow oraz sitemap. Wszystko, czego nie rozumie, odrzuca bez komunikatu i przechodzi dalej. Illyes podał wymowny przykład: jeśli ktoś wpisze po ludzku „don’t crawl secret page”, Google uzna to za nieprawidłową regułę, zignoruje ją i może tę stronę mimo wszystko zaindeksować.
Z tego wynika najważniejsza lekcja praktyczna. Reguła, która wygląda zrozumiale dla człowieka, wcale nie musi działać dla maszyny. Literówka, niestandardowe odstępy czy „kreatywny” zapis mogą sprawić, że blokada istnieje tylko na papierze. Dlatego każdą zmianę w robots.txt trzeba zweryfikować testem na rzeczywistych adresach URL, a nie samą lekturą pliku.
Komentarze poprzedzone znakiem # są dozwolone i crawlery je ignorują, więc technicznie można tam wkleić nawet grafikę ASCII. Prommawin wspomniała jednak o witrynie, której robots.txt w 97% składał się z ozdobników, a tylko w 3% z dyrektyw. Parser się nie zepsuł, ale każdy bot pobierał niepotrzebne dane. Zasada Google brzmi: „keep it boring”, czyli plik ma być nudny i przewidywalny.
Emoji, polskie znaki i percent-encoding
Druga część odcinka dotyczy znaków spoza podstawowego alfabetu łacińskiego. Według Google token user-agent może zawierać tylko litery i myślniki. Emoji to wielobajtowy znak UTF-8, którego nie da się zakodować tak, by spełniał ten wymóg, więc reguła z emoji w nazwie bota po prostu nie zadziała. To samo dotyczy liter z diakrytykami w nazwie crawlera.
Inaczej jest ze ścieżkami URL. Googlebot traktuje znaki narodowe tak jak każdy klient HTTP i automatycznie je koduje, więc niemieckie umlauty, chińskie znaki czy polskie „ą”, „ł” i „ź” nie stanowią dla niego problemu. Kłopot w tym, że inne lub starsze crawlery mogą się na nich pogubić, a reguła, której nie potrafią przetworzyć, bywa ignorowana w całości. W efekcie bot może wejść dokładnie tam, gdzie chcieliśmy go zatrzymać.
Rekomendacja Google jest jednoznaczna: w regułach zapisuj ścieżki w formie, jakiej oczekuje serwer, czyli w kodowaniu procentowym. Przykładowo zamiast /promocje/łódź/ lepiej wpisać /promocje/%C5%82%C3%B3d%C5%BA/. Dla polskich serwisów z adresami zawierającymi diakrytyki to realne ryzyko, które warto sprawdzić przy okazji audytu. Szczególnie dotyczy to witryn wielojęzycznych, gdzie, jak pisaliśmy w tekście o ukrytej złożoności international SEO
, takie niuanse techniczne łatwo przeoczyć.
Robots.txt a boty AI: dostęp to nie licencja
Najwięcej pytań dotyczyło generatywnej AI. Illyes wyjaśnił, że robots.txt jest protokołem preferencji dostępu: mówi botowi wyłącznie „możesz wejść na tę stronę” albo „nie wchodź na tamtą”. Nie reguluje tego, co system zrobi z danymi, które już pobrał. Dyrektywa disallow oznacza „nie wchodź do pokoju” i nic ponadto. Nie da się więc zapisać w pliku „możesz crawlować, ale nie trenuj na mojej treści”.
Własne, wymyślone dyrektywy w stylu „no-AI-training” zostaną przez parser wyrzucone do kosza. Jeśli chcesz zablokować konkretnego crawlera AI, musisz wskazać go z nazwy, używając oficjalnego tokena user-agent podanego przez jego operatora. Warto też pamiętać, że Google korzysta z kilku botów o różnych zadaniach, co szczegółowo opisaliśmy w artykule o tym, jak działa Googlebot i jakie są rodzaje botów Google . Pomyłka w nazwie oznacza, że reguła nie obejmie żadnego bota.
W praktyce należy rozdzielić dwie decyzje: kontrolę crawlowania i politykę wykorzystania treści do trenowania modeli. Zablokowanie dostępu nie cofa tego, co zostało pobrane wcześniej. Jeśli zastanawiasz się, skąd modele czerpią wiedzę i gdzie robots.txt w ogóle ma znaczenie, pomocne będzie nasze omówienie training data, RAG i MCP .
Co z tego wynika dla właściciela strony
Barry Schwartz, komentując odcinek, zwrócił uwagę na jeszcze jedną rzecz: robots.txt nie jest mechanizmem bezpieczeństwa. Plik prosi zgodne ze standardem boty, by omijały wskazane ścieżki, ale nie powstrzyma nieautoryzowanych klientów i nie gwarantuje, że każdy bot się podporządkuje. Danych wrażliwych nie chroni się regułą disallow, tylko uwierzytelnianiem i kontrolą dostępu po stronie serwera. Jeśli z kolei celem jest wykluczenie strony z indeksu, właściwym narzędziem jest meta tag robots
lub nagłówek X-Robots-Tag
, a nie samo blokowanie crawlowania.
W codziennej pracy przy audytach technicznych sprowadzamy to do kilku kroków. Sprawdzamy, czy plik zawiera wyłącznie obsługiwane dyrektywy i czy nie ma w nim linii, które parser po cichu odrzuci. Weryfikujemy zapis ścieżek ze znakami narodowymi i testujemy reguły na prawdziwych adresach. Na koniec porządkujemy listę crawlerów AI według ich oficjalnych tokenów, tak by decyzja o blokadzie była świadoma i faktycznie działała.
Podsumowanie
Google przypomina, że robots.txt ma być prosty, zgodny z RFC 9309 i ograniczony do czterech obsługiwanych reguł, a wszystko poza nimi zostanie zignorowane. Polskie znaki w ścieżkach warto zapisywać w percent-encodingu, a boty AI blokować wyłącznie po ich oficjalnych nazwach. Przede wszystkim jednak trzeba pamiętać, że robots.txt steruje dostępem, a nie wykorzystaniem treści ani bezpieczeństwem danych.
Źródło: Search Engine Roundtable (otwiera się w nowej karcie)
