Nie każdy robot związany z AI robi to samo. Jeden może zbierać informacje dla wyszukiwania, drugi pozyskiwać publiczne treści do rozwoju modeli, a trzeci otworzyć konkretną stronę dlatego, że użytkownik poprosił asystenta o wykonanie zadania.
Dlatego kontrola dostępu nie powinna zaczynać się od pytania „blokować AI czy nie?”. Najpierw trzeba ustalić operatora, zastosowanie crawlera, rzeczywistą odpowiedź serwera i biznesowy skutek blokady. Dopiero później można świadomie zaprojektować robots.txt, WAF, limity, cache oraz ochronę treści prywatnych.
robots.txt pozwala przekazać respektującym go crawlerom reguły pobierania adresów, ale nie jest systemem bezpieczeństwa, nie gwarantuje braku indeksacji i nie przesądza o tym, czy marka zostanie cytowana lub rekomendowana przez AI. W praktyce warto oddzielać roboty wyszukiwania od crawlerów treningowych i działań inicjowanych przez użytkownika. Treści publiczne można udostępniać selektywnie, a materiały poufne chronić prawdziwą kontrolą dostępu: logowaniem, uprawnieniami, tokenami lub ograniczeniami sieciowymi.
Najpierw ustal, po co crawler pobiera stronę
Określenie „crawler AI” jest zbyt szerokie, aby na jego podstawie podejmować decyzję o blokowaniu.
Crawler wyszukiwania
Pobiera lub aktualizuje treści wykorzystywane do odnajdywania dokumentów i przygotowywania odpowiedzi.
Crawler treningowy
Może pozyskiwać publiczne materiały przeznaczone do określonych zastosowań związanych z rozwojem modeli.
Robot użytkownika
Pobiera stronę w związku z konkretnym poleceniem człowieka, np. otwarciem URL-a, analizą lub wykonaniem zadania.
Te trzy zastosowania mogą mieć osobne tokeny, polityki i konsekwencje biznesowe.
Nie pytaj tylko „czy to bot AI?”
Lepszy zestaw pytań wygląda tak:
Crawlowanie nie oznacza obecności w odpowiedzi AI
W logu można zobaczyć wizytę robota i jednocześnie nie zobaczyć żadnego efektu w wyszukiwaniu ani odpowiedziach AI.
crawler żąda URL-a
system interpretuje zasób
informacja może zostać zapisana
dokument może zostać odnaleziony
informacja może wejść do odpowiedzi
źródło może zostać pokazane
Wizyta crawlera potwierdza przede wszystkim próbę pobrania. Nie jest dowodem indeksacji, wykorzystania treści, wzmianki, cytowania ani rekomendacji.
Kod 200 również nie oznacza, że crawler otrzymał właściwą treść
Serwer może zwrócić 200, ale dokumentem faktycznie dostarczonym robotowi może być:
Dlatego przy audycie trzeba badać nie tylko status HTTP, ale także treść, typ MIME i rozmiar odpowiedzi.
Retrieval, grounding i cytowanie to kolejne osobne warstwy
| Proces | Co oznacza? |
|---|---|
| Crawl | próba pobrania zasobu |
| Indeksacja | zapis informacji do późniejszego odnajdywania |
| Retrieval | odnalezienie dokumentu dla konkretnej potrzeby |
| Grounding | oparcie odpowiedzi na odnalezionych danych |
| Cytowanie | pokazanie źródła użytkownikowi |
| Rekomendacja | wskazanie marki jako możliwego wyboru |
Zablokowanie własnej domeny nie usuwa marki z całego ekosystemu
Informacje o firmie mogą nadal istnieć w:
W efekcie marka może nadal być opisywana, lecz oficjalne źródło będzie mniej dostępne do sprawdzenia aktualnych faktów.
Przykładowe grupy botów należy rozdzielać według funkcji
| Zastosowanie | Przykładowe tokeny |
|---|---|
| Wyszukiwanie | Googlebot, bingbot, OAI-SearchBot, Claude-SearchBot, PerplexityBot |
| Rozwój modeli | GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot |
| Działanie użytkownika | ChatGPT-User, Claude-User, Perplexity-User |
Nazwy tokenów, zakres zastosowań i zasady operatorów mogą się zmieniać. Konfigurację trzeba okresowo porównywać z aktualną dokumentacją dostawców.
Google-Extended nie jest osobnym botem widocznym w logach
To szczególny przypadek, który łatwo błędnie interpretować.
Token kontroli wykorzystania ≠ osobny User-Agent wykonujący każde pobranie.
Dlatego brak ciągu „Google-Extended” w logach nie dowodzi, że konfiguracja jest ignorowana.
robots.txt steruje pobieraniem, nie poufnością
Plik powinien znajdować się w katalogu głównym konkretnego hosta.
Host + protokół + port → własny robots.txt.
Reguły domeny głównej nie muszą automatycznie kontrolować:
Podstawowe dyrektywy mają bardzo konkretne znaczenie
| Dyrektywa | Funkcja |
|---|---|
User-agent | określa robota lub grupę robotów |
Disallow | wskazuje ścieżki niedozwolone do pobierania |
Allow | może tworzyć bardziej szczegółowy wyjątek |
Sitemap | wskazuje lokalizację mapy witryny |
Najważniejsza konfiguracja biznesowa to często dostęp selektywny
Firma może chcieć pozostawić publiczne materiały dostępne dla wyszukiwania, a podjąć inną decyzję wobec crawlerów związanych z rozwojem modeli.
Publiczna wiedza → dostęp dla wyszukiwania
Treści wrażliwe → autoryzacja
Crawl treningowy → osobna decyzja biznesowa.
Ten model jest znacznie bardziej precyzyjny niż `User-agent: *` stosowany bez analizy konsekwencji.
Przykład: wyszukiwanie dozwolone, crawl treningowy zablokowany
User-agent: OAI-SearchBot
Disallow:
User-agent: GPTBot
Disallow: /
User-agent: Claude-SearchBot
Disallow:
User-agent: ClaudeBot
Disallow: /
Taka polityka ilustruje zasadę rozdzielenia zastosowań. Przed wdrożeniem trzeba zweryfikować aktualne tokeny i dokumentację konkretnych operatorów.
Nie publikuj poufnych ścieżek jako „zabezpieczenia” w robots.txt
Plik robots.txt jest publiczny. Nie służy do ukrywania paneli klientów, danych osobowych, raportów płatnych ani dokumentów wewnętrznych.
Jeżeli zasób ma być naprawdę niedostępny, użyj mechanizmu egzekwowanego przez serwer.
Treści prywatne wymagają uwierzytelnienia
Jeżeli osoba znająca URL nie powinna zobaczyć zasobu, robots.txt nie jest właściwym mechanizmem ochrony.
Disallow nie jest tym samym co noindex
| Mechanizm | Główny cel |
|---|---|
Disallow | ograniczenie pobierania przez respektującego robota |
noindex | prośba o niewłączanie dokumentu do obsługiwanego indeksu |
| Uwierzytelnienie | techniczne uniemożliwienie dostępu bez uprawnień |
Jeżeli crawler ma odczytać noindex, musi najpierw móc pobrać dokument.
Jednoczesne zablokowanie adresu w robots.txt i oczekiwanie, że robot odczyta znajdujące się na tej stronie noindex.
robots.txt jest polityką, a WAF jest egzekwowaniem ruchu
Te warstwy nie powinny być ze sobą mylone.
| robots.txt | WAF / firewall |
|---|---|
| publikuje zasady dla crawlera | technicznie przepuszcza lub odrzuca żądanie |
| wymaga respektowania | działa na poziomie infrastruktury |
| identyfikuje grupę przez token | może używać IP, reputacji, kraju i innych sygnałów |
Zezwolenie w robots.txt nie gwarantuje dostępu
Crawler może być dozwolony, a mimo to otrzymywać:
Dlatego konfigurację trzeba testować end-to-end, a nie wyłącznie przez odczyt pliku robots.txt.
CDN może ukryć rzeczywistą aktywność crawlerów przed originem
Jeżeli odpowiedź zostanie obsłużona z cache, żądanie może nie dotrzeć do serwera źródłowego.
Logi CDN + logi WAF + logi reverse proxy + logi originu.
Analiza wyłącznie logów hostingu może więc mocno zaniżać liczbę pobrań.
Cache pomaga, ale może również podawać nieaktualną treść
User-Agent nie potwierdza tożsamości crawlera
Dowolny klient HTTP może zadeklarować:
User-Agent: Googlebot
Nie oznacza to, że żądanie rzeczywiście pochodzi od Google.
Do decyzji bezpieczeństwa potrzebujesz dodatkowej weryfikacji
Nazwa User-Agent jest przydatna do klasyfikacji logów. Sama nie powinna być jedyną podstawą reguły bezpieczeństwa.
Jakie informacje powinny trafiać do logów?
Co mierzyć dla każdego crawlera?
liczba żądań
unikalne adresy
udane odpowiedzi
ograniczenia ruchu
transfer
udział cache
Ważne jest również, które katalogi są pobierane, jak często bot wraca do tych samych URL-i oraz czy interesuje go HTML, PDF, obrazy czy inne zasoby.
Nie mierz widoczności liczbą requestów bota
Duża liczba wizyt crawlera treningowego nie oznacza wysokiej widoczności marki w odpowiedziach AI.
Osobno trzeba mierzyć:
Jakie są biznesowe skutki blokowania?
| Decyzja | Możliwa konsekwencja |
|---|---|
| Blokada crawlera wyszukiwania | mniejsza możliwość pobrania aktualnej wersji własnej strony |
| Blokada crawlera treningowego | ograniczenie przyszłego pobierania dla danego zastosowania |
| Blokada wszystkich botów | ryzyko utraty klasycznej i AI-owej widoczności |
| Ograniczenie zbędnych URL-i | niższe obciążenie infrastruktury |
| Autoryzacja materiałów płatnych | rzeczywista ochrona treści |
Największe ryzyko dla marki: AI zna ją z innych źródeł, ale nie może sprawdzić oficjalnej strony
To szczególnie ważne w AI Search.
Oficjalna domena zablokowana → źródła zewnętrzne dostępne → AI nadal opisuje markę → aktualne dane firmy trudniejsze do weryfikacji.
Z tego powodu całkowite blokowanie wszystkich robotów nie zawsze jest zgodne z celem budowania widoczności i kontroli nad publicznym obrazem firmy.
Polityka dla marki budującej widoczność w AI powinna być selektywna
określ treści do odkrywania
zdecyduj o crawlerach wyszukiwania
podejmij osobną decyzję
zabezpiecz autoryzacją
usuń niezamierzone blokady
sprawdzaj rzeczywisty ruch
Nie pozwalaj crawlerom marnować zasobów na bezwartościową przestrzeń URL
W wielu serwisach problemem nie jest sam crawler, lecz ogromna liczba adresów generowanych przez:
Kontrola crawlowania może więc służyć również ochronie zasobów infrastruktury i koncentracji pobrań na wartościowych dokumentach.
llms.txt nie zastępuje robots.txt
To dwa różne zagadnienia.
robots.txt dotyczy polityki pobierania przez obsługujące go roboty. llms.txt nie jest uniwersalnym standardem kontroli dostępu do crawlerów AI.
Szczegółowo granice tego rozwiązania opisuje analiza llms.txt w AI Search.
Najczęstsze błędy wdrożeniowe
Blokada wszystkiego
User-agent: * i Disallow: / mogą odciąć znacznie więcej niż crawler treningowy.
Disallow + noindex
Robot nie może pobrać dokumentu i przez to może nie zobaczyć dyrektywy noindex.
Zły host
Reguła domeny głównej niekoniecznie steruje subdomeną sklepu lub dokumentacji.
WAF blokuje robots.txt
Crawler nie może nawet odczytać opublikowanej polityki.
Wiara w User-Agent
Nazwa bota jest traktowana jak dowód jego tożsamości.
Tylko logi originu
Ruch obsłużony przez CDN całkowicie znika z analizy.
Mity dotyczące crawlerów AI
| Mit | Rzeczywistość |
|---|---|
| Wizyta GPTBot oznacza cytowanie w ChatGPT | crawl i cytowanie to różne procesy |
| Blokada GPTBot blokuje ChatGPT Search | wyszukiwanie może mieć osobny crawler |
| Google-Extended steruje Google Search | nie należy utożsamiać go z Googlebotem |
| Disallow usuwa URL z indeksu | ogranicza przede wszystkim pobieranie |
| robots.txt chroni pliki prywatne | do tego potrzebna jest kontrola dostępu |
| User-Agent potwierdza bota | można go sfałszować |
| Brak bota w logach oznacza brak wiedzy o marce | system może korzystać z innych źródeł i wcześniejszych danych |
Jak przeprowadzić audyt crawlerów AI?
ustal co ma być publiczne
zinwentaryzuj domeny i subdomeny
sprawdź wszystkie pliki
zidentyfikuj rzeczywisty ruch
zweryfikuj ich tożsamość
sprawdź co faktycznie otrzymują
wdroż reguły selektywne
usuń konflikty infrastruktury
monitoruj efekty
Audyt zaczyna się od klasyfikacji treści, nie od botów
| Typ zasobu | Domyślna intencja |
|---|---|
| publiczny artykuł ekspercki | odnajdywalność i wykorzystanie |
| strona ofertowa | aktualna widoczność marki |
| publiczny raport | źródło referencyjne |
| panel klienta | brak publicznego dostępu |
| płatny raport | dostęp zgodny z modelem biznesowym |
| dane osobowe | ochrona techniczna |
Po zmianie robots.txt nie oceniaj efektu natychmiast
Plik może być cache’owany, a crawlery wracają według własnych harmonogramów.
Zmiana polityki → ponowne pobranie robots.txt → kolejny crawl → aktualizacja systemu → dopiero później obserwacja efektu.
Nie należy zatem wyciągać wniosków na podstawie pojedynczego testu kilka minut po wdrożeniu.
Jak mierzyć skutki zmiany polityki dostępu?
Crawl
Żądania, statusy HTTP, URL-e, transfer, WAF i cache.
AI Search
Wzmianki, cytowania, rekomendacje i poprawność informacji.
Efekt
Ruch referencyjny, leady, konwersje oraz koszt infrastruktury.
Model końcowy: polityka dostępu powinna odpowiadać celowi zasobu
Zasób → cel biznesowy → typ crawlera → reguła robots.txt → egzekwowanie infrastrukturalne → logi → efekt w AI Search.
Nie ma jednego poprawnego pliku robots.txt dla każdej firmy.
Sklep internetowy, serwis usługowy, wydawca płatnych raportów i baza dokumentacji mogą mieć zupełnie inne potrzeby.
Dobra polityka nie odpowiada więc na pytanie „czy pozwalam AI?”. Odpowiada na pytanie: który system może pobrać który zasób, w jakim celu i jakie konsekwencje biznesowe akceptujemy.
Dla marki budującej widoczność w AI Search najczęściej racjonalny jest model selektywny: pozostawić aktualne, publiczne i wiarygodne materiały dostępne dla mechanizmów wyszukiwania, osobno zdecydować o crawlerach treningowych, ograniczyć bezwartościową przestrzeń URL, a treści prywatne zabezpieczać rzeczywistym uwierzytelnieniem.
