1. Выбрать точку выбора
Опишите, какое решение принимает пользователь: выбрать сервис, подрядчика, приложение, товар или подход. От этого зависят промпты, конкуренты и источники. Слишком широкий банк запросов скрывает конкретные пробелы.
Запишите задачу в одном предложении: «Хотим понять, какие сервисы мониторинга AI-видимости рекомендуют российским B2B-компаниям и по каким критериям». Такая формулировка задаёт рынок, аудиторию, категорию и ожидаемый тип ответа.
2. Зафиксировать исходное состояние
Baseline должен быть снят до публикаций и внешних размещений. Сохраните не только итоговые проценты, но и исходные ответы: они понадобятся, чтобы проверить контекст упоминаний и состав источников.
Минимальная карточка baseline содержит версию prompt bank, список AI-поверхностей, дату, число ожидаемых и валидных ответов, определения сигналов и известные ограничения.
3. Устранить технические барьеры
Сначала исправьте доступность, канонические адреса, sitemap, перелинковку и страницы с противоречивым описанием. Техническая исправность не создаёт рекомендацию, но без неё содержательная работа может остаться необнаруженной.
Не смешивайте технические и редакционные задачи в одну формулировку. «Исправить canonical на странице методологии» проверяется HTTP и HTML; «сделать методологию полезной» проверяется содержанием, источниками и пользовательским вопросом.
4. Построить тематический контур
У продукта должна быть отдельная страница, а у базы знаний — страницы под разные вопросы. Определения ведут к статьям, статьи к гайдам, гайды к данным и кейсам. Связь строится по смыслу, а не одинаковым блоком на всех URL.
Минимальный законченный кластер:
продукт → методология → определение метрики → практический гайд → данные или кейс.
Каждая страница выполняет собственную работу. Если один и тот же текст повторяется на всех пяти URL, это не кластер, а дублирование.
5. Добавить доказательства
Приоритет получают собственные данные, прозрачная методология, реальные примеры и внешние источники, которые подтверждают конкретный тезис. Массовые поверхностные статьи увеличивают объём сайта, но не доказательность.
| Утверждение | Подходящее подтверждение |
|---|---|
| продукт измеряет сигнал | реальный интерфейс, отчёт или спецификация |
| метрика считается по формуле | публичная методология и пример |
| на рынке есть решения | проверяемый реестр и критерии включения |
| действие дало результат | baseline, вмешательство и сопоставимый повтор |
| платформа поддерживает функцию | актуальная официальная документация |
6. Проверить source gaps
Сопоставьте источники конкурентов с собственным присутствием. Если ответная система регулярно использует отраслевые каталоги, исследования или обзоры, оцените, какого проверяемого материала о бренде там нет.
Source gap не означает «разместиться везде». Сначала подтвердите повторяемость домена по целевому кластеру, затем проверьте редакционную уместность, возможность публиковать проверяемые сведения и способ измерить результат.
7. Запустить один эксперимент
Меняйте ограниченный набор факторов и фиксируйте дату. Например: опубликовать методологию и связать её с продуктом и глоссарием. Не смешивайте десятки изменений, если хотите понять, что могло повлиять на результат.
Карточка эксперимента включает гипотезу и механизм, изменённые URL, дату публикации, primary metric, контроль, условие остановки и окно повторных запусков.
8. Повторить срез
Проверяйте те же запросы и системы. Сначала оцените полноту запуска, затем метрики. Если сигнал появился один раз, продолжите наблюдение; если повторяется, зафиксируйте его как устойчивое изменение, но не как гарантированную причинность.
Как расставлять приоритеты
| Приоритет | Когда ставить | Пример |
|---|---|---|
| P0 | информация недоступна или явно неверна | noindex, 404, противоречивая категория продукта |
| P1 | пробел закрывает важный интент или доказательство | нет методологии, отчёта, страницы продукта |
| P2 | есть основание для эксперимента | новый формат исследования или внешняя площадка |
| Не делать | нет отдельного вопроса или способа проверки | десятки страниц-синонимов |
Сначала исправляйте то, что влияет на весь кластер: сущность, доступность и ключевые доказательства. Потом расширяйте покрытие.
Рабочий ритм
- Еженедельно проверять доступность изменённых URL и технические ошибки.
- По утверждённому расписанию запускать core prompt bank.
- Раз в цикл разбирать конкурентов и источники, а не только общий процент.
- Фиксировать, какие задачи опубликованы и какие ещё не обнаружены.
- Обновлять backlog по данным, сохраняя контрольную группу.
Когда остановиться и пересмотреть план
Остановите масштабирование, если полнота запуска падает, определения меняются между срезами, страницы дублируют друг друга или команда не может связать задачу с наблюдением. В такой ситуации новый контент добавит шум.
Цикл считается рабочим, когда у каждой публикации есть исходная точка, ожидаемый сигнал и сопоставимый повтор. Отсутствие роста тоже является результатом: гипотеза может быть отклонена или потребовать другого механизма.
