Аудит готовности к ИИ: читают ли движки ваш сайт?

Четверг, 09:40. Руководитель маркетинга B2B-компании вводит в ассистента самый частый вопрос своей категории — хочет увидеть, что принесло опубликованное две недели назад руководство на 42 страницы. Ответ занимает четыре предложения, под ним три источника, и ни один из них не её домен. Днём приходит однострочный ответ от разработчика: правило, добавленное в robots.txt полгода назад во время паники из-за нагрузки, полностью закрыло GPTBot. Руководство было написано хорошо. Разрешения прочитать его у движка не было.

Этот материал о том, как найти ту самую строку. По порядку: чем «сайт работает» отличается от «сайт читается», какие восемь категорий проверяет аудит готовности к ИИ, как проверить robots.txt и доступ по агентам, зачем нужен llms.txt и чем он не является, сколько текста остаётся на странице без JavaScript, где заканчивается польза schema-разметки, что делает абзац цитируемым, что проверяют критерии свежести и айдентики бренда, как превратить находки в упорядоченный бэклог и в какие ловушки чаще всего попадают при чтении итогового балла. Все пункты проверяемы, ни один не является мнением.

Где начинается разница между «работает» и «читается»?

Страница открывается у вас в браузере потому, что проходит три отдельных барьера: сервер принимает запрос, браузер выполняет JavaScript, а вы читаете текст глазами. Сборщик языковой модели ведёт себя иначе на всех трёх. На первом его личность определяется по заголовку User-Agent, и в большинстве современных инфраструктур эта личность попадает в отдельный набор правил. На втором большинство сборщиков либо не выполняют JavaScript, либо выполняют ограниченно: что вернул сервер в сыром HTML, то и существует. На третьем он не восстанавливает контекст, который ваш глаз собирает бесплатно, — на какой вопрос отвечает предложение в середине страницы, он выводит из окружающего заголовка и структуры.

Поэтому первый вопрос аудита не про эстетику: какой HTTP-код возвращает страница, для какого агента и сколько слов в полученном теле ответа. Сайт может грузиться быстро, выглядеть аккуратно и показывать здоровый трафик в аналитике — и при этом отдавать сборщику 403. Правила ботов на файрволе, ограничение частоты запросов, блокировки по стране и страницы проверки относятся сюда же. На коммерческих страницах картина ещё жёстче: ответ на вопрос, почему ИИ пропускает страницу товара, обычно спрятан в том, как эта страница отвечает на запрос, а не в качестве текста.

Что именно проверяет аудит готовности к ИИ?

Аудит должен быть чек-листом, а не впечатлением. «Аудит готовности к ИИ» в Rocketly проверяет сайт по восьми категориям и 70 критериям: сканируемость, отвечаемость, цитируемость, айдентика бренда, свежесть, структурированные данные, доступ агентов и измеримость. Эти восемь выбраны не случайно: они повторяют этапы, которые предложение должно пройти, чтобы оказаться внутри ответа движка. Недоступную страницу нельзя прочитать, непрочитанный абзац ни на что не отвечает, а текст без ясного происхождения не цитируют.

Набор статусов важен не меньше самих критериев. Каждый критерий получает один из четырёх: выполнено, частично, не выполнено и не удалось проверить. Четвёртого в большинстве инструментов нет, и его отсутствие тихо портит балл: считая непроверенное невыполненным, вы идёте чинить несуществующую проблему, а считая выполненным — прячете реальную дыру. То, что проверить не удалось, вычитается из знаменателя: вы видите долю от реально проверяемых критериев, а число непроверенных пунктов указывается отдельно.

На практике первый аудит — это смесь четырёх типов находок: проблемы доступа на уровне сервера, проблемы формата на уровне страницы, отсутствующие файлы на уровне сайта и слепые зоны на стороне измерения. Вес у них разный. Проблемы доступа обычно единичны, но блокируют всё остальное; проблемы формата растянуты на сотни страниц, но чинятся один раз в шаблоне.

Что robots.txt говорит каждому боту и как это проверить?

robots.txt — это декларация, а не слой авторизации: обязателен для сборщиков, которые его уважают, и безразличен остальным. При этом именно здесь чаще всего лежит самый выгодный пункт аудита, потому что ошибки здесь молчаливы — никто не сообщит вам, что правило вас исключило. Инструменты Rocketly для llms.txt, robots и схемы читают файл агент за агентом и показывают статус доступа отдельно для GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended и CCBot. Инструменты ничего не записывают на ваш сайт: результат — черновик, а при нехватке данных вместо пустого поля выводится название того, чего не хватает.

Агент	Что делает	Чем обернётся блокировка
GPTBot	Общий краулер OpenAI, собирает контент	Ваши страницы остаются вне этого корпуса
ChatGPT-User	Забирает страницу по запросу пользователя	Даже вставленную ссылку прочитать нельзя
ClaudeBot	Краулер Anthropic, собирающий контент	Вас нет в этом пуле источников
PerplexityBot	Краулер движка, который ставит ссылки на источники	Шанс получить цитирование падает напрямую
Google-Extended	Управляет использованием в генеративных функциях	Влияет на генеративное использование, не на позиции
CCBot	Наполняет архив Common Crawl	Вы выпадаете из множества производных наборов

Каждая строка таблицы — управленческое решение, а не техническое требование. Одни издатели сознательно держат контент вне обучающих корпусов, другие разрешают только живую подгрузку. Важно, чтобы решение было принято осознанно и чтобы две разные цели не смешивались: массовый сбор и подгрузка по запросу пользователя идут через разных агентов. Если вы хотите зафиксировать, какое именно разрешение выдали, наш разбор темы данных клиентов и приватности в работе с ИИ показывает, как такая документация должна выглядеть.

Проверка занимает один запрос. Запросите файл с нужным заголовком User-Agent, прочитайте тело ответа, затем тем же агентом запросите содержательную страницу и запишите код и длину тела. Три ошибки встречаются чаще прочих: незамеченная строка Disallow с подстановочным символом, robots.txt за цепочкой редиректов и файл, отдающий 404 вместо 200. Четвёртая столь же обычна: robots.txt разрешает, а файрвол — нет.

Нужен ли llms.txt и что в него класть?

llms.txt — это машиночитаемое оглавление в корне сайта: короткое описание, основные разделы и канонические ссылки к каждому. Это не фактор ранжирования, он не заменяет robots.txt и ни один движок не считает его обязательным. Польза в другом: он убирает момент, когда модель вынуждена угадывать, какая версия вашего текста каноническая. Если одно и то же описание функции живёт на десяти адресах, выбираете вы, а не она.

Проверяемые пункты однозначны. Лежит ли файл в корне, отдаёт ли 200, отдаётся ли как обычный текст, все ли ссылки внутри возвращают 200, совпадают ли перечисленные названия с заголовками страниц и когда файл обновлялся в последний раз. llms.txt, не прошедший эти шесть пунктов, не даёт ничего одним фактом существования. То же касается ссылки на страницу, которой у вас больше нет, или забытого закрытого раздела — так файл превращается в потерю доверия.

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

Сколько от вашей страницы остаётся без JavaScript?

Проверка рендеринга проста: запросите страницу «сырой» и посчитайте видимые слова в полученном HTML. Если в браузере 1200 слов, а в сыром теле 90, то с точки зрения генерации ответа у вас страница на 90 слов. Архитектуры одностраничных приложений, описания товара, подгружаемые на клиенте, текст за вкладками и аккордеонами, а также списки с бесконечной прокруткой — самые частые причины этого разрыва.

Лечение редко требует переписывать архитектуру. Обычно хватает серверного рендеринга критичных маршрутов, переноса ключевого текста в первый HTML-ответ или того, чтобы содержимое аккордеона было визуально скрыто, но присутствовало в разметке. Второе, что стоит проверить, — не живёт ли текст внутри картинок: таблица характеристик, выложенная скриншотом, не отдаёт ни одной цифры как текст. Как читаются изображения — отдельная тема; наш материал про видимость в мультимодальном поиске подробно разбирает критерии по alt-тексту и именам файлов.

Третья проверка — редиректы. Переадресация по выбору языка, определению региона или согласию на куки может безупречно работать для человека и оставить сборщика на пустой промежуточной странице. Сюда же относятся противоречивые canonical: если страница A указывает на B, а B обратно на A, движку нечем решить, какой адрес запоминать.

Где schema-разметка помогает, а где превращается в шум?

Структурированные данные явно маркируют информацию страницы для машины и помогают ровно настолько, насколько убирают догадки. Базовых типов в аудите немного: Organization для компании, Product на страницах товаров, FAQPage на блоках вопрос-ответ, Article в статьях и BreadcrumbList для навигации. Сначала проверяется наличие, потом валидность и только потом — совпадение с видимым содержимым страницы.

Именно на третьем пункте ошибаются чаще всего. Разметить блок вопрос-ответ, которого на странице нет, объявить рейтинг, которого никто не видит, или проштамповать один блок Organization по всем шаблонам и забыть обновить домен — это риск, а не выигрыш. Вторая частая ошибка — неполнота: блок Organization без названия, домена, логотипа и ссылок на официальные профили — то место, где категория айдентики теряет больше всего баллов. Если вы выстраиваете блоки вопрос-ответ всерьёз, мы отдельно разбирали, почему контент в формате вопрос-ответ цитируют.

Что делает абзац цитируемым?

Отвечаемость и цитируемость — две разные категории. Первая спрашивает, отвечает ли страница на вопрос вообще; вторая — переносится ли этот ответ. Переносимый абзац осмыслен сам по себе: подлежащее названо, термины определены, у чисел есть единицы, контекст лежит внутри предложения. Фраза, начинающаяся со слов «как сказано выше», теряет смысл, как только её вынули со страницы, — поэтому её и не выносят.

Конкретные проверки такие: заголовок — это настоящий вопрос или маркетинговый слоган, даётся ли ответ в первых двух предложениях под ним, объясняются ли термины при первом появлении, оформлены ли сравнения таблицей и указаны ли на странице собственные границы — дата, версия, охват. В сравнительных запросах эта разница в форматировании прямо отражается на результате; о нужной структуре мы писали в тексте про сравнительные запросы вида «X или Y».

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

Что проверяют критерии свежести и айдентики бренда?

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

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

Сторонние источники — в той же рамке. Экран источников перечисляет домены, питающие ответ движка, с метками владения (вы, конкурент, третья сторона, пользовательский контент) и типа (площадка отзывов, маркетплейс, каталог, форум, видео, новости); незнакомому домену он пишет «не определено», а не выдумывает тип. Почему форумы и сообщества так часто оказываются в этих списках, мы разбирали в тексте почему ИИ ссылается на Reddit и форумы.

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

Как превратить находки аудита в упорядоченный бэклог?

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

Практическая последовательность обычно такая. Сначала доступ: правила robots, исключения на файрволе, корневые файлы с кодом 200. Затем рендеринг: критичный текст присутствует в сыром HTML. Дальше структура: типы схемы, canonical, иерархия заголовков. Потом формат: заголовки-вопросы, ответ в первых двух предложениях, сравнительные таблицы. И только в конце производство контента под реальные пробелы в темах. При обратном порядке хорошо написанные новые страницы просто копятся на нечитаемом сайте.

Второе практическое правило — сводить одну корневую причину в один пункт. Если один и тот же конкурент опережает вас в восьми вопросах, это один пункт, а не восемь карточек; ошибка форматирования из шаблона на четырёхстах страницах — одна задача, а не четыреста. Иначе список растёт, а сайт — нет.

Какие ловушки подстерегают при чтении балла аудита?

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

Вторая ловушка — считать пропуск нулём. Если в какой-то день измерение не прошло, значение этого дня не ноль, его просто нет. Видеть это различие на экране важно: график в этой точке разрывается, а доля показывает прочерк, а не 0%; число неизмеренных дней указывается отдельно. Та же логика стоит за статусом «не удалось проверить» в аудите.

Третья ловушка — выводить тренд из одного замера. Генеративные движки могут по-разному сформулировать ответ на один и тот же вопрос в двух прогонах; колебание между двумя точками — ещё не изменение. Экран отслеживания изменений говорит, что изменилось, и не утверждает, почему. Четвёртая ловушка — оставить пустой категорию измерения: если вы не размечаете визиты из ИИ-ассистентов как отдельный канал, связать работу по аудиту с бизнес-результатом не получится. Почему этот трафик ведёт себя иначе, мы объясняли в материале о том, как конвертируются посетители из ИИ-поиска.

Не относитесь к аудиту как к разовой работе: изменения шаблонов, новые типы страниц и обновления инфраструктуры тихо возвращают закрытые двери. Чтобы увидеть готовность собственного сайта по всем 70 критериям, вы можете открыть бесплатный аккаунт и запустить аудит.

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

Смогут ли ИИ-движки прочитать сайт без llms.txt?

Смогут. llms.txt — это карта, а не пропуск; его отсутствие сайт не закрывает. Доступ определяют правила robots.txt, ответы сервера и политика файрвола. Добавляйте llms.txt после того, как закрыли пункты по доступу и рендерингу, а не до того.

Навредит ли блокировка всех ИИ-ботов в robots.txt?

Зависит от того, что вы защищаете. Для издателя, лицензирующего архив, закрыть массовые сборщики — последовательный выбор. Но если вы закроете и агентов, которые забирают страницу по запросу пользователя, вы сами снизите свои шансы попасть в цитирование. Оценивайте две цели отдельно.

Балл вырос, а в ответах меня по-прежнему нет. Почему?

Потому что готовность и видимость — разные измерения. Готовность говорит, что страницы можно прочитать и процитировать. Попадание в ответ зависит ещё от тематического авторитета, частоты упоминаний вне вашего сайта и конкурентности самого вопроса. Ведите их на разных экранах.

Как часто повторять аудит?

Обязательно после смены шаблона или инфраструктуры, в остальное время достаточно раза в месяц. Важна сопоставимость, а не частота: если набор критериев тот же, разница между двумя датами читается однозначно. И сделайте привычкой проверять после каждого релиза, что корневые файлы по-прежнему отдают 200.