Htaccess - блокировка KeenableBot. Что за AI краулер - 2026

Published: 2026-09-14

Введение

В 2026 году количество автоматических систем, которые собирают содержимое веб-сайтов для нужд искусственного интеллекта, выросло на порядок. Сначала веб-индустрия привыкла к поисковым ботам Google (Googlebot) и Bing (Bingbot). Потом появились тренировочные краулеры OpenAI (GPTBot), Anthropic (ClaudeBot) и Common Crawl (CCBot). Следом пришли «ретривал-боты» — PerplexityBot, ChatGPT-User, OAI-SearchBot, которые читают страницы в момент, когда пользователь задаёт вопрос ассистенту. И вот, в августе 2026 года, на сцену вышел ещё один игрок — молодая компания Keenable.ai, которая решила построить «следующий Google для AI-агентов» и начала строить собственный независимый веб-индекс.

Естественным техническим следствием такого проекта является собственный краулер. В логах веб-мастеров он появляется под идентификатором KeenableBot, а рядом с ним время от времени фиксируется второй агент — Keenable-User. Обе строки формально маскируются под браузерные приставки Mozilla/5.0 AppleWebKit/537.36, но честно называют себя в части «compatible;» и оставляют ссылку на сайт компании: +https://keenable.ai/.

Задача этой статьи — досконально разобрать, что такое KeenableBot, чего хочет стоящая за ним компания, какие данные он собирает с чужих сайтов, чем это отличается от поисковых и тренировочных ботов, как обнаружить его в собственных логах и, главное, как заблокировать — в том числе через классический файл .htaccess, на котором работает огромное количество виртуальных хостингов и VPS-панелей вроде FastPanel, а также через nginx, Cloudflare и robots.txt.

Важно сразу оговориться: компания Keenable на момент написания статьи не публикует официальной документации по своему краулеру — ни политики robots.txt для владельцев сайтов, ни списка IP-диапазонов, ни формы opt-out. Поэтому технические детали ниже собраны из независимых реестров ботов (прежде всего udger.com) и из анализа официальных документов компании — публичных страниц сайта, документации API, условий использования, политики конфиденциальности.

Keenable — компания

Основатели и история

Keenable.ai, Inc. — американский стартап, зарегистрированный по адресу 215 Verano Drive Unit B, Los Altos, CA 94022. Компания вышла из режима стелса 25 августа 2026 года, когда TechCrunch опубликовал статью Анны Хайм о раунде финансирования. Объём раунда — 26 миллионов долларов, лидирующий инвестор — известный венчурный фонд Accel. В раунде также участвовали Conviction Partners и бизнес-ангелы, работающие в Google, xAI, NVIDIA, Amazon и Hugging Face.

Команда состоит примерно из пятнадцати инженеров, распределённых между США и Европой; по заявлениям основателей, к концу 2026 года численность планируется удвоить. Юридическим лицом является Keenable.ai, Inc.

Кто стоит за проектом

Основателей двое, и у обоих — глубокая экспертиза в поисковых системах:

• Andrey Styskin (CEO) — ранее руководил поиском, AI-подразделением и облаком в российском поисковике Yandex; затем работал в Amazon. Собственный послужной список он оценивает в двадцать лет опыта в поисковой инженерии. В Yandex он участвовал в построении индекса, по разным оценкам охватывавшего сотни миллиардов документов.
• Matthias Petri (Chief Scientist) — в прошлом Principal Applied Scientist в Amazon AGI, где строил систему web grounding (привязку ответов AI к веб-источникам) для голосового ассистента Alexa.

Именно пара «поиск — масштаб — интернет-инфраструктура» делает этот стартап принципиально иным по сравнению с большинством AI-проектов 2026 года: Keenable не собирается перепродавать результаты Google или Bing, а строит собственную вертикально-интегрированную цепочку: свой краулер, свой индекс, свой ранжировщик и свой API.

Финансирование и амбиции

В статье TechCrunch Styskin прямо называет цель компании — стать «следующим Google для AI-агентов». Строительство «собственного большого индекса» он сам же описывает словами «это мучительно дорого» (painfully expensive). Из этого признания следует простой практический вывод для владельцев сайтов: раз индекс строится за реальные деньги, компания будет агрессивно и масштабно сканировать веб, и трафик от этого индекса будет расти.

Партнёрство, которое Keenable готова назвать публично (и это единственный названный клиент на момент публикации расследований) — интеграция с голосовой AI-компанией Gradium для живого поиска в низколатентных диалогах. Остальные потребители «нескольких AI-лабораторий» остаются неназванными — независимые издания (quasa.io, AI Insiders) прямо подчёркивают, что утверждение о «нескольких продакшн-инсталляциях» известно только со слов самой компании и внешнего подтверждения не имеет.

Что такое AI-краулеры вообще

Чтобы корректно понять место KeenableBot в экосистеме, нужно определиться с терминами. Всё, что ходит на сайт по HTTP и само себя не идентифицирует как обычный браузер, в общем случае можно разделить на несколько категорий.

Поисковая индексация

Классические боты Googlebot, Bingbot, YandexBot ходят за тем, чтобы страница появилась в поисковой выдаче для людей. Для этого они копируют HTML-содержимое, сохраняют слепок страницы и периодически перекачивают её заново. Взамен владелец сайта получает трафик — это своеобразный «бартер», сформировавшийся за двадцать пять лет эволюции поиска.

Тренировочные краулеры

GPTBot, ClaudeBot, CCBot, Bytespider, Applebot-Extended и другие сканируют сайты, чтобы собрать корпус текстов для обучения большой языковой модели. Фактически это массовое копирование контента, при котором владелец сайта не получает обратной отдачи — ни трафика, ни ссылок, ни атрибуции. Из-за этого именно тренировочные боты стали главным объектом блокировок последних двух лет.

Ретривал-боты (поиск по требованию)

PerplexityBot, ChatGPT-User, OAI-SearchBot, Claude-User работают иначе: они ходят на страницу в момент, когда пользователь задаёт вопрос ассистенту, чтобы построить ответ с источниками. Этот режим называют retrieval или grounding, и он создаёт потенциальный трафик и цитируемость, поэтому часть издателей такие боты сознательно оставляет разрешёнными.

Гибридные и «серые» краулеры

На стыке всех категорий находятся системы, у которых цель шире простого ответа пользователю: они копируют контент сайта в собственный индекс, чтобы потом перепродавать доступ к нему другим AI-системам. Именно такую модель строит Keenable, и поэтому её краулер одновременно похож и на поискового, и на тренировочного бота, но не обязан вести себя как тот или другой.

Общеотраслевую систему координат даёт Cloudflare, который в своей документации делит ботов на три поведенческих класса:

• Search — краулеры, которые индексируют контент, чтобы отвечать на вопросы о нём позже;
• Agent — автоматика, работающая в реальном времени от имени человека (фетч-боты, browser-use-агенты);
• Training — краулеры, собирающие контент для обучения и дообучения моделей.

Ключевое правило Cloudflare: если бот сочетает Training и Search (mixed-purpose), его следует классифицировать как Training — то есть как претендента на блокировку, а не на «полезный цитируемый бот». Как будет показано ниже, KeenableBot по описанию компании-основателя попадает именно в такую серую зону.

Краткая хронология AI-краулеров: 2023-2026

Чтобы понять значимость появления KeenableBot, стоит вспомнить, как стремительно менялась картина AI-краулинга за последние три года.

• 2023 год - OpenAI объявляет GPTBot и открывает дискуссию о robots.txt для тренировочных ботов. Сайты массово начинают прописывать токен GPTBot, возникает целый пласт сервисов и списков, посвящённых блокировке AI-ботов.
• 2024 год - Google вводит специальный токен Google-Extended, который управляет использованием уже проиндексированного контента для Gemini и обучения, не затрагивая обычную выдачу. В этом же году к массовым спорам присоединяются PerplexityBot и концепция «который краулит для ответов».
• 2025 год - OpenAI разделяет идентичность на несколько агентов: GPTBot (обучение), OAI-SearchBot (живой поиск) и ChatGPT-User (чтение по требованию). Подобное дробление становится индустриальным паттерном: у всех крупных игроков появляются пары «серверный индексный краулер» и «персональный фетч-агент».
• 2026 год - Cloudflare вводит поведенческие категории Search / Agent / Training и блокировки по типу поведения; компании-ветераны публикуют списки IP и политики robots.txt. На этом фоне Keenable выходит из стелса с собственным индексом и двумя юзер-агентами.

Именно паттерн «дробления идентичности» повторяет Keenable: KeenableBot отвечает за фоновый сбор, Keenable-User-агент - за чтение по прямому запросу. Для администратора сайта это означает одно: нужно отслеживать все варианты идентичности вендора, а не один.

KeenableBot и Keenable-User: два агента

Общее устройство

Сама компания краулеры детально не документирует, но в публичном реестре ботов udger.com зарегистрированы два юзер-агента, выпущенных производителем «Keenable.ai, Inc.»:

• KeenableBot/1.0 — статус Active, первое наблюдение 2026-09-12, категория в реестре — «Uncategorised» (не классифицирован);
• Keenable-User/1.0 — первое наблюдение 14 августа 2026 года, последнее наблюдение в реестре — 3 сентября 2026 года.

Разница между ними важна для понимания, какую часть трафика вы видите в логах.

KeenableBot — фоновый сборщик индекса

KeenableBot — это «рабочая лошадка» индекса. Компания заявляет, что обслуживает более ста миллиардов документов, и для этого необходимо постоянно переобъезжать веб: обходить новые сайты, забирать обновления, находить удалённые страницы. Поток запросов от KeenableBot — это фоновый краулинг, который не привязан к конкретному пользователю и конкретному вопросу. По этой причине в терминах Cloudflare его правильнее всего относить к классам Search или Training, но никак не Agent.

TechCrunch прямо цитирует позицию компании: API уже используется «и во время обучения, и во время исполнения» (during both training and runtime). Это значит, что содержимое собранного KeenableBot индекса может использоваться и для обучения моделей клиентов, и для живых ответов. Для владельца сайта такой бот неотличим от тренировочного: он копирует полные страницы, ходит с дата-центров без явной пользы владельцу и не гарантирует атрибуцию.

Keenable-User — фетч по запросу агента

Keenable-User — поведенческий аналог ChatGPT-User или Perplexity-User. Такие агенты ходят на страницу в момент, когда агент пользователя запросил конкретный URL через функцию fetch_page_content с параметром live=true. Документация API Keenable прямо описывает этот механизм: по умолчанию fetch возвращает сохранённую в индексе копию страницы, а live=true «забирает страницу напрямую с источника, включая URL, которые не проиндексированы». Последний вариант генерирует живой запрос к вашему сайту с юзер-агентом Keenable-User.

Таким образом, в логах могут встречаться оба агента, и блокировать их нужно в связке — закрывать только один из них бессмысленно. Если закрыть лишь KeenableBot, индекс продолжит жить за счёт ранее собранных копий, а live-запросы агентов продолжат ходить под Keenable-User и даже смогут докачивать страницы, которых нет в индексе.

User-Agent строки

Идентификация в логах идёт по строке User-Agent. Обе известные строки Keenable имеют одинаковую структуру:

KeenableBot/1.0:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; KeenableBot/1.0; +https://keenable.ai/)

Keenable-User/1.0:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Keenable-User/1.0; +https://keenable.ai/)

Что здесь важно понимать.

• Начало строки — Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; ...) — это не честная идентификация браузера, а стандартная формальная приставка, которую по инерции копируют многие программные клиенты. Отсутствие токенов Chrome/ Safari в явном виде указывает на то, что это не реальный браузер.
• Идентифицирующей частью является идущий после «compatible;» блок — KeenableBot/1.0 или Keenable-User/1.0 — и именно по нему следует строить блокировки и подсчёт статистики.
• В строке присутствует ссылка на сайт компании +https://keenable.ai/ — признак того, что краулер как минимум декларирует себя, а не прячется полностью.

Такая структура типична для современных AI-краулеров: Mozilla-приставка нужна для совместимости со статистическими системами и нехитрыми фильтрами, а сама строка при этом остаётся различимой и легко блокируемой. Появление версии «/1.0» означает, что в будущем не исключены и другие версии, поэтому при написании правил лучше использовать регулярное выражение, допускающее любой номер версии.

Ещё один практический нюанс: регистр в блокировках. Токены KeenableBot и Keenable-User пишутся с большой буквы K, но надёжные правила должны быть регистронезависимыми (флаг NC в Apache, ~* в nginx), потому что неаккуратные клиенты могут прислать keenablebot или KEENABLEBOT.

IP-адреса и инфраструктура

Google Cloud в основе

И API, и наблюдаемые краулерные адреса Keenable размещаются в облаке Google (AS396982, сеть *.bc.googleusercontent.com, дата-центры в США). Например:

• DNS-запись api.keenable.ai → 34.107.249.55 (Google Cloud, AS396982, регион Kansas City);
• наблюдавшиеся адреса KeenableBot — 34.121.120.30, 34.56.80.44, 34.45.226.223, 136.65.120.206;
• наблюдавшиеся адреса Keenable-User — 34.55.18.20, 136.111.254.239.

Важное предостережение: диапазоны вроде 35.222.0.0/16, 34.58.0.0/16, 35.193.0.0/16 — это общие пулы Google Cloud, доступные сотням тысяч клиентов, и привязывать их к Keenable нельзя. Нельзя блокировать «весь Google Cloud» — под запрет попадут десятки невинных сервисов и одновременно это не гарантирует блокировки Keenable, которая в любой момент может получить другие адреса в тех же пулах.

Почему IP-блокировка ненадёжна

У Keenable нет публичного списка IP-диапазонов краулера (в отличие, например, от Google, который публикует свои). На практике краулеры крупных AI-компаний мигрируют между дата-центрами, а публичные облака выдают клиентам огромные динамические пространства. Поэтому правильная стратегия — блокировать по юзер-агенту, а IP учитывать только как справочную информацию для анализа логов и для тонкой настройки WAF-правил Cloudflare.

Продукты Keenable и роль краулера

Чтобы понять, зачем краулеру ходить к вам на сайт десятки раз в сутки, полезно посмотреть на продуктовую линейку компании:

• Search API — REST-эндпоинт api.keenable.ai/v1/search, возвращающий ранжированные результаты с заголовками, описаниями и датами. Имеет продвинутые фильтры по дате публикации и дате индексации.
• MCP-сервер — точка api.keenable.ai/mcp, через которую поиск подключается к Claude Code, Cursor, Windsurf и другим MCP-совместимым агентам.
• fetch_page_content — превращает URL в чистый markdown; в этом инструменте как раз заложена логика «сначала сохранённая копия из индекса, при live=true — живой поход на сайт».
• Клиентский CLI — устанавливается через brew (brew install keenableai/tap/keenable-cli) и сам настраивает MCP для обнаруженных агентов.
• SELECT (Web Query Language) — технология превращения сотен веб-страниц в таблицу значений с источником для каждой строки. По сути это один запрос, который читает десятки тысяч страниц.
• Time Machine — исторический поиск по прошлым версиям индексных слепков; находится в статусе раннего доступа.

Любой из этих продуктов потенциально генерирует краулинг. Живой пример — партнёрство с headless-браузером Lightpanda: компания сообщила в блоге, что агент Lightpanda при отсутствии собственного ключа ищет через keyless-эндпоинт Keenable, причём клиент встроен прямо в бинарник браузера на языке Zig. Чем больше таких интеграций — тем больше реального фонового трафика доходит до сайтов.

Цены как индикатор масштаба

Открытая «витрина» Keenable важна и вот почему: она показывает, насколько активно планируется использовать индекс:

• Бесплатный тариф — 100 000 авторизованных запросов в месяц, повторяющихся ежемесячно;
• keyless-эндпоинт — общий пул 1 000 запросов в час и 10 запросов в секунду на IP, без авторизации и без кредитов;
• Agent Builder — 4 доллара за 1 000 запросов, только облако;
• Frontier — 1 доллар за 1 000 запросов при нагрузке от 100 RPS, облако и on-premises;
• дефолтный лимит авторизованного трафика — 10 запросов в секунду на организацию.

Кредитная система более сложная, чем «один запрос — одна единица»: существуют SKU search.pro, search.realtime, fetch, fetch.live, и по документации конкретные цены могут списывать более одного кредита за вызов. Когда бесплатный пул исчерпан, API отвечает кодом HTTP 402. Для владельца сайта из этих цифр важна одна: 100 000 бесплатных запросов и 100 RPS на продакт-тарифе — это институциональные масштабы потребления, которые превращают краулинг в постоянный фон, а не в единичные визиты.

Природа бота: retrieval, training или поиск?

Выше уже упоминалась классификация Cloudflare. Применим её к Keenable.

• Keenable-User — классический retrieval/Agent: ходит в момент запроса пользователя, требует ключ для высоких лимитов, при отсутствии ключа ограничен общими пулами. Блокировать его стоит лишь тем, кто не хочет, чтобы контент отдавался агентам по требованию.
• KeenenableBot — фоновый сборщик индекса. По заявлениям компании контент индекса используется «и при обучении, и при рантайме» — это определение mixed-purpose Search+Training. Cloudflare в такой ситуации рекомендует трактовать бота как Training и блокировать во всех пресетах, запрещающих тренировку.

Есть ещё один нюанс честности. Сравнение с поисковиками в пользу KeenableBot было бы корректным только в том случае, если бы компания выполняла обязательства «поискового» бартера — атрибутировала источники, уважала robots.txt, публиковала списки IP и давала владельцам сайтов инструменты контроля. Ничего из этого на момент исследования не опубликовано. Поэтому на практическом уровне отличать «индексирующий бот» от «тренировочного» для защиты сайта не нужно: отношение к нейтральному сайту в обоих случаях одинаково — незваное копирование содержимого без обратной отдачи.

Экономика краулинга: почему трафик индексов будет расти

У решения Keenable строить собственный индекс есть экономическая логика, из которой напрямую вытекает рост нагрузки на сайты.

Индекс требует постоянных переобходов

Любой веб-индекс живёт за счёт свежести. Если страница изменилась, а копия в индексе не обновлена, поисковый API начнёт отдавать устаревшие данные - и клиенты-агенты заметят это по качеству ответов. Поэтому серверная часть вынуждена постоянно возвращаться на успешно обойдённые сайты, не говоря о новых. Переобход горячих страниц - это не одноразовая операция, а непрерывный фоновый процесс, и его объём тем больше, чем больше клиентов платят за свежесть.

Перепродажа retrieval усиливает погоню за свежестью

Бизнес-модель Keenable - продажа доступа к индексу другим AI-системам и агентным рантаймам. Чем больше потребителей, тем больше запросов, а чем больше запросов - тем выше требования к актуальности. Возникает порочный круг для веб-мастеров: успех продукта вендора означает более частые и глубокие переобходы их сайтов. Бесплатный тариф в 100 000 запросов в месяц и keyless-эндпоинт (1 000 запросов в час, 10 в секунду на IP) лишь усиливают этот эффект - порог входа для любого агента нулевой.

Что из этого следует владельцу сайта

Развилка простая: либо сайт сознательно остаётся в индексе Keenable (и тогда стоит хотя бы понимать, что копии страниц будут отдаваться агентам без визита на сайт), либо владелец добивается исключения через блокировку на своей стороне - так как официального opt-out не существует. Третьего пути (например, «пусть копирует только главную») тоже нет: точечных правил по путям Keenable не публикует.

Практический тезис: если блокировать бот - блокировать комплексно и сразу, не дожидаясь, пока страницы будут переиндексированы десятки раз. Каждый дополнительный переобход - это израсходованные ресурсы вашего сервера и контент, который снова попал в чужой индекс.

Прозрачность: что Keenable публикует (и чего нет)

Документация для потребителей API

Весь публичный архив документации завёрнут в файл docs.keenable.ai/llms.txt. Он содержит порядка сорока страниц, и все они посвящены использованию поискового API с точки зрения клиента: Quickstart, авторизация, лимиты, кредиты, MCP, CLI, интеграции, changelog, справочник API. Раздела «документация для владельцев сайтов» в нём нет в принципе — нет страницы про краулер, нет страницы про то, как из него выйти, нет страницы с IP-диапазонами.

Самое близкое к признанию существования краулера — описание функции fetch: «по умолчанию поддерживаются только URL, которые Keenable уже проиндексировала; передайте live=true, чтобы забрать страницу напрямую с источника, включая не проиндексированные URL».

Политика для владельцев сайтов

На момент написания статьи у Keenable отсутствуют:

• описание юзер-агента краулера в официальных документах;
• политика обработки robots.txt сторонних сайтов;
• страница с IP-диапазонами краулера;
• форма opt-out для владельцев сайтов;
• процедура DMCA и designated agent (в договоре нет даже раздела про авторские права).

Независимое издание The Prompt Insider проверило и TechCrunch, и пресс-релиз инвестора Accel и пришло к выводу: ни имя краулера, ни user-agent, ни robots.txt-политика не раскрыты — на момент публикации «не является вопросом сложности поиска, этого просто нет в открытом доступе». Прогрессивные обзоры (например, progressiverobot.com) формулируют то же самое: «ничего про robots.txt, лицензирование и opt-out для издателей».

Отдельная тонкость: собственный robots.txt сайта keenable.ai устроен либерально — на своём маркетинговом сайте компания «намеренно не ограничивает» AI-краулеры, резонно замечая, что продаёт агентам и хочет быть для них читаемой. Это политика для собственного сайта и она ничего не говорит об отношении их краулера к чужому robots.txt.

Trust Center

Страница trust.keenable.ai построена на платформе Vanta и почти пуста с точки зрения аттестаций:

• SOC 2 — опубликованного отчёта нет; есть только подготовительный контроль «System Description» и стандартное письмо о начале аудита (Engagement Letter), что указывает на начатую, но не завершённую подготовку;
• ISO 27001 — отсутствует;
• Data Processing Agreement (DPA) — публичного шаблона нет; политика конфиденциальности говорит, что enterprise-данные обслуживаются по отдельному договору;
• GDPR-артефакты — отдельной секции, прав субъектов и SCC нет; политика заявляет, что на сигналы Do Not Track компания не отвечает.

Для владельца сайта это означает практическую вещь: кроме блокирования на своей стороне, формальных механизмов защиты или переговоров на текущий момент просто не существует.

Правовые аспекты: что написано в договорах

Лицензия на контент пользователей

Условия использования Keenable (редакция от 30.07.2026) содержат широкую лицензию на User Content: неисключительную, всемирную, безроялти, полностью оплаченную, передаваемую, сублицензируемую на несколько уровней, бессрочную и безотзывную. Она разрешает Keenable копировать, отображать, загружать, исполнять, распространять, хранить, изменять и использовать контент пользователя: для работы сервиса, для разработки и улучшения продуктов «включая AI-модели», а также для маркетинга. Пользователь также соглашается на удаление метаданных и отказывается от моральных прав и атрибуции.

Важная оговорка юридической точности: эта лицензия касается контента, который пользователь загружает в сервис, а не веб-контента третьих сайтов, который индексирует краулер. Публичных заявлений о том, что модели обучаются именно на контенте индексируемых сайтов, нет ни в договорах, ни в независимых обзорах — это не подтверждено.

Использование данных об использовании

Раздел Usage Data разрешает Keenable использовать обезличенные/агрегированные данные об использовании для поддержки, улучшения, обучения (train) и дообучения (finetune) текущих и будущих продуктов — в том числе после прекращения пользования сервисом. Именно этот пункт вызвал больше всего критики в обзоре Neodrop: «договор по умолчанию позволяет Keenable обучаться на данных использования и хранить контент доступным для улучшения продукта и обучения моделей, если отдельное соглашение не говорит иное».

Ограничения на вывод API

API Output лицензирован только для внутренних бизнес-целей клиента: запрещены перепродажа, сублицензирование, распространение в standalone-виде, переупаковка в CSV/XML/JSON, использование в конкуренции с Keenable и раскрытие вывода третьим лицам как отдельного продукта.

Запрещённые сферы и ответственность

Договор запрещает использовать сервис для автоматических решений в существенных сферах — финансовой, юридической, трудовой, медицинской, образовательной, жилищной, страховой, социального обеспечения — и требует человеческой проверки при принятии решений. Также снимается ответственность за то, что вывод не является профессиональным советом. Любопытная деталь: самим подписчикам запрещено использовать сервис «для дата-майнинга, роботов, скрейпинга и подобных способов сбора», тогда как сам Keenable скрейпит весь веб — классическая асимметрия «для тебя запрещено, для нас — бизнес-модель».

Для физических лиц действует обязательный арбитраж и отказ от коллективного иска.

Техническое устройство краулинга: как бот читает сайт

Чтобы правильно выстраивать защиту, полезно понимать, как технически работает краулер индекса и чем он отличается от обычного «живого» фетча агента.

Порядок действий краулера

Типовой цикл фонового краулера примерно таков:

• запрос корня сайта и чтение robots.txt (если вендор соблюдает REP);
• обход списка исходящих ссылок на странице: разделы, статьи, пагинация, карты сайта (sitemap.xml), если они обнаружены;
• сохранение слепка HTML в собственном хранилище и извлечение текстового содержимого в чистый вид (в терминах Keenable - «clean markdown»);
• при повторных визитах - сравнение с предыдущим слепком, чтобы понять, менялась ли страница;
• проверка новых URL, появившихся на сайте с момента прошлого обхода.

Глубина такого обхода больше, чем у печатных агрегаторов, и сравнима с поисковыми ботами. Именно поэтому KeenableBot часто находят в логах по запросам к глубоким разделам, а не только к главной странице.

Живой фетч (live=true)

Отдельный сценарий - функция fetch_page_content с параметром live=true, когда агент пользователя просит «прочитать вот этот URL сейчас». В этом случае запрос идёт напрямую к вашему веб-серверу с юзер-агентом Keenable-User, минуя индексную копию. Такой запрос неотличим от обычного короткого визита и может прийти даже на страницы, которые краулер ранее не сохранял.

Роль headless-браузеров

Как показал блог Keenable о партнёрстве с Lightpanda, современные краулинговые движки всё чаще выполняют JavaScript и эмулируют браузерную среду. Это означает, что часть трафика может выглядеть в логах «человечнее», но идентифицирующая часть юзер-агента при этом должна оставаться. При мониторинге логов смотрите не на случайную похожесть на браузер, а на наличие слова keenable в строке агента.

Как обнаружить KeenableBot в логах

Строки в access-логах

Самый быстрый способ понять, ходит ли бот на ваш сайт, — поиск по логам веб-сервера. В nginx типичная запись выглядит так:

34.121.120.30 - - [12/Sep/2026:08:14:03 +0000] "GET /statiya HTTP/1.1" 200 8453
"-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; KeenableBot/1.0; +https://keenable.ai/)"

Выделить такие строки можно командами вроде:

zgrep -i "keenable" /var/log/nginx/access.log* | head
zgrep -i "KeenableBot" /var/log/nginx/access.log* | head
zgrep -i "Keenable-User" /var/log/nginx/access.log* | head

В системных журналах Apache ищите всё, что содержит подстроку theyenable (регистронезависимо), а также адреса из списка наблюдаемых IP.

На что обращать внимание

• Сверьте частоту запросов: одиночные визиты — обычное дело, сотни запросов в сутки с одного IP при одинаковом UA — признак краулинга.
• Смотрите на глубину обхода: печатные агрегаторы и мониторинги заходят на главную; краулер индекса ползёт по разделам, статьям и каталогам, эмулируя структуру сайта по ссылкам.
• Сверьтесь со списком наблюдаемых адресов из таблицы выше.
• Учитывайте, что компания краулер не документирует; поэтому надёжного официального альтернативного подтверждения, кроме udger, не существует.

Блокировка через .htaccess

Что такое .htaccess

.htaccess — распределённый конфигурационный файл Apache, который позволяет менять поведение веб-сервера на уровне отдельной директории без перезапуска Apache. Он де-факто является стандартом для виртуального хостинга и панельных окружений вроде FastPanel, поэтому блокировка через него — самый доступный вариант для подавляющего большинства обычных сайтов.

Три обязательных условия корректной работы:

• Apache должен быть собран с модулем mod_rewrite;
• в конфигурации виртуального хоста должна быть разрешена директива AllowOverride All или AllowOverride FileInfo;
• сам файл должен лежать в корневой директории сайта (или в директории, где нужно применять правила).

Простое правило на mod_rewrite

Классический рецепт блокировки Keenable в .htaccess выглядит так:

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} KeenableBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Keenable-User [NC]
RewriteRule .* - [F,L]

Разбор построчно:

• RewriteEngine On — включает движок перезаписи; без этой строки правила не работают;
• RewriteCond %{HTTP_USER_AGENT} KeenableBot [NC] — проверяет значение HTTP-заголовка User-Agent на вхождение подстроки KeenableBot; флаг NC делает сравнение регистронезависимым;
• OR — связывает условия логическим ИЛИ: второе условие сработает, даже если первое не сработало;
• RewriteCond %{HTTP_USER_AGENT} Keenable-User [NC] — ловит второй, «фетчевый» агент;
• RewriteRule .* - [F,L] — если хоть одно условие истинно, вернуть клиенту ответ 403 Forbidden ([F]), а обработку дальнейших правил прекратить ([L]).

Именно парность условий критична: блокировка только KeenableBot оставит дыру для Keenable-User, и наоборот.

Компактный вариант одной строкой

Использование регулярного выражения позволяет объединить два условия в одно:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "KeenenableBot|Keenable-User" [NC]
RewriteRule .* - [F,L]

Литерал | внутри строки означает «или». Такой вариант легче читать и проще поддерживать.

Отдача 410 Gone вместо 403

Некоторые администраторы предпочитают не 403, а код 410 Gone — он говорит клиенту, что ресурс удалён и бесполезно ходить повторно. Формально бот может и проигнорировать код, но для аккуратных клиентов 410 снижает настойчивость повторных попыток:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "KeenenableBot|Keenable-User" [NC]
RewriteRule .* - [G,L]

Блокировка через SetEnvIf (альтернатива)

Кроме mod_rewrite, Apache предоставляет модуль mod_setenvif, который позволяет присвоить переменную окружения по значению юзер-агента, а затем запретить доступ через контейнер Require:

SetEnvIf User-Agent "KeenenableBot" bot_blocked
SetEnvIf User-Agent "Keenable-User" bot_blocked

<RequireAll>
    Require all granted
    Require not env bot_blocked
</RequireAll>

Разница между подходами невелика: mod_rewrite даёт гибкие флаги (F, G, L, NC) и работает на уровне движка перезаписи, а SetEnvIf + Require реализует классическую модель авторизации Apache 2.4. Оба способа корректны, и выбор сводится к стилю остального конфига: если на сервере уже используется Require, удобнее SetEnvIf; если правятся только RewriteRule - оставайтесь на mod_rewrite.

Предостережения по .htaccess

• Блок по User-Agent работает только против ботов, которые честно представляются. Нечестный сборщик может подменить строку — и тогда блок бесполезен. Поэтому .htaccess — первый, но не единственный рубеж.
• Никогда не вставляйте блокировку в середину правил WordPress: стандартный .htaccess WordPress уже содержит свои RewriteRule для пермалинков. Свои правила ставьте сразу после строки RewriteEngine On и до «# BEGIN WordPress».
• Файл .htaccess обрабатывается на каждый запрос — при очень высоких нагрузках Apache читает его каждый раз (хотя modern versions кешируют). Для высоконагруженных проектов производительнее выносить правила в конфиг виртуального хоста; та же логика реализуется там идентичными директивами.
• Документация Apache прямо рекомендует для больших проектов переносить такие правила из .htaccess в конфигурацию, это лишь вопрос масштаба, а не корректности.

Совместимость с панелями (FastPanel, ISPmanager, cPanel)

В панельных окружениях .htaccess обычно читается автоматически. Убедитесь, что файл принадлежит тому же пользователю, которому принадлежит корень сайта, и что права не меньше 644. После сохранения проверьте сайт обычным браузером и тестовым curl-запросом (раздел про проверку ниже).

Блокировка через nginx

На серверах, где нет Apache и .htaccess не читается вообще (это принципиальное отличие: nginx не умеет в .htaccess), применяется один из двух способов: директива if с регулярным выражением либо map-переменная.

Вариант через map (рекомендуется)

Чистый и поддерживаемый способ — сначала объявить map-переменную в контексте http, а затем ссылаться на неё в виртуальном хосте. Типичный блок:

map $http_user_agent $ai_bot {
    default 0;
    "~*KeenenableBot"       1;
    "~*Keenable-User"     1;
}

Значения с префиксом ~* — регистронезависимые регулярные выражения; переменная $ai_bot примет значение 1, если юзер-агент содержит одну из подстрок, и 0 в противном случае. Использование в server-блоке:

server {
    ...
    if ($ai_bot) {
        return 403;
    }
    ...
}

map объявляется один раз и может включаться, например, отдельным файлом вида /etc/nginx/conf.d/ai-bots.conf. Главное преимущество: добавление новых ботов — одна строка в одном месте, а не правка каждого виртуального хоста.

Вариант через if прямо в server

Для одиночного сайта допустим короткий вариант:

if ($http_user_agent ~* "keenable") {
    return 403;
}

Регулярное выражение ~* "keenable" перехватит обе строки (и любые будущие варианты вида Keenable-Something). Минус такого подхода — избыточность: вместе с Keenable блокируется любая строка, содержащая слово keenable, что для этого краулера практически не даёт ложных срабатываний, но лишает вас точечности.

Официальная документация nginx описывает map как механизм зависимых переменных и явно рекомендует map для ситуаций, когда решение должно приниматься в нескольких местах конфигурации.

Синтаксис регулярных выражений: ~ и ~*

• ~ — регистрозависимое сравнение;
• ~* — регистрозависимое (insensitive) сравнение.

Для блокировки ботов всегда используйте ~*: вы защищаетесь и от KeenableBot, и от случайного keenablebot.

Блокировка через Cloudflare

Если сайт стоит за Cloudflare, эффективнее срабатывают правила на уровне сети до попадания на origin.

Встроенные AI-политики

Cloudflare в 2026 году предоставляет управляемые политики «AI bot policies», которые классифицируют ботов по поведению на три категории — Search, Agent, Training — и позволяют блокировать их на всех страницах либо только на страницах с рекламой. Согласно документации, с 15 сентября 2026 года для новых доменов включён дефолт: Training и Agent блокируются, Search остаётся разрешённым; кроме того, mixed-purpose боты (Search+Training) блокируются всеми конфигурациями, запрещающими тренировку.

Учитывая, что KeenableBot официально описан компанией как используемый и при обучении, и при рантайме, он де-факто попадает под категорию mixed-purpose — то есть блокируется пресетами, запрещающими Training. Keenable-User, работающий в реальном времени по запросу агента, соответствует категории Agent.

Именованная проверка: ядро уджер

Важное уточнение: KeenableBot отсутствует в списке verified-ботов Cloudflare (Radar). Это означает, что эвристическая классификация будет работать не по имени, а по поведению агрегатов. Гарантией является только кастомное WAF-правило по юзер-агенту.

Кастомное WAF-правило

В разделе WAF → Custom Rules добавьте выражение фильтрации запросов:

(http.user_agent contains "KeenenableBot") or (http.user_agent contains "Keenable-User")

с действием Block. Такое правило применяется к сетевому краю Cloudflare, не нагружает origin и работает до того, как запрос дойдёт до вашего веб-сервера. Именно эту комбинацию — «имя бота не в verified-списке → эвристика может не поймать → добавляем явное правило» — стоит использовать владельцам сайтов под Cloudflare.

robots.txt: ограничения метода

Минимальная декларация

Декларация для конкретных агентов оформляется отдельными группами:

User-agent: KeenableBot
Disallow: /

User-agent: Keenable-User
Disallow: /

Правила соответствуют стандарту REP (RFC 9309), токены чувствительны к регистру, поэтому используются точные написания.

Почему этого недостаточно

robots.txt — это «знаковая система», а не «замок»: протокол добровольный. Спецификация работает только против послушных ботов, а крупные компании и Google, и Cloudflare прямо предупреждают: нерадивые скрейперы игнорируют robots.txt, подделывают юзер-агенты и ходят через резидентные прокси. Применительно к Keenable проблема острее: компания не публикует заявления об уважении Robots Exclusion Protocol, поэтому полагаться на декларацию нельзя.

Последовательная стратегия выглядит так:

• robots.txt ставим как первый, информационный слой (вдруг краулер станет послушным);
• фактическую блокировку выполняем на уровне веб-сервера (.htaccess/nginx) или CDN (Cloudflare WAF);
• лог-анализ держим включённым, чтобы заметить, что бот игнорирует декларацию.

Проверка блокировки: тесты

Имитация запроса через curl

После написания правил проверьте результат из терминала. Подмена юзер-агента выполняется флагом -A, заголовки смотрим через -I:

curl -A "KeenableBot/1.0" -I https://example.com/
curl -A "Keenable-User/1.0" -I https://example.com/
curl -A "Mozilla/5.0 Chrome/126" -I https://example.com/

Ожидания:

• первые две команды — HTTP/1.1 403 Forbidden;
• третья команда от реального вида браузерной строки — прежний рабочий ответ (200 или 301);

Чего проверять дополнительно

• Повторный запрос с нижним регистром (keenablebot) — убедиться, что NC/~* работает;
• запрос с версией вида KeenableBot/2.0 — проверить, что ваше регулярное выражение ловит любые версии;
• отдельную страницу, а не только главную — правила .htaccess в корне покрывают и все поддиректории, но на nginx map/if применяются на уровне server.

Если первая команда вернула 200 — правило не сработало, ищите опечатку в регулярном выражении или (для .htaccess) проверяйте наличие модулей mod_rewrite и AllowOverride.

Автоматизация мониторинга и реагирования

Единоразовая блокировка - это половина дела. Вторая половина - постоянное наблюдение, потому что боты меняют строки, а списки блокировки устаревают.

Простейший лог-скрипт

Например, ежедневная сводка числа запросов Keenable до и после блокировки может строиться так:

#!/bin/bash
LOG=/var/log/nginx/access.log
echo "KeenableBot  за сутки:"
zgrep -ic "keenable" $LOG* || true
echo "Топ-10 адресов агента Keenable:"
zgrep -i "keenable" $LOG* | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Скрипт легко поставить в cron на раз в сутки. После введения блокировки ожидаемый результат - нулевые новые записи; любые оставшиеся визиты с бота говорят о том, что либо правило не сработало в конкретной точке, либо бот сменил строку.

Алёртинг

На хостингах без SIEM достаточно простого механизма: скрипт, который при обнаружении новой записи с ключевым словом keenable отправляет сообщение в Telegram или e-mail. Такая система замечает возвращение бота и смену версии юзер-агента раньше, чем сайт начнёт терять ресурсы.

Контроль обновления блоклистов

Раз в месяц имеет смысл сверяться с открытыми списками (ai-robots-txt/ai.robots.txt, Known Agents) и переносить появившиеся там новые токены в свои правила: если Keenable официально оформит краулер, токен появится именно там. Мониторинг - часть обслуживания сервера, а не разовая задача.

Актуальное состояние блоклистов

Молодость бота (первое наблюдение KeenableBot — лишь 12 сентября 2026 года) означает, что готовые списки AI-ботов его пока не содержат:

• DarkVisitors (переименован в Known Agents) — записи KeenableBot нет, страницы /agents/keenablebot отдают 404;
• Cloudflare Radar (verified bots) — запись отсутствует;
• блоклист GitHub ai-robots-txt/ai.robots.txt (nginx-block-ai-bots.conf, .htaccess, Caddyfile, HAProxy, lighttpd) — содержит сотни токенов, но токенов Keenable в нём пока нет;
• Kownable, WhatIsBot — домены в нерабочем/нерелевантном состоянии;
• edger.com — единственный каталог, где бот описан (категория Uncategorised, статус Active).

Практический вывод: до появления Keenable в крупных списках (обновления приходят по мере наблюдений) единственные надёжные правила — ваши собственные блоки по UA, описанные выше. Отслеживайте обновления репозитория ai-robots-txt: как только токены будут добавлены, вы сможете просто обновить свои файлы.

Перечисленное в прошлой таблице сравнение наглядно демонстрирует, чем Keenable отличается от ветеранов индустрии. Для полноты сведём публичность операторов в отдельную таблицу - именно по этим критериям владелец сайта обычно решает, доверять ли боту:

Оператор	Публикует юзер-агент	Публикует IP-диапазоны	Публикует robots.txt-политику	Есть opt-out для издателей
Google (Googlebot)	Да	Да	Да	Да
OpenAI (GPTBot / OAI-SearchBot / ChatGPT-User)	Да	Да	Да	Да
Anthropic (ClaudeBot)	Да	Да	Да	Да
Perplexity (PerplexityBot)	Да	Да	Да	Да
Common Crawl (CCBot)	Да	Да	Да	Нет (открытые данные)
Keenable (KeenableBot / Keenable-User)	Нет	Нет	Нет	Нет

Вывод из сопоставления прост: за исключением Keenable, все заметные операторы AI-краулеров 2026 года оформляют свою идентичность и дают издателям инструменты контроля. Отсутствие такой оформленности у Keenable не является технической случайностью - это публично выбранная позиция нового игрока, которую издатели компенсируют собственными блокировками.

Сравнение с другими AI-краулерами

Бот	Компания	Назначение	robots.txt-политика	Способ блокировки
KeenableBot	Keenable.ai	Индексирование веба для AI-поиска (заявка б/и)	Не публикуется	UA (htaccess/nginx/CF)
Keenable-User	Keenable.ai	Фетч страниц по запросу агента	Не публикуется	UA (htaccess/nginx/CF)
GPTBot	OpenAI	Тренировка GPT-моделей	Опубликована (Token: GPTBot)	UA
OAI-SearchBot	OpenAI	Живой поиск в ChatGPT	Опубликована	Управляемое решение
ChatGPT-User	OpenAI	Чтение по требованию пользователя	Опубликована	Управляемое решение
ClaudeBot	Anthropic	Тренировка Claude	Опубликована (Token: ClaudeBot)	UA
PerplexityBot	Perplexity	Поиск-индексация для ответов	Опубликована	UA
CCBot	Common Crawl	Открытые наборы данных	Опубликована (Token: CCBot)	UA
Bytespider	ByteDance	Тренировка, частые запросы	Опубликована	UA

Особенность Keenable относительно перечисленных: почти все операторы-ветераны публикуют имя бота, юзер-агент, IP-списки и политику robots.txt (Google, OpenAI, Anthropic, Perplexity). Keenable публично не сделала ничего из перечисленного; единственное официальное упоминание в реестре найдено сторонним сервисом udger. Это ставит владельцев сайтов в положение «нечем управлять, кроме собственных блокировок». Обзоры The Rundown и Neodrop сходятся в этом выводе: независимость от поисковой монополии — да, но независимость издателя от краулинга такой инфраструктуры — предмет отдельного обсуждения.

Частые вопросы

Влияет ли блокировка Keenable на поисковую выдачу?

Нет. Keenable не является поисковой системой для людей и не участвует в ранжировании вашего сайта в Google, Yandex или Bing. Блокировка затрагивает только копии страниц в собственном индексе Keenable и запросы её API.

Будет ли бот пытаться обходить блокировку?

Поведение конкретно этой компании неизвестно, так как политику краулера она не публикует. В общем случае аккуратные вендоры меняют юзер-агент и версии со временем, поэтому мониторинг логов - обязательная часть стратегии.

Как поступать с новыми версиями бота (KeenenableBot/2.0)?

Правила, описанные в статье, не фиксируют номер версии и перехватят любую версию. Дополнительно следите за обновлениями открытых блоклистов - они быстрее всех замечают новые вариации известных краулеров.

Это поисковый бот Google?

Нет. KeenableBot не имеет отношения ни к Google, ни к Bing, ни к Yandex. Это краулер частной компании Keenable.ai, строящей собственный индекс.

Обучается ли Keenable на контенте моего сайта?

Прямых подтверждений, что модели обучаются именно на контенте индексируемых сайтов, нет ни в ToS, ни в независимых обзорах. Зато ToS явно разрешает обучение на данных об использовании (usage data) и на контенте, загруженном пользователями. Модель компании — перепродажа доступа к индексу другим AI-системам, поэтому сохранённые копии страниц в любом случае попадают в чужие ответы без посещения вашего сайта.

Могу ли я официально отказаться (opt-out)?

На момент статьи — нет. Публичного opt-out-механизма, DMCA-процедуры и страницы для веб-мастеров у Keenable не существует. Остаётся только техническая блокировка на своей стороне.

robots.txt достаточно?

Нет. это декларация. С убеждением, что бот уважает REP, подтверждений нет; блокируйте на уровне сервера или CDN.

Что выбрать: .htaccess или nginx?

Зависит от сервера: Apache читает .htaccess, nginx — нет. Под FastPanel и классический виртуальный хостинг подходит .htaccess; под выделенный сервер на nginx используйте directory if/map.

Блокировка затронет поисковые системы?

Нет, если блокировать только строки Keenable. Googlebot, Bingbot и YandexBot имеют собственные юзер-агенты, и правила выше их не касаются.

Что делать с уже собранными копиями страниц?

Удалить их нельзя — нет контактных инструментов. Можно сократить будущее копирование блокировкой и отправить запрос в поддержку (privacy@ и support@keenable.ai) — но формальных обязательств по выполнению такого запроса нет.

Распространённые ошибки при блокировке

Практика показывает, что большинство проблем с блокировкой AI-ботов сводится к небольшому набору типовых ошибок:

• блокировка только одного из двух юзер-агентов Keenable - второй канал остаётся открытым;
• использование регистрозависимых правил без флага NC (Apache) или ~* (nginx) - «KeenableBot» и «keenablebot» начинают вести себя по-разному;
• блокировка всего Google Cloud по IP - под запрет попадают десятки несвязанных сервисов, а Keenable в любой момент получит новые адреса в тех же пулах;
• уверенность, что robots.txt решает проблему - это лишь декларация, а не техническая преграда;
• слишком широкая блокировка по слову «keenable» там, где нужна точечность (например, правило ~*keenable может зацепить строки будущих продуктов компании, которых вы, возможно, хотели бы впустить);
• забытая проверка AllowOverride в конфигурации Apache - правило в .htaccess молча игнорируется;
• отсутствие проверки через curl после внесения правил - ошибка в регулярном выражении обнаруживается уже после потери трафика;
• при обновлении версии бота (KeenenableBot/2.0) правила с жёстко прописанной версией перестают работать - всегда пишите выражение без фиксации номера версии.

Следование простой последовательности - robots.txt, серверная блокировка, проверка curl, мониторинг - закрывает большинство из этих ошибок ещё до того, как они станут проблемой.

Практический чек-лист защиты сайта

Итоговая последовательность действий, которую можно выполнить за один вечер, сводится к восьми пунктам:

1. Добавить в robots.txt декларативные группы для KeenableBot и Keenable-User с Disallow: /.
2. Внести серверную блокировку: в Apache - блок mod_rewrite в .htaccess (сразу после RewriteEngine On), в nginx - map-переменную или if с ~*.
3. Если сайт за Cloudflare - добавить кастомное WAF-правило по (http.user_agent contains "KeenableBot") or (http.user_agent contains "Keenable-User") с действием Block.
4. Проверить блокировку через curl с подменой юзер-агента и обычным браузерным юзер-агентом.
5. Настроить ежедневную выгрузку из логов всех записей со словом keenable и сравнение с днём до блокировки.
6. Раз в месяц сверяться с открытыми списками AI-ботов и переносить новые токены в свои правила.
7. Убедиться, что правила не задевают поисковых ботов (Googlebot, Bingbot, YandexBot) - тестировать их отдельно.
8. Зафиксировать изменения и дату в журнале изменений сервера - чтобы при откате знать, что именно и зачем менялось.

Этот цикл даёт и защиту, и наблюдаемость: сайт не отдаёт контент в чужой индекс по умолчанию, а если бот вернётся под новой строкой - вы увидите это в логах и сможете отреагировать.

Дополнительные меры: заголовки и метаданные

Блокировка на уровне сервера - основная защита, но её можно и нужно дополнить сигналами, которые понятны аккуратным краулерам.

X-Robots-Tag и noai

В HTTP-ответ можно добавлять заголовок X-Robots-Tag, который сообщает роботам о запрете индексации и использования в AI:

X-Robots-Tag: noindex, nofollow, noai, noimageai

Аналогичный сигнал можно заложить в HTML-страницу через мета-тег: <meta name="robots" content="noindex, nofollow, noai, noimageai" />

Поддержка значений noai/noimageai в 2026 году расширена: их учитывают многие тренировочные и ретривал-краулеры крупных вендоров. Однако, как и в случае с robots.txt, это честный запрос, а не техническая блокировка, - бот, который игнорирует декларации, пройдёт мимо.

Как сочетаются слои защиты

Правильная архитектура защиты выглядит трёхслойной:

• слой по умолчанию - robots.txt и X-Robots-Tag для послушных ботов;
• технический слой - правила на веб-сервере (.htaccess, nginx) для всех, кто дошёл до origin;
• сетевой слой - Cloudflare WAF или аналогичный CDN-контроль для блокировки до origin;
• наблюдательный слой - мониторинг логов, который ловит смену строк и попытки обхода.

Ни один из слоёв в одиночку не гарантирует результат, но вместе они превращают разовую блокировку в управляемую политику.

Резюме

KeenableBot — фоновый краулер новых AI-поисковой инфраструктуры Keenable.ai, строящей независимый веб-индекс на 100+ миллиардов документов после привлечения 26 миллионов долларов от Accel. Рядом с ним фиксируется второй агент Keenable-User, который фетчит страницы по живому запросу агентов. Обе строки формально маскируются под браузер-префикс Mozilla/5.0 AppleWebKit/537.36, но самоидентифицируются в части compatible; и несут ссылку +https://keenable.ai/.

Ключевые выводы для владельца сайта:

• бот реально существует и наблюдается, но официальной документации от компании нет — ни robots.txt-политики, ни IP-списков, ни opt-out;
• два агента нужно блокировать в связке, иначе останется канал обхода;
• блок по UA — единственная надёжная мера (Apache .htaccess, nginx, Cloudflare WAF); robots.txt — только информационный первый слой;
• IP-блокировки по «диапазонам Google Cloud» бесполезны — они общие для сотен тысяч сервисов;
• компания публикует широкие лицензии на данные пользователей и data usage, но не даёт издателям инструментов контроля;
• следите за обновлениями открытых блоклистов (ai-robots-txt, Known Agents): отсутствие токенов сегодня — вопрос времени, а не политики.

В мире, где «агенты читают интернет», выращивание собственного индекса означает массовое копирование чужих сайтов. Пока оператор не предложит издателям нормальный механизм контроля, единственная асимметричная мера остаётся на вашей стороне сервера — строгие правила .htaccess или nginx на обе строки Keenable. Именно это и является практическим предназначением данной статьи.

Ссылки

• Официальный сайт Keenable: keenable.ai
• Документация API: docs.keenable.ai и индекс llms.txt, интеграции integrations
• MCP-сервер: api.keenable.ai/mcp
• Технораунд Accel: TechCrunch — Accel-backed Keenable is indexing the web for AI agents
• Блог Keenable (Lightpanda): Keenable now runs inside Lightpanda
• Реестр ботов udger (KeenableBot): udger.com — KeenableBot
• Trust Center: trust.keenable.ai
• Статус API: status.keenable.ai
• Документация Apache mod_rewrite: httpd.apache.org — mod_rewrite
• Документация nginx (map): nginx.org — ngx_http_map_module
• Cloudflare — блокировка AI-ботов: Cloudflare — Block AI Bots
• Google — спецификация robots.txt: Google Developers — robots.txt spec
• Открытый блоклист AI-ботов: github.com/ai-robots-txt/ai.robots.txt
• Обзор The Rundown: The Rundown — Keenable Search API review
• Анализ условий Neodrop: Neodrop — Keenable indexed the web for agents
• Поиск индекса и цены (quasa.io): quasa.io — Keenable Raises $26M
• Статья о выходе из стелса (AIInsiders): AIInsiders — Keenable exits stealth
• The Prompt Insider о сокрытии краулера: The Prompt Insider — Search index for AI agents