Я попросила Алису AI и ГигаЧат настроить lifecycle-политику объектного хранилища в одном конкретном облаке. Ответы выглядели убедительно, пока я не сверила их с документацией и не нашла расхождения. Почему так получилось? А главное, что с этим делать SEO-специалисту и техническому писателю?

---

Меня зовут Ева Писаревская, я SEO-специалист в Cloud.ru. Работаю с интентом пользователей в поисковых системах и в ИИ, а также отвечаю за то, чтобы наши технические писатели и авторы блога делали материалы, которые попадают в топ не только классического, но и ИИ-поиска. 

Расскажу в статье, как страницы попадают в ответы ИИ, почему сервисы искажают факты и что изменить на сайте, чтобы повысить видимость материалов и снизить риск ошибок.

Что вообще такое ИИ-поиск и генеративные ответы

Простого ответа тут не будет, готовьтесь.

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

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

Поэтому сам по себе ИИ-чат еще не равен ИИ-поиску. Поиском он становится, если может обратиться к поисковому индексу или другому внешнему источнику. Например, так работают AI Overviews в Google, быстрые ответы Алисы AI и Perplexity. Сервис находит страницы, извлекает нужные фрагменты и собирает из них ответ.

Пользователю не всегда нужно переходить по ссылкам: иногда он получает готовый ответ прямо в поиске. Такой сценарий называют Zero Click.

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

По данным лаборатории «Ашманов и партнеры», пользователи рунета обращают внимание на ИИ-блок в выдаче в 1,3 раза чаще, чем на классические результаты, и в 6 раз чаще, чем на рекламу. В источники для ответов Алисы AI все чаще попадают страницы из первой десятки поисковой выдачи: за полгода доля остальных сайтов снизилась с 40 до 10%.

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

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

Но сама проверка хоть и показывает проблему, но не объясняет ее причину. Чтобы найти ее, нужно сравнить ответ ИИ с источниками и понять, где информация потерялась или исказилась.

Разберем это на запросе о lifecycle-политике — правиле, по которому облачное хранилище автоматически переносит или удаляет данные.

Я решила пройтись по отечественным моделям — задала Алисе AI и ГигаЧату одинаковый вопрос:

Как в Object Storage Cloud.ru настроить lifecycle-политику, чтобы через 30 дней переносить объекты в холодный класс хранения, а через 365 дней удалять?

Объекты здесь — это данные, которые пользователь загрузил в хранилище, например документы, изображения, резервные копии или логи.

В Cloud.ru объектное хранилище работает сразу на двух платформах: Cloud.ru Advanced и Cloud.ru Evolution. На первой данные можно автоматически переносить в другой класс хранения и удалять. На второй — настроить удаление, но автоматический перенос между классами хранения пока не поддерживается.

Я намеренно не указала платформу: от нее зависит правильный ответ.

Поэтому полный ответ должен:

1. уточнить, что настройка зависит от платформы;

2. объяснить ограничение Cloud.ru Evolution;

3. дать инструкцию для Cloud.ru Advanced, на которой доступны оба действия из запроса.

Я сравнила ответы с инструкцией для Cloud.ru Advanced и описанием lifecycle-политик для Cloud.ru Evolution.

И вот что у меня получилось.

Что показал эксперимент

Оба ИИ-чата передали часть данных из документации без ошибок, но при этом оба не учли вариативность платформ в облаке: 

• Алиса AI описала правильный порядок действий, но выбрала другой класс хранения. 

• ГигаЧат выбрал нужный класс, но добавил неверные ограничения.

Изучаем ответ Алисы AI

Алиса AI описала, где открыть настройки lifecycle-политики, как создать правило и через сколько дней удалять данные. Этот порядок действий совпадает с инструкцией.

А вот потом совершила фатальную ошибку: назвала холодный класс теплым. В начале ответа нейросеть написала, что политика должна:

— …перемещать объекты в холодный класс хранения (Warm) через 30 дней.

Теплый (Warm) и холодный (Cold) — принципиально разные классы хранения:

• Первый используют для данных, которые запрашивают редко (до 12 раз в год), но хотят получать без ожидания.

• Второй предназначен для архивных данных, доступ к которым требуется еще реже (до раза в год). Перед скачиванием такие данные нужно восстановить. И иногда это занимает несколько часов.

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

Еще в промпте я просила перенести данные в холодный класс, а Алиса AI выбрала в панели управления настройку перехода в теплый. В общем, много чего перепутала.

Та же подмена повторилась в примере конфигурации для API: Алиса AI снова указала теплый класс вместо холодного.

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

В рекомендациях Алиса AI также указала минимальный срок хранения в 30 дней. Но это, правда, только для теплого класса. Для холодного же минимальный срок — 90 дней.

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

Смотрим на ответ ГигаЧата

ГигаЧат показал, как настроить в Cloud.ru Advanced перенос данных в теплый класс хранения через 30 дней и удаление через 365 дней. Эта часть ответа соответствует запросу и документации.

В ответе он правильно указал еще два условия:

1. Срок отсчитывается после последнего обновления данных.

2. Удаление должно происходить позже переноса.

Но и тут пошли косяки — в пояснении к переходу в холодный класс. ГигаЧат пишет:

— …минимальный срок перед переносом в Cold составляет 30 дней.

Ниже в том же ответе сказано, что при прямом переносе из стандартного класса в холодный такого ограничения нет.

Правильный вариант по доке — второй. Данные можно сразу переносить из стандартного (Standard) класса в холодный: обязательного периода ожидания нет. Провести не менее 30 дней в холодном классе данные должны только в том случае, если их последовательно переводят:

• из стандартного в теплый;

• а затем из теплого в холодный. 

То есть информация уже неполная — ее не хватит для корректной работы с хранилищем.

Еще одна ошибка касается минимального срока хранения. ГигаЧат указал для холодного класса диапазон от 30 до 60 дней. По документации в Cloud.ru Advanced минимальный срок — 90 дней. 

Кроме того, ГигаЧат упомянул Soft Delete и связал его с версионированием. В холодном хранилище Cloud.ru Advanced действительно можно восстановить:

• удаленные объекты;

• предыдущие версии объектов;

• объекты после перезаписи.

Однако в документации эта функция не называется Soft Delete. Из ответа ГигаЧата непонятно, какой именно механизм он имеет в виду и при каких условиях тот работает.

Что именно пошло не так

В эксперименте проявились четыре типовые проблемы.

Сервис не учитывает неоднозначность запроса

Пользователь указал сервис Object Storage, но не назвал платформу. От нее зависят доступные настройки. В Cloud.ru Advanced можно настроить и перенос данных в другой класс хранения, и их удаление. В Cloud.ru Evolution — только удаление. Автоматически переносить данные между классами пока нельзя. 

Алиса AI и ГигаЧат не уточнили платформу и сразу дали инструкцию для Cloud.ru Advanced. Пользователь Cloud.ru Evolution не сможет повторить эти шаги: автоматический перенос между классами хранения на этой платформе не поддерживается. Если положиться на ответ ИИ, можно потратить время на поиск несуществующей настройки и ошибочно рассчитывать, что данные перейдут в холодный класс автоматически. 

В ответе смешиваются похожие понятия 

И теплый, и холодный класс предназначены для данных, к которым обращаются редко. Но они разные, а значит, условия доступа и оплаты у них различаются.

Алиса AI напутала с терминами, назвала теплый класс холодным, а затем предложила настройку перехода для теплого.

Важное условие отделено от своего сценария 

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

ГигаЧат сначала представил ограничение в 30 дней как общее правило для перехода в холодный класс хранения. Ниже в том же ответе он уточнил, что при прямом переносе ограничение не действует. Условие потеряло связь со своим сценарием, поэтому внутри одной инструкции появились два разных правила.

В итоговом ответе появляются неподтвержденные детали 

ГигаЧат указал, что минимальный срок хранения в холодном классе составляет от 30 до 60 дней. В документации указан другой срок — 90 дней.

Там же появился Soft Delete — механизм для восстановления удаленных данных. Он не описан в проверенных разделах документации. ИИ-чат добавил к основной инструкции дополнительные сведения, но не показал, откуда они взяты и применимы ли к этому сервису.

Разберемся, на каких этапах возникают такие ошибки и на что может повлиять владелец сайта.

Где страница может потеряться

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

Доступ, или краулинг. Сначала ИИ-бот должен открыть страницу. Это не получится сделать, если установлены ограничения в robots.txt — файле с правилами для поисковых роботов. Также могут помешать настройки WAF, антибот-защиты или CDN. Эти системы защищают сайт от подозрительных запросов и иногда принимают ИИ-бота за нарушителя. Зарубежного краулера могут заблокировать и по геолокации или ASN — номеру сети, из которой он обращается к сайту.

Порой мешают и ошибки сервера. Код 403 означает, что доступ запрещен, а 429 — что бот отправил слишком много запросов. Важно и значение TTFB — время до получения первого байта ответа от сервера. Если страница долго загружается, ИИ-агент переходит к другому источнику.

Рендеринг. Некоторые страницы собраны с помощью JavaScript. Многие ИИ-краулеры не могут выполнить скрипт, поэтому не видят итоговый контент. Особенно уязвимы SPA — сайты, которые работают как одно веб-приложение. Без SSR, то есть без предварительной сборки страницы на сервере, краулер считает их пустыми.

Информация также может скрываться за действиями пользователя: нажатием на таб, аккордеон, кнопку «Показать еще» или калькулятор. Форма оплаты, авторизация, окно согласия на cookie и капча тоже зачастую не пускают краулер к основному тексту.

Извлечение информации. Даже открытую страницу нужно правильно разобрать. ИИ нужно время, чтобы извлечь текст из изображений и canvas — области, которую сайт отрисовывает как графику. Проблемы создают PDF без текстового слоя, сложные таблицы и iframe — встроенные блоки с содержимым другой страницы.

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

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

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

Не все ошибки одинаково опасны. Мы, например, считаем критичными только те, которые могут повлиять на покупку или создать юридический и репутационный риск:

• выдуманные цены, SLA и условия договора;

• несуществующие продукты или утверждения, что у Cloud.ru нет сервиса, который на самом деле есть;

• ошибки в информации о безопасности и комплаенсе — соблюдении 152-ФЗ, аттестациях и локализации данных;

• рекомендация конкурента по брендовому запросу с ложной аргументацией;

• ссылки на несуществующие страницы или чужие домены под видом источников Cloud.ru.

На такие ошибки нужно реагировать сразу: исправлять источник и проводить контрольную проверку.

Есть и значимые, но не критичные ошибки: упоминание продуктов прошлых поколений вместо линейки Cloud.ru Evolution, неверные лимиты и характеристики, смешение продуктовых линеек. Их можно исправлять в плановом порядке и перепроверять через две-четыре недели.

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

С приоритетами разобрались. Теперь посмотрим, как работать с источниками.

Как попадать в ответы ИИ

Сразу оговорюсь:

❌ Нельзя заставить Алису AI, ГигаЧат и любой другой ИИ всегда выбирать нужный источник и безошибочно его пересказывать. 

✅ Но можно поработать над страницами на сайте и докой — сделать важные условия заметнее и сократить количество фрагментов, которые ИИ может понять неправильно. 

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

Как повысить видимость материалов

Раскрывайте не один запрос, а всю тему целиком

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

Например, рядом с инструкцией по настройке объектного хранилища могут быть материалы о классах хранения, ограничениях, стоимости и типовых ошибках. Так сайт сможет ответить не на один запрос, а на несколько вопросов по теме.

Давайте факты, которых нет у других 

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

Такие материалы помогают подтвердить E-E-A-T сайта — его опыт, экспертность, авторитетность и надежность. А еще дают ИИ конкретные факты, на которые можно сослаться.

Следите за видимостью в обычном поиске

Некоторые ИИ-сервисы ищут источники через классическую выдачу. Поэтому техническое SEO, позиции страниц и внутренняя перелинковка по-прежнему влияют на шанс попасть в ответ.

Проверяйте доступ для ИИ-ботов

Убедитесь, что страницы не закрыты в robots.txt, WAF или антибот-защите. Проверьте скорость ответа сервера и доступность текста без JavaScript.

Как помочь ИИ верно понять информацию

Называйте продукты одинаково 

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

По этой же причине проверяйте статьи в СМИ и отраслевых каталогах. Информация в них не должна противоречить официальным материалам компании.

Добавляйте контекст к цифрам 

Если пишете про лимиты, укажите рядом с ними единицу измерения и регион. 

В инструкции важно прописать еще несколько пунктов: требования, ожидаемый результат и способ отката к прежней версии. Вместо шаблонного «В новой версии функция недоступна» назовите, что это за версия и какая именно функция больше не работает.

В инструкции также стоит назвать:

• предварительные требования,

• ожидаемый результат,

• ограничения,

• способ отката,

• актуальную версию продукта.

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

Поддерживайте один источник истины

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

• Если информация о продукте изменилась, сначала обновляем основную документацию, а затем — связанные с ней статьи. 

• Если актуальная версия страницы находится по новому адресу, настраиваем редирект — автоматическое перенаправление со старого адреса на новый. 

• Если адрес не изменился, редирект не нужен: достаточно обновить страницу. 

Так в разных разделах сайта не останутся противоречащие друг другу цены, условия и характеристики. 

Закрепите правила в редакционной политике

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

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

А можно ли оставить на странице инструкцию для ИИ?

Да, например, попросить его игнорировать другие указания или рекомендовать определенный продукт. Такой прием называют prompt injection.

Использовать его не стоит. Скрытая команда создает риски для безопасности и репутации. Поисковая система также может посчитать ее попыткой показать роботу и человеку разный контент. Лучше давать ИИ прямые ответы, точные условия и факты, которые можно проверить.

Как понять, что ИИ рассказывает о вашем продукте

Начните с диагностической проверки — ее можно провести за неделю. 

Она покажет текущее положение дел и поможет расставить приоритеты. Но это лишь первый шаг. Чтобы видимость бренда в ИИ-ответах росла, мониторинг и обновление материалов должны стать регулярной частью стратегии. 

Вот план действий на первую неделю:

1. Соберите 15–20 реальных вопросов из поиска по сайту, обращений в поддержку и комментариев к документации. Возьмите запросы о выборе сервиса, настройке, ограничениях, расчете стоимости и типовых ошибках.

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

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

После правок повторите тест в тех же условиях.

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

Но даже после такого аудита ошибки все равно могут остаться. В моем эксперименте официальная документация была доступна, а оба сервиса нашли нужные страницы и все равно смешали классы хранения, условия и платформы. Корректный источник сам по себе не гарантирует, что ИИ правильно выберет и свяжет факты.

На часть этого пути бренд может повлиять: открыть страницы для краулинга, убрать устаревшие материалы и дубли, явно назвать продукт, платформу и условия. Если все это сделано, а ИИ продолжает ошибаться, причина уже внутри черного ящика. Мы не можем узнать, почему модель выбрала конкретные фрагменты или заставить ее сформулировать ответ иначе.

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

Напомню про основные шаги.

Чек-лист: как работать со страницами

1. Давайте прямой ответ. Начинайте раздел с главной мысли, а подробности и исключения раскрывайте ниже.

2. Используйте понятные заголовки. Если уместно, формулируйте их как ответы на вопросы пользователей.

3. Не прячьте важное за JavaScript. Проверьте, что текст в табах, аккордеонах и других интерактивных элементах доступен ИИ-краулерам.

4. Добавляйте контекст к фактам. Рядом с цифрами указывайте единицы измерения, продукт, платформу, регион и другие важные условия.

5. Работайте с сигналами E-E-E-A-T. ИИ предпочитают высокое качество контента, подтвержденную надежность и авторитетность ресурса и экспертов.

6. Называйте продукты одинаково. Используйте одни и те же названия в документации, блоге, меню и других материалах.

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

8. Убирайте старые и повторяющиеся страницы. Настройте перенаправления и укажите основную версию материала, чтобы ИИ не выбрал устаревший источник.

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

10. Регулярно проверяйте ответы ИИ. Задавайте сервисам реальные вопросы пользователей и сверяйте ответы с документацией.

В следующем материале разберем, как адаптировать GEO-стратегию для лендингов и коммерческих страниц. А пока расскажите, как вы работаете над контентом вашего бренда?