robots.txt dla crawlerów AI — przykłady konfiguracji
Dobra konfiguracja nie zaczyna się od listy wszystkich botów, tylko od decyzji: które cele i zasoby chcesz dopuścić. Poniżej znajdziesz scenariusze do adaptacji — od rozdzielenia wyszukiwania i treningu po ograniczenie wybranych katalogów.
Szybka odpowiedź
W robots.txt tworzysz grupę dla konkretnego tokenu User-Agent, a następnie wskazujesz dozwolone i niedozwolone ścieżki. Używaj osobnych grup dla crawlerów o różnych celach, testuj plik na każdym hoście i pamiętaj, że robots.txt jest komunikatem, a nie zaporą bezpieczeństwa ani uniwersalnym zastrzeżeniem każdego sposobu użycia treści.
Dla webmasterów, wydawców, zespołów SEO, content, security i compliance, które potrzebują czytelnego punktu wyjścia do polityki dostępu crawlerów AI.
1. Zacznij od poprawnej składni i zakresu hosta
Grupa składa się z jednej lub kilku linii User-agent oraz następujących po nich reguł. Disallow wskazuje niedozwolony prefiks ścieżki, Allow może doprecyzować wyjątek, a przy konflikcie standard wybiera najbardziej szczegółowe dopasowanie.
Plik /robots.txt obowiązuje w kontekście hosta, z którego jest pobierany. Polityka dla example.com nie jest automatycznie polityką dla sklep.example.com. Brak pasującej grupy oznacza użycie reguł User-agent: *, jeśli istnieją; bez pasującej grupy i bez grupy ogólnej nie ma ograniczeń protokołu.
User-agent: ExampleBot
Disallow: /prywatne-archiwum/
Allow: /prywatne-archiwum/indeks.html2. Zapisz politykę przed edycją pliku
Lista nazw botów bez uzasadnienia szybko staje się nieczytelna. Najpierw zbuduj prostą macierz dostawca × cel × zasób. Dla każdego wiersza określ Allow, Monitor, Rate limit albo Block oraz właściciela decyzji.
- Search: klasyczne wyszukiwarki i crawlery wspierające wyniki AI
- Training/model development: pobrania deklarowane jako potencjalne źródło danych dla modeli
- User action: pobranie strony w wyniku działania konkretnego użytkownika
- Validation / Service crawler: techniczny review reklamy, monitoring albo inny proces usługowy
- Unknown: klient bez wiarygodnej tożsamości lub celu
- Resource: publiczny artykuł, dane produktowe, archiwum premium albo panel chroniony
3. Wariant: widoczność w AI Search bez crawlerów treningowych
Ten scenariusz pozostawia dostęp dla OAI-SearchBot, Claude-SearchBot i PerplexityBot, a ogranicza GPTBot, ClaudeBot oraz Google-Extended. Jest użyteczny, gdy organizacja chce zachować możliwość cytowania publicznych stron w wyszukiwaniu AI, lecz sygnalizować inną decyzję dla wykorzystania treningowego.
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /4. Wariant: publiczne artykuły dostępne, wartościowe katalogi zablokowane
Politykę można różnicować według ścieżki. Przykład dopuszcza publiczną bazę wiedzy, ale ogranicza dane produktowe i archiwum premium dla dwóch crawlerów związanych z rozwojem modeli.
User-agent: GPTBot
Allow: /baza-wiedzy/
Disallow: /dane-produktowe/
Disallow: /archiwum-premium/
User-agent: ClaudeBot
Allow: /baza-wiedzy/
Disallow: /dane-produktowe/
Disallow: /archiwum-premium/5. Wariant: dodanie Common Crawl do polityki
CCBot jest crawlerem Common Crawl i respektuje robots.txt. Dane Common Crawl mogą być wykorzystywane przez różne podmioty i projekty, dlatego decyzję o tym crawlerze warto zapisać osobno, zamiast zakładać, że jest tożsama z polityką konkretnego dostawcy AI.
User-agent: CCBot
Disallow: /User-agent: CCBot
Allow: /baza-wiedzy/
Disallow: /6. Wariant: pełna blokada nazwanych crawlerów automatycznych
Poniższy wariant jest czytelny, ale ma najszerszy wpływ: ogranicza zarówno crawlery treningowe, jak i automatyczne crawlery AI Search. Nie obejmuje w sposób gwarantowany klientów działających na żądanie użytkownika ani botów podszywających się pod inną nazwę.
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /7. Czego nie zapiszesz skutecznie w standardowym robots.txt
robots.txt nie jest systemem uwierzytelniania i nie odbiera klientowi technicznej możliwości wysłania żądania. Standard nie zapewnia też jednolitego rate limitu, potwierdzenia tożsamości, usunięcia danych pobranych wcześniej ani dowodu sposobu późniejszego wykorzystania treści.
- rate limit egzekwuj na CDN-ie, WAF-ie, reverse proxy lub w aplikacji
- tożsamość sprawdzaj dodatkowymi sygnałami, np. publikowanymi zakresami IP
- zasoby poufne chroń uwierzytelnieniem i autoryzacją
- zdarzenia zapisuj w logach razem z wersją polityki i wykonaną akcją
- skutków prawnych nie sprowadzaj do automatycznego statusu allow/block
8. Checklista publikacji i utrzymania polityki
Przetestuj konfigurację najpierw w trybie obserwacji, jeśli równolegle wdrażasz reguły egzekwujące. Pozwoli to wykryć wpływ na pożądane indeksowanie, integracje i ruch użytkowników przed szeroką blokadą.
- potwierdź odpowiedź 200 i text/plain dla /robots.txt
- sprawdź każdą domenę i subdomenę objętą polityką
- porównaj reguły z aktualną dokumentacją wszystkich nazwanych dostawców
- zapisz właściciela, uzasadnienie, wersję i datę przeglądu
- monitoruj żądania, źródła sieciowe i kody odpowiedzi po zmianie
- oddziel obserwację konfliktu z polityką od oceny zgodności prawnej
Czytaj także
Źródła i dalsza weryfikacja
Prawo, dokumentacja platform i standardy techniczne mogą się zmieniać. Przed działaniem sprawdź aktualne źródła oraz kontekst swojej organizacji.