robots.txt dla agentów

robots.txt ma trzydzieści lat. Powstał w 1994 roku jako nieformalna konwencja między właścicielami stron a operatorami crawlerów — prosta odpowiedź na problem: jak powiedzieć botowi żeby nie indeksował pewnych części strony. Format jest banalny, mechanizm działa na zasadzie honoru — plik jest publiczny, każdy może go zignorować, ale w praktyce poważne silniki wyszukiwania go respektują.

Przez trzy dekady robots.txt spełniał swoje zadanie w świecie gdzie crawlerów było kilku — Googlebot, Bingbot, ewentualnie kilka mniejszych. Zasady były proste: Disallow: /admin/ i po sprawie.

Dziś do tego samego pliku zaglądają dziesiątki różnych crawlerów AI, agentów zakupowych, asystentów osobistych i systemów RAG. I pytanie które robots.txt musi teraz odpowiedzieć jest fundamentalnie inne niż „czy indeksować tę stronę” — brzmi: kogo wpuszczasz, na jakich warunkach i co mu wolno robić.

Jak robots.txt działa z agentami AI

Mechanizm się nie zmienił — zmienili się aktorzy. Każdy agent AI który respektuje konwencję robots.txt identyfikuje się przez user-agent i sprawdza plik przed crawlowaniem. Masz teraz możliwość adresowania konkretnych agentów z osobna.

Przykład z webflux.pl pokazuje jak to wygląda w praktyce:

User-agent: *
Allow: /wp-json/webflux/v1/slownik
Disallow: /wp-json/
Disallow: /?rest_route=

Ale możesz być znacznie bardziej precyzyjny — adresując konkretnych crawlerów AI z osobna:

# Pozwól GPTBot indeksować treści
User-agent: GPTBot
Allow: /

# Zablokuj ClaudeBot całkowicie
User-agent: ClaudeBot
Disallow: /

# Perplexity — tylko treści publiczne
User-agent: PerplexityBot
Allow: /blog/
Disallow: /

# Wszystkie inne boty
User-agent: *
Disallow: /wp-json/
Allow: /wp-json/webflux/v1/slownik

Znane user-agenty crawlerów AI które możesz adresować: GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot(Perplexity), Google-Extended (Google — osobny od Googlebot, tylko dla AI), Amazonbot (Amazon), cohere-ai (Cohere), Bytespider (ByteDance/TikTok).

Trzy warstwy sygnałów — robots.txt to tylko początek

robots.txt to najstarszy i najszerzej respektowany sygnał — ale nie jedyny. W erze agentów masz trzy warstwy gdzie możesz wyrażać swoją politykę wobec AI.

robots.txt — kontrola dostępu crawlerów. Które boty mogą wejść, które nie, do których sekcji. Działa zanim bot wykona zapytanie — sprawdza plik i decyduje czy wchodzić. Ograniczenie: honorowane tylko przez boty które chcą go honorować. Jak pokazuje kazus Amazon vs Perplexity opisany szczegółowo w artykule Sygnały dla agentów na webflux.pl — Perplexity aktywnie omijało techniczne blokady Amazona przez zmianę identyfikacji agenta. robots.txt nie jest ścianą, jest sygnałem.

X-Robots-Tag w nagłówkach HTTP — kontrola indeksowania odpowiedzi. Możesz dodać go do odpowiedzi REST API lub konkretnych endpointów żeby powiedzieć crawlerom jak traktować tę treść — nawet jeśli ogólny robots.txt jej nie blokuje. Na webflux.pl endpoint słownika używa X-Robots-Tag: index, follow właśnie w tym celu.

Content-Signal w nagłówkach HTTP — nowy sygnał Cloudflare który deklaruje intencje właściciela wobec AI. Content-Signal: ai-train=yes, search=yes, ai-input=yes mówi: możesz tej treści używać do trenowania modeli, indeksowania przez AI i jako input dla agentów. To nie jest standard który wszyscy respektują — ale jest coraz szerzej rozpoznawany.

Dlaczego brak decyzji to też decyzja

Jak opisuje artykuł o filarze sygnałów na webflux.pl, okno w którym „po prostu wpuszczamy agenta bo to klient” się zamknęło. Amazon pozwał Perplexity za nieautoryzowany dostęp agenta Comet do swojego sklepu. Sąd federalny wydał zabezpieczenie. To nie są rzeczy peryferyjne — to pierwsze precedensy które będą kształtować prawo agentowe przez lata.

Właściciel strony który nie ma świadomej polityki wobec ruchu agentowego w praktyce decyduje: wpuszczam wszystkich na wszystkich warunkach. Przy małym ruchu agentowym to jeszcze bez konsekwencji. Przy rosnącym ruchu agentowym — to może oznaczać przeciążenie serwera crawlerami których nie zaprosiłeś, scraping treści bez wartości zwrotnej, albo agentów wykonujących operacje których nie chciałeś.

robots.txt a llms.txt — dwie różne funkcje

To pojęcia które są często mylone bo oba to pliki tekstowe w katalogu głównym strony. Ale pełnią fundamentalnie różne funkcje.

robots.txt mówi: kogo wpuszczam i dokąd. To jest bramkarz — kontroluje dostęp.

llms.txt mówi: co tu masz i jak to rozumieć. To jest przewodnik — ułatwia nawigację tym których już wpuściłeś.

Analogia: robots.txt to polityka wizowa. llms.txt to mapa dla turystów którzy dostali wizę.

Używasz obu razem — robots.txt do kontroli dostępu, llms.txt do ułatwienia dostępu tym którym na to pozwoliłeś.

Praktyczna konfiguracja dla WordPress

Jeśli używasz Yoast SEO lub RankMath — masz edytor robots.txt wbudowany w panel. Ustawienia → Narzędzia → Edytor pliku robots.txt.

Minimalna konfiguracja która ma sens w 2026:

# Własne API — otwarte dla AI
User-agent: *
Allow: /wp-json/[twoja-namespace]/

# REST API WordPressa — zamknięte
User-agent: *
Disallow: /wp-json/

# Google Extended — osobna polityka dla Google AI
User-agent: Google-Extended
Allow: /

# GPTBot — indeksowanie treści publicznych
User-agent: GPTBot
Allow: /
Disallow: /wp-admin/
Disallow: /wp-login.php

Sitemap: https://twojastrona.pl/sitemap_index.xml

Ważna zasada kolejności: Allow z dłuższą ścieżką zawsze przed Disallow z krótszą — inaczej ogólna reguła może nadpisać szczegółową zanim agent zobaczy wyjątek.

Pojęcia powiązane w słowniku: llms.txt, AI crawler, Tożsamość agenta, Agent discovery, Filar 3 — odkrywalność, Markdown for Agents

Powiązane artykuły na webflux.pl: Sygnały dla agentów — filar trzeci agent-readiness, Sześć filarów agent-readiness