Agents.txt nie jest mechanizmem kontroli dostępu

DreamHost dokumentuje już, że plany Web Hosting automatycznie obejmują domyślne pliki robots.txt i agents.txt, jeśli witryna nie ma własnych wersji tych plików.¹

Ten drobny szczegół hostingowy wskazuje na większą zmianę. Witryny internetowe mówią dziś jednocześnie do co najmniej 3 grup odbiorców: crawlerów wyszukiwarek, crawlerów AI oraz asystentów działających w czasie wnioskowania, którzy szukają uporządkowanego kontekstu. Same nazwy plików sprawiają, że ta zmiana wygląda schludnie. robots.txt określa, co zautomatyzowani klienci mogą crawlowac. llms.txt daje LLM-om wyselekcjonowaną mapę. agents.txt sugeruje politykę dla agentów. Żaden z tych plików nie powinien dawać operatorowi poczucia ochrony.

Agents.txt nie jest mechanizmem kontroli dostępu. Pliki dla crawlerów należy traktować jako publiczne wskazówki polityki i pomoce w odkrywaniu treści. Rzeczywista kontrola nadal wynika z autoryzacji po stronie serwera, weryfikacji tożsamości botów, limitów żądań, logów, zachowania pamięci podręcznej oraz dowodów, że istotne crawlery faktycznie zobaczyły aktualne pliki.

W skrócie

Standard Robots Exclusion Protocol mówi, że reguły dla crawlerów „nie są formą autoryzacji dostępu”.² Google ostrzega również, że URL zablokowany w robots.txt nadal może pojawić się w wyszukiwarce, jeśli prowadzą do niego linki z innych stron.³ Także artykuł DreamHost o kontroli botów mówi, że pliki robots działają jak sugestie dla zgodnych wyszukiwarek, a złe boty mogą zignorować plik albo użyć mylących ciągów user-agent.¹

Crawlery AI dodają kolejne wymiary polityki. OpenAI rozdziela OAI-SearchBot dla wyszukiwania w ChatGPT od GPTBot dla crawlowania związanego z treningiem i wskazuje, że ChatGPT-User reprezentuje działania wywołane przez użytkownika, w których robots.txt może nie mieć zastosowania.⁴ Google informuje, że Google-Extended nie ma osobnego ciągu HTTP user-agent i działa jako token produktowy w robots.txt dla preferencji dotyczących trenowania oraz grounding modeli, a nie dla obecności w Google Search.⁵ Plik kontroli crawlerów wymaga dziś polityki na poziomie celu, a nie jednego przełącznika „zezwól albo zablokuj”.

Warto używać agents.txt, jeśli oczekuje tego host, platforma albo ekosystem agentów. Warto używać llms.txt, jeśli narzędzia działające w czasie wnioskowania mają rozumieć najlepsze strony witryny. robots.txt powinien pozostawać poprawny, bo duże crawlery nadal z niego korzystają. Następnie należy weryfikować żądania na brzegu serwera i czytać logi. Plik tekstowy może wyrazić intencję. Nie zatrzyma niezaufanego klienta.

Najważniejsze wnioski

Dla właścicieli witryn: - Publikować robots.txt dla polityki crawlowania, llms.txt dla kontekstu czytelnego dla AI, a agents.txt wyłącznie jako wskazówkę dla agentów. - Nie umieszczać prywatnych tras, nazw tajnych plików, wewnętrznych instrukcji ani wrażliwych ścieżek w żadnym publicznym pliku dla crawlerów. - Po zmianach sprawdzać logi. Plik polityki ma znaczenie tylko wtedy, gdy właściwy crawler go pobierze i zmieni zachowanie.

Dla zespołów SEO i AIO: - Oddzielać widoczność w wyszukiwarkach od zgód na trening i pobrań wywołanych przez użytkownika. - Jawnie wskazywać listę dozwolonych botów, na których zależy witrynie, takich jak crawlery wyszukiwarek i systemy odpowiedzi AI. - Łączyć pliki dla crawlerów z weryfikacją sitemap, canonical, schema i llms.txt.

Dla zespołów bezpieczeństwa: - Traktować ciągi user-agent jako deklaracje, a nie tożsamość. - Weryfikować crawlery przez reverse DNS albo opublikowane zakresy IP tam, gdzie operator to wspiera. - Dostęp do wrażliwych zasobów egzekwować przez uwierzytelnianie, reguły WAF, politykę aplikacji i limity żądań, a nie przez etykietę crawlerów.

Co zmieniło się wraz z agents.txt?

robots.txt istnieje od dekad. RFC definiuje plik robots.txt, który właściciele usług udostępniają, aby crawlery mogły zdecydować, do których URI wolno im uzyskać dostęp.² Podstawowa postać pliku wygląda znajomo:

User-agent: *
Disallow: /private-draft/
Sitemap: https://example.com/sitemap.xml

agents.txt pojawia się w innym momencie. Sieć nie przyjmuje już wyłącznie crawlerów wyszukiwarek. Trafiają do niej crawlery treningowe, crawlery silników odpowiedzi, crawlery bezpieczeństwa reklam, pobrania asystentów przeglądarkowych, pobrania LLM wywołane przez użytkownika, crawlery archiwizujące, narzędzia SEO oraz spam boty, które pożyczają nazwy od legalnych crawlerów.

Dokumentacja DreamHost ma znaczenie, ponieważ przesuwa agents.txt z niszowego pomysłu do domyślnego zachowania hostingu u co najmniej jednego popularnego dostawcy. Artykuł mówi, że DreamHost automatycznie dołącza domyślne pliki robots.txt i agents.txt do planów Web Hosting i pozwala właścicielom witryn nadpisać dowolny z nich przez umieszczenie własnego pliku w katalogu głównym witryny.¹ Nie czyni to z agents.txt standardu o semantyce egzekwowania. Sprawia jednak, że ta nazwa pliku będzie częściej spotykana w praktyce.

Bezpieczna interpretacja jest wąska:

Nazwy plików nie powinny ze sobą konkurować. Powinny tworzyć pakiet polityki: o co crawlery mogą poprosić, co systemy AI powinny czytać, co agenci powinni wiedzieć i co serwer faktycznie zaobserwował.

Robots.txt nadal ma znaczenie, ale nie chroni

Pliki dla crawlerów zawodzą wtedy, gdy zespoły używają ich jako granic bezpieczeństwa.

RFC jasno wyznacza tę granicę. Protokół prosi zautomatyzowanych klientów o respektowanie reguł przy dostępie do URI; nie autoryzuje dostępu.² Google mówi to samo w praktyce operacyjnej: jeśli inna strona linkuje do niedozwolonego URL-a, Google może nadal znaleźć i zaindeksować adres URL oraz inne publiczne informacje z linków, nawet bez crawlowania treści zablokowanej strony.³ DreamHost ostrzega, że reguły robots działają jak sugestie dla zgodnych wyszukiwarek, a złe boty mogą zignorować plik albo użyć fałszywych ciągów user-agent.¹

Z tych faktów wynika prosta reguła: nigdy nie należy umieszczać w robots.txt, agents.txt ani llms.txt niczego, co zaszkodziłoby witrynie po skopiowaniu do wyniku wyszukiwania, zeskrobaniu do zbioru danych albo wyświetleniu przez LLM.

Złe pliki dla crawlerów więcej ujawniają, niż chronią:

User-agent: *
Disallow: /internal-product-roadmap/
Disallow: /legal-private/
Disallow: /prompt-drafts/
Disallow: /customers/acme-renewal-risk/

Powyższy plik mówi każdemu odwiedzającemu, gdzie mogą znajdować się wrażliwe materiały. Zgodny crawler może omijać te ścieżki. Atakujący otrzymuje mapę katalogów.

Bezpieczniejszy plik wyraża publiczną politykę crawlowania bez nazywania wrażliwego inwentarza:

User-agent: *
Allow: /
Disallow: /*.md$
Sitemap: https://example.com/sitemap.xml

Ta wersja przekazuje realną preferencję bez ujawniania prywatnej struktury. Jeśli /prompt-drafts/ istnieje, serwer powinien chronić go uwierzytelnianiem oraz, tam gdzie to właściwe, nagłówkami noindex. Plik dla crawlerów nie powinien dźwigać tego ciężaru.

Crawlery AI potrzebują polityki na poziomie celu

Polityka dla crawlerów wyszukiwarek kiedyś wydawała się binarna: zezwolić Googlebot, zablokować hałaśliwe narzędzia SEO, a prywatne strony trzymać prywatnie za pomocą kontroli serwerowych.

Polityka dla crawlerów AI dodaje cel. Właściciel witryny może chcieć, aby strona pojawiała się w wynikach wyszukiwania ChatGPT, a jednocześnie wyłączyć tę samą stronę z użycia do trenowania modeli. Dokumentacja crawlerów OpenAI pokazuje ten podział wprost. OAI-SearchBot obsługuje funkcje wyszukiwania ChatGPT, natomiast GPTBot crawluje treści, które mogą być używane do trenowania bazowych modeli generatywnej AI OpenAI.⁴ OpenAI mówi również, że te ustawienia są niezależne: webmaster może zezwolić OAI-SearchBot i jednocześnie zablokować GPTBot.⁴

Google wyznacza podobną granicę innym sposobem. Dokumentacja crawlerów Google mówi, że Google-Extended nie ma osobnego ciągu user-agent dla żądania HTTP; crawl wykonują istniejące user agenty Google, a Google-Extended działa jako token produktowy w robots.txt.⁵ Google wskazuje, że token kontroluje, czy zcrawlowane treści z witryny mogą wspierać przyszłe trenowanie modeli Gemini i grounding, oraz że nie wpływa na obecność ani ranking w Google Search.⁵

Te 2 przykłady pokazują, dlaczego płaska lista blokad mija się z celem. Rzeczywista macierz polityki pyta:

Plik polityki powinien odpowiadać celowi. Nie należy blokować każdego user agenta AI, a potem zastanawiać się, dlaczego wyszukiwarki AI ignorują witrynę. Nie należy też zezwalać każdemu crawlerowi AI, a potem narzekać, że crawlery treningowe pobierają strony przeznaczone wyłącznie do wyszukiwania dla użytkowników. Trzeba rozdzielić cele, zapisać preferencję i zweryfikować zachowanie.

Llms.txt rozwiązuje inny problem

llms.txt nie zastępuje robots.txt. Propozycja Jeremy’ego Howarda opisuje /llms.txt jako sposób dostarczenia informacji, które pomagają LLM-om korzystać z witryny w czasie wnioskowania.⁶ Ta sama propozycja mówi, że llms.txt może współistnieć z obecnymi standardami sieci: sitemapy wymieniają strony dla wyszukiwarek, natomiast llms.txt oferuje wyselekcjonowany przegląd dla LLM-ów i może uzupełniać robots.txt kontekstem dla dozwolonej treści.⁶

Dla pracy AIO to istotne rozróżnienie.

robots.txt odpowiada: „Czy ten crawler może poprosić o tę ścieżkę?”.

llms.txt odpowiada: „Jeśli asystent czyta moją witrynę, co powinien zrozumieć najpierw?”.

agents.txt może odpowiadać: „Co klienci agentowi powinni wiedzieć o pożądanym zachowaniu?”.

Te pytania leżą blisko siebie, ale nie sprowadzają się do jednego pliku. Poważna witryna powinna traktować odkrywanie przez AI jak powierzchnię wydawniczą:

1. Publikować strony kanoniczne z jasnymi tytułami i opisami.
2. Dodawać dane strukturalne zgodne z widoczną stroną.
3. Utrzymywać aktualny sitemap i RSS.
4. Publikować llms.txt i llms-full.txt jako wyselekcjonowany kontekst AI.
5. Publikować robots.txt z jawną polityką crawlerów.
6. Dodawać agents.txt tylko wtedy, gdy platforma albo ekosystem agentów daje temu plikowi konkretnego czytelnika.
7. Sprawdzać logi, aby potwierdzić, że crawlery pobierają zmienione pliki.

Pominięcie ostatniego kroku zamienia AIO w rytuał nadziei. Plik dla crawlerów istnieje. Trasa zwraca 200. Żaden dowód nie potwierdza, że zamierzeni klienci go zobaczyli.

Weryfikacja należy do brzegu serwera

Ciągi user-agent nie dowodzą tożsamości. Losowy skrypt może wysłać User-Agent: Googlebot. Scraper może wysłać User-Agent: GPTBot. Polityka ufająca samemu nagłówkowi najłagodniej traktuje to, co najłatwiej podrobić.

Google dokumentuje 2 ścieżki weryfikacji żądań deklarujących pochodzenie od Google: reverse DNS plus forward DNS dla pojedynczych sprawdzeń oraz dopasowanie do opublikowanych zakresów IP dla większych systemów.⁷ OpenAI publikuje pliki JSON adresów IP dla OAI-SearchBot, GPTBot i ChatGPT-User w dokumentacji crawlerów.⁴ Te mechanizmy nie obejmują każdego crawlera. Ustanawiają jednak właściwy model: tożsamość wymaga dowodu wykraczającego poza ciąg tekstowy.

Minimalna polityka brzegowa powinna rejestrować:

Taki pakiet logów zmienia politykę crawlerów z opinii w dowód. Jeśli GPTBot nadal żąda niedozwolonych ścieżek, można to udowodnić. Jeśli fałszywy Googlebot z proxy mieszkaniowego atakuje URL-e wyglądające na prywatne, można go zablokować bez karania prawdziwego Googlebot. Jeśli OAI-SearchBot nigdy nie poprosił o zmieniony artykuł, wiadomo, dlaczego strona nie pojawiła się w wyszukiwaniu ChatGPT.

Praktyczny pakiet polityki dla crawlerów AI

Nie należy zaczynać od pliku. Trzeba zacząć od wyniku.

Taki pakiet przypisuje każdej warstwie właściwe zadanie. robots.txt komunikuje preferencję. llms.txt komunikuje kontekst. agents.txt komunikuje intencję dla agentów tam, gdzie istnieje czytelnik. Serwer egzekwuje. Logi dowodzą.

Na mojej własnej witrynie praca z crawlerami podąża za tym podziałem. Publiczny plik polityki wita legalne crawlery i blokuje surowe ścieżki Markdown, które crawlery wywnioskowały z przykładów w blokach kodu. Pliki kontekstu AI dają asystentom wyselekcjonowaną drogę do publicznych tekstów. Nocny spis crawlowania pokazuje mi, czy crawlery widziały błędy, nieświeży cache, brakujące trasy albo stare URL-e, które powinny już zwracać 410. Plik polityki przekazuje intencję. Logi rozstrzygają, czy intencja zadziałała.

Co umieścić w agents.txt

Dopóki ekosystem się nie ustabilizuje, agents.txt powinien być nudny i publiczny.

Dobre kandydatury:

• Kontakt do witryny i URL polityki.
• Wskaźniki do robots.txt, sitemap, llms.txt i RSS.
• Deklaracja preferowanego użycia publicznej treści.
• Ostrzeżenie, że trasy prywatne albo wymagające uwierzytelnienia wymagają autoryzacji.
• Adres wsparcia dla problemów z crawlowaniem.

Złe kandydatury:

• Tajne ścieżki.
• Wewnętrzne reguły instrukcji.
• Niepubliczne trasy API.
• Nazwy klientów.
• Wyjątki bezpieczeństwa.
• Instrukcje, które zaszkodziłyby witrynie, gdyby skopiował je wrogi klient.

Właściwy standard dla agents.txt nie brzmi: „Czy dobry agent to doceni?”. Właściwy standard brzmi: „Czy byłoby w porządku, gdyby zły agent, wynik wyszukiwania i losowy użytkownik wszyscy przeczytali ten plik?”.

Lepszy model myślowy

Pliki dla crawlerów są znakami przy publicznej drodze.

Znak może mówić „wjazd dla dostaw”, „nie wjeżdżać” albo „zacznij tutaj”. Uważni kierowcy stosują się do znaku. Lekkomyślni go ignorują. Znak nadal pomaga, bo większość legalnego ruchu chce jasnych instrukcji. Znak zawodzi wtedy, gdy traktuje się go jak zamknięte drzwi.

Crawlery AI sprawiają, że znaki są jednocześnie ważniejsze i mniej wystarczające. Ważniejsze, bo systemy AI potrzebują jasnego publicznego kontekstu, polityki specyficznej dla celu i map tras. Mniej wystarczające, bo user agenty się mnożą, trening i wyszukiwanie rozdzielają, a źli klienci mogą podszywać się pod dobrych.

Odpowiedzią nie jest rezygnacja z plików dla crawlerów. Odpowiedzią jest obniżenie ich autorytetu do właściwego poziomu. Publikować jasną publiczną politykę. Weryfikować, kto pobiera pliki. Obserwować, co pobiera. Egzekwować prywatne granice na serwerze. Każde twierdzenie o „widoczności AI” traktować jako nieudowodnione, dopóki nie wspierają go logi i działające trasy.

Na tym polega różnica między teatrem AIO a rzeczywistą obsługą crawlerów.

FAQ

Czym jest agents.txt?

agents.txt to wyłaniający się plik tekstowy dla agentów, który niektóre hosty lub narzędzia mogą serwować w katalogu głównym witryny. DreamHost dokumentuje domyślne pliki agents.txt dla planów Web Hosting, ale ta dokumentacja nie czyni z pliku standardu kontroli dostępu. Należy traktować go jako publiczną wskazówkę, dopóki konkretna platforma agentowa nie udokumentuje dokładnie, jak czyta i stosuje ten plik.¹

Czy robots.txt blokuje crawlery AI?

Zgodne crawlery mogą respektować robots.txt, a główni operatorzy dokumentują konkretne tokeny dla swoich crawlerów. OpenAI dokumentuje kontrolę OAI-SearchBot i GPTBot, natomiast Google dokumentuje Google-Extended jako token produktowy dla preferencji dotyczących treningu i groundingu.⁴⁵ robots.txt nadal jednak nie uwierzytelnia klienta, nie ukrywa treści ani nie zatrzymuje bota, który zdecyduje się zignorować plik.²³

Czy warto publikować llms.txt?

Warto publikować llms.txt, jeśli asystenci AI mają znaleźć wyselekcjonowaną mapę publicznej treści witryny. Propozycja przedstawia llms.txt jako kontekst czasu wnioskowania, a nie zamiennik sitemap ani robots.txt.⁶ Użyteczny plik wskazuje strony, które faktycznie mają być zrozumiane przez agentów.

Czy niedozwolony URL nadal może pojawić się w wyszukiwarce?

Tak. Google mówi, że URL zablokowany przez robots.txt nadal może się pojawić, jeśli linkują do niego inne strony, mimo że Google nie będzie crawlować ani indeksować treści zablokowanej strony.³ Dla stron, które muszą pozostać poza publicznymi wynikami, należy używać uwierzytelniania, noindex tam, gdzie dostęp crawlerów jest dozwolony, oraz polityki po stronie serwera.

Jak odróżnić prawdziwego crawlera od fałszywego?

Trzeba używać czegoś więcej niż ciągu user-agent. Google dokumentuje sprawdzenia reverse DNS plus forward DNS oraz dopasowanie do opublikowanych zakresów IP.⁷ OpenAI publikuje pliki JSON adresów IP dla udokumentowanych botów.⁴ Tam, gdzie operator crawlera nie publikuje danych weryfikacyjnych, należy klasyfikować żądanie jako deklarację i ograniczać jego tempo albo poddawać je wyzwaniu zgodnie z zachowaniem.

Jaka konfiguracja plików dla crawlerów jest najbezpieczniejsza dla publicznej witryny?

Używać robots.txt dla polityki crawlerów, sitemap dla odkrywania URL-i, llms.txt dla wyselekcjonowanego kontekstu AI oraz agents.txt wyłącznie dla publicznych wskazówek dla agentów. Wrażliwe ścieżki trzymać poza wszystkimi publicznymi plikami. Następnie zweryfikować działające trasy, stan cache, pobrania przez crawlery i logi serwera, zanim uzna się, że konfiguracja działa.

Źródła