Контроль AI-краулерів стає частиною SEO: що змінив Cloudflare і як власникам сайтів захистити свій контент

Штучний інтелект змінює не лише пошукову видачу, створення контенту чи роботу інтернет-магазинів. Він поступово змінює саму архітектуру відкритого Інтернету — зокрема правила, за якими автоматизовані системи отримують доступ до сайтів.

Раніше відносини між власниками сайтів і пошуковими системами були досить зрозумілими: пошуковий робот сканував сторінки, додавав їх до індексу, а потім пошукова система повертала на сайт відвідувачів.

Сайт віддавав контент — пошуковик віддавав трафік.

Сьогодні ця модель перестає бути універсальною. AI-сервіси можуть прочитати сторінку, використати її інформацію для формування готової відповіді та практично не привести користувача на першоджерело.

Редакція Sitezilla ознайомилася з матеріалом Cloudflare «Your site, your rules: new AI traffic options for all customers», опублікованим 1 липня 2026 року. У ньому компанія пропонує перейти від примітивного поділу «AI-бот або не AI-бот» до більш точного контролю, заснованого на тому, що саме автоматизована система робить із контентом сайту.

Розбираємо, що саме змінилося, чому керування AI-краулерами поступово стає частиною SEO та яку політику доступу до контенту варто використовувати власникам інтернет-магазинів, корпоративних сайтів і контентних проєктів.

Старий обмін «контент в обмін на трафік» більше не працює як раніше

Протягом десятиліть власники сайтів фактично погоджувалися на неформальний обмін:

1. пошуковий робот отримує доступ до сторінок;

2. пошукова система індексує інформацію;

3. користувач бачить сторінку в результатах пошуку;

4. сайт отримує перехід, показ реклами, заявку або продаж.

Саме на цій моделі побудовані класичне SEO, контент-маркетинг, інформаційні портали, партнерські сайти й велика частина електронної комерції.

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

За спостереженнями Cloudflare, які компанія наводила під час першого Content Independence Day, співвідношення сканувань до отриманих переходів для великих AI-операторів могло становити від приблизно 118 сканувань на один перехід до майже 50 000 сканувань на один перехід. Це означає, що сервер може десятки тисяч разів віддати контент автоматизованій системі, перш ніж сайт отримає хоча б одного відвідувача.

Для власника сайту це створює одразу декілька проблем:

• AI-бот використовує серверні ресурси та пропускну здатність;

• контент може стати основою для готової відповіді стороннього сервісу;

• користувач отримує відповідь, не відкриваючи першоджерело;

• сайт не отримує перегляду, реклами, ліда або продажу;

• автору складно визначити, хто саме використовував його матеріали й навіщо.

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

Не кожен AI-бот виконує однакову роботу

Однією з головних тез нового підходу Cloudflare є відмова від спроб назвати весь автоматизований AI-трафік одним словом.

Поняття «AI-бот» стало занадто широким.

Один робот може збирати інформацію для пошукового індексу. Інший — завантажувати сторінку безпосередньо на прохання користувача. Третій — формувати набір даних для навчання майбутньої версії мовної моделі.

Наслідки для власника сайту в кожному випадку різні.

Cloudflare пропонує оцінювати автоматизований трафік за трьома питаннями:

• що бот робить на сайті;

• яку інформацію він зберігає;

• як він може повторно використати або показати контент.

Для практичного керування Cloudflare виділяє три основні класи: Search, Agent і Training.

Search: сканування для пошуку та відповідей

До категорії Search належать системи, які збирають або індексують інформацію, щоб пізніше використовувати її для відповіді на запити користувачів.

За логікою Cloudflare, власник сайту, який дозволяє таке сканування, повинен очікувати принаймні одну з двох форм цінності:

• переходи на сайт;

• іншу справедливу форму компенсації.

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

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

Agent: дії від імені конкретного користувача

Категорія Agent охоплює автоматизовані системи, які відкривають сайт у реальному часі для виконання конкретного завдання користувача.

Наприклад, AI-агент може:

• прочитати сторінку, посилання на яку надіслав користувач;

• знайти характеристики товару;

• перевірити наявність;

• порівняти декілька моделей;

• заповнити форму;

• додати товар до кошика;

• допомогти оформити замовлення.

У цьому випадку за діями бота зазвичай стоїть реальна людина, яка очікує результат.

Cloudflare окремо відносить до Agent чат-боти, що завантажують сторінку за запитом користувача, та браузерних агентів, які керують вебінтерфейсом для виконання певної операції.

Для e-commerce це потенційно корисний вид трафіку. Надалі AI-агенти можуть стати новим каналом продажів: не лише рекомендувати товар, а й виконувати частину шляху покупця.

Однак доступ агентів потребує контролю. Автоматизованій системі не обов’язково дозволяти відкривати внутрішній пошук тисячі разів, перебирати всі фільтри, створювати порожні кошики або навантажувати оформлення замовлення.

Training: використання контенту для навчання моделей

Категорія Training — це сканування, під час якого інформація збирається для навчання або донавчання AI-моделі.

У цьому сценарії контент може бути включений до набору даних і використаний для поліпшення майбутніх можливостей системи.

Такий доступ не обов’язково приносить сайту:

• переходи;

• згадування бренду;

• посилання на джерело;

• заявки;

• прямий дохід.

Саме тому багато видавців і власників унікальних баз даних найобережніше ставляться до Training-краулерів.

Позиція Cloudflare полягає не в тому, що навчання необхідно блокувати абсолютно всім. Компанія прагне надати власнику можливість самостійно вибрати умови: дозволити доступ, заборонити його або вимагати оплату.

Головна зміна Cloudflare: окремі правила замість глобального блокування

Раніше Cloudflare пропонував функцію Block AI Bots, яка дозволяла одним перемикачем блокувати роботів, пов’язаних зі збиранням даних для навчання моделей.

Однак універсальне блокування виявилося недостатньо гнучким.

Тому Cloudflare запровадив окреме керування трьома сценаріями:

Для кожного типу поведінки Cloudflare дозволяє обрати одну з базових політик:

• блокувати на всьому сайті;

• блокувати лише на сторінках із рекламою;

• не блокувати.

Нові налаштування доступні через розділ керування політиками AI-ботів у Cloudflare Security Settings, зокрема й для клієнтів безплатного тарифу.

Що зміниться 15 вересня 2026 року

Cloudflare оголосив, що 15 вересня 2026 року змінить стандартні налаштування для нових доменів, які підключатимуться до платформи.

На сторінках, де Cloudflare визначить наявність реклами:

• Training-боти блокуватимуться за замовчуванням;

• Agent-боти блокуватимуться за замовчуванням;

• Search-краулери залишатимуться дозволеними.

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

Водночас Search залишається дозволеним, оскільки саме пошукова функція найчастіше пов’язана з потенційним поверненням аудиторії на сайт.

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

Cloudflare планує застосовувати до таких роботів найбільш обмежувальне з установлених правил. Наприклад, якщо власник дозволив Search, але заблокував Training, змішаний краулер із двома призначеннями може бути заблокований.

У матеріалі Cloudflare серед прикладів багатоцільових систем названі Googlebot, Applebot і Bingbot. Тому перед увімкненням жорсткого блокування Training необхідно перевірити, чи не вплине правило на звичайну пошукову індексацію.

Дозволити доступ — ще не означає дозволити робити з контентом усе

Cloudflare також розвиває концепцію content use — рівня допустимого використання контенту після його сканування.

Запропоновано три рівні:

Immediate

Система може взаємодіяти зі сторінкою в поточний момент, але не повинна зберігати або повторно використовувати отриманий контент.

Такий режим може підходити для агента, що виконує одноразове завдання користувача.

Reference

Система може індексувати інформацію, показувати короткі уривки та посилатися на першоджерело.

Cloudflare розглядає цей рівень як стандартний варіант.

Full

Система може створювати розгорнуті перекази та відтворювати інформацію значно ширше.

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

Таким чином, майбутня політика доступу може виглядати не просто як «дозволити AI-пошук», а, наприклад:

Дозволити пошуковим AI-системам індексувати сторінки, цитувати короткі фрагменти та обов’язково посилатися на джерело, але не дозволяти повне відтворення матеріалів.

Це значно точніше, ніж звичайний дозвіл або блокування User-Agent.

Нові сигнали в robots.txt

Cloudflare тестує розширення Content Signals, яке дозволяє зазначати побажання власника сайту безпосередньо у файлі robots.txt.

Приклад такої політики:

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

Цей запис означає:

• сканування для пошуку дозволено;

• використання для навчання AI небажане;

• контент дозволено використовувати на рівні посилання, індексації та короткого цитування.

Водночас Cloudflare прямо зазначає, що Content Signals у robots.txt виражають побажання власника, але самі по собі не є технічним блокуванням. Для реальної заборони потрібно застосовувати правила безпеки, Bot Management, WAF або інші серверні механізми.

Це принципово важливо.

robots.txt — це декларація правил для добросовісних роботів. Зловмисний або неправильно ідентифікований сканер може її проігнорувати.

Що таке Pay Per Crawl

Cloudflare пропонує третій варіант між безплатним доступом і повним блокуванням — Pay Per Crawl.

Модель дозволяє власнику сайту встановити плату за успішне отримання сторінки AI-краулером.

Базова схема працює так:

1. краулер запитує захищений матеріал;

2. Cloudflare повідомляє, що доступ платний;

3. сервер повертає статус HTTP 402 Payment Required і вказує ціну;

4. краулер може погодитися з умовами;

5. після підтвердження він отримує сторінку;

6. подія фіксується для подальших розрахунків.

Cloudflare виступає технічною платформою та Merchant of Record — стороною, яка обробляє комерційну частину операції між власником контенту й оператором краулера.

Для окремого краулера власник може обрати одну з трьох дій:

• Allow — надати безплатний доступ;

• Charge — вимагати оплату;

• Block — повністю заборонити доступ.

У документації Cloudflare за 2026 рік описано встановлення ціни для домену, додаткові правила ціноутворення та моніторинг платних запитів. Мінімальна базова ціна, зазначена Cloudflare, становить 0,01 долара США за одне успішне сканування. Доступність функції та конкретних налаштувань потрібно перевіряти в обліковому записі Cloudflare.

Pay Per Crawl навряд чи одразу стане значним джерелом прибутку для звичайного інтернет-магазину. Проте сама поява такого механізму важлива: доступ автоматизованої системи до контенту вперше розглядається як окрема економічна операція, а не як безумовне право будь-якого робота.

Чому повне блокування всіх AI-ботів може бути помилкою

На перший погляд найпростішим рішенням здається повна заборона AI-трафіку.

Проте для більшості комерційних сайтів така політика може бути надто агресивною.

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

Для малого бізнесу існує подвійний ризик:

• відкрити все й дозволити необмежене використання контенту;

• закрити все й втратити видимість у нових каналах пошуку.

Сам Cloudflare визнає, що універсальне блокування не підходить усім. Саме тому компанія переходить до окремого керування Search, Agent і Training замість політики «блокувати всю автоматизацію».

На думку Sitezilla, правильне рішення — не глобальна заборона, а політика доступу за типами сторінок і поведінкою краулера.

Рекомендована політика Sitezilla для інтернет-магазинів

Нижче наведено практичну модель, яку можна використовувати як основу для e-commerce-проєкту.

Це не універсальна офіційна рекомендація Cloudflare, а практична інтерпретація нових інструментів від Sitezilla.

Товарні сторінки й категорії

Такі сторінки повинні залишатися доступними для Search-краулерів. Саме вони допомагають AI-пошуку зрозуміти:

• що продає магазин;

• які характеристики має товар;

• яка актуальна ціна;

• чи є товар у наявності;

• які способи доставки та оплати доступні;

• чим один товар відрізняється від іншого.

Для цих сторінок особливо важливі структуровані дані, коректна розмітка Product, Offer, BreadcrumbList, Brand та актуальні ціни.

Блогові статті

Блог варто відкривати для пошуку, але не обов’язково дозволяти необмежене використання для навчання моделей.

Для типових SEO-статей можна застосувати політику use=reference: індексація та коротке цитування дозволені за умови посилання на джерело.

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

Фільтри та внутрішній пошук

AI-бот не повинен безконтрольно генерувати тисячі комбінацій параметрів.

Наприклад:

/category?color=red&size=42&sort=price&page=17

Масове сканування таких URL:

• створює дублікати;

• витрачає серверні ресурси;

• засмічує аналітику;

• збільшує навантаження на базу даних;

• не обов’язково створює корисну пошукову цінність.

Для фільтрів необхідні canonical, правила індексації, обмеження параметрів і контроль частоти запитів.

Адміністративні та персональні розділи

Адміністративна панель, особистий кабінет, історія замовлень, службові API та внутрішні маршрути мають бути закриті не тільки від AI-ботів, а й від усіх неавторизованих автоматизованих систем.

Тут недостатньо robots.txt. Потрібні:

• авторизація;

• правила WAF;

• обмеження частоти запитів;

• перевірка сесій;

• захист API;

• блокування підозрілої автоматизації.

AI-краулери потрібно не тільки блокувати, а й аналізувати

Однієї настройки Cloudflare недостатньо.

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

Cloudflare розвиває для цього BotBase та Attribution Business Insights. BotBase класифікує відомих роботів за поведінкою, а Attribution Business Insights показує обсяг бот-трафіку, використану пропускну здатність, співвідношення сканувань до переходів і поточну дію — дозволення або блокування.

На думку Sitezilla, подібний звіт варто мати й у власній системі вебаналітики.

Що має показувати звіт «AI-краулери»

Для кожного робота бажано збирати:

• назву або визначеного оператора;

• User-Agent;

• підтверджений або непідтверджений статус;

• IP-адреси та країни;

• кількість запитів;

• кількість унікальних URL;

• обсяг переданих даних;

• середній час відповіді;

• коди 200, 301, 404, 403, 429 і 500;

• сторінки з найбільшою кількістю звернень;

• частоту повторного сканування;

• отримані переходи від відповідного AI-сервісу;

• співвідношення сканувань до переходів;

• створені заявки або замовлення;

• приблизну вартість серверного навантаження.

Окремо варто відстежувати відомих операторів пошукових систем, AI-платформ та агентів, не покладаючись лише на текст User-Agent. Його можна підробити, тому для важливих рішень необхідно використовувати підтвердження IP, DNS, Web Bot Auth або класифікацію Cloudflare.

Як оцінювати користь конкретного краулера

Припустімо, що за місяць певний робот:

• виконав 100 000 запитів;

• завантажив 20 ГБ даних;

• регулярно звертався до важких сторінок фільтрів;

• створив додаткове навантаження на MySQL;

• привів двох відвідувачів;

• не створив жодного замовлення.

Такий доступ навряд чи вигідний магазину.

Інший оператор може:

• виконати 2 000 запитів;

• сканувати лише основні товарні сторінки;

• привести 200 користувачів;

• створити декілька асистованих конверсій.

Другого робота логічно залишити дозволеним, тоді як для першого можна встановити обмеження, блокування або платний режим.

Тому рішення потрібно приймати не за назвою компанії та не за загальним ярликом «AI», а за реальною поведінкою.

Покроковий план упровадження політики AI-краулерів

Крок 1. Провести аудит автоматизованого трафіку

Потрібно проаналізувати серверні журнали та визначити:

• які роботи відвідують сайт;

• які URL вони сканують;

• як часто повертаються;

• які створюють помилки;

• які споживають найбільше ресурсів.

Бажано аналізувати період щонайменше 30 днів.

Крок 2. Розділити URL за призначенням

Усі маршрути потрібно згрупувати:

• публічний комерційний контент;

• інформаційний контент;

• унікальні авторські матеріали;

• сторінки взаємодії;

• персональні сторінки;

• службові маршрути;

• API;

• параметричні та технічні URL.

Крок 3. Визначити цінність кожної групи

Для кожного типу сторінок потрібно відповісти:

• чи потрібна видимість у пошуку;

• чи може AI-агент привести клієнта;

• чи дозволяємо використання для навчання;

• чи містить сторінка унікальні комерційні дані;

• чи створює сканування суттєве навантаження;

• чи можна монетизувати доступ.

Крок 4. Налаштувати окремі політики

Не варто використовувати одну глобальну дію для всього домену.

Можлива базова конфігурація:

• Search — дозволити на публічних сторінках;

• Agent — дозволити перевіреним системам із rate limiting;

• Training — блокувати або дозволяти вибірково;

• внутрішні сторінки — блокувати для всіх автоматизованих систем;

• дорогі авторські матеріали — ліцензувати або монетизувати.

Крок 5. Налаштувати robots.txt і Content Signals

Файл robots.txt повинен відображати загальну політику сайту, але не бути єдиним механізмом захисту.

Для реального контролю його потрібно доповнювати правилами Cloudflare, WAF, серверними обмеженнями та перевіркою ботів.

Крок 6. Відстежувати переходи з AI-сервісів

У системі аналітики варто окремо групувати переходи від:

• AI-пошукових систем;

• чат-ботів;

• браузерних асистентів;

• звичайних пошукових систем;

• невизначених реферерів.

Поступово це дозволить визначити, які AI-платформи реально приводять користувачів.

Крок 7. Переглядати політику щомісяця

Екосистема змінюється дуже швидко. Робот, який сьогодні використовується тільки для навчання, завтра може почати працювати як пошуковий агент або навпаки.

Тому правила не варто налаштовувати один раз назавжди.

SEO перетворюється на SEO, AEO та GEO одночасно

Класичне SEO оптимізує сайт для сторінки пошукової видачі.

AEO, або Answer Engine Optimization, допомагає контенту потрапляти до готових відповідей.

GEO, або Generative Engine Optimization, зосереджується на тому, щоб генеративні системи правильно розуміли бренд, товари, факти та першоджерело.

Cloudflare прямо звертає увагу на перехід від звичайного SEO-середовища до світу AEO та GEO, де важливо аналізувати не лише позиції й органічний трафік, а й поведінку AI-краулерів.

Для власника сайту це означає появу нового напряму роботи:

• контролювати доступ до контенту;

• залишатися видимим для корисних AI-систем;

• захищати унікальні матеріали;

• вимірювати AI-переходи;

• формувати машинозрозумілу структуру сайту;

• перевіряти правильність інформації про бренд;

• не дозволяти автоматизації створювати зайве навантаження.

Контроль AI-ботів стає не тільки завданням системного адміністратора або спеціаліста з безпеки. Це вже питання SEO, маркетингу, контентної стратегії та економіки сайту.

Позиція Sitezilla

Sitezilla не рекомендує більшості комерційних сайтів вмикати глобальне блокування всіх AI-ботів без попереднього аналізу.

Повна відкритість також не є оптимальним рішенням.

Раціональна політика повинна бути вибірковою:

• публічні товари й категорії — доступні для Search;

• перевірені агенти, що діють на користь покупця, — дозволені з обмеженнями;

• навчання моделей — тільки за усвідомленою згодою власника;

• унікальний дорогий контент — захищений, ліцензований або монетизований;

• фільтри, пошук і технічні URL — обмежені;

• кошик, кабінет, API та адміністративні маршрути — закриті;

• уся активність роботів — окремо журналюється й аналізується.

Основний принцип можна сформулювати просто:

Не потрібно блокувати весь AI. Потрібно розуміти, хто прийшов на сайт, що він робить, яку цінність отримує та що повертає власнику контенту.

Висновок

Cloudflare фактично пропонує нову модель відносин між сайтами й автоматизованими системами.

Замість безумовного доступу або повної заборони власник повинен мати можливість:

• дозволяти корисне пошукове сканування;

• обслуговувати агентів реальних користувачів;

• блокувати навчання моделей;

• обмежувати спосіб повторного використання матеріалів;

• вимагати оплату за доступ;

• бачити реальну статистику сканувань і переходів.

Для власників сайтів це означає, що файл robots.txt, SEO та захист від ботів більше не можна розглядати окремо.

У найближчі роки конкурентну перевагу матимуть не ті сайти, які просто відкрили або закрили доступ для AI, а ті, які створили керовану систему:

дозволяти корисне, блокувати шкідливе, вимірювати результат і встановлювати власні правила використання контенту.

Саме це і є головна ідея Content Independence Day: ваш сайт, ваш контент — і ваші умови доступу.