Техническая доступность сайта для ИИ

Что мы проверяем в первую очередь: доступен ли сайт для ИИ

Прежде чем работать с текстами и упоминаниями, нужно убедиться, что нейросети физически могут прочитать сайт. На практике примерно каждый второй сайт частично или полностью закрыт от ИИ-краулеров (crawler — робот, который обходит сайты и скачивает страницы), причём почти всегда по недосмотру. Вот что мы проверяем до начала остальных работ.

1. Доступ в robots.txt

robots.txt — служебный текстовый файл в корне сайта, в котором владелец указывает роботам, какие разделы можно обходить, а какие нет. Многие сайты закрыли в нём ИИ-ботов в 2023–2024 годах, когда шли споры об использовании контента для обучения, и забыли об этом. Сейчас это означает отсутствие в ответах.

Важно различать два типа ботов. Одни собирают данные для обучения моделей — их закрытие на присутствие в ответах почти не влияет. Другие ходят на сайт в момент запроса пользователя или формируют поисковый индекс ИИ-сервиса — вот их закрывать нельзя, иначе компания исчезает из ответов. Различают ботов по user-agent (англ. «агент пользователя») — имени, которым робот представляется сайту при каждом обращении; по этому имени в robots.txt и задаются правила.

Отдельно проверяем, не блокирует ли ИИ-ботов защита от DDoS-атак (Distributed Denial of Service — «распределённый отказ в обслуживании»: сайт заваливают потоком запросов, чтобы он перестал отвечать) или фильтр хостинга — это частая причина, когда robots.txt открыт, а бот до страниц не доходит.

2. Рендеринг JavaScript (сборка страницы скриптами)

Самый недооценённый пункт. JavaScript — язык программирования, на котором работают интерактивные элементы сайта; рендеринг (rendering — «отрисовка») — сборка итоговой страницы из кода. Поисковые системы научились выполнять JavaScript и видеть содержимое, подгружаемое скриптами. ИИ-краулеры в большинстве своём этого не делают: они забирают исходный HTML и работают с тем, что в нём есть.

Если текст, цены, характеристики или блок вопросов и ответов подгружаются скриптом после загрузки страницы, для нейросети их не существует. Сайт на React, Vue или Angular (популярных JavaScript-фреймворках — готовых каркасах для разработки интерфейсов) без серверного рендеринга — SSR (Server-Side Rendering), когда страница собирается на сервере и отдаётся браузеру уже с готовым текстом, — может быть полностью пустым с точки зрения ИИ, при этом нормально ранжироваться в Яндексе и Google.

Как проверить самостоятельно: откройте страницу, отключите JavaScript в браузере и посмотрите, что осталось. Либо посмотрите исходный код страницы — HTML (HyperText Markup Language, язык разметки страниц) — сочетанием клавиш Ctrl+U и найдите в нём текстом то, что должно попасть в ответ нейросети. Если не нашли — не найдёт и модель.

3. Структура и разметка

• Семантические (смысловые) теги — команды HTML-разметки, которые сообщают, чем является фрагмент: заголовки h1–h3 (от heading — «заголовок» первого–третьего уровня) по иерархии, списки списками, таблицы таблицами. Текст, свёрстанный div-блоками (div, от division — универсальный контейнер без смыслового значения) с отступами, хуже разбирается на фрагменты.
• Микроразметка Schema.org — общий словарь машиночитаемых описаний, который понимают Google, Яндекс и Microsoft. Каждый тип разметки описывает сущность и её атрибуты — по сути, это набор готовых триплетов «сущность — атрибут — значение»: Organization (организация), Service (услуга), Product (товар), FAQPage (страница вопросов и ответов), HowTo (пошаговая инструкция), Article (статья) с указанием автора и даты. Разметка не гарантирует попадания в ответ, но помогает модели понять, что перед ней.
• Единство данных: название компании, телефон, адрес и режим работы — атрибуты одной сущности — должны совпадать на сайте, в разметке и во всех внешних карточках. Расхождения не дают модели уверенно связать факты с компанией и снижают доверие к источнику.
• Файл llms.txt в корне: краткое описание компании и карта ключевых разделов, адресованные LLM (Large Language Model — большая языковая модель). Стандарт пока не поддержан официально ни одной крупной моделью, внедряем как недорогую подстраховку, не обещая эффекта.

4. Скорость и коды ответа

ИИ-краулеры работают с коротким таймаутом (timeout — предельное время ожидания ответа) и редко возвращаются к странице, которая долго отвечала. Проверяем время ответа сервера, корректность HTTP-кодов ответа (200 — страница доступна, 301 — постоянное перенаправление, 404 — не найдена, 5xx — ошибка сервера), отсутствие цепочек редиректов (redirect — автоматическое перенаправление на другой адрес) и доступность страниц без авторизации и без обязательных баннеров согласия на cookie (небольшие файлы, которые сайт сохраняет в браузере посетителя), перекрывающих контент.

5. Проверка по логам

Финальная и самая показательная проверка. Выгружаем логи сервера (журналы, куда записывается каждое обращение к сайту), фильтруем по user-agent ИИ-краулеров и смотрим, какие страницы они забирали и как часто. Это единственный способ узнать наверняка, дошёл ли бот до материала, а не предполагать это по косвенным признакам. Если страница опубликована месяц назад и ни один ИИ-бот её не открывал — проблема в доступности, и переписывать текст бессмысленно.

Короткий чек-лист для самопроверки

• Открыты ли поисковые и «живые» ИИ-боты в robots.txt
• Не режет ли их защита от ботов на уровне сервера
• Виден ли основной текст в исходном HTML-коде без выполнения JavaScript
• Соблюдена ли иерархия заголовков и семантика вёрстки
• Есть ли микроразметка Schema.org для организации, услуги, вопросов-ответов и статей с автором (Organization, Service, FAQPage, Article)
• Совпадают ли данные о компании на сайте и во внешних источниках
• Укладывается ли ответ сервера в адекватное время, нет ли цепочек редиректов
• Подтверждают ли логи, что ИИ-краулеры реально забирают страницы

Проверку технической доступности мы проводим в начале работ по GEO-продвижению — до того как переходить к текстам и внешним упоминаниям.