Что такое слой данных для ИИ
Начнём с термина. В веб-аналитике dataLayer — объект JavaScript, через который Google Tag Manager и другие инструменты получают события и значения: просмотр товара, добавление в корзину, сумму покупки. Он описан в документации Google для разработчиков. Но сам по себе dataLayer — не стандарт, по которому ИИ-агенты читают сайты.
Здесь слоем данных для ИИ мы называем другое — согласованный набор сведений, которые сайт отдаёт в форме, доступной программам: названия, характеристики, цены, условия, авторство, даты обновления. Отдельная версия сайта для этого не нужна, тайный текст «для нейросетей» — тоже. Это те же факты, с которыми работает человек, только программе не приходится угадывать их по оформлению.
Цену, набранную крупным шрифтом, человек обычно узнаёт и так. Программе нужны подробности: валюта, единица продажи, вариант товара, срок действия предложения. Без них число «от 15 000» слишком легко понять неверно.
При этом нет единого формата, который достаточно установить, чтобы сайт стал доступен всем ИИ-помощникам. Google прямо пишет в своей документации: чтобы попасть в AI Overviews и AI Mode, не нужны ни специальные файлы для ИИ, ни особая микроразметка. Важная информация должна быть доступна в виде текста, а структурированные данные — соответствовать содержанию страницы. Но это правила одной конкретной поисковой системы, про остальных агентов они ничего не говорят.
Поэтому новый протокол подождёт. Начните с вопроса: что именно получает программа по адресу вашей страницы?
Сначала проверьте, доступны ли факты
Откройте исходный HTML-код нескольких важных страниц. Есть ли в нём описание продукта, цена, условия и характеристики — или только каркас, который заполняется после выполнения JavaScript?
Это не значит, что сайты на JavaScript машинам не прочитать. Яндекс, например, такие сайты обрабатывает, а управлять обработкой можно в Вебмастере. Но по умолчанию робот сам решает, выполнять ли код, и даже настройка «Рекомендую рендерить» только повышает вероятность обработки — гарантии она не даёт.
Разумный инженерный подход — не заставлять каждого посетителя собирать основные сведения заново. Ключевые факты можно включить в HTML, который сервер отдаёт сразу, и сохранить при этом внешний вид страницы. Человек разницы не заметит, а программа перестанет зависеть от загрузки скриптов.
Заодно проверьте, не спрятаны ли условия только в картинках, всплывающих окнах или элементах, до которых нужно добираться в несколько действий. Сайт может быть удобен постоянному клиенту и при этом не давать быстро извлечь из него точный ответ.
Проверьте и доступ для роботов. Страница может открываться у сотрудника, но блокироваться защитой от роботов. А разрешение, выданное одному роботу, на остальных не распространяется. OpenAI в документации для разработчиков разделяет поискового робота OAI-SearchBot и GPTBot, который собирает материалы для обучения, — управлять ими можно по отдельности. Чтобы появляться в поиске, открывать сайт для обучения не обязательно.
Один факт — один источник
Самая дорогая ошибка — противоречие между каналами. Отсутствие разметки обходится дешевле.
На странице товар в наличии, в выгрузке он закончился, а программный интерфейс возвращает вчерашнюю цену. По отдельности каждый источник выглядит исправным. Агенту остаётся выбрать один из них — и вряд ли этот выбор обрадует компанию.
Поэтому первым делом определите источник истины. Где хранится актуальная цена? Кто отвечает за условия возврата? Откуда берётся срок доставки? Страница, микроразметка и товарная выгрузка должны брать сведения из согласованных источников, и править их порознь нельзя.
Для каждого типа сущности нужен небольшой набор обязательных полей:
- у товара — устойчивый идентификатор, вариант, характеристики, цена и наличие;
- у услуги — состав, ограничения, география и то, как рассчитывается стоимость;
- у статьи — автор, дата, заголовок и ссылки на исходные материалы.
Особенно внимательно отнеситесь к условиям. «Доставка за два дня» — неполный факт, если обещание действует только в определённом городе и только для товаров со склада. Ограничения нужно хранить и передавать вместе с самим обещанием. Примечание на другой странице для этого не годится.
Неизвестное так и помечайте. Цена по запросу — не нулевая цена. Отсутствие сведений о наличии — не отсутствие товара. Хорошая структура данных сохраняет эти различия — одних фигурных скобок вокруг текста для этого мало.
Четыре способа передать данные
HTML, микроразметка, товарная выгрузка и программный интерфейс решают разные задачи, и внедрять всё сразу не обязательно.
| Способ | Зачем нужен | Основание | Что учесть |
|---|---|---|---|
| Текст в доступном HTML | Чтобы основные сведения можно было прочитать прямо со страницы | Google рекомендует давать важное содержание в текстовом виде | Текст не гарантирует цитирования, но убирает часть препятствий для чтения |
| Структурированные данные, например JSON-LD | Чтобы явно указать тип сущности и её свойства | Google требует, чтобы разметка соответствовала видимому содержанию | В разметке не должно быть цены выгоднее, чем на странице, и условий, которых там нет |
| Товарная выгрузка | Чтобы передавать каталог в конкретную систему | OpenAI публикует отдельную спецификацию товарных данных для поиска и покупок в ChatGPT | Нужна интеграция по правилам получателя: файл на сайте сам по себе её не заменит |
| API — программный интерфейс | Чтобы получать актуальные значения и выполнять предусмотренные операции | В интеграции OpenAI каталог и оформление покупки описаны как разные компоненты | Собственный API не становится сам собой известен всем агентам |
Информационный сайт может начать с доступного текста, аккуратной структуры и согласованной разметки. Большому магазину с быстро меняющимися остатками понадобится ещё и регулярная передача каталога.
В спецификации OpenAI, например, каждый товар или вариант, который можно купить, передаётся отдельной записью. Документация задаёт требования к идентификаторам, адресам страниц и изображений, описаниям и другим полям. Это хорошо показывает, почему фразы «у нас уже есть JSON» недостаточно: получателю нужны определённая структура и правила обновления.
И не ждите, что такая интеграция сама решит задачу для российского рынка. Выгрузка для ChatGPT не заменяет проверку индексирования в Яндексе и не подключает каталог к Алисе. Возможности и условия каждого канала придётся проверять отдельно.
Отделите чтение от действий
Сайт может хорошо отдавать информацию и быть совсем не готов к действиям агента. Прочитать условия доставки — одна задача. Зарезервировать товар, применить скидку или оформить заказ — другая.
Это различие есть и в документации OpenAI: товарные данные помогают находить и показывать предложения, а для оформления покупки нужны отдельные интерфейсы, которые создают и изменяют сессию заказа.
Проведите такую же границу в своей архитектуре. Общедоступный слой отдаёт сведения, а операции, которые меняют состояние системы, проходят через авторизацию, проверки и подтверждения. Открывать внутреннюю систему целиком только потому, что агенту понадобилась цена, незачем.
С аналитическим dataLayer нужна особая осторожность. Он создан, чтобы передавать данные тегам, и может содержать сведения о действиях пользователя. Превращать его в публичную витрину, не разобрав состав, — плохая идея.
Готовить сайт к агентам — не значит публиковать персональные данные, служебные комментарии или внутренние коммерческие условия. Машине нужен ясный доступ к тому, что разрешено, и только к этому.
Принимайте работу по ответам
Итоговая проверка проста по замыслу: может ли программа правильно ответить на реальные вопросы по тем данным, которые отдаёт сайт? Сам по себе нужный файл на сайте ещё ничего не доказывает.
Возьмите несколько важных страниц и задайте вопросы, ответы на которые можно проверить: сколько стоит конкретный вариант, в каком регионе действует предложение, что входит в услугу, когда обновлялись условия. Сравните ответы с исходной системой и с тем, что видно на странице.
Ошибки разбирайте по видам. «Не удалось получить страницу», «не найдено поле», «неверно понято условие» и «получены устаревшие данные» исправляются по-разному. Общий вывод «агент плохо читает сайт» разработчику почти ничего не даёт.
Отдельно поменяйте тестовое значение и проследите, где оно обновилось: на странице, в разметке, в выгрузке, в API. Так быстро находятся расхождения, которых не покажет валидатор синтаксиса.
Начинать лучше с одного шаблона, например с карточки товара или страницы услуги. Если на нём данные читаются точно и обновляются согласованно, решение можно распространять дальше. Перестраивать весь сайт до первой проверки незачем.
Главное — согласованность
Сайт, подготовленный для ИИ, не обязан выглядеть иначе. Человеку по-прежнему нужны хороший интерфейс, понятный текст и нормальная навигация. Агенту — доступные факты в однозначных полях и предсказуемые способы их получить.
Основная работа здесь — добиться, чтобы продукт, цена и условия совпадали везде, где сайт их показывает или передаёт. Если это налажено, новая интеграция становится просто ещё одним способом передать данные, которые уже в порядке. Если нет, любой «слой для ИИ» только быстрее разнесёт противоречия, которые уже есть.
Читайте также
AIO-аудит сайта: чек-лист сигналов, которые считывают LLM, а не люди
Брендинг без экрана: кому достанется идентичность, когда за компанию говорит ИИ
Хотите понять, что исправлять срочно, а что может подождать? Оставьте заявку на бесплатный SEO-аудит — мы расставим задачи по важности.