У AI-видимости нет одного универсального аналога позиции в классической поисковой выдаче. В одном случае платформа сама даёт статистику показов сайта в генеративных функциях. В другом можно измерить переходы из AI-сервиса. В третьем остаётся регулярно задавать одинаковые вопросы и фиксировать, упоминается ли сущность, какой источник используется и насколько корректно она описана.
Поэтому хороший отчёт не сводит всё к одному «AI Visibility Score». Он разделяет platform data, referral traffic и собственные повторяемые наблюдения по фиксированному набору prompts. Только после этого можно говорить о динамике.
Главная задача измерения — не доказать, что бренд «занимает место №3 в нейросети», а получить ряд наблюдений, который можно воспроизвести и сравнить с предыдущим замером.
Сначала определите, что именно вы называете AI-видимостью
Под одним словом часто смешивают несколько разных событий:
- бренд или сущность названы в ответе;
- сайт указан среди источников;
- конкретная страница процитирована или связана с ответом;
- система корректно объяснила сущность;
- сайт получил переход из AI-сервиса;
- страница получила impressions внутри генеративной функции поиска.
Это не одна метрика. Например, AI-система может назвать компанию, но сослаться на сторонний обзор. Или наоборот: использовать страницу сайта как источник для факта, не выводя название бренда как отдельную рекомендацию. Поэтому перед первым замером нужно определить, какой результат считается наблюдаемым.
Упоминание и цитирование — разные события
Для brand visibility важен факт появления сущности в ответе. Для publisher visibility важен факт использования собственного сайта как источника. Эти события могут совпадать, но не обязаны.
Поэтому в журнале лучше иметь минимум два отдельных поля:
Entity mentioned: да / нет
Own domain cited or linked: да / нет
Не объединяйте их в одно бинарное «виден / не виден».
Корректное упоминание и просто упоминание тоже нужно разделять
Сам факт появления названия ещё не означает хороший результат. AI-ответ может правильно описать сущность, перепутать её с одноимённым объектом, приписать неверного автора, использовать устаревшие сведения или сделать вывод сильнее доступных источников.
Для небольшой панели достаточно трёх статусов:
| Статус | Что означает |
|---|---|
| Корректно | Основные факты и контекст совпадают с проверяемыми источниками |
| Частично корректно | Основное определение верно, но есть существенная неточность или потеря условия |
| Некорректно | Сущность перепутана или важный факт передан неверно |
Первый слой измерения — официальные данные самой платформы
Если платформа даёт собственный отчёт, его лучше отделять от ручного prompt-monitoring.
В 2026 году Google начал развёртывать отдельный Generative AI performance report в Search Console. Он показывает, как сайт получает impressions в генеративных функциях Google Search. В отчёт включены AI Overviews и AI Mode.
Google позволяет смотреть:
- динамику impressions;
- страницы;
- страны;
- устройства;
- даты.
Это другой тип данных, чем ручная проверка нескольких вопросов. Здесь речь идёт о platform telemetry — о том, что зафиксировал сам Google внутри своих генеративных поисковых функций.
Что означает impression в генеративном отчёте Google
Google определяет impression в этом отчёте как случай, когда ссылка на сайт была показана пользователю внутри генеративной функции Google Search. Метрика не означает, что бренд обязательно был назван в тексте ответа, что сайт был главным источником или что произошёл переход.
Она отвечает на более конкретный вопрос:
Сколько раз ссылка на сайт была показана в поддерживаемых generative AI features Google Search?
В Generative AI report тоже есть ограничения агрегации
На уровне графика Search Console агрегирует generative AI impressions по property. Если в одном генеративном результате показаны две ссылки одного сайта, в property total это может считаться одним impression. Если данные сгруппированы по page, каждая страница получает собственную статистику.
Поэтому chart total и сумма строк Pages иногда различаются. Кроме того, даты используются в Pacific Time, самые свежие данные могут быть preliminary, а обычные ограничения Search Console по строкам и периодам распространяются и на generative AI report.
Даже официальный AI-отчёт нужно читать по тем же принципам сопоставимости данных, что и другие аналитические источники.
Не все сайты уже видят Generative AI performance report
На момент проверки Google разворачивает отчёт постепенно. По официальной документации он может отсутствовать, если property ещё не получил доступ к функции или сайт не набрал достаточного числа impressions в поддерживаемых генеративных функциях.
Поэтому отсутствие раздела в Search Console само по себе не означает нулевую AI-видимость сайта во всех системах.
Второй слой — referral traffic из AI-сервисов
AI-ответ и переход на сайт — разные события. Система может показать ссылку, но пользователь не перейдёт.
OpenAI указывает, что publishers, разрешающие OAI-SearchBot доступ к сайту, могут отслеживать referral traffic из ChatGPT через обычные аналитические платформы. ChatGPT добавляет к referral URL параметр:
utm_source=chatgpt.com
Это даёт отдельный измеряемый слой:
AI answer / search result
↓
link
↓
click
↓
visit on site
Referral traffic нельзя использовать как полный proxy AI-видимости. Но он полезен как подтверждение фактических переходов.
Impressions, citations и referrals нельзя складывать в одну цифру
Google Search Console может показывать generative AI impressions, ручной мониторинг — citations домена в AI-ответах, а веб-аналитика — переходы из ChatGPT.
Это разные этапы:
появление / показ
↓
источник в ответе
↓
переход пользователя
Между ними нет обязательного отношения 1:1. Поэтому итоговый отчёт лучше строить слоями, а не пытаться вывести единую «видимость 73 балла» без прозрачной формулы.
Третий слой — собственная панель фиксированных prompts
Для платформ, где у владельца сайта нет полноценной first-party статистики видимости, остаётся observational monitoring.
- Зафиксировать набор вопросов.
- Задавать их в одних и тех же системах.
- Сохранять ответы.
- Отмечать упоминания и источники.
- Повторять замер по расписанию.
Это не «официальный объём показов». Это панель контролируемых проверок, похожая по логике на набор тестовых запросов.
Prompt panel должен появиться до первого результата
Если вопросы добавляются после просмотра удачных ответов, выборка становится предвзятой. Например, сначала проверили 30 формулировок, а сущность появилась в четырёх. Если в отчёт оставить только эти четыре, visibility будет выглядеть как 100%.
Поэтому сначала фиксируют denominator:
всего prompts в панели: N
и только после этого считают:
prompts с упоминанием / все prompts
Не нужно создавать десятки почти одинаковых вопросов
Панель должна покрывать самостоятельные пользовательские задачи, а не искусственно увеличивать denominator близкими перефразировками.
Вместо пяти вариантов «Что такое X?» полезнее оставить один основной вопрос на определение и добавить другие интенты: категорию, задачу, сравнение и поиск источника.
Разделите prompts по пользовательским задачам
| Класс | Какой вопрос проверяет |
|---|---|
| Entity | Понимает ли система, что это за сущность |
| Category | Появляется ли сущность внутри своей категории |
| Problem | Появляется ли она при решении релевантной задачи |
| Comparison | Попадает ли в сравнение с альтернативами |
| Source-seeking | Какие источники система использует по теме |
Так visibility можно анализировать не только общим процентом, но и по типам интента.
Entity prompt и discovery prompt измеряют разные вещи
Запрос «Что такое [сущность]?» уже содержит название. Если система повторила его в ответе, это ещё не доказывает discovery внутри категории.
Более строгий тест — вопрос, где название не подсказывается заранее.
Поэтому полезно разделять:
branded / entity-known prompts
vs
unbranded / discovery prompts
Их не стоит смешивать в одну долю без пометки.
Формулировку базового prompt лучше сохранять неизменной
Если в одном замере спросили «Какие сервисы подходят для задачи X?», а в следующем — «Назови лучшие современные сервисы для X в России», это уже другой запрос.
Изменились оценочность, требование современности и география.
Поэтому для временного ряда базовый prompt лучше не редактировать. Новые формулировки можно добавлять как новые строки с собственной датой начала наблюдений.
Сохраняйте систему и surface
Название AI-сервиса недостаточно. Пользователь может получать ответ через обычный чат, режим поиска, AI Mode, API или стороннее приложение. Это разные surfaces.
В журнале полезно хранить:
платформа
surface / режим
дата
язык
страна или локаль, если релевантно
точный prompt
Если baseline собирался в пользовательском интерфейсе, последующий ряд лучше продолжать в том же типе interface, а API-тесты держать отдельно.
Не называйте API-замер автоматически «тем, что видит пользователь»
API полезен для автоматизации повторяющихся тестов, но consumer product и API могут использовать разные product-level настройки, инструменты и режимы.
Поэтому правильнее подписывать метод буквально:
Результат получен через API по фиксированному prompt.
или:
Результат получен в пользовательском интерфейсе сервиса.
Не смешивайте два способа в один временной ряд без отдельной проверки сопоставимости.
Сохраняйте полный ответ, а не только «да / нет»
Бинарный журнал не показывает контекст, роль сущности, корректность фактов, конкурентов и sources.
Поэтому сохраняйте:
- полный текст ответа или доступный export;
- скриншот, если интерфейс важен;
- source links;
- дату и время;
- точный prompt.
Source URL лучше фиксировать отдельно от source domain
AI-система может в одном замере сослаться на одну страницу домена, а в следующем — на другую. На уровне domain источник формально не изменился. На уровне контента изменился.
Поэтому полезны два поля:
source domain
source URL
Проверяйте правильность атрибуции
Система может сослаться на реальную страницу и при этом приписать ей утверждение, которого там нет.
Поэтому статус «домен процитирован» лучше дополнять проверкой:
Источник действительно подтверждает соседний claim?
| Статус source attribution | Значение |
|---|---|
| Поддерживает | Источник содержит информацию, соответствующую claim |
| Частично поддерживает | Источник близок по теме, но не подтверждает весь claim |
| Не поддерживает | Ссылка существует, но нужного основания в источнике нет |
Mention rate считается только при известном denominator
Mention rate =
число prompts, где сущность упомянута
/
общее число проверенных prompts
× 100%
Если панель содержит 20 prompts, а сущность появилась в 7 ответах, корректно сказать:
Сущность упомянута в 35% ответов внутри нашей фиксированной панели из 20 prompts.
Но нельзя переносить этот процент на все возможные ответы системы.
Citation rate считайте отдельно
Citation rate =
prompts, где указан нужный домен
/
все проверенные prompts
× 100%
Можно использовать и другой denominator, например только prompts с внешними источниками. Главное — определить его заранее и не менять между замерами.
Не придумывайте «среднюю AI-позицию», если интерфейс не даёт ранга
В генеративном ответе сущности могут упоминаться в прозе, списке, таблице или только в source card. Номер предложения или визуальная последовательность не всегда являются рейтингом.
Поэтому метрика «AI Average Position» требует строгого определения метода. Если такого определения нет, лучше измерять более наблюдаемые признаки: mention, citation, recommendation status и source URL.
Recommendation — отдельный статус
Сущность может быть просто упомянута, включена в список вариантов или явно рекомендована для заданного сценария.
Для собственной панели можно использовать простую шкалу:
0 — отсутствует
1 — упомянута
2 — включена в релевантный список / сравнение
3 — явно рекомендована под условие prompt
Это редакционная кодировка вашей панели, а не внутренняя метрика AI-платформы. Именно так её и нужно подписывать.
Конкурентов сравнивайте на одном prompt panel
Для comparative monitoring нужны:
одинаковые prompts
+
одинаковые системы
+
одинаковые даты
+
одинаковая логика кодировки
Тогда можно сравнивать prompt coverage разных сущностей. Но это всё равно доля присутствия внутри выбранной панели, а не «доля всего AI-рынка».
Язык и география — часть условий замера
Один и тот же вопрос на русском и английском может обращаться к разным информационным пространствам. География тоже влияет на часть поисковых и локальных сценариев.
Поэтому при регулярном monitoring стоит хранить язык prompt и страну или регион, если они релевантны.
Дата замера обязательна
AI-продукты и поисковые функции меняются. Обновляются модели, retrieval, источники, интерфейсы и доступность функций.
Поэтому вместо «система упоминает бренд» лучше писать:
В замере от 20 августа 2026 года сущность появилась в 7 из 20 prompts выбранной панели.
Повторный замер должен сохранять старые prompts
Новые пользовательские вопросы полезно добавлять, но если каждый месяц полностью менять prompt set, временной ряд исчезает.
Core panel
— неизменный набор для динамики
Expansion panel
— новые prompts для исследования
Retired prompts
— вопросы, которые больше не актуальны, но сохраняются в истории
Так можно одновременно поддерживать актуальность и сопоставимость.
Не смешивайте платформы в один ряд без разбивки
Общий unweighted показатель можно использовать как техническую сводку, но результаты по каждой системе лучше показывать отдельно.
Если вводятся веса платформ, у них должно быть бизнес-основание: referral traffic, данные CRM, исследование аудитории или другой проверяемый источник.
Source diversity можно измерять отдельно
Кроме собственного домена интересно наблюдать, какие источники повторяются по теме: официальные сайты, отраслевые СМИ, исследования, форумы и другие типы ресурсов.
Для каждого замера можно сохранять список cited domains и смотреть, какие источники повторяются, появляются впервые или исчезают.
Это observational source map. Она описывает источники внутри вашей панели, а не полный набор ресурсов, используемых системой.
Не делайте причинный вывод после появления citation
Если 1 августа опубликована новая статья, а 10 августа собственный домен впервые появился среди источников AI-ответа, можно зафиксировать последовательность событий. Но из неё нельзя автоматически заключить, что именно эта публикация вызвала citation. Между замерами могли измениться retrieval, индекс, модель, конкурирующие источники и сама система. Задача этой статьи — измерять наблюдение, а не доказывать причинность.
Google советует измерять свои generative features через Search Console
В официальном руководстве Google 2026 года сказано использовать Generative AI performance report в Search Console для оценки того, как контент работает в генеративных функциях Google Search. Там же Google предупреждает: сторонние инструменты не имеют доступа к внутренним ranking или AI systems Google. Поэтому внешний сервис может быть полезен для workflow и собственных prompt-наблюдений, но его proprietary score нельзя представлять как внутреннюю метрику Google.
Сторонний AI visibility score всегда требует методологии
Если инструмент показывает «AI Visibility = 64», нужно выяснить:
- какие платформы включены;
- сколько prompts;
- как prompts выбираются;
- как часто проводится проверка;
- что считается mention;
- что считается citation;
- есть ли веса;
- используется UI или API;
- как обрабатываются повторные ответы.
Без этого score удобен как интерфейсный индикатор, но слаб как воспроизводимая аналитическая метрика.
При смене инструмента сделайте параллельный замер
Чтобы не принять смену методики за рост или падение, старый и новый инструменты полезно на короткое время запускать параллельно.
Неделя 1:
старый инструмент + новый инструмент
Неделя 2:
старый инструмент + новый инструмент
Неделя 3:
новый инструмент
Так становится видна систематическая разница между методиками.
Referral traffic проверяйте отдельно от ручной панели
Mention rate может расти, citation rate — тоже, а referral traffic оставаться прежним. Это не противоречие: пользователь может получить ответ без перехода.
И наоборот, рост referrals не доказывает, что mention rate вырос во всех prompt-классах.
| Слой | Что фиксируем |
|---|---|
| Platform telemetry | Официальные impressions и другие доступные метрики самой платформы |
| Prompt monitoring | Упоминания, citations, корректность, тип ответа |
| Referral | Фактические переходы на сайт из AI-сервисов |
| Business outcome | Лиды, сделки, выручка после перехода, если атрибуция позволяет это установить |
Рабочая карточка одного AI-замера
Дата:
Время:
Платформа:
Surface / режим:
Язык:
Страна / локаль:
Prompt ID:
Точный prompt:
Класс prompt:
Сущность упомянута:
[ ] да
[ ] нет
Статус:
[ ] просто упоминание
[ ] сравнение / список
[ ] рекомендация
Корректность:
[ ] корректно
[ ] частично
[ ] некорректно
Есть внешние источники:
[ ] да
[ ] нет
Собственный домен среди источников:
[ ] да
[ ] нет
Source domain:
Source URL:
Источник поддерживает соседний claim:
[ ] да
[ ] частично
[ ] нет
Ответ сохранён:
[ ] текст
[ ] скриншот
[ ] export
Что делать, если один prompt даёт разные ответы
Не выбирайте самый выгодный результат. Если один и тот же prompt проверяется несколько раз, каждый повтор нужно сохранить. Тогда можно отдельно считать repeat mention rate:
Prompt P01
5 повторов
упоминание:
да / нет / да / да / нет
repeat mention rate:
3 / 5
Этот показатель нельзя смешивать с общим prompt coverage: denominator у них разный.
Не скрывайте нулевые наблюдения
Если в очередном замере сущность не появилась, собственный домен исчез из sources или описание стало менее точным, эти точки нужно сохранять. Иначе история превращается в подборку удачных ответов, а не временной ряд.
Если разные сервисы дают разные AI-метрики, сначала сравните методологию
Один сервис показывает visibility 30%, второй — 52%. До вывода о проблеме проверьте платформы, prompts, язык, регион, способ доступа, дату, определение mention и denominator.
Это тот же класс reconciliation-задачи, который встречается в обычной веб-аналитике. Общая методика разбора таких расхождений описана в статье о том, почему аналитические системы показывают разные цифры.
Короткий алгоритм мониторинга AI-видимости
- Определите измеряемую сущность.
- Разделите mention, citation, correctness и referral.
- Проверьте, есть ли first-party platform data.
- Создайте core prompt panel до просмотра результатов.
- Разделите branded и discovery prompts.
- Зафиксируйте платформы и surfaces.
- Сохраните язык и географию.
- Не меняйте базовые prompts между замерами.
- Сохраняйте полный ответ и source URLs.
- Кодируйте корректность отдельно от самого упоминания.
- Считайте метрики только с явным denominator.
- Не превращайте визуальный порядок сущностей в «позицию» без методики.
- Отдельно отслеживайте referrals.
- Сохраняйте нулевые наблюдения.
- Формулируйте вывод в пределах собственной панели.
Диагностическая таблица
| Наблюдение | Что проверить |
|---|---|
| Бренд упоминается, но сайт не цитируется | Разделяйте brand mention и own-domain citation |
| Сайт цитируется, но бренд не назван | Фиксируйте publisher visibility отдельно |
| Mention rate вырос после смены сервиса мониторинга | Не изменилась ли методика сбора |
| Результаты одного prompt меняются | Используйте repeats и сохраняйте каждый ответ |
| Разные AI-tools дают разные visibility scores | Сравните prompt set, platforms, denominator и метод получения ответа |
| Citation выросла, referrals нет | Это разные стадии, отсутствие клика не отменяет citation |
| Referral traffic вырос, mention panel стабильна | Панель может не покрывать prompts, которые дали переходы |
| Google показывает generative impressions, ручная панель нет | First-party telemetry шире выбранного набора ручных prompts |
| Один ответ содержит неверный факт о сущности | Не считать упоминание автоматически качественным результатом |
| Сущность появилась после публикации статьи | Фиксировать последовательность, но не объявлять причинность |
Итог: AI-видимость — это несколько измерительных слоёв
Рабочая модель выглядит так:
сущность
↓
фиксированный набор prompts
↓
платформа и surface
↓
дата / язык / география
↓
упоминание
↓
корректность
↓
citation / source URL
↓
повторный замер
↓
platform telemetry
↓
referral traffic
↓
динамика с ограничениями
Для Google в 2026 году уже появляется отдельный first-party слой через Generative AI performance report в Search Console. Для ChatGPT можно отдельно видеть referral traffic на сайт. Для остальных задач остаётся собственная повторяемая панель наблюдений.
Эти источники не заменяют друг друга.
Хороший AI-visibility report показывает не одну красивую оценку, а что именно наблюдалось, где, по каким prompts, в какой день и каким способом это можно проверить повторно.
В общей системе SEO-измерений такой мониторинг является одним из отдельных слоёв наряду с поисковой динамикой и ссылочными показателями. Общая методика собрана в материале о том, как измерять SEO-эксперимент.
Источники
Источники проверены 19 августа 2026 года.