Robots.txt - co to jest i jak go skonfigurować?
Robots.txt to plik tekstowy sterujący dostępem crawlerów. Poznaj dyrektywy Disallow, Allow i Sitemap, typowe błędy konfiguracji i blokowanie botów AI.
Robots.txt to plik tekstowy wskazujący botom, które zasoby domeny mogą odwiedzać, a które pominąć. Decyduje o zarządzaniu crawlowaniem i wpływa na widoczność w Google.
Co to jest plik robots.txt?
Plik działa jako zestaw reguł dla crawlerów, czyli botów automatycznie odwiedzających strony w sieci. Google opisuje jego rolę wprost: służy przede wszystkim do zarządzania ruchem crawlerów na stronie, żeby nie przeciążać serwera zbędnymi żądaniami i skierować boty tam, gdzie faktycznie mają coś do zrobienia.
Standard ma swoją historię. Zaproponował go Martijn Koster w lutym 1994 roku, gdy pracował dla firmy Nexor, w odpowiedzi na problemy z agresywnymi robotami przeciążającymi wczesne serwery WWW. Już w czerwcu tego samego roku stał się faktycznym standardem, a z czasem respektowali go najwięksi gracze ówczesnego wyszukiwania: WebCrawler, Lycos i AltaVista. Formalnie protokół doczekał się standaryzacji dopiero dekady później. Google zgłosił go do IETF w lipcu 2019 roku, a we wrześniu 2022 roku powstał RFC 9309, czyli oficjalna specyfikacja Robots Exclusion Protocol.
Jak działa robots.txt i gdzie go umieścić?
Plik musi leżeć dokładnie w katalogu głównym hosta, do którego ma zastosowanie, na przykład www.przyklad.pl/robots.txt. Google jest tu kategoryczny: pliku nie można umieścić w podkatalogu. Musi też nosić dokładnie nazwę robots.txt i być zapisany jako plik tekstowy w kodowaniu UTF-8.
Reguły działają per host, czyli protokół plus domena plus port. Subdomena sklep.przyklad.pl ma więc własny, niezależny plik robots.txt, inny niż www.przyklad.pl, tak samo wersja pod https:// inna niż pod http://.
Sam plik nie musi istnieć, żeby strona się indeksowała. Google jasno definiuje zachowanie w takich sytuacjach: błąd 404 i pozostałe kody 4xx, poza kodem 429, są traktowane tak, jakby poprawny plik robots.txt w ogóle nie istniał, czyli crawler zakłada brak jakichkolwiek ograniczeń. Inaczej wygląda to przy błędach serwera 5xx: przez pierwsze 12 godzin Google wstrzymuje crawlowanie całej witryny, próbując dalej pobrać plik, przez kolejne 30 dni korzysta z ostatniej zapamiętanej wersji, a po tym czasie, jeśli reszta serwisu działa normalnie, zaczyna traktować brak pliku jak brak ograniczeń.
Składnia i dyrektywy: User-agent, Disallow, Allow, Sitemap
Struktura pliku opiera się na grupach reguł przypisanych do konkretnego robota.
- User-agent wskazuje, którego bota dotyczy grupa reguł poniżej. Gwiazdka
*obejmuje wszystkie boty, choć crawlery AdsBot trzeba wskazać po nazwie osobno. - Disallow blokuje dostęp do wskazanej ścieżki względem katalogu głównego.
- Allow odblokowuje konkretną podścieżkę wewnątrz katalogu zablokowanego wcześniej regułą Disallow.
- Sitemap wskazuje pełny, kwalifikowany adres pliku XML z mapą witryny, na przykład
Sitemap: https://przyklad.pl/sitemap.xml. Nie musi być zakodowany jako URL.
Reguły są wrażliwe na wielkość liter: Disallow: /plik.html dotyczy https://przyklad.pl/plik.html, ale nie PLIK.html. We wszystkich dyrektywach oprócz Sitemap działają dwa symbole wieloznaczne: gwiazdka zastępuje dowolny ciąg znaków, a znak dolara oznacza koniec adresu. Gwiazdka na samym końcu ścieżki jest ignorowana, więc /produkt* to dokładnie to samo co /produkt. Komentarze zaczynają się od znaku #, wszystko po nim w danej linii crawler pomija. Google przetwarza plik do rozmiaru 500 kibibajtów, a treść za tym limitem po prostu ignoruje.
Częste pytanie: co z dyrektywą Crawl-delay, mającą spowalniać tempo odwiedzin bota? Google jej nie obsługuje, dokumentacja wymienia ją wprost jako pole nieuwzględniane w parserze. Inne wyszukiwarki interpretują tę dyrektywę na własnych zasadach, ale żadna z nich nie zmienia sposobu, w jaki plik czyta Google.
Jak Google interpretuje plik robots.txt
Kiedy w pliku istnieje kilka grup reguł pasujących do tego samego user agenta, Google łączy je wewnętrznie w jedną grupę i stosuje razem. Przy sprzecznych regułach wygrywa ta bardziej szczegółowa, czyli dłuższa ścieżką w znakach. Gdy reguła Allow i Disallow są równie szczegółowe, Google stosuje regułę mniej restrykcyjną. RFC 9309 idzie tym samym torem i zapisuje wprost, że przy remisie reguła allow powinna zostać użyta.
Zawartość pliku Google zwykle trzyma w pamięci podręcznej do 24 godzin, dłużej przy błędach pobierania, a czas cache dopasowuje też do nagłówków Cache-Control z odpowiedzi serwera. Sama specyfikacja RFC 9309 definiuje formalnie tylko trzy dyrektywy: User-agent, Allow i Disallow. Sitemap, mimo powszechnego wsparcia w praktyce, w rdzeniu standardu nie występuje. RFC dopuszcza jedynie, że crawler może interpretować inne rekordy, niebędące częścią protokołu robots.txt, na przykład właśnie Sitemaps.
Czym robots.txt NIE jest
Najczęstsze nieporozumienie: robots.txt to nie jest sposób na ukrycie strony przed Google. Dokumentacja stawia sprawę jasno, nie jest to mechanizm utrzymywania strony poza Google. Strona zablokowana regułą Disallow może się mimo to pojawić w wynikach, jeśli linkują do niej inne serwisy, tyle że bez opisu, bo Google nigdy nie wszedł na nią, żeby ten opis wygenerować.
Jeżeli celem jest realne usunięcie strony z indeksu, właściwe narzędzia to znacznik noindex, zabezpieczenie strony hasłem albo usunięcie treści. Kluczowy warunek: znacznik noindex działa tylko wtedy, gdy strona nie jest zablokowana w robots.txt. Google pisze to wprost: jeśli crawler nie ma dostępu do strony, nigdy nie zobaczy reguły noindex umieszczonej w jej kodzie, więc adres może dalej pojawiać się w wynikach wyszukiwania. To jeden z najczęściej powtarzanych błędów przy porządkowaniu witryny: ktoś dodaje jednocześnie Disallow i noindex, w przekonaniu, że wzmacniają się nawzajem, a w rzeczywistości Disallow blokuje działanie noindex.
Najczęstsze błędy w robots.txt
Poniższe błędy najczęściej wychodzą przy audytach SEO i każdy z nich realnie szkodzi widoczności witryny.
Zablokowane CSS i JS. Google renderuje strony podobnie jak przeglądarka, uruchamiając JavaScript i stosując style. Dokumentacja Google Search Central podaje wprost: Google Search nie wyrenderuje JavaScriptu z zablokowanych plików ani na zablokowanych stronach. Jeśli katalog ze stylami czy skryptami trafi pod Disallow, Google widzi stronę bez layoutu i bez treści dobudowywanej przez JS, co potrafi zaniżyć ocenę jakości i użyteczności strony.
Disallow: / na produkcji. Klasyczny błąd po przeniesieniu ustawień ze środowiska deweloperskiego albo stagingowego, gdzie cały serwis był celowo zablokowany. Jedna niezauważona linia potrafi odciąć całą witrynę od crawlowania na tygodnie, zanim ktoś to zauważy.
Blokowanie stron, do których prowadzą linki. Zablokowanie w robots.txt strony, na którą wskazują linki z innych serwisów, nie usuwa jej z wyników, tylko zamienia normalny wynik z opisem w goły adres URL bez opisu, co wygląda gorzej i obniża CTR, a i tak nie rozwiązuje problemu widoczności strony.
Traktowanie robots.txt jako zabezpieczenia. Wypisanie wrażliwych ścieżek w Disallow, na przykład panelu logowania czy katalogu administracyjnego, działa odwrotnie do zamierzonego efektu. Plik jest publicznie dostępny, więc staje się gotową listą celów dla botów szukających podatności. Poleganie na ukryciu ścieżki zamiast na realnym zabezpieczeniu to dokładnie sytuacja, przed którą ostrzega zasada bezpieczeństwa przez zaciemnienie, odradzana wprost przez amerykański instytut standaryzacji NIST.
Boty AI w robots.txt: GPTBot, Google-Extended, ClaudeBot
Boty AI, takie jak GPTBot, Google-Extended i ClaudeBot, to oddzielne crawlery od klasycznych robotów wyszukiwarek, które można blokować w robots.txt niezależnie.
| Bot | Firma | Token user-agent | Do czego służy |
|---|---|---|---|
| GPTBot | OpenAI | GPTBot |
Zbiera treści do trenowania modeli generatywnych OpenAI |
| OAI-SearchBot | OpenAI | OAI-SearchBot |
Zasila wyniki wyszukiwania w ChatGPT; zablokowanie wyklucza stronę z odpowiedzi z wyszukiwaniem |
| Google-Extended | Google-Extended |
Kontroluje użycie treści do trenowania przyszłych modeli Gemini i groundingu; nie wpływa na obecność w Google Search | |
| ClaudeBot | Anthropic | ClaudeBot |
Zbiera treści webowe do trenowania modeli Claude |
GPTBot ma jedno konkretne zadanie: jak podaje OpenAI, służy do tego, żeby ich modele generatywnej AI były bardziej użyteczne i bezpieczne, crawlując treści, które mogą posłużyć do ich trenowania. Zablokowanie go sygnalizuje, że danych ze strony nie wolno użyć do tego treningu. Google-Extended działa inaczej niż większość crawlerów: nie ma własnego, osobnego ciągu user agent w żądaniach HTTP, to wyłącznie token sterujący w robots.txt, kontrolujący dostęp treści do trenowania przyszłych generacji modeli Gemini zasilających aplikacje Gemini oraz Vertex AI API dla Gemini. Google zaznacza też wyraźnie, że zablokowanie Google-Extended nie wpływa na obecność witryny w Google Search ani nie jest sygnałem rankingowym. ClaudeBot od Anthropic działa najbardziej wprost: pomaga zwiększać użyteczność i bezpieczeństwo generatywnych modeli AI firmy, zbierając treści webowe, które mogą przyczynić się do ich trenowania, a zablokowanie go to prosta reguła z User-agent: ClaudeBot i Disallow: /.
Jak przetestować plik robots.txt
Najszybszy test to wejście na twojadomena.pl/robots.txt w przeglądarce i sprawdzenie, czy plik w ogóle się ładuje i wygląda tak, jak zakładałeś.
Do dokładniejszej diagnostyki służy raport robots.txt w Google Search Console, dostępny wyłącznie dla właściwości domenowych albo właściwości typu prefiks adresu URL bez ścieżki. Raport pokazuje, które pliki robots.txt Google znalazł dla dwudziestu najważniejszych hostów w witrynie, kiedy ostatnio zostały crawlowane oraz wszelkie napotkane ostrzeżenia i błędy: błędy 404, niepowodzenia pobrania, błędy parsowania blokujące działanie reguł i ostrzeżenia parsowania, które reguł nie blokują, ale sygnalizują literówkę czy nietypowy zapis. Pojedynczy adres URL najlepiej sprawdzić narzędziem do sprawdzania adresów URL w Search Console, a do lokalnych testów i integracji z własnymi skryptami Google udostępnia otwartoźródłową bibliotekę parsującą robots.txt. Po poprawieniu krytycznego błędu można poprosić o ponowne zcrawlowanie pliku, choć Google i tak sięga po niego regularnie bez ręcznej interwencji.
Źródła
- robots.txt intro (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/robots/intro
- Create and submit a robots.txt file (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/robots/create-robots-txt
- How Google interprets the robots.txt specification (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt
- Block Search indexing with noindex (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/block-indexing
- JavaScript SEO basics (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- Google-Extended and other crawlers (Google Search Central) – https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers
- robots.txt report (Search Console Help) – https://support.google.com/webmasters/answer/6062598
- RFC 9309: Robots Exclusion Protocol (IETF) – https://www.rfc-editor.org/rfc/rfc9309
- GPTBot and OpenAI crawlers (OpenAI Developers) – https://developers.openai.com/api/docs/bots
- Does Anthropic crawl data from the web and how can site owners block the crawler? (Anthropic Help Center) – https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler
- Robots.txt (Wikipedia) – https://en.wikipedia.org/wiki/Robots.txt
Komentarz eksperta
W każdym audycie SEO robots.txt sprawdzam jako jeden z pierwszych plików, bo jeden błąd w Disallow może przez tygodnie blokować całą witrynę. Najczęstszy błąd, jaki widzę: mylenie Disallow z noindex. Ktoś blokuje stronę w robots.txt, licząc, że usunie ją z wyników, a tymczasem strona może wisieć w Google bez opisu.
Zwracam też uwagę, że wypisywanie wrażliwych ścieżek w Disallow działa odwrotnie: plik jest publicznie dostępny. Coraz częściej podczas audytów rozpatruję też reguły dla botów AI, GPTBot, Google-Extended, ClaudeBot, bo to świadoma decyzja biznesowa, nie techniczny detal.
Najczęściej zadawane pytania (FAQ)
Czy plik robots.txt jest obowiązkowy?
Nie. Strona działa bez niego normalnie, a brak pliku albo błąd 404 Google traktuje tak, jakby nie było żadnych ograniczeń w crawlowaniu. Mimo to warto go skonfigurować świadomie, bo dzięki niemu sterujesz ruchem botów i wskazujesz lokalizację sitemapy.
Czy Disallow w robots.txt ukrywa stronę z Google?
Nie w pełni. Strona zablokowana regułą Disallow może nadal pojawić się w wynikach, jeśli linkują do niej inne serwisy, tylko bez opisu. Do realnego usunięcia strony z indeksu służy znacznik noindex, ale musi on być dostępny dla crawlera, więc strona nie może być jednocześnie zablokowana w robots.txt.
Czy blokowanie plików CSS i JS w robots.txt szkodzi SEO?
Tak. Zablokowanie tych plików sprawia, że Google nie wyrenderuje layoutu ani treści budowanej przez JS, co może zaniżyć ocenę jakości i użyteczności strony w rankingu.
Jak zablokować boty AI, na przykład GPTBot albo ClaudeBot, w robots.txt?
Trzeba dodać osobną grupę reguł z dokładnym tokenem user agenta danego bota i regułą Disallow: /, na przykład User-agent: GPTBot, Disallow: /. Każdy bot AI, GPTBot, Google-Extended, ClaudeBot, ma własny, niezależny token, więc blokuje się je osobno, a nie regułą wspólną dla wszystkich botów.
Co się dzieje, gdy plik robots.txt zwraca błąd serwera 5xx?
Google wstrzymuje crawlowanie witryny i przez pierwsze 12 godzin próbuje ponownie pobrać plik. Jeśli to nie skutkuje, przez kolejne 30 dni stosuje ostatnią zapamiętaną wersję, po czym zakłada brak ograniczeń.
Jak sprawdzić, czy mój plik robots.txt jest poprawny?
Najprościej wejść na adres domena.pl/robots.txt w przeglądarce i zobaczyć, czy w ogóle się ładuje. Do dokładnej diagnostyki służy raport robots.txt w Google Search Console, pokazujący błędy i ostrzeżenia parsowania, oraz narzędzie do sprawdzania adresów URL dla pojedynczych stron.