Как да напишете robots.txt, който наистина блокира AI скрейпъри

Неудобната истина за robots.txt

Файлът robots.txt не е ключалка. Той е табела на вратата.

Това разграничение е важно, когато екипи питат дали могат да „блокират AI скрейпъри“ с един малък текстов файл. За надеждни crawler-и, които следват Robots Exclusion Protocol, да: правилно написан robots.txt може да им каже да не обхождат страниците ви. За неизвестни скрейпъри, имитатори, браузърна автоматизация и ботове, на които просто не им пука, сам по себе си той няма да направи нищо.

Затова практическата цел не е „да направим scraping-а невъзможен“. Тя е:

• Да кажете на спазващите правилата AI crawler-и да не използват сайта ви.
• Да избегнете случайно блокиране на търсачки или полезни услуги.
• Да добавите по-силни сървърни контроли срещу злоупотреби.
• Да поддържате политиката управляема, докато имената на crawler-ите се променят.

Това е скучната версия. Тя е и версията, която работи.

Какво може и какво не може robots.txt

Файлът robots.txt се намира в корена на сайта:

https://example.com/robots.txt

Crawler-ите го заявяват, преди да започнат обхождане. Файлът съдържа групи от правила. Всяка група започва с един или повече редове User-agent, последвани от директиви Allow или Disallow.

Просто блокиране на целия сайт изглежда така:

User-agent: GPTBot
Disallow: /

Това означава: ако си GPTBot, не обхождай нищо в този сайт.

Но robots.txt има сериозни ограничения:

1. Той е доброволен. Недобросъвестни участници могат да го игнорират.
2. Той не пречи даден URL да бъде заявен от нормален браузър или скрипт.
3. Той не премахва съдържание, което вече е събрано другаде.
4. Сам по себе си той не определя авторски права, лицензиране или права за обучение.
5. Може да бъде конфигуриран погрешно по начин, който блокира неправилните ботове.

Ако ви е нужен реален контрол на достъпа, използвайте автентикация, авторизация, rate limiting, IP-базирани контроли, bot management или правни механизми. Robots.txt все още е полезен, но мястото му е в по-широка стратегия за защита на съдържанието.

Това напомня на други проблеми в управлението на уеба: видимият контрол рядко е целият контрол. Ако организацията ви вече има неуправлявана вътрешна употреба на AI, важи същият принцип; бърз одит на shadow AI често е по-полезен от преструването, че един-единствен документ с политика решава проблема.

Започнете с решението за политиката

Преди да редактирате файла, решете какво всъщност се опитвате да блокирате.

Има поне четири различни неща, които хората имат предвид под „AI scraper“:

• Crawler-и, използвани за събиране на данни за обучение.
• AI търсачки или crawler-и на answer engines.
• Fetcher-и, задействани от потребителя, например когато някой поиска от AI продукт да обобщи URL.
• Общи скрейпъри, които се представят за обикновени браузъри.

Може да искате да блокирате всички тях. Или може да искате откриваемост в търсенето, като същевременно отказвате участие в обучение на модели. Това не са еднакви политики.

Например OpenAI документира отделни user agents за различни цели, включително GPTBot, ChatGPT-User и OAI-SearchBot. Google използва Google-Extended като контролен token за някои случаи на употреба на Gemini и Vertex AI, докато нормалното обхождане за Google Search се извършва от други Googlebot user agents.

Това разделение е важно. Ако блокирате широки user agents небрежно, можете да навредите на обикновената видимост в търсенето, докато се опитвате да блокирате AI обучение.

Разумен robots.txt шаблон за блокиране на AI

Ето консервативна начална точка за блокиране на няколко често документирани AI-свързани crawler-а, като оставите общите crawler-и на търсачките незасегнати:

# 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: /

Това не е магически универсален списък. Това е поддържаем модел.

Няколко бележки:

• Disallow: / означава „не обхождай нито един path“.
• User-agent: * се прилага за crawler-и, които не съвпадат с по-специфична група.
• Allow: / не е строго задължително за групата по подразбиране, но прави намерението ви ясно.
• Дръжте коментарите кратки. Някои parser-и са снизходителни, но robots.txt трябва да остане скучен.
• Не включвайте частни URL адреси в robots.txt. Файлът е публичен и изброяването на чувствителни path-ове може да ги рекламира.

Последната точка си заслужава да се повтори. Robots.txt не е механизъм за секретност. Ако /client-contracts/ не трябва да е публичен, защитете го с автентикация. Не го забранявайте само с disallow.

Внимавайте с Google-Extended

Google-Extended често се разбира погрешно. Той не е същото като блокиране на Google Search.

Според документацията на Google Google-Extended е самостоятелен продуктов token, който издателите могат да използват, за да управляват дали съдържанието на сайта може да помага за подобряване на определени възможности на Gemini и Vertex AI. Блокирането му само по себе си не би трябвало да блокира Googlebot от обхождане за Search.

Въпреки това не заменяйте всички Google директиви с широко блокиране като това, освен ако наистина го имате предвид:

User-agent: Googlebot
Disallow: /

Това би казало на основния crawler на Google Search да не обхожда сайта ви. За повечето публични уебсайтове това не е желаното поведение.

Същото разграничение важи и другаде. Някои доставчици разделят crawler-и за обучение от задействано от потребител сърфиране или AI search crawler-и. Други не го правят. Трябва да прочетете документацията за ботовете, които ви интересуват, и да третирате своя robots.txt като жив файл, а не като еднократна отметка.

Тествайте файла като production code

Robots.txt изглежда прост, което е причината да е лесно да бъде счупен.

Чести грешки включват:

• Качването му на грешно място, например /assets/robots.txt вместо /robots.txt.
• Използването на „умни“ кавички, копирани от редактор на документи.
• Случайно блокиране на всички crawler-и с User-agent: * и Disallow: /.
• Предположението, че файлът на един домейн важи за друг subdomain.
• Забравянето, че http://, https://, www и хостове без www може да се обработват различно в зависимост от настройката ви.

За сайтове с множество домейни проверете всеки canonical host. Robots файл на https://www.example.com/robots.txt не управлява автоматично https://app.example.com/robots.txt.

При debugging проверявайте действителния HTTP response, не само това, което показва preview-то на CMS-а. Искате response 200 OK, content type text/plain, ако е възможно, и точния файл, който очаквате. Ако има redirects, caching или CDN правила, raw header inspection помага. Работният процес в debugging на redirects и HTTP headers в production се прилага директно тук.

Добавете сървърни контроли за ботове, които игнорират правилата

Ако crawler-ът спазва правилата, robots.txt е най-чистият сигнал. Ако crawler-ът злоупотребява, ви трябва enforcement.

Практически контроли включват:

Rate limiting

Задайте прагове за необичайни модели на заявки: твърде много страници в минута, дълбоко преминаване през pagination, повтарящи се 404-и или висок обем заявки от малък набор IP адреси. Rate limits трябва да са достатъчно щедри, за да не наказват реални потребители, и достатъчно строги, за да направят масовото извличане скъпо.

Филтриране по user-agent

Можете да блокирате документирани user agents на AI crawler-и на ниво web server, reverse proxy, CDN или application layer. Това е по-силно от robots.txt, защото връща реален denial response.

Например Nginx може да блокира user agent pattern, макар че production правилата трябва да се тестват внимателно:

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

Това не е безотказно. User-agent strings се фалшифицират лесно. Но спира честния или мързелив трафик и намалява натоварването.

IP и ASN контроли

Някои оператори публикуват IP ranges, но много scraper екосистеми не го правят. IP-базираното блокиране може да работи при очевидна злоупотреба, особено от cloud hosting ranges без нормален потребителски трафик, но може да създаде и false positives. Използвайте logs преди rules.

Автентикация и paywalls

Ако съдържанието не трябва да се копира в мащаб, не поставяйте пълното съдържание на публичен URL. Robots.txt е неподходящ за конфиденциални материали, лицензирани бази данни, частни общности или платени архиви.

Минимизиране на съдържанието

Понякога най-добрата защита е архитектурна. Не излагайте ненужни APIs, големи JSON payloads, скрити metadata, draft endpoints или пълни архиви, ако публичната страница се нуждае само от малко подмножество. Сайтовете с много изображения също трябва да обмислят какви metadata публикуват; логиката за поверителност в премахването на EXIF metadata преди споделяне на снимки онлайн важи и за content operations.

Използвайте robots meta tags за правила на ниво страница

Robots.txt контролира обхождането. Robots meta tags и X-Robots-Tag headers контролират индексирането и snippet поведението за спазващи правилата търсачки и crawler-и.

Например:

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

Или като HTTP header:

X-Robots-Tag: noindex, noarchive

Това не са AI-специфични щитове. Те са полезни, когато искате дадена страница да е достъпна, но да не се индексира. Ако обаче блокирате crawler да изтегли страница в robots.txt, той може никога да не види meta tag-а на ниво страница. Не разчитайте на noindex tag върху URL, който на crawler-а е забранено да обхожда.

Грубото правило:

• Използвайте robots.txt, за да намалите или предотвратите обхождането.
• Използвайте meta robots или X-Robots-Tag, за да контролирате поведението при индексиране.
• Използвайте сървърни контроли, за да наложите достъп.

Следете logs след публикуване

Публикуването на файла е само първата стъпка. След това проверете logs.

Търсете:

• Заявки към /robots.txt от user agents, които сте посочили.
• Продължаващо обхождане, след като са поднесени disallow rules.
• Подозрителни user agents с висок обем.
• User agents, приличащи на браузъри, които заявяват хиляди страници последователно.
• Повтарящ се достъп до feeds, sitemaps, search pages и pagination.

Ако бот заяви robots.txt, види пълен disallow и след това спре, robots.txt си е свършил работата. Ако продължи, преместете този бот към enforcement: rate limits, blocks или authentication.

Прегледайте и exposure-а на sitemap-овете си. Sitemaps са полезни за търсачки, но са и удобни карти за скрейпъри. Това не означава, че трябва да ги премахнете от обикновени сайтове. Означава, че не трябва да включвате URL адреси, които не искате публични системи да откриват.

Дръжте файла малък и преглеждан

Robots.txt има склонност да остарява. Маркетинг екип добавя campaign microsite. Developer добавя staging path. Vendor променя името на crawler-а си. Две години по-късно никой не знае защо съществува половината от правилата.

Третирайте го като configuration:

• Съхранявайте го във version control, когато е възможно.
• Добавете кратък коментар за всяка група AI crawler-и.
• Преглеждайте го на тримесечие.
• Проверявайте документацията на vendor-а, преди да добавяте широки rules.
• Тествайте след промени в CDN, CMS или hosting.

Ако сайтът ви публикува AI-assisted content, отделете crawler policy от editorial transparency. Блокирането на AI скрейпъри е въпрос на достъп и повторна употреба. Disclosure е въпрос на доверие на читателя. Те се припокриват етично, но не са един и същ контрол. Практически подход към disclosure е разгледан в как изглежда честното AI disclosure в малък уебсайт.

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

💡 Опитайте това: След като добавите правила за AI обхождащи ботове, потвърдете синтаксиса с Robots.txt Tester, за да не блокирате случайно и легитимни ботове.

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

Изводът

Добър файл robots.txt ще блокира спазващите правилата AI crawler-и. Той няма да спре решителен scraping, копирани user-agent strings, компрометирани браузъри или хора, които ръчно поставят съдържанието ви в AI системи.

Това не го прави безполезен. Прави го един слой.

Напишете ясни правила за документирани AI crawler-и. Избягвайте широки блокирания, които вредят на видимостта в търсенето. Тествайте поднесения файл, не черновата. Следете logs. Налагайте със сървърни контроли там, където поведението преминава от нежелано в злоупотребяващо.

Уебът винаги е работил чрез комбинация от протокол, норми и enforcement. Robots.txt е слоят на нормите. Използвайте го, но не го бъркайте със стена.