Llmstxtscan: почему этот «AI-краулер» вообще не читает контент вашего сайта

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

Что такое llms.txt и почему появился краулер, который его проверяет

llms.txt — предложенный в сентябре 2024 года австралийским исследователем Джереми Ховардом (Answer.AI) открытый стандарт: markdown-файл в корне сайта (/llms.txt), который в сжатом и структурированном виде описывает содержимое ресурса специально для языковых моделей — по аналогии с тем, как robots.txt регулирует доступ, а sitemap.xml перечисляет страницы для обычных поисковых систем. Стандарт остаётся добровольной инициативой сообщества, а не официальным протоколом, обязательным для соблюдения крупными AI-компаниями — тем не менее формат уже приняли документация Anthropic, Cloudflare и сотни компаний, работающих с разработчиками.

Поскольку стандарт новый и добровольный, естественно возник интерес к тому, насколько широко его вообще принял веб — отсюда и craulер вроде llmstxtscan: он не использует найденные файлы для обучения ИИ, а измеряет саму статистику внедрения подобных «well-known» файлов по публичному вебу в рамках исследования по безопасности и AI-готовности сайтов.

Параметры бота

Чем это отличается от исходной классификации «нежелательный»

Ярлык «нежелательный» из общей категории AI-краулеров подразумевает риск утечки уникального контента в чужой AI-контур без атрибуции. Для llmstxtscan этот сценарий буквально неприменим: бот запрашивает исключительно служебные файлы фиксированного, известного заранее списка — а не статьи, описания товаров или страницы каталога. Если сайт не публиковал у себя /llms.txt или /AGENTS.md, запрос просто вернёт 404, и никакого содержательного контента бот с этого визита не унесёт вовсе.

Как найти бота в логах

# Базовый поиск
grep -i "llmstxtscan" /var/log/nginx/access.log

# Какие именно служебные файлы запрашивал бот
grep -i "llmstxtscan" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c

Если в выдаче видны только запросы к перечисленным выше служебным путям и ничего больше — это соответствует заявленному поведению оператора; заметный обход обычных страниц сайта под тем же UA стал бы поводом усомниться в подлинности запроса и свериться с ASN IP через whois.

Стоит ли блокировать

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

• если сайт уже публикует /llms.txt или планирует его внедрить как часть AI-оптимизации контента — присутствие в исследовании распространённости стандарта не несёт практического риска, поскольку бот лишь фиксирует факт наличия файла, а не забирает остальной контент;
• если нежелательно даже минимальное периодическое обращение к этим путям — можно воспользоваться официальным e-mail для opt-out прямо из строки UA, что избавляет от необходимости настраивать серверные правила вручную;
• на позиции в органической выдаче Google, Bing или Яндекса присутствие или отсутствие этого бота не влияет — это не поисковый краулер ни одной из систем.

Как настроить доступ, если предпочтительна серверная блокировка

Стандартный запрет через robots.txt:

User-agent: llms.txt crawler bot
Disallow: /

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

Но, учитывая официально указанный контактный адрес для запроса на исключение, для большинства сайтов проще и надёжнее один раз написать на opt-out@llmstxtscan.org с указанием домена, чем поддерживать отдельное серверное правило ради бота, чья нагрузка и без того намеренно сведена оператором к минимуму.