Cloudflare дозволила заборонити AI training без втрати пошуку — але неправильний Block може вдарити по SEO

Cloudflare розділила пошук, AI-агентів і навчання моделей

Для власників сайтів за Cloudflare з’явилася важлива зміна, яка на перший погляд виглядає як ще одна настройка ботів, але на практиці може впливати і на SEO, і на те, чи потрапляє контент у датасети для навчання моделей. Cloudflare запустила окремий режим Disallow AI Training: він дозволяє заявити, що сайт не хоче віддавати контент для навчання AI, але при цьому залишатися доступним для пошукової індексації там, де crawler підтримує таке розділення.

Проблема, яку Cloudflare намагається вирішити, виникла через так звані mixed-use crawlers. Один і той самий бот може використовуватися одразу для кількох цілей: наприклад, будувати пошуковий індекс і паралельно збирати дані для тренування моделей. Раніше власник сайту часто опинявся перед грубим вибором: дозволити такого бота повністю або заблокувати його разом із корисною пошуковою функцією.

Що саме змінилося 15 вересня

Cloudflare тепер оперує трьома окремими типами поведінки: Search, Training і Agent. Search — це індексація для пошуку. Training — збір контенту для навчання або донавчання моделей. Agent — автоматизований доступ від імені користувача, наприклад коли AI-агент відкриває сторінку, щоб виконати конкретне завдання.

Для Training з’явився варіант Disallow AI Training. Cloudflare через Bot Preference Sync публікує відповідну no-training перевагу в robots.txt. Для crawler’ів, які Cloudflare вважає «Accountable» і які вміють розділяти свої режими роботи, це означає: пошуковий доступ може залишатися дозволеним, а використання контенту для тренування — ні.

Одночасно змінилося значення жорстких режимів Block і Block on pages with ads. Вони тепер поширюються і на mixed-use crawler’и. Тобто якщо просто поставити Training = Block, це може зачепити бота, який виконує ще й пошукову функцію. Саме тому Cloudflare прямо радить використовувати Disallow AI Training, якщо головна мета — заборонити тренування, але не втратити пошукову видимість.

Чому тут легко випадково нашкодити SEO

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

Cloudflare окремо попереджає: якщо власник хоче прибрати mixed-use crawler повністю, потрібно вибрати Block — і тоді пошукова складова теж зникне. У контексті Googlebot, Applebot або Bingbot це вже може мати наслідки для discoverability. Підтримка no-training сигналів у різних операторів також розгортається не одночасно, тому сайтам варто перевіряти актуальну поведінку конкретного crawler’а, а не припускати, що всі пошукові системи працюють однаково.

Нові дефолти для сайтів із рекламою

Для нових доменів Cloudflare рекомендує різні стартові конфігурації залежно від монетизації. Якщо сайт заробляє на рекламі, Search залишається дозволеним, Training отримує Disallow AI Training, а Agent може блокуватися на сторінках із рекламою. Логіка проста: пошук здатен привести людину на сторінку, тоді як тренувальний crawler або агент може забрати інформацію без людського перегляду сторінки.

Для сайтів без рекламної монетизації рекомендована стартова політика м’якша. Але це саме дефолт, а не обов’язкова політика: власник домену може змінити кожен із трьох режимів окремо.

Що перевірити власнику сайту прямо зараз

Якщо домен працює через Cloudflare, варто відкрити налаштування Security і знайти політики AI bots. Перше — перевірити Search: якщо вам потрібна індексація, він не має бути випадково заблокований. Друге — вирішити, чи дозволяєте ви Training. Якщо ні, але пошуковий трафік важливий, режим Disallow AI Training логічніший за повний Block. Третє — окремо подумати про Agent traffic: для магазину, SaaS або документації AI-агенти можуть бути корисними, але для сторінок, що живуть із реклами, вони можуть обходити сам механізм монетизації.

Також варто перевірити robots.txt після зміни налаштувань. Bot Preference Sync має синхронізувати заявлені переваги з політиками Cloudflare, але складні кастомні WAF-правила або старі ручні записи можуть створювати суперечності. Якщо robots.txt говорить одне, а edge rule блокує інше, діагностика проблем із crawler’ами стане значно складнішою.

Що це означає для вебу в цілому

Ця зміна цікава не лише як функція Cloudflare. Веб поступово відходить від бінарної моделі «бот дозволений / бот заборонений» до моделі, де власник контенту намагається визначити мету доступу. Один і той самий URL може бути відкритим для класичного пошуку, забороненим для тренування і частково доступним для агентів.

Для SEO це означає, що політика crawler’ів стає частиною технічної оптимізації сайту. Для видавців — це можливість точніше контролювати використання контенту. А для AI-компаній — стимул чіткіше декларувати, який саме бот що робить. Поки стандарти ще формуються, головний практичний висновок простий: не ставити Block навмання. Спочатку потрібно визначити, що саме ви хочете заборонити — пошук, тренування чи агентний доступ.

↗