Google popiera wspólną kontrolę nad trenowaniem AI w robots.txt
30 października 2026 · Aktualności
Google zapowiedziało wsparcie dla wspólnego sygnału dotyczącego trenowania modeli AI, zapisywanego w pliku robots.txt. To nie jest kolejny tag meta ani osobny plik konfiguracyjny — to próba zastąpienia mnogości indywidualnych dyrektyw jednym mechanizmem uzgodnionym między dostawcami. Dla osób zarządzających stroną zmienia się sam sposób myślenia o robots.txt: z pliku technicznego, który blokuje indeksowanie, staje się on dokumentem deklarującym politykę wobec trenowania AI. Poniżej rozkładam zapowiedź na części i oddzielam to, co wiadomo już teraz, od tego, co pozostaje deklaracją na przyszłość.
Co dokładnie zapowiedziano
Na stole leży deklaracja planów, a nie wdrożona funkcja. Mechanizm opiera się na pracach grupy AIPREF działającej w ramach IETF, czyli na próbie standaryzacji słownika preferencji dotyczących treści. Google przedstawia nowy sygnał jako rozszerzenie tego, co oferuje od 2023 roku poprzez Google-Extended — firmowy token sterujący wykorzystaniem treści do trenowania modeli.
Różnica jest jednak zasadnicza i dotyczy zasięgu. Google-Extended działał wyłącznie w relacji wydawca–Google, a nowy token ma być wspólny dla wielu dostawców AI. Zamiast osobnego wpisu dla każdego dostawcy — wpisu, który trzeba negocjować i utrzymywać — pojawia się jedno miejsce na deklarację o charakterze przekrojowym.
Jak działa wspólny token polityki
Wydawca umieszcza w robots.txt jeden wspólny token opisujący preferencję, zamiast powielać instrukcje dla każdego dostawcy osobno. Google zapowiada przy tym konkretną interpretację: jeśli strona użyje tokena do opt-outu i jednocześnie nie wskaże Google-Extended wprost, Google odczyta to tak, jakby wydawca zablokował Google-Extended. Inni uczestnicy mają stosować analogiczną logikę.
W praktyce daje to dwie ścieżki. Pierwsza to szeroki opt-out jednym wpisem, obejmujący wszystkich uczestniczących dostawców. Druga to wybiórcze wyjątki — ogólna blokada plus imienne dopuszczenie tych dostawców, z którymi chcemy współpracować. Warto zauważyć hierarchię: nowy sygnał działa jak tło, a wpis imienny może je nadpisać w konkretnym przypadku.
Istniejące, firmowe mechanizmy kontroli nie znikają. Działają równolegle z nowym sygnałem, co oznacza, że migracja nie wymaga wycinania dotychczasowych dyrektyw. To łagodzi ryzyko: nawet jeśli wspólny token nie zostanie jeszcze rozpoznany przez któregoś dostawcę, stary wpis nadal wykonuje swoją pracę.
Co to zmienia dla właścicieli stron
Po pierwsze, spada koszt utrzymania polityki. Lista wpisów rosnąca wraz z liczbą dostawców AI to problem operacyjny, który z czasem tylko się pogarsza. Po drugie, porządkuje się audyt — jeden wpis z jasnym uzasadnieniem jest znacznie łatwiejszy do udokumentowania niż zbiór rozproszonych deklaracji.
Po trzecie, zmienia się stawka. Google wprost wiąże jawne zezwolenie Google-Extended z możliwością pojawiania się w odpowiedziach i otrzymywania kliknięć przez grounding w Gemini Apps. Decyzja o opt-outcie przestaje być wyłącznie kwestią „czy oddawać treść”, a staje się pytaniem „czy chcemy być cytowani w interfejsach AI”.
To ostatnie pytanie rzadko ma jedną odpowiedź dla całej domeny. Inną politykę chce mieć redakcja monetyzująca artykuły, inną sklep z kartami produktowymi, a jeszcze inną dział marketingu publikujący materiały, których celem jest właśnie widoczność w asystentach. Rozdzielenie tych obszarów przed wprowadzeniem tokena jest tańsze niż poprawianie go po fakcie.
Warto też uczciwie powiedzieć zespołowi biznesowemu, czego opt-out nie robi. Sygnał dotyczy przyszłego pobierania treści, a nie cofa danych już pozyskanych — zmiana decyzji po roku nie unieważni tego, co trafiło do zbiorów wcześniej. To argument za tym, by politykę ustalać raz, świadomie, zamiast reagować pod presją pierwszego artykułu w mediach branżowych.
Ograniczenia, o których trzeba pamiętać
Przede wszystkim to projekt w fazie draftu, a nie obowiązujący standard. Google mówi o celu wsparcia mechanizmu w 2027 roku, więc do tego czasu obowiązuje status quo. Wszelkie wdrożenia „na zapas” trzeba traktować jako przygotowanie, nie jako uruchomienie funkcji.
Po drugie, sygnał w robots.txt pozostaje deklaracją, a nie zabezpieczeniem technicznym. Nie uniemożliwia pobrania treści — komunikuje wolę wydawcy. Ktoś, kto zignoruje plik, nadal może treść pozyskać, a egzekwowanie odbywa się na poziomie umów, regulacji i reputacji, nie zaś technicznej blokady.
Po trzecie, wartość mechanizmu rośnie wraz z liczbą uczestników. Przy wąskiej grupie dostawców wydawca nadal będzie zarządzał wyjątkami ręcznie i utrzymywał podwójną dokumentację. Do tego dochodzi niedomknięta standaryzacja: uzgodniona jest definicja trenowania, ale reszta słownika AIPREF pozostaje przedmiotem dyskusji w grupie roboczej.
Jest jeszcze kwestia czysto operacyjna, o której łatwo zapomnieć przy dużych witrynach. robots.txt obowiązuje per host, więc w domenach z subdomenami, osobnymi hostami statycznymi czy środowiskiem testowym token trzeba powtórzyć w każdym pliku. Jeden wpis w głównej domenie nie ochroni subdomeny z archiwum artykułów.
Praktyczny plan przygotowania
Zanim gdziekolwiek pojawi się nowy token, warto uporządkować to, co już mamy. Poniższa lista porządkuje kroki od inwentaryzacji do decyzji redakcyjnych.
- Zinwentaryzuj obecne wpisy w robots.txt i sprawdź, czy Google-Extended jest wymieniony jawnie, czy tylko domyślnie objęty blokadą.
- Rozstrzygnij politykę per sekcja: treści redakcyjne, strony płatne, zasoby techniczne i pliki produktowe mogą wymagać różnych decyzji.
- Nie usuwaj istniejących dyrektyw firmowych — nowy sygnał ma działać obok nich, a nie w ich miejsce.
- Ustal wersjonowanie pliku i zapisuj uzasadnienia decyzji, żeby móc odtworzyć politykę przy audycie lub zmianie zespołu.
- Poczekaj na składnię i datę wdrożenia, zanim wpiszesz token do wersji produkcyjnej — nieznany dostawcom ciąg znaków nic nie wnosi.
Dlaczego robots.txt wraca do centrum
Zapowiedź wpisuje się w szerszy ruch regulacyjny. Google wskazuje, że propozycja jest spójna z unijnym kodeksem praktyk dla dostawców modeli ogólnego przeznaczenia w ramach AI Act, który uznaje robots.txt za podstawową metodę wyrażania preferencji w formie czytelnej maszynowo. To nadaje plikowi status, którego wcześniej nie miał: z narzędzia opartego na grzeczności staje się elementem zgodności.
Dla rynku oznacza to presję na dostawców, by sygnał nie tylko odczytywali, ale realnie respektowali. Dla wydawców — argument w rozmowach handlowych, którego wcześniej brakowało. Sam plik pozostaje jednak tak dobry, jak strona, na której leży: jeśli robots.txt blokuje potrzebne zasoby albo przeczy sobie nawzajem, żadna polityka AI tego nie naprawi.
Dlatego przed każdą zmianą w robots.txt sprawdź podstawy techniczne — title, meta robots, canonical i H1 — w naszym narzędziu do audytu on-page. Jedna sprzeczna dyrektywa potrafi zniweczyć najlepiej napisaną politykę, a taniej jest wyłapać ją teraz niż po wdrożeniu wspólnego tokena.