Jak napisać robots.txt, który naprawdę blokuje scrapery AI

Niewygodna prawda o robots.txt

Plik robots.txt nie jest zamkiem. Jest tabliczką na drzwiach.

Ta różnica ma znaczenie, gdy zespoły pytają, czy mogą „zablokować scrapery AI” jednym małym plikiem tekstowym. W przypadku renomowanych crawlerów, które przestrzegają Robots Exclusion Protocol, tak: poprawnie napisany robots.txt może powiedzieć im, aby nie crawlowaly Twoich stron. W przypadku nieznanych scraperów, podszywających się botów, automatyzacji przeglądarki i botów, którym po prostu na tym nie zależy, sam w sobie nie zrobi nic.

Praktyczny cel nie brzmi więc: „uniemożliwić scraping”. Brzmi on:

• Powiedzieć zgodnym crawlerom AI, aby nie używały Twojej witryny.
• Uniknąć przypadkowego blokowania wyszukiwarek lub użytecznych usług.
• Dodać silniejsze kontrole po stronie serwera dla nadużyć.
• Utrzymywać politykę w stanie łatwym do zarządzania, gdy nazwy crawlerów się zmieniają.

To jest nudna wersja. To także wersja, która działa.

Co robots.txt może, a czego nie może zrobić

Plik robots.txt znajduje się w katalogu głównym witryny:

https://example.com/robots.txt

Crawlery pobierają go przed crawlowaniem. Plik zawiera grupy reguł. Każda grupa zaczyna się od jednej lub więcej linii User-agent, po których następują dyrektywy Allow lub Disallow.

Prosta blokada całej witryny wygląda tak:

User-agent: GPTBot
Disallow: /

Oznacza to: jeśli jesteś GPTBot, nie crawluy niczego w tej witrynie.

Ale robots.txt ma twarde ograniczenia:

1. Jest dobrowolny. Źli aktorzy mogą go zignorować.
2. Nie uniemożliwia zażądania adresu URL przez zwykłą przeglądarkę lub skrypt.
3. Nie usuwa treści już zebranych gdzie indziej.
4. Sam w sobie nie definiuje praw autorskich, licencjonowania ani praw do treningu.
5. Może zostać błędnie skonfigurowany w sposób, który zablokuje niewłaściwe boty.

Jeśli potrzebujesz rzeczywistej kontroli dostępu, użyj uwierzytelniania, autoryzacji, limitowania żądań, kontroli opartych na IP, zarządzania botami lub środków prawnych. Robots.txt nadal jest przydatny, ale należy do szerszej strategii ochrony treści.

To podobne do innych problemów zarządzania w sieci: widoczna kontrola rzadko jest całą kontrolą. Jeśli Twoja organizacja już ma wewnętrznie niezarządzane użycie AI, obowiązuje ta sama zasada; szybki audyt shadow AI jest często bardziej użyteczny niż udawanie, że jeden dokument z polityką rozwiązuje problem.

Zacznij od decyzji polityki

Zanim zaczniesz edytować plik, zdecyduj, co właściwie próbujesz zablokować.

Istnieją co najmniej cztery różne rzeczy, które ludzie mają na myśli, mówiąc „scraper AI”:

• Crawlery używane do zbierania danych treningowych.
• Crawlery wyszukiwania AI lub silników odpowiedzi.
• Fetchery uruchamiane przez użytkownika, na przykład gdy ktoś prosi produkt AI o streszczenie adresu URL.
• Ogólne scrapery udające zwykłe przeglądarki.

Możesz chcieć zablokować je wszystkie. Możesz też chcieć zachować odkrywanie w wyszukiwarce, jednocześnie rezygnując z treningu modeli. To nie jest ta sama polityka.

Na przykład OpenAI dokumentuje osobne user agenty do różnych celów, w tym GPTBot, ChatGPT-User i OAI-SearchBot. Google używa Google-Extended jako tokenu kontrolnego dla niektórych zastosowań Gemini i Vertex AI, podczas gdy zwykłe crawlowanie Google Search obsługują inne user agenty Googlebot.

To rozróżnienie jest ważne. Jeśli nieostrożnie zablokujesz szerokie user agenty, możesz zaszkodzić zwykłej widoczności w wyszukiwarkach, próbując zablokować trening AI.

Rozsądny szablon robots.txt blokujący AI

Oto konserwatywny punkt wyjścia do blokowania kilku powszechnie udokumentowanych crawlerów związanych z AI przy jednoczesnym pozostawieniu ogólnych crawlerów wyszukiwarek bez zmian:

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

To nie jest magiczna, uniwersalna lista. To wzorzec łatwy do utrzymania.

Kilka uwag:

• Disallow: / oznacza „nie crawluy żadnej ścieżki”.
• User-agent: * dotyczy crawlerów, które nie pasują do bardziej szczegółowej grupy.
• Allow: / nie jest bezwzględnie wymagane dla grupy domyślnej, ale jasno pokazuje intencję.
• Komentarze powinny być krótkie. Niektóre parsery są wyrozumiałe, ale robots.txt powinien pozostać nudny.
• Nie umieszczaj prywatnych adresów URL w robots.txt. Plik jest publiczny, a wypisanie wrażliwych ścieżek może je reklamować.

Ostatni punkt warto powtórzyć. Robots.txt nie jest mechanizmem utajniania. Jeśli /client-contracts/ nie powinno być publiczne, zabezpiecz to uwierzytelnianiem. Nie poprzestawaj na dyrektywie disallow.

Uważaj na Google-Extended

Google-Extended jest często źle rozumiany. To nie to samo co blokowanie Google Search.

Zgodnie z dokumentacją Google, Google-Extended jest samodzielnym tokenem produktu, którego wydawcy mogą używać do zarządzania tym, czy treść witryny może pomagać ulepszać wybrane możliwości Gemini i Vertex AI. Zablokowanie go samo w sobie nie powinno blokować Googlebot przed crawlowaniem na potrzeby Search.

Mimo to nie zastępuj wszystkich dyrektyw Google szeroką blokadą taką jak ta, chyba że naprawdę o to Ci chodzi:

User-agent: Googlebot
Disallow: /

To powiedziałoby głównemu crawlerowi Google Search, aby nie crawlowal Twojej witryny. W przypadku większości publicznych stron internetowych nie jest to to, czego chcesz.

To samo rozróżnienie występuje gdzie indziej. Niektórzy dostawcy oddzielają crawlery treningowe od przeglądania uruchamianego przez użytkownika lub crawlerów wyszukiwania AI. Inni tego nie robią. Musisz czytać dokumentację botów, na których Ci zależy, i traktować swój robots.txt jako żywy plik, a nie jednorazowe pole do odhaczenia.

Testuj plik jak kod produkcyjny

Robots.txt wygląda prosto i właśnie dlatego łatwo go zepsuć.

Typowe błędy obejmują:

• Wgranie go w niewłaściwe miejsce, na przykład do /assets/robots.txt zamiast /robots.txt.
• Użycie inteligentnych cudzysłowów skopiowanych z edytora dokumentów.
• Przypadkowe zablokowanie wszystkich crawlerów przez User-agent: * i Disallow: /.
• Założenie, że plik jednej domeny dotyczy innej subdomeny.
• Zapomnienie, że hosty http://, https://, www i bez www mogą być obsługiwane inaczej w zależności od konfiguracji.

W przypadku witryn wielodomenowych sprawdź każdy host kanoniczny. Plik robots pod adresem https://www.example.com/robots.txt nie zarządza automatycznie https://app.example.com/robots.txt.

Podczas debugowania sprawdzaj rzeczywistą odpowiedź HTTP, a nie tylko to, co pokazuje podgląd CMS. Chcesz zobaczyć odpowiedź 200 OK, typ treści text/plain, jeśli to możliwe, oraz dokładnie ten plik, którego oczekujesz. Jeśli w grę wchodzą przekierowania, cache lub reguły CDN, pomaga bezpośrednia inspekcja nagłówków. Workflow z artykułu o debugowaniu przekierowań i nagłówków HTTP na produkcji ma tu bezpośrednie zastosowanie.

Dodaj kontrole po stronie serwera dla botów, które ignorują reguły

Jeśli crawler jest zgodny, robots.txt jest najczystszym sygnałem. Jeśli crawler jest nadużywający, potrzebujesz egzekwowania.

Praktyczne kontrole obejmują:

Limitowanie żądań

Ustal progi dla nietypowych wzorców żądań: zbyt wiele stron na minutę, głębokie przechodzenie przez paginację, powtarzające się 404 lub duży wolumen żądań z małego zestawu adresów IP. Limity powinny być na tyle hojne, by nie karać prawdziwych użytkowników, i na tyle restrykcyjne, by masowe pozyskiwanie danych było kosztowne.

Filtrowanie user-agentów

Możesz blokować udokumentowane user agenty crawlerów AI na poziomie serwera WWW, reverse proxy, CDN lub warstwy aplikacji. To silniejsze niż robots.txt, ponieważ zwraca rzeczywistą odpowiedź odmowy.

Na przykład Nginx może zablokować wzorzec user agenta, choć reguły produkcyjne należy testować ostrożnie:

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

To nie jest niezawodne. Ciągi user-agent łatwo podrobić. Ale zatrzymuje uczciwy lub leniwy ruch i zmniejsza obciążenie.

Kontrole IP i ASN

Niektórzy operatorzy publikują zakresy IP, ale wiele ekosystemów scraperów tego nie robi. Blokowanie oparte na IP może działać przy oczywistych nadużyciach, zwłaszcza z zakresów hostingu chmurowego bez normalnego ruchu użytkowników, ale może też powodować fałszywe trafienia. Użyj logów przed regułami.

Uwierzytelnianie i paywalle

Jeśli treści nie wolno kopiować na dużą skalę, nie umieszczaj pełnej treści pod publicznym adresem URL. Robots.txt nie nadaje się do materiałów poufnych, licencjonowanych baz danych, prywatnych społeczności ani płatnych archiwów.

Minimalizacja treści

Czasem najlepszą ochroną jest architektura. Nie udostępniaj niepotrzebnych API, dużych payloadów JSON, ukrytych metadanych, endpointów roboczych ani pełnych archiwów, jeśli publiczna strona potrzebuje tylko małego podzbioru. Witryny bogate w obrazy powinny też zastanowić się, jakie metadane publikują; logika prywatności z usuwania metadanych EXIF przed udostępnianiem zdjęć online ma zastosowanie również w operacjach na treści.

Używaj tagów robots meta dla reguł na poziomie strony

Robots.txt kontroluje crawlowanie. Tagi robots meta i nagłówki X-Robots-Tag kontrolują indeksowanie oraz zachowanie snippetów dla zgodnych wyszukiwarek i crawlerów.

Na przykład:

<meta name="robots" content="noindex, noarchive">

Albo jako nagłówek HTTP:

X-Robots-Tag: noindex, noarchive

To nie są tarcze specyficzne dla AI. Są przydatne, gdy chcesz, aby strona była dostępna, ale nieindeksowana. Jeśli jednak zablokujesz crawlerowi pobranie strony w robots.txt, może on nigdy nie zobaczyć tagu meta na poziomie strony. Nie polegaj na tagu noindex pod adresem URL, którego crawlerowi nie wolno crawlowac.

Przybliżona zasada:

• Używaj robots.txt, aby ograniczyć lub zapobiec crawlowaniu.
• Używaj meta robots lub X-Robots-Tag, aby kontrolować zachowanie indeksowania.
• Używaj kontroli po stronie serwera, aby egzekwować dostęp.

Monitoruj logi po publikacji

Opublikowanie pliku to dopiero pierwszy krok. Potem sprawdzaj logi.

Szukaj:

• Żądań do /robots.txt od user agentów, które wskazałeś.
• Dalszego crawlowania po podaniu reguł disallow.
• Podejrzanych user agentów o dużym wolumenie.
• User agentów podobnych do przeglądarek, które żądają tysięcy stron w sekwencji.
• Powtarzającego się dostępu do feedów, sitemap, stron wyszukiwania i paginacji.

Jeśli bot zażąda robots.txt, zobaczy pełne disallow, a potem się zatrzyma, robots.txt wykonał swoje zadanie. Jeśli kontynuuje, przenieś tego bota do egzekwowania: limity żądań, blokady lub uwierzytelnianie.

Sprawdź także ekspozycję sitemap. Sitemapy są użyteczne dla wyszukiwarek, ale są też wygodnymi mapami dla scraperów. To nie znaczy, że należy usuwać je ze zwykłych witryn. Oznacza to, że nie należy umieszczać w nich adresów URL, których nie chcesz udostępniać publicznym systemom do odkrywania.

Utrzymuj plik mały i przeglądany

Robots.txt ma tendencję do starzenia się. Zespół marketingu dodaje mikrowitrynę kampanii. Deweloper dodaje ścieżkę stagingową. Dostawca zmienia nazwę crawlera. Dwa lata później nikt nie wie, dlaczego istnieje połowa reguł.

Traktuj go jak konfigurację:

• Przechowuj go w kontroli wersji, gdy to możliwe.
• Dodaj krótki komentarz dla każdej grupy crawlerów AI.
• Przeglądaj go kwartalnie.
• Sprawdzaj dokumentację dostawców przed dodaniem szerokich reguł.
• Testuj po zmianach CDN, CMS lub hostingu.

Jeśli Twoja witryna publikuje treści wspomagane przez AI, oddziel też politykę crawlerów od transparentności redakcyjnej. Blokowanie scraperów AI dotyczy dostępu i ponownego użycia. Ujawnianie dotyczy zaufania czytelników. Etycznie się nakładają, ale nie są tą samą kontrolą. Praktyczne podejście do ujawniania opisuje artykuł jak wygląda uczciwe ujawnianie użycia AI na małej stronie internetowej.

<!-- tool-cta:start -->

💡 Wypróbuj to: Po dodaniu reguł dla crawlerów AI potwierdź składnię za pomocą Robots.txt Tester, aby przypadkowo nie zablokować także legalnych botów.

<!-- tool-cta:end -->

Najważniejszy wniosek

Dobry plik robots.txt zablokuje zgodne crawlery AI. Nie zatrzyma zdeterminowanego scrapingu, skopiowanych ciągów user-agent, przejętych przeglądarek ani ludzi ręcznie wklejających Twoje treści do systemów AI.

To nie czyni go bezużytecznym. Czyni go jedną warstwą.

Napisz jawne reguły dla udokumentowanych crawlerów AI. Unikaj szerokich blokad, które szkodzą widoczności w wyszukiwarkach. Testuj serwowany plik, nie wersję roboczą. Obserwuj logi. Egzekwuj kontrolami po stronie serwera tam, gdzie zachowanie przechodzi z niechcianego w nadużywające.

Sieć zawsze działała jako mieszanka protokołu, norm i egzekwowania. Robots.txt jest warstwą norm. Używaj go, ale nie myl go ze ścianą.