Як написати robots.txt, який справді блокує AI-скрейперів

Незручна правда про robots.txt

Файл robots.txt — це не замок. Це табличка на дверях.

Це розрізнення важливе, коли команди запитують, чи можуть вони “заблокувати AI-скрейперів” одним невеликим текстовим файлом. Для авторитетних краулерів, які дотримуються Robots Exclusion Protocol, так: правильно написаний robots.txt може повідомити їм, що не слід сканувати ваші сторінки. Для невідомих скрейперів, імітаторів, браузерної автоматизації та ботів, яким просто байдуже, він сам по собі нічого не зробить.

Тож практична мета — не “зробити скрейпінг неможливим”. Вона така:

• Повідомити сумлінним AI-краулерам, щоб вони не використовували ваш сайт.
• Уникнути випадкового блокування пошукових систем або корисних сервісів.
• Додати сильніші серверні засоби контролю проти зловживань.
• Підтримувати політику в актуальному стані, коли назви краулерів змінюються.

Це нудна версія. Але саме вона працює.

Що robots.txt може і чого не може

Файл robots.txt розміщується в корені сайту:

https://example.com/robots.txt

Краулери запитують його перед скануванням. Файл містить групи правил. Кожна група починається з одного або кількох рядків User-agent, за якими йдуть директиви Allow або Disallow.

Просте блокування всього сайту виглядає так:

User-agent: GPTBot
Disallow: /

Це означає: якщо ти GPTBot, не скануй нічого на цьому сайті.

Але robots.txt має жорсткі обмеження:

1. Він добровільний. Недобросовісні учасники можуть його ігнорувати.
2. Він не забороняє запитувати URL звичайному браузеру або скрипту.
3. Він не видаляє контент, уже зібраний деінде.
4. Він сам по собі не визначає авторське право, ліцензування або права на навчання.
5. Його можна неправильно налаштувати так, що буде заблоковано не тих ботів.

Якщо вам потрібен справжній контроль доступу, використовуйте автентифікацію, авторизацію, обмеження швидкості, контроль на основі IP, керування ботами або юридичні механізми. Robots.txt усе ще корисний, але він має бути частиною ширшої стратегії захисту контенту.

Це схоже на інші проблеми вебурядування: видимий контроль рідко є всім контролем. Якщо у вашій організації вже є некероване внутрішнє використання ШІ, діє той самий принцип; швидкий аудит тіньового ШІ часто корисніший, ніж удавати, що один політичний документ вирішує проблему.

Почніть із рішення щодо політики

Перш ніж редагувати файл, вирішіть, що саме ви намагаєтеся заблокувати.

Є щонайменше чотири різні речі, які люди мають на увазі під “AI-скрейпером”:

• Краулери, які використовують для збирання навчальних даних.
• Краулери AI-пошуку або систем відповідей.
• Засоби отримання контенту, запущені користувачем, наприклад коли хтось просить AI-продукт підсумувати URL.
• Загальні скрейпери, що прикидаються звичайними браузерами.

Можливо, ви хочете заблокувати їх усіх. А можливо, хочете залишити пошукове виявлення, але відмовитися від навчання моделей. Це не одна й та сама політика.

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

Це розмежування важливе. Якщо необережно блокувати широкі user agents, можна зашкодити звичайній видимості в пошуку, намагаючись заблокувати навчання ШІ.

Розумний шаблон robots.txt для блокування AI

Ось консервативна відправна точка для блокування кількох поширених задокументованих AI-краулерів, залишаючи загальні пошукові краулери незаблокованими:

# 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: / означає “не сканувати жоден шлях”.
• User-agent: * застосовується до краулерів, які не збігаються з конкретнішою групою.
• Allow: / не є строго обов’язковим для групи за замовчуванням, але чітко показує ваш намір.
• Коментарі мають бути короткими. Деякі парсери поблажливі, але robots.txt має залишатися нудним.
• Не додавайте приватні URL до robots.txt. Файл публічний, і перелік чутливих шляхів може їх розрекламувати.

Останній пункт варто повторити. Robots.txt — не механізм секретності. Якщо /client-contracts/ не має бути публічним, захистіть його автентифікацією. Не обмежуйтеся лише disallow.

Будьте обережні з Google-Extended

Google-Extended часто розуміють неправильно. Це не те саме, що блокування Google Search.

Згідно з документацією Google, Google-Extended — це окремий продуктовий токен, який видавці можуть використовувати, щоб керувати тим, чи може контент сайту допомагати покращувати певні можливості Gemini та Vertex AI. Його блокування саме по собі не повинно блокувати сканування Googlebot для Search.

Водночас не замінюйте всі директиви Google широким блокуванням на кшталт цього, якщо ви справді не маєте цього на увазі:

User-agent: Googlebot
Disallow: /

Це повідомило б основному краулеру Google Search не сканувати ваш сайт. Для більшості публічних вебсайтів це не те, чого ви хочете.

Те саме розмежування працює й в інших місцях. Деякі постачальники відокремлюють краулери для навчання від користувацького перегляду або AI-пошукових краулерів. Інші — ні. Вам потрібно читати документацію щодо ботів, які для вас важливі, і ставитися до свого robots.txt як до живого файлу, а не одноразового прапорця.

Тестуйте файл як продакшн-код

Robots.txt виглядає простим, і саме тому його легко зламати.

Типові помилки:

• Завантажити його не туди, наприклад у /assets/robots.txt замість /robots.txt.
• Використати “розумні” лапки, скопійовані з редактора документів.
• Випадково заблокувати всіх краулерів через User-agent: * і Disallow: /.
• Припустити, що файл одного домену застосовується до іншого субдомену.
• Забути, що хости http://, https://, www і без www можуть оброблятися по-різному залежно від вашого налаштування.

Для сайтів із кількома доменами перевіряйте кожен канонічний хост. Файл robots за адресою https://www.example.com/robots.txt не керує автоматично https://app.example.com/robots.txt.

Під час налагодження перевіряйте фактичну HTTP-відповідь, а не лише те, що показує попередній перегляд у вашій CMS. Вам потрібна відповідь 200 OK, тип вмісту text/plain, якщо можливо, і саме той файл, якого ви очікуєте. Якщо задіяні редиректи, кешування або правила CDN, допомагає перевірка сирих заголовків. Робочий процес із налагодження редиректів і HTTP-заголовків у продакшні прямо застосовний і тут.

Додайте серверні засоби контролю для ботів, які ігнорують правила

Якщо краулер сумлінний, robots.txt — найчистіший сигнал. Якщо краулер зловживає, потрібне примусове застосування.

Практичні засоби контролю:

Обмеження швидкості

Задайте пороги для незвичних шаблонів запитів: забагато сторінок за хвилину, глибоке проходження пагінації, повторювані 404 або великий обсяг запитів із невеликого набору IP. Обмеження швидкості мають бути достатньо щедрими, щоб не карати реальних користувачів, і достатньо суворими, щоб зробити масове вилучення дорогим.

Фільтрація user-agent

Ви можете блокувати задокументовані user agents AI-краулерів на рівні вебсервера, reverse proxy, CDN або застосунку. Це сильніше за robots.txt, бо повертає фактичну відповідь із відмовою.

Наприклад, Nginx може блокувати шаблон user agent, хоча продакшн-правила слід ретельно тестувати:

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

Це не безвідмовно. Рядки user-agent легко підробити. Але це зупиняє чесний або лінивий трафік і зменшує навантаження.

Контроль IP та ASN

Деякі оператори публікують діапазони IP, але багато екосистем скрейперів цього не роблять. Блокування на основі IP може працювати для очевидних зловживань, особливо з діапазонів хмарного хостингу без нормального користувацького трафіку, але воно також може створювати хибні спрацьовування. Використовуйте логи перед правилами.

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

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

Мінімізація контенту

Іноді найкращий захист — архітектурний. Не відкривайте зайві API, великі JSON-навантаження, приховані метадані, чернеткові endpoints або повні архіви, якщо публічній сторінці потрібна лише невелика підмножина. Сайтам із великою кількістю зображень також варто подумати про те, які метадані вони публікують; логіка приватності з видалення EXIF-метаданих перед поширенням фотографій онлайн застосовна й до контентних операцій.

Використовуйте robots meta tags для правил на рівні сторінки

Robots.txt керує скануванням. Robots meta tags і заголовки X-Robots-Tag керують індексацією та поведінкою фрагментів для сумлінних пошукових систем і краулерів.

Наприклад:

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

Або як HTTP-заголовок:

X-Robots-Tag: noindex, noarchive

Це не спеціальні щити від ШІ. Вони корисні, коли ви хочете, щоб сторінка була доступною, але не індексувалася. Однак якщо ви блокуєте краулеру отримання сторінки в robots.txt, він може ніколи не побачити meta tag на рівні сторінки. Не покладайтеся на тег noindex на URL, який краулеру заборонено сканувати.

Приблизне правило:

• Використовуйте robots.txt, щоб зменшити або запобігти скануванню.
• Використовуйте meta robots або X-Robots-Tag, щоб керувати поведінкою індексації.
• Використовуйте серверні засоби контролю, щоб примусово застосовувати доступ.

Моніторте логи після публікації

Публікація файлу — лише перший крок. Після цього перевіряйте логи.

Шукайте:

• Запити до /robots.txt від user agents, які ви назвали.
• Продовження сканування після віддавання правил disallow.
• Підозрілі user agents із великим обсягом.
• Схожі на браузер user agents, які послідовно запитують тисячі сторінок.
• Повторний доступ до feeds, sitemaps, сторінок пошуку та пагінації.

Якщо бот запитує robots.txt, бачить повну заборону й потім зупиняється, robots.txt виконав свою роботу. Якщо він продовжує, перенесіть цього бота в примусове застосування: обмеження швидкості, блокування або автентифікацію.

Також перегляньте видимість вашого sitemap. Sitemaps корисні для пошукових систем, але вони також є зручними картами для скрейперів. Це не означає, що їх слід прибрати зі звичайних сайтів. Це означає, що не варто включати URL, які ви не хочете показувати публічним системам для виявлення.

Тримайте файл невеликим і перевіреним

Robots.txt має властивість застарівати. Маркетингова команда додає мікросайт кампанії. Розробник додає шлях для staging. Постачальник змінює назву свого краулера. Через два роки ніхто не знає, навіщо існує половина правил.

Ставтеся до нього як до конфігурації:

• Зберігайте його в системі контролю версій, коли це можливо.
• Додавайте короткий коментар для кожної групи AI-краулерів.
• Переглядайте його щоквартально.
• Перевіряйте документацію постачальників перед додаванням широких правил.
• Тестуйте після змін у CDN, CMS або хостингу.

Якщо ваш сайт публікує контент за допомогою ШІ, також відокремлюйте політику щодо краулерів від редакційної прозорості. Блокування AI-скрейперів стосується доступу й повторного використання. Розкриття стосується довіри читачів. Етично вони перетинаються, але це не один і той самий контроль. Практичний підхід до розкриття описано в матеріалі як виглядає чесне розкриття використання ШІ на невеликому вебсайті.

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

💡 Спробуйте це: Після додавання правил для AI-краулерів перевірте синтаксис за допомогою Robots.txt Tester, щоб випадково не заблокувати й легітимних ботів.

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

Підсумок

Хороший файл robots.txt заблокує сумлінних AI-краулерів. Він не зупинить наполегливий скрейпінг, скопійовані рядки user-agent, скомпрометовані браузери або людей, які вручну вставляють ваш контент в AI-системи.

Це не робить його марним. Це робить його одним шаром.

Пишіть явні правила для задокументованих AI-краулерів. Уникайте широких блокувань, які шкодять видимості в пошуку. Тестуйте відданий файл, а не чернетку. Стежте за логами. Застосовуйте серверні засоби контролю там, де поведінка переходить від небажаної до зловживальної.

Веб завжди працював на поєднанні протоколів, норм і примусового застосування. Robots.txt — це шар норм. Використовуйте його, але не плутайте зі стіною.