Какие запросы отслеживать в AI-поиске: от списка к решениям

Классификация запросов для AI-поиска

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

flowchart LR
  A["Запросы для AI-поиска"]
  B["Брендовые<br/>О своей компании"]
  C["Категорийные<br/>О задаче или продукте"]
  D["Конкурентные<br/>О других решениях"]
  B1["Описание · условия · доверие<br/>Что входит в тариф [наш бренд]?"]
  C1["Задача · критерии · выбор<br/>Какая CRM подходит отделу<br/>из восьми менеджеров?"]
  D1["Сравнение · альтернативы<br/>Чем заменить [конкурент]<br/>при смене CRM?"]
  A --> B --> B1
  A --> C --> C1
  A --> D --> D1
  classDef main fill:#0B5FD7,color:#FFFFFF,stroke:#0B5FD7
  classDef example fill:#FFFFFF,stroke:#DDE3EA,color:#10151C
  class A main
  class B1,C1,D1 example

В примерах замените [наш бренд] и [конкурент] на названия конкретных компаний. Категорийный запрос оставьте без названия бренда.

• Брендовые: проверяем, правильно ли AI описывает компанию, возможности продукта и условия покупки.
• Категорийные: проверяем, появляется ли продукт в ответах на задачу клиента без подсказки нашего названия.
• Конкурентные: проверяем, предлагает ли AI наш продукт при сравнении решений или поиске замены.

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

Начните с решения, которое принимает клиент

Запрос «лучшая CRM» почти ничего не говорит о покупателе. Неясны размер команды, бюджет, задача и ограничения. Ответ на такой вопрос может выглядеть убедительно и при этом не иметь отношения к вашему продукту.

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

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

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

Это учебные примеры. Они не показывают реальную выдачу или результаты какого-либо бренда.

Соберите вопросы из разговоров с клиентами

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

Для стартового списка достаточно четырёх источников:

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

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

Один вопрос можно уточнить по аудитории, географии или ограничению. Но добавляйте только детали, которые меняют решение. «CRM для команды из восьми человек» и «CRM для сети филиалов с разграничением доступа» — разные ситуации. «Посоветуй CRM» и «Какую CRM посоветуешь» могут оказаться дублями.

Отберите запросы, по которым можно действовать

Перед добавлением в мониторинг ответьте на четыре вопроса. Каждый ответ «да» даёт указанный балл. Это предложенная редакционная шкала для организации работы, а не формула ранжирования нейросетей.

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

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

Не превращайте внутренние поиски в список промптов

Google объясняет, что AI Mode и AI Overviews могут выполнять несколько связанных поисков для подготовки ответа. Этот механизм называют query fan-out: исходный вопрос раскладывается на подзадачи.

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

Посчитайте объём проверок до выбора сервиса

Для пилота предлагаю 12 клиентских ситуаций, по одному основному вопросу на каждую. Проверяйте их в двух нужных вам поисковых AI-продуктах, по три раза в отдельных новых диалогах. Получится 12 × 2 × 3 = 72 ответа за один цикл.

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

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

Зафиксируйте условия замера

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

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

Для каждого наблюдения сохраняйте:

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

Доступ через интерфейс и результат через API также разделяйте: это разные условия наблюдения. Если сервис мониторинга не раскрывает часть настроек, укажите «неизвестно». Не дописывайте их по догадке.

Точный промпт в регулярном наборе лучше не редактировать. Новую формулировку добавьте с новым ID и некоторое время проверяйте рядом со старой. Так вы отделите изменение вопроса от изменения ответа.

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

Компания может появиться в ответе как пример, как неподходящий вариант или как рекомендация. Ссылка может вести на ваш сайт либо на сторонний обзор. Для бизнеса это разные события.

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

Считайте показатели с явным знаменателем

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

В учебном примере один продукт дал 36 пригодных ответов: 12 вопросов × 3 повтора. Бренд упомянут в девяти, свой домен указан в четырёх, продукт рекомендован в трёх.

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

Ошибки сервиса и ответы без нужного режима отражайте отдельной строкой: сколько попыток сделано и сколько ответов пригодно. Если из 36 попыток пригодно только 24, изменение доли без этой оговорки может ввести в заблуждение.

Не путайте проценты и процентные пункты

В другом учебном примере доля выросла с 25% до 33,3%. Изменение составляет 8,3 процентного пункта. Относительный рост — примерно 33%, но на небольшом наборе это может быть всего три дополнительных ответа: было 9 из 36, стало 12 из 36.

В отчёт ставьте и долю, и абсолютное число. Рядом показывайте результаты отдельных вопросов: общий показатель способен скрыть падение в важной клиентской ситуации.

Превратите ответ в задачу для сайта

Полезный результат мониторинга — конкретное действие с ответственным и сроком проверки. Запись «улучшить GEO» этого не даёт.

Для Google базовые требования остаются прежними: страница должна быть индексируемой, доступной для показа со сниппетом и отвечать требованиям поиска. Специальная AI-разметка для включения в AI Mode и AI Overviews не требуется. Выполнение требований не гарантирует появления страницы.

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

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

Отчитывайтесь о решениях и ограничениях

В еженедельном отчёте достаточно четырёх частей:

1. Какие ситуации клиента проверяли и в каких AI-продуктах.
2. Сколько было попыток, пригодных ответов, упоминаний и ссылок.
3. Какие ошибки или пробелы обнаружили и на каких страницах.
4. Что исправляем, кто отвечает и когда повторяем замер.

Например: «В учебном наборе по переносу CRM бренд появился в 4 из 12 ответов. В двух ответах неверно описан импорт контактов. Проверяем страницу переноса и процитированный обзор. Следующий замер — после обновления материалов». Такая запись объясняет работу лучше, чем число без состава выборки.

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

Ошибки, которые портят мониторинг

• Менять набор перед каждым отчётом. Состав выборки изменился — итоговая доля уже не сопоставима. Показывайте старый и новый набор отдельно.
• Объединять разные AI-продукты в одно число. Рост в одном может скрыть падение в другом. Начинайте отчёт с отдельных результатов.
• Удалять важный вопрос из-за нулевого результата. Ноль может указывать на пробел. Сначала проверьте, по-прежнему ли ситуация важна бизнесу.
• Принимать ссылку за рекомендацию. Прочитайте фрагмент, где упомянут продукт: он может содержать критику или исключение.
• Публиковать учебные цифры как свой кейс. Примеры в этой статье показывают расчёт. Для кейса нужны сохранённые ответы и описание условий реального замера.

План первого цикла

1. Выберите одно направление бизнеса и выпишите клиентские ситуации.
2. Подготовьте 12 основных вопросов и несколько отдельных вопросов о бренде.
3. Укажите ID, приоритет и целевую страницу для каждого вопроса.
4. Зафиксируйте AI-продукты и условия проверки.
5. Проведите первый цикл, сохраните ответы и разметьте события.
6. Выберите две конкретные задачи по страницам или ошибочным сведениям.
7. После правок повторите замер, сохранив исходный набор.

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