Jak sprawdzić, czy crawler AI respektuje robots.txt i zastrzeżenie TDM?

1. Zdefiniuj test dla tokenu, ścieżki i czasu

Pytanie „czy crawler respektuje robots.txt?” jest zbyt szerokie. Test powinien wskazywać konkretny host, token User-Agent, URL lub klasę ścieżek, regułę oraz przedział czasu, w którym ta wersja polityki obowiązywała.

Osobno oceniaj automatyczne crawlery wyszukiwania, crawlery związane z rozwojem modeli i fetchery uruchamiane na żądanie użytkownika. Dostawcy opisują te klienty oddzielnie, a pobrania inicjowane przez użytkownika mogą nie podlegać regułom robots.txt w taki sam sposób jak automatyczny crawl.

• host i publiczny adres /robots.txt
• token klienta i jego deklarowany cel
• testowany URL oraz oczekiwana decyzja Allow lub Disallow
• wersja polityki i czas, od którego była publicznie dostępna

2. Zachowaj wersję opublikowanej polityki

Pobierz /robots.txt z tego samego hosta, którego dotyczy test, i zapisz treść, kod HTTP, typ odpowiedzi oraz czas obserwacji. Reguły domeny głównej nie opisują automatycznie subdomen, a odpowiedź błędu może być interpretowana inaczej niż prawidłowy plik.

Jeżeli organizacja publikuje odrębne zastrzeżenie TDM, zachowaj także jego treść, miejsce publikacji, właściciela decyzji i datę obowiązywania. Nie zakładaj, że każdy techniczny sygnał ma identyczny zakres lub skutek.

3. Oddziel deklarowany User-Agent od potwierdzonej tożsamości

Nagłówek User-Agent może zostać skopiowany przez dowolnego klienta. Traktuj go jako deklarację. Następnie porównaj adres źródłowy z aktualnym oficjalnym zakresem dostawcy, jeśli taki zakres został opublikowany, albo zastosuj wskazaną przez dostawcę procedurę weryfikacji.

OpenAI, Anthropic i Perplexity publikują źródła adresów dla wskazanych klientów. Google opisuje zarówno listy adresów, jak i ręczną procedurę reverse DNS zakończoną ponownym sprawdzeniem forward DNS. Brak zgodności nie dowodzi, kto faktycznie wysłał żądanie — uzasadnia status „identity unverified”.

Jeżeli klient udostępnia zewnętrzny mechanizm podpisanego lub kryptograficznie potwierdzonego żądania, wynik jego weryfikacji może być dodatkowym dowodem tożsamości. Nawet poprawnie zweryfikowana tożsamość nie dowodzi jednak celu pobrania, respektowania konkretnej reguły, upoważnienia do użycia treści ani zgodności prawnej. Ten materiał nie oznacza, że Bot Protection obecnie weryfikuje takie podpisy.

• zapisz surowy User-Agent i adres widziany po prawidłowym odtworzeniu łańcucha proxy
• zapisz źródło oraz czas pobrania oficjalnej listy adresów
• sprawdź, czy token i zakres sieciowy dotyczą tej samej klasy klienta
• nie przypisuj operatora wyłącznie na podstawie nazwy w nagłówku

Web Bot Auth jako sygnał tożsamości, nie zgodności

4. Oblicz oczekiwaną decyzję według robots.txt

Dopasuj grupę User-Agent i regułę dla testowanej ścieżki zgodnie z RFC 9309. Uwzględnij najbardziej szczegółowe dopasowanie ścieżki, składnię znaków specjalnych oraz fakt, że reguły odnoszą się do adresów URL w obrębie konkretnego hosta.

Dla każdego zdarzenia zapisz nie tylko wynik Allow lub Disallow, ale także token, grupę i konkretną regułę, które doprowadziły do tej decyzji. Ułatwia to późniejszy przegląd parsera i zmian konfiguracji.

5. Porównaj politykę z żądaniami po jej publikacji

W access logach wyszukaj żądania testowanego klienta do /robots.txt oraz do właściwych zasobów. Samo pobranie pliku nie potwierdza, że reguła została zastosowana, a brak późniejszych żądań nie dowodzi respektowania polityki — crawler mógł po prostu nie planować wizyty.

Jeżeli po udostępnieniu i czasie potrzebnym na odczyt nowej wersji widzisz potwierdzone żądania do ścieżki objętej Disallow, oznacz je do przeglądu. Sprawdź cache, host, moment zmiany, przekierowania i to, czy obserwowany klient jest automatycznym crawlerem, a nie fetcherem użytkownika.

6. Stosuj statusy, które pokazują poziom dowodu

Status powinien opisywać obserwację techniczną, nie intencję ani zgodność prawną podmiotu. Warto rozdzielić ocenę tożsamości, dopasowanie polityki i zachowanie widoczne w logach.

• consistent with policy — nie zaobserwowano sprzecznego żądania w określonym zakresie
• observed policy conflict — zaobserwowano żądanie sprzeczne z dopasowaną regułą
• identity unverified — deklaracja klienta nie została potwierdzona dostępną metodą
• insufficient data — brakuje wersji polityki, logów albo wystarczającego okresu obserwacji
• not applicable — rodzaj pobrania nie jest według dokumentacji automatycznym crawlem objętym testem
• manual review — zdarzenie wymaga oceny technicznej lub prawnej poza automatycznym statusem

7. Zapisz odtwarzalny rekord dowodowy

Rekord powinien rozdzielać pola zaobserwowane, źródła weryfikacji i wnioski. Adres 192.0.2.44 w poniższym przykładzie należy do puli dokumentacyjnej — nie przedstawia rzeczywistego crawlera ani incydentu.

{
  "observedAt": "2026-08-24T08:41:12Z",
  "host": "example.com",
  "requestUrl": "/archiwum-premium/raport",
  "sourceIp": "192.0.2.44",
  "userAgentToken": "ExampleAI-Bot",
  "identityStatus": "unverified",
  "policyVersion": "robots-2026-08-24-01",
  "matchedRule": "Disallow: /archiwum-premium/",
  "expectedAction": "do-not-crawl",
  "httpStatus": 403,
  "conformanceStatus": "manual-review",
  "confidence": "low"
}

8. Oddziel conformance robots.txt od oceny zastrzeżenia TDM

robots.txt odpowiada na techniczne pytanie o reguły dostępu automatycznych klientów. Zastrzeżenie TDM wynika z odrębnego kontekstu prawa autorskiego, statusu uprawnionego, rodzaju treści i sposobu sformułowania zastrzeżenia. Te warstwy mogą korzystać ze wspólnych dowodów, ale nie są tym samym testem.

Żądanie sprzeczne z Disallow można opisać jako zaobserwowany konflikt z polityką. Nie dowodzi ono samo w sobie wykorzystania treści do treningu, naruszenia praw autorskich ani odpowiedzialności wskazanego podmiotu. Takie wnioski wymagają dodatkowych danych i właściwej oceny prawnej.

Sprawdź, kiedy polityka crawlera może mieć znaczenie dla RODO