Robots.txt: jak go poprawnie używać

W tym poradniku dowiesz się, czym jest robots.txt, jak działają jego reguły i jak go poprawnie używać, także wobec botów AI. Plik robots.txt to plik tekstowy w katalogu głównym domeny, który mówi crawlerom, których adresów URL nie skanować. Robots.txt steruje skanowaniem, a nie indeksacją, więc nie usuwa stron z Google.

Poprawne użycie robots.txt sprowadza się do pięciu zasad: blokuj tylko adresy bez wartości dla wyszukiwarki, nie blokuj CSS ani JavaScriptu potrzebnego do renderowania, do usuwania z indeksu używaj noindex, dodaj linię Sitemap i sprawdzaj plik w raporcie robots.txt w Google Search Console. Dokumentacja, nazwy raportów i tokeny botów są aktualne na październik 2026.

Przykłady pochodzą z audytu bynajmniej.pl z 14.10.2026 (crawl Screaming Frog i URL Inspection w Google Search Console). Pełny przebieg tego audytu opisałem w poradniku jak zrobić audyt SEO.

Robots.txt w skrócie: definicja i zakres

Robots.txt to plik z regułami Robots Exclusion Protocol, opisanymi od września 2022 roku w standardzie RFC 9309 (autorzy: Martijn Koster, Gary Illyes, Henner Zeller, Lizzi Sassman). Według wprowadzenia do robots.txt w Google Search Central plik służy głównie do tego, żeby crawlery nie przeciążały serwera, i „nie jest mechanizmem do trzymania strony poza Google”.

Plik robots.txt działa tylko dla protokołu, hosta i portu, pod którym leży. Według specyfikacji robots.txt w Google Search Central (aktualizacja 31.08.2026) plik musi być w katalogu głównym, na przykład https://example.com/robots.txt, a subdomena sklep.example.com potrzebuje własnego pliku. Crawlery nie szukają robots.txt w podkatalogach.

Reguły w robots.txt są prośbą, nie zabezpieczeniem. Dokumentacja Google podaje, że nie wszystkie wyszukiwarki obsługują reguły robots.txt i że różne crawlery różnie interpretują składnię. Standard RFC 9309 mówi wprost, że reguły robots.txt „nie są formą autoryzacji dostępu”, a każdy może otworzyć plik i przeczytać wpisane w nim ścieżki.

Robots.txt a noindex, canonical i hasło

Blokada w robots.txt zatrzymuje skanowanie, ale adres URL może zostać w indeksie. Według dokumentacji Google zablokowany URL może pojawić się w wynikach bez opisu, jeśli prowadzą do niego linki z innych stron. Do każdego celu służy inne narzędzie:

Noindex i blokada w robots.txt wykluczają się nawzajem. Dokumentacja Google o blokowaniu indeksowania podaje, że Googlebot nie zobaczy reguły noindex na stronie zablokowanej w robots.txt, więc strona może zostać w wynikach. Duplikaty rozwiązuje adres kanoniczny, o czym piszę w tekście o canonicalu.

Składnia robots.txt: pola i symbole

Google obsługuje w robots.txt cztery pola. Specyfikacja Google wymienia crawl-delay jako pole nieobsługiwane, a pozostałe nieznane linie parser pomija.

Ścieżki w robots.txt dopasowuje się od początku adresu URL. Specyfikacja Google obsługuje dwa symbole: * zastępuje dowolny ciąg znaków, a $ oznacza koniec adresu. Reguła Disallow: /*.pdf$ blokuje wszystkie pliki PDF, a reguła Disallow: /*?sort= blokuje adresy z parametrem sortowania.

Nazwy pól w robots.txt można pisać dowolną wielkością liter, ale ścieżki rozróżniają wielkość liter, więc Disallow: /Admin/ nie blokuje katalogu /admin/. Plik musi być tekstem w UTF-8, komentarz zaczyna się od #, a Google czyta pierwsze 500 KiB pliku i ignoruje resztę.

Pierwszeństwo reguł w robots.txt

Crawler stosuje w robots.txt tylko jedną grupę: najbardziej szczegółową, która pasuje do jego nazwy. Według specyfikacji Google grupy dla tego samego crawlera się scalają, ale grupa konkretnego crawlera nie łączy się z grupą User-agent: *. Kolejność grup w pliku nie ma znaczenia.

Wewnątrz grupy wygrywa najdłuższa pasująca reguła. Przy remisie długości specyfikacja Google stosuje regułę mniej restrykcyjną, czyli Allow. W przykładzie Googlebot ma zablokowany tylko katalog /szukaj/, a pozostałe crawlery nie mogą skanować /szukaj/ i /koszyk/ z wyjątkiem /koszyk/pomoc/, bo dłuższa reguła Allow wygrywa:

User-agent: *
Disallow: /szukaj/
Disallow: /koszyk/
Allow: /koszyk/pomoc/

User-agent: Googlebot
Disallow: /szukaj/

Sitemap: https://example.com/sitemap_index.xml

W przykładowym pliku robots.txt Googlebot może skanować /koszyk/, bo ma własną grupę i nie czyta reguł spod gwiazdki. Brak dziedziczenia reguł z grupy * to moim zdaniem najczęstsza pułapka w robots.txt: po dopisaniu grupy dla jednego bota trzeba w niej powtórzyć wszystkie blokady z grupy *. Blog Bing Webmaster opisuje tak samo zachowanie Bingbota.

Jak Google reaguje na kody HTTP pliku robots.txt

Kod odpowiedzi serwera dla adresu /robots.txt zmienia zachowanie Googlebota bardziej niż treść pliku. Specyfikacja Google opisuje cztery przypadki:

Błąd 5xx na robots.txt jest groźniejszy niż brak pliku. Plik robots.txt z kodem 503 wstrzymuje skanowanie całej witryny, a brak pliku (404) oznacza zgodę na wszystko. Google trzyma robots.txt w cache zwykle do 24 godzin, więc poprawka pliku działa z opóźnieniem. Wpływ skanowania na liczbę odwiedzanych adresów opisałem w tekście o crawl budgecie.

Jak poprawnie używać robots.txt w 6 krokach

Bezpieczna zmiana robots.txt to sześć kroków od listy adresów do sprawdzenia w Google Search Console:

1. Spisz adresy, których skanowanie nie ma sensu: wyniki wyszukiwarki wewnętrznej, koszyk, panel klienta, parametry sortowania i filtrów. Nie blokuj CSS, JavaScriptu ani obrazków potrzebnych do wyrenderowania strony.
2. Pobierz aktualny plik poleceniem curl https://example.com/robots.txt -o robots.txt, jak zaleca instrukcja aktualizacji robots.txt w Google Search Central. Wtyczka SEO, CMS albo CDN mogą serwować inną treść niż plik na dysku.
3. Dopisz reguły w edytorze tekstowym i zapisz plik w UTF-8. Dodaj linię Sitemap: z pełnym adresem mapy witryny.
4. Wgraj plik do katalogu głównego jako robots.txt i otwórz go w oknie prywatnym przeglądarki. Sprawdź kod odpowiedzi: ma być 200.
5. Otwórz raport robots.txt w Google Search Console (Ustawienia → robots.txt) i sprawdź stan pobierania oraz kolumnę Problemy. Po odblokowaniu ważnych adresów użyj opcji „Poproś o ponowne zindeksowanie”.
6. Sprawdź kilka adresów w Narzędziu do sprawdzania adresów URL i obserwuj statusy „URL zablokowany przez plik robots.txt” i „Strona zindeksowana, ale zablokowana przez plik robots.txt” w raporcie Indeksowanie stron.

Raport robots.txt w Google Search Console zastąpił w listopadzie 2023 roku stary Tester pliku robots.txt. Według pomocy Google do raportu robots.txt raport pokazuje pliki dla 20 głównych hostów usługi, ze stanami „Pobrano”, „Nie pobrano – nie znaleziono (404)” i „Nie pobrano – dowolny inny powód”, oraz wersje pliku z ostatnich 30 dni. Raport działa tylko w usłudze domeny albo w usłudze z prefiksem URL na poziomie hosta.

Raport robots.txt nie testuje reguł, których jeszcze nie ma na serwerze. Do sprawdzenia nowej reguły przed publikacją pomoc Google odsyła do zewnętrznych testerów robots.txt, a programiści mogą zbudować open-source’ową bibliotekę robots.txt od Google.

Robots.txt w WordPressie: przykład bynajmniej.pl

WordPress bez fizycznego pliku generuje wirtualny robots.txt funkcją do_robots(). Według dokumentacji WordPressa domyślny plik zawiera User-agent: *, blokadę /wp-admin/ i wyjątek dla admin-ajax.php. Od WordPressa 5.3 opcja „Proś wyszukiwarki o nieindeksowanie tej witryny” nie dopisuje już Disallow: /, tylko tag meta robots.

Robots.txt na bynajmniej.pl generuje wtyczka Yoast SEO i w październiku 2026 roku ma trzy linie: User-agent: *, puste Disallow: i Sitemap: https://bynajmniej.pl/sitemap_index.xml. Puste Disallow: niczego nie blokuje, bo specyfikacja Google pomija reguły bez ścieżki.

W audycie bynajmniej.pl z 14.10.2026 sprawdziłem dostęp botów do strony: robots.txt nie blokował żadnego bota, również botów AI. GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Googlebot i Bingbot dostali pełną treść strony (test z podszytym nagłówkiem User-Agent, wynik orientacyjny), a cała treść jest w HTML bez JavaScriptu. Na blogu bez koszyka i filtrów nie widzę powodu, żeby cokolwiek blokować.

Robots.txt bynajmniej.pl w audycie był czysty, a sygnały dla crawlerów psuła sitemapa: 2 adresy w sitemapie zwracały przekierowanie 301 (/podcast/ i /wordpress-seo/), a 2 nieindeksowalne adresy były w sitemapie. Linia Sitemap w robots.txt wskazuje mapę, ale nie naprawia jej zawartości.

Robots.txt a boty AI w 2026 roku

Firmy AI mają osobne tokeny dla trenowania modeli, wyszukiwarki i pobierania na prośbę użytkownika, więc w robots.txt każdą rolę ustawia się osobno. Tabela tokenów botów AI pokazuje role według dokumentacji firm, stan na październik 2026:

Dane o tokenach pochodzą z dokumentacji OpenAI, Anthropic, Perplexity, Google i Apple. Według Google token Google-Extended nie wpływa na obecność strony w wyszukiwarce Google i nie jest sygnałem rankingowym, a Apple podaje to samo o Applebot-Extended.

Przeglądy od AI i Tryb AI w Google nie mają osobnego tokena w robots.txt. Dokumentacja Google o funkcjach AI w wyszukiwarce wskazuje jako kontrolę robots.txt dla Googlebota oraz reguły nosnippet, data-nosnippet, max-snippet i noindex. Blokada Googlebota wyłącza stronę z wyników Google, a nie tylko z AI.

Jeśli chcesz wyłączyć trenowanie modeli, a zostać w wyszukiwarkach AI, polecam blokować tokeny treningowe i zostawić tokeny wyszukiwarek. Blokada Google-Extended wyłącza też grounding w Gemini Apps i Vertex AI, nie tylko trenowanie. Grupa dla GPTBota z regułą Disallow: / nie dotyka OAI-SearchBota, który ma własny token. Według Cloudflare z 29.08.2025 w lipcu 2025 roku na jedno odesłanie ruchu przypadało 38 065,7 skanowań Anthropic i 1 091,4 skanowań OpenAI, a 79% ruchu crawlerów AI służyło trenowaniu (dane Cloudflare).

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Disallow: /szukaj/

Robots.txt na Cloudflare może zawierać reguły, których nie ma w CMS-ie. Funkcja managed robots.txt w Cloudflare dopisuje do pliku reguły dla botów AI i linię Content-Signal: search=yes, ai-train=no. Według wpisu Cloudflare o Content Signals Policy z 24.09.2025 managed robots.txt działa na ponad 3,8 mln domen, a sygnały „wyrażają preferencje” i nie są technicznym zabezpieczeniem przed scrapingiem.

Czego nie robić z robots.txt

Poradniki o robots.txt wciąż polecają reguły, które Google przestał obsługiwać 1 września 2019 roku. Mój faworyt to Noindex: w robots.txt, który od 2019 roku działa mniej więcej tak skutecznie jak kartka „nie czytać” przyklejona na drzwiach.

• Reguły noindex, nofollow i crawl-delay w robots.txt Google pomija od 1.09.2019 według wpisu Google Search Central z 2 lipca 2019. Crawl-delay obsługują Bing i boty Anthropic, ale nie Googlebot.
• Nie blokuj w robots.txt strony z tagiem noindex, bo Googlebot nie przeczyta tagu, a URL może zostać w wynikach bez opisu.
• Nie wpisuj w robots.txt ścieżek do tajnych katalogów. Plik robots.txt jest publiczny, a boty pobierające strony na prośbę użytkownika, takie jak ChatGPT-User i Perplexity-User, według dokumentacji OpenAI i Perplexity mogą pominąć reguły.
• Nie blokuj CSS ani JavaScriptu potrzebnego do wyrenderowania strony. Dokumentacja Google pozwala blokować tylko zasoby, bez których strona dalej działa.
• Nie blokuj adresów z błędem 404, bo Googlebot nie zobaczy kodu 404. Obsługę usuniętych stron opisałem w tekście o błędzie 404.
• Nie zostawiaj Disallow: / po przeniesieniu strony z wersji testowej na produkcję. Reguła Disallow: / w grupie * zatrzymuje skanowanie całej witryny przez wszystkie crawlery respektujące robots.txt.

FAQ: najczęstsze pytania o robots.txt

Czy plik robots.txt jest obowiązkowy?

Plik robots.txt nie jest obowiązkowy. Według specyfikacji Google brak pliku, czyli odpowiedź 404, oznacza brak ograniczeń skanowania, a raport robots.txt w Google Search Console traktuje brak pliku jako stan poprawny.

Czy robots.txt blokuje indeksowanie strony?

Robots.txt blokuje skanowanie, a nie indeksowanie. Google może zaindeksować zablokowany adres URL bez opisu, jeśli prowadzą do niego linki, więc do usuwania stron z wyników służy tag noindex albo nagłówek X-Robots-Tag.

Gdzie znajduje się plik robots.txt?

Plik robots.txt znajduje się w katalogu głównym hosta, pod adresem domena/robots.txt, na przykład https://bynajmniej.pl/robots.txt. Każda subdomena i każdy niestandardowy port potrzebują osobnego pliku robots.txt.

Jak sprawdzić, czy robots.txt działa poprawnie?

Poprawność robots.txt sprawdzasz w raporcie robots.txt w Ustawieniach Google Search Console, który pokazuje stan pobierania, datę sprawdzenia i problemy z parsowaniem. Pojedyncze adresy sprawdzasz w Narzędziu do sprawdzania adresów URL.

Jak zablokować boty AI w robots.txt?

Boty AI blokujesz osobnymi grupami, na przykład User-agent: GPTBot i Disallow: /. Blokada GPTBota i ClaudeBota wyłącza trenowanie modeli, blokada Google-Extended dodatkowo grounding w Gemini Apps i Vertex AI, a OAI-SearchBot, Claude-SearchBot i PerplexityBot decydują o obecności strony w wyszukiwarkach AI.

Czy Google obsługuje crawl-delay w robots.txt?

Google nie obsługuje crawl-delay: specyfikacja robots.txt w Google Search Central wymienia crawl-delay jako pole nieobsługiwane. Według dokumentacji Google o zmniejszaniu częstotliwości skanowania Googlebot zwalnia, gdy serwer zwraca kody 500, 503 albo 429.

Paweł Zinkiewicz

Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.