Пошук

Як використовувати оновлений Bots Directory Cloudflare Radar та API BotBase

·

Команда Cloudflare оновила розділ Bots Directory у Cloudflare Radar і перевела його на новий каталог BotBase. Нижче — практичний розбір, як тепер описуються боти та що варто змінити у власних інтеграціях з Radar API.

1. Що змінилося в Bots Directory на Cloudflare Radar

Bots Directory тепер підживлюється даними з BotBase — внутрішнього каталогу ботів і агентів, які відстежує Cloudflare. Інтерфейс директорії також переробили під дизайн головної сторінки Radar, щоб було легше переходити між аналітикою та деталями конкретного бота.

Animation filtering the Bots Directory and opening the Cloudflare Crawler bot page, with its Identity and Traffic sections

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

2. Новий розділ Identity на сторінці бота

Для кожного бота в Bots Directory додали секцію Identity. Вона зосереджується не на технічних деталях, а на тому, як саме бот взаємодіє з контентом і сайтами:

  • Access level — рівень доступу бота.
  • Content use — як бот використовує завантажений контент.
  • Web Bot Auth — чи підтримує бот верифікацію через Web Bot Auth.
  • User agents — які user agent рядки асоційовані з цим ботом.

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

Окремий практичний момент — операторів ботів тепер можна шукати прямо через пошук на сайті Radar. Тобто, якщо ви знаєте компанію або сервіс, можна подивитися всі їхні боти та порівняти їхню поведінку.

3. Нові поля в Radar API для роботи з ботами

Разом з оновленням директорії Cloudflare змінив опис ботів у Radar API. Це стосується двох endpointів:

Тепер у відповіді API з'явилися нові атрибути, узгоджені з BotBase.

3.1. Поле categories замість category

У попередній версії кожен бот мав один category. Тепер в API використовується масив categories, і бот може належати до кількох груп одночасно.

  • Категорії синхронізовані з групами BotBase.
  • Додана нова група COMMERCE.
  • Частину старих категорій об'єднали в ширші групи.

Практично це означає, що нефіксовані фільтри на кшталт «показати тільки пошукових ботів» варто переглянути. Якщо ваш код очікує один рядок category, його потрібно адаптувати до масиву categories і вирішити, як обробляти ботів з кількома категоріями.

3.2. accessLevel — як бот виходить в інтернет

Поле accessLevel описує, як бот отримує доступ до сайтів:

  • DIRECT — бот звертається безпосередньо, під власною ідентичністю.
  • INTERMEDIARY — бот діє через посередника, від імені іншого агента або людини.

Це корисно, якщо ви будуєте політику доступу за типом трафіку. Наприклад, можна дозволяти DIRECT ботів з надійною документацією і уважніше перевіряти INTERMEDIARY, які працюють «за когось».

3.3. contentUse — як бот працює з вашим контентом

Поле contentUse показує, що відбувається з контентом, який бот завантажує:

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

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

3.4. documentationUrl та operatorWebsiteUrl

У відповіді Get bot details з'явилися два додаткові URL:

  • documentationUrl — сторінка з офіційною документацією бота.
  • operatorWebsiteUrl — сайт оператора бота.

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

4. Депрековані поля та міграція існуючого коду

Старі атрибути в Radar API оголосили застарілими:

  • category — замінюється на categories.
  • operatorUrl — замінюється на documentationUrl.

Їх можуть ще повертати з API протягом перехідного періоду, але розраховувати на це надовго не варто. Якщо ви:

  • фільтруєте ботів за category,
  • виводите посилання на operatorUrl в інтерфейсі або звітах,
  • зберігаєте ці значення у власній базі,

доведеться:

  1. Перейти на масив categories і визначити, як поводитися з кількома категоріями (наприклад, брати всі, вибирати головну або будувати власні групи).
  2. Замінити operatorUrl на documentationUrl у відображенні та в сховищі.
  3. Додати за потреби operatorWebsiteUrl як окреме поле з інформаційним сайтом оператора.

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

5. Як застосувати новий Bots Directory у повсякденній роботі

Кілька практичних сценаріїв, де оновлення може бути корисним:

  • Налаштування правил фільтрації ботів. Можна комбінувати categories, accessLevel та contentUse, щоб вибудувати більш гнучкі правила допуску до сайту.
  • Внутрішня документація про ботів. За допомогою documentationUrl і operatorWebsiteUrl легше збирати посилання на офіційні джерела й пояснювати команді, хто саме сканує сайт.
  • Аналітика ботів у власних дашбордах. Нові поля з Radar API можна додати до ваших BI-звітів, щоб, наприклад, окремо дивитися трафік ботів з full використанням контенту.

Детальніші приклади роботи з оновленим API можна знайти в офіційній документації Cloudflare за посиланнями на сторінки List bots та Get bot details. Для огляду самих ботів у візуальному інтерфейсі варто почати з оновленої директорії Bots Directory.

Джерело: Cloudflare Changelog

Пошук

Закрити