Plik robots.txt nie mówi nic o tym, co bot AI zrobi z treścią, którą już pobrał. Tak jednoznacznie postawił sprawę Gary Illyes z Google w nowym odcinku serii wideo Search Central, opublikowanym w środę 22 października 2026 roku. Kto chce trzymać konkretnego bota AI z dala od swojej strony, musi go wskazać po nazwie, a dopisywanie własnych dyrektyw w rodzaju „zakaz treningu” nie da żadnego efektu.
Dla polskich wydawców i sklepów to praktyczna wiadomość z dwóch powodów. Po pierwsze, porządkuje wiele mitów o tym, jak blokować trening modeli językowych. Po drugie, w tym samym odcinku padła rada, która dotyczy niemal każdej polskiej strony: ścieżki z polskimi znakami w robots.txt warto zapisywać w postaci zakodowanej procentowo.
Kontekst: nowa seria Google o nietypowych pytaniach technicznych
Odcinek jest drugą częścią cyklu „The Non-Canonical Cabinet”, w którym Gary Illyes i Cherry Prommawin z zespołu Google Search Relations odpowiadają na nietypowe pytania techniczne zgłaszane przez społeczność. Jak podaje serwis Search Engine Journal, tym razem padło pytanie, które wraca w branży od dwóch lat: czy da się w robots.txt pozwolić botom AI na crawling strony, a jednocześnie zabronić wykorzystania tych samych treści do trenowania modeli generatywnych?
Odpowiedź Google jest krótka: standardowymi narzędziami robots.txt nie da się tego zrobić. I nie jest to ograniczenie wynikające z polityki Google, tylko z samej definicji protokołu.
Warto pamiętać, że Illyes nie jest tu przypadkowym komentatorem. Jest współautorem, razem z Martinem Thomsonem z Mozilli, roboczego dokumentu IETF, który ma dać robots.txt standardowy sposób zapisywania preferencji dotyczących użycia treści. W samym odcinku ten projekt nie został jednak wspomniany ani słowem.
Kluczowe fakty: co dokładnie powiedział Google
Robots.txt to protokół dostępu, nie licencja
Illyes odwołał się wprost do RFC 9309, czyli internetowego standardu opisującego robots.txt. W jego ujęciu robots.txt jest „protokołem preferencji dostępu”, który „nie dyktuje, co system robi z danymi po tym, jak już je pobrał”. Innymi słowy: plik reguluje, które adresy URL crawler może odpytać. Co dzieje się z pobraną treścią później (indeksowanie, streszczanie, trening, grounding odpowiedzi), leży poza zakresem tego standardu.
Jeśli właściciel strony chce całkowicie odciąć konkretnego crawlera AI od witryny, musi według Illyesa „wskazać jego token user-agent wprost w pliku”. Nie ma uniwersalnej flagi „AI”, która zadziała na wszystkie boty naraz.
Wymyślone dyrektywy są ignorowane
Na ekranie pokazano żartobliwą, fikcyjną dyrektywę „No-AI-Chicken-Training”, którą parser po prostu pominie. Dokumentacja Google dotycząca specyfikacji robots.txt wymienia tylko cztery obsługiwane elementy: User-agent, Allow, Disallow i Sitemap. Nieprawidłowe linie Google ignoruje.
Jest tu jednak niuans, na który zwrócił uwagę Search Engine Journal. RFC 9309 w sekcji 2.2.4 pozwala crawlerom samodzielnie decydować, jak przetwarzają rekordy wykraczające poza protokół. To znaczy, że dodatkowa linia może coś znaczyć dla konkretnego bota, ale tylko wtedy, gdy jego operator ją rozumie i respektuje. Dla Google takie linie nie istnieją.
Google-Extended działa inaczej, niż wiele osób zakłada
Google-Extended to token robots.txt, który nie ma własnego user-agenta. Google crawluje strony swoimi standardowymi botami, a token działa wyłącznie jako przełącznik kontrolny. Według listy popularnych crawlerów Google decyduje on, czy treści pobrane przez Google mogą służyć do trenowania przyszłych modeli Gemini oraz do groundingu w aplikacjach Gemini i w usłudze Grounding with Google Search na Vertex AI.
Ta sama dokumentacja zaznacza, że Google-Extended nie wpływa na obecność strony w wyszukiwarce Google i nie jest sygnałem rankingowym. Ważne zastrzeżenie: znaczenie tego tokenu jako kontroli użycia treści wynika z dokumentacji produktów Google, a nie z RFC 9309. To umowa Google z wydawcami, nie standard internetowy.
Polskie znaki w ścieżkach: koduj procentowo
Druga część odcinka dotyczyła ścieżek zawierających znaki spoza alfabetu angielskiego oraz emoji. Cherry Prommawin zaleciła, by w regułach robots.txt używać wersji zakodowanej. Parser Google radzi sobie z surowymi znakami, bo sam je koduje, ale jak ujęła to Prommawin, „inne lub starsze crawlery w sieci mogą się pogubić”. Na ekranie przykład z surowym emoji opisano jako działający dla Google, ale mogący zepsuć się u innych.
Dla polskich witryn to bardzo konkretna wskazówka. Jeśli Twój sklep ma adres w stylu /miasta/łódź, bezpieczniej zapisać regułę jako Disallow: /miasta/%C5%82%C3%B3d%C5%BA. Google traktuje obie formy identycznie, ale boty AI, narzędzia SEO i mniej dopracowane crawlery mogą interpretować surowe znaki UTF-8 w różny sposób.
| Element | Co kontroluje | Czego nie kontroluje |
|---|---|---|
| Disallow / Allow (RFC 9309) | Które adresy URL dany crawler może pobrać | Dalszego wykorzystania treści już pobranych |
| User-agent konkretnego bota AI (np. GPTBot, ClaudeBot) | Dostęp tego jednego bota do wskazanych ścieżek | Innych botów tej samej firmy działających pod inną nazwą |
| Google-Extended | Trening przyszłych modeli Gemini i grounding w Gemini Apps oraz Vertex AI | Indeksowania i rankingu w Google Search |
| Własne dyrektywy (np. „no-ai-training”) | Nic po stronie Google, u innych botów tylko to, co zadeklaruje ich operator | Wszystkiego, co nie wynika z dokumentacji danego bota |
| Content-Usage (projekt IETF) | Docelowo: preferencje użycia treści, np. trening AI | Na razie nic, to wciąż wersja robocza |
Projekt IETF: reguła Content-Usage wciąż w poczekalni
Najciekawszy kontekst do wypowiedzi Illyesa leży poza samym nagraniem. Robocza wersja dokumentu IETF, której jest współautorem, datowana na 19 sierpnia 2026 roku, aktualizowałaby RFC 9309 o regułę Content-Usage w robots.txt oraz odpowiadający jej nagłówek HTTP.
W tym modelu Allow i Disallow nadal decydowałyby o tym, co wolno pobrać, a Content-Usage określałby preferencje co do sposobu wykorzystania pobranych treści. Preferencje dotyczyłyby wyłącznie ścieżek, do których crawler ma dostęp. Przykładowy plik w projekcie zezwala na crawling i jednocześnie zawiera pole Content-Usage z wartością train-ai=n, czyli sygnał „możesz czytać, ale nie trenuj na tym modeli”.
Status dokumentu jest jednak ostrożny. Według wpisu w IETF Datatracker to wciąż dokument grupy roboczej, który nie trafił jeszcze do oceny przez IESG, czyli grupę sterującą IETF. Grupa planowała przekazać go dalej w sierpniu 2026 roku, a ten termin minął. Sama etykieta train-ai pochodzi z osobnego dokumentu ze słownikiem pojęć, w wersji z 14 września, który wprost zaznacza, że nie odzwierciedla konsensusu grupy roboczej. Bieżąca wersja projektu Content-Usage wygaśnie 20 lutego 2027 roku, jeśli wcześniej nie zastąpi jej nowa rewizja.
Wniosek jest prosty: dziś nie istnieje standardowy sposób wyrażenia preferencji dotyczącej treningu niezależnie od tego, które boty mają dostęp do strony. Istnieje tylko projekt.
Co to znaczy dla SEO i AIO
Blokowanie „AI” jest zawsze blokowaniem konkretnych botów
Każda decyzja w robots.txt dotycząca sztucznej inteligencji sprowadza się do listy nazw. Osobno trzeba potraktować boty treningowe, osobno boty wyszukiwarek AI, a osobno fetchery uruchamiane przez użytkownika w czasie rzeczywistym. Pisaliśmy o tym szczegółowo w poradniku robots.txt dla botów AI: GPTBot, ClaudeBot, PerplexityBot, gdzie rozbieramy, które tokeny odpowiadają za trening, a które za widoczność w odpowiedziach asystentów.
To rozróżnienie ma bezpośredni wpływ na AIO. Zablokowanie bota wyszukiwarki AI zwykle oznacza, że strona przestaje być cytowana w odpowiedziach danego asystenta. Zablokowanie bota treningowego najczęściej nie zmienia bieżącej widoczności, ale też nie cofa treningu, który już się odbył na wcześniej pobranych danych.
Fetchery użytkownika to osobna kategoria
Wypowiedź Illyesa dotyczyła crawlingu w rozumieniu RFC 9309. Tymczasem coraz więcej ruchu botów AI to pobrania wywoływane przez użytkownika, które operatorzy traktują inaczej. W sierpniu opisywaliśmy, że według OpenAI robots.txt może nie dotyczyć ChatGPT-User, a w lipcu Google przeniósł NotebookLM na osobny fetcher, który również nie stosuje się do reguł robots.txt. W praktyce robots.txt chroni dziś przed crawlingiem, ale nie przed każdą formą automatycznego pobrania strony.
Google-Extended to jedyna dźwignia wobec Gemini
Dla wydawców, którzy chcą zostać w Google Search, ale nie chcą zasilać Gemini, udokumentowaną kontrolą pozostaje Google-Extended. Trzeba jednak pamiętać o pełnym zakresie tej decyzji: token obejmuje zarówno trening, jak i grounding w Gemini Apps oraz Vertex AI. Wyłączenie go to więc nie tylko sprzeciw wobec treningu, ale potencjalnie także rezygnacja z części cytowań w ekosystemie Gemini.
Według dokumentacji Google nie ma to wpływu na ranking w wyszukiwarce. To ważne dla działów prawnych i zarządów, które obawiają się, że ochrona treści przed treningiem oznacza utratę ruchu organicznego. Nie oznacza.
Polskie adresy URL: szybki audyt robots.txt
Druga część odcinka daje gotowe zadanie na najbliższy tydzień. Wystarczy otworzyć własny plik robots.txt i sprawdzić, czy którakolwiek reguła zawiera polskie znaki: ą, ć, ę, ł, ń, ó, ś, ź, ż. Jeśli tak, warto przepisać je do postaci zakodowanej. Przykład:
- przed:
Disallow: /oferta/żółte-ręczniki - po:
Disallow: /oferta/%C5%BC%C3%B3%C5%82te-r%C4%99czniki
Dla Googlebota nic się nie zmieni. Zyskujesz natomiast przewidywalność wobec botów AI, narzędzi do audytu i crawlerów, które parsują plik mniej starannie. Najczęściej problem dotyczy sklepów z polskimi nazwami kategorii w URL, serwisów lokalnych z nazwami miast oraz blogów, które nigdy nie wyłączyły polskich znaków w permalinkach WordPressa.
Lista kontrolna dla zespołów SEO
- Sprawdź, czy robots.txt nie zawiera wymyślonych dyrektyw typu „noai” lub „no-training”. Google ich nie respektuje, a mogą dawać fałszywe poczucie ochrony.
- Zrób listę tokenów botów AI, które chcesz zablokować lub dopuścić, i rozdziel je na boty treningowe, wyszukiwarki AI i fetchery użytkownika.
- Zdecyduj świadomie o Google-Extended, pamiętając, że obejmuje także grounding w Gemini.
- Przepisz reguły ze znakami diakrytycznymi do postaci zakodowanej procentowo.
- Uzupełnij robots.txt o warstwę serwerową (reguły WAF, CDN), jeśli ochrona treści jest dla Ciebie biznesowo krytyczna.
Reakcje branży
W środowisku SEO wypowiedź Google odebrano raczej jako uporządkowanie niż zaskoczenie. Specjaliści techniczni od dawna podkreślali, że robots.txt jest umową dżentelmeńską: działa tylko wobec botów, które chcą go przestrzegać, i tylko w zakresie dostępu do adresów. Nowością jest to, że tak wyraźnie powiedział to przedstawiciel Google, a do tego współautor projektu, który ma tę lukę zamknąć.
Search Engine Journal w swoim omówieniu zwraca uwagę na rozjazd między nagraniem a stanem prac w IETF. Odcinek nie wspomina projektu Content-Usage, mimo że jego współautor siedzi przed kamerą. Komentatorzy odczytują to jako sygnał, że Google nie chce sugerować rozwiązań, które nie zostały jeszcze przyjęte, ani składać obietnic co do ich obsługi.
Równolegle rynek idzie własną drogą. Część wydawców zamiast czekać na standard przenosi kontrolę do warstwy infrastruktury. Dobrym przykładem jest model Pay Per Use od Cloudflare, w którym boty AI płacą za użycie treści, a nie tylko za dostęp do nich. To dokładnie ta luka, o której mówił Illyes: robots.txt rozstrzyga o dostępie, a o użyciu muszą rozstrzygać inne mechanizmy, techniczne lub umowne.
Dla polskiego rynku jest jeszcze wymiar prawny. Wyjątek dotyczący eksploracji tekstów i danych w prawie unijnym pozwala właścicielom treści zastrzec, że nie zgadzają się na ich eksplorację, w formie odczytywalnej maszynowo. Robots.txt bywa wskazywany jako jedna z takich form, ale wypowiedź Google pokazuje, że z technicznego punktu widzenia zastrzeżenie dotyczące użycia, a nie dostępu, nie ma dziś standardowego zapisu. To argument za tym, by zastrzeżenia formułować równolegle w regulaminie serwisu i w metadanych, a nie tylko w jednym pliku.
Co dalej
Najbliższe miesiące przyniosą trzy rzeczy warte obserwowania. Pierwsza to los projektu Content-Usage w IETF. Jeśli grupa robocza przekaże dokument do IESG, robots.txt po raz pierwszy od ponad trzydziestu lat zyska oficjalną regułę mówiącą o sposobie wykorzystania treści. Jeśli nie, projekt wygaśnie w lutym 2027 roku i trzeba będzie czekać na nową wersję.
Druga to reakcja operatorów botów AI. Nawet przyjęty standard zadziała tylko wtedy, gdy OpenAI, Anthropic, Perplexity, Google i pozostali zadeklarują jego obsługę. Bez tego Content-Usage będzie kolejną linią, którą część parserów zignoruje, dokładnie tak jak fikcyjna dyrektywa z odcinka.
Trzecia to sam cykl wideo. Według opisu nagrania następny odcinek „The Non-Canonical Cabinet” będzie poświęcony kodowi odpowiedzi 404, co przy ostatnich dyskusjach o indeksacji i porządkowaniu serwisów może przynieść kilka praktycznych doprecyzowań.
Do tego czasu rekomendacja dla zespołów SEO jest pragmatyczna: traktuj robots.txt jako listę kontroli dostępu dla nazwanych botów, Google-Extended jako jedyną udokumentowaną kontrolę wobec Gemini, a polskie znaki w regułach koduj procentowo. Wszystko, co wykracza poza te trzy punkty, wymaga dziś narzędzi poza robots.txt.
FAQ
Czy robots.txt może zablokować trening AI na mojej stronie?
Nie bezpośrednio. Według Google robots.txt reguluje wyłącznie dostęp crawlera do adresów URL, a nie dalsze użycie treści. Możesz zablokować konkretne boty treningowe po nazwie, a wobec Gemini użyć tokenu Google-Extended, ale nie ma dziś standardowej dyrektywy „nie trenuj”.
Czy zablokowanie Google-Extended obniży moje pozycje w Google?
Nie. Dokumentacja Google mówi, że Google-Extended nie wpływa na obecność strony w wyszukiwarce i nie jest sygnałem rankingowym. Obejmuje natomiast zarówno trening modeli Gemini, jak i grounding w Gemini Apps oraz Vertex AI, więc może ograniczyć cytowania w tym ekosystemie.
Czy własne dyrektywy, np. „noai”, mają jakiś sens?
Dla Google nie, bo parser obsługuje tylko User-agent, Allow, Disallow i Sitemap, a pozostałe linie ignoruje. Inne boty mogą je respektować tylko wtedy, gdy ich operator to zadeklarował w dokumentacji. Bez takiej deklaracji to wyłącznie fałszywe poczucie ochrony.
Jak zapisać w robots.txt adres z polskimi znakami?
Najbezpieczniej w postaci zakodowanej procentowo, np. /miasta/%C5%82%C3%B3d%C5%BA zamiast /miasta/łódź. Google traktuje obie formy tak samo, ale starsze lub mniej dopracowane crawlery mogą błędnie interpretować surowe znaki UTF-8.
Czym jest reguła Content-Usage?
To propozycja z roboczego dokumentu IETF, którego współautorem jest Gary Illyes. Pozwalałaby zapisać w robots.txt i nagłówku HTTP preferencje użycia treści, np. train-ai=n. Na razie nie jest standardem, nie trafiła do oceny IESG, a bieżąca wersja wygasa 20 lutego 2027 roku.