Контент-план для query fan-out: закрывать подзадачи, а не плодить URL

Что здесь означает query fan-out

В Google AI Overviews и AI Mode сложный вопрос может приводить к нескольким связанным поискам по подтемам и источникам. Яндекс описывает похожий принцип для Алисы AI: она может уточнить исходную формулировку, обратиться к Поиску с уточнёнными запросами и собрать ответ по смысловым блокам.

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

С чего начать: не с ключевого слова, а с решения пользователя

Сформулируйте исходный вопрос с рынком и ограничением. Например: «Как российскому B2B-бренду выбрать способ мониторинга упоминаний в AI-ответах?» Это не равнозначно фразе «мониторинг AI-видимости»: здесь уже есть выбор, география, тип компании и ожидаемый результат.

Wordstat полезен для поиска реальных формулировок и связанных тем в Яндексе, но не является счётчиком запросов во всех AI-системах. Поэтому в рабочей карте храните отдельно:

Как разложить вопрос на 5–8 проверяемых подзадач

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

1. Что именно считается AI-видимостью: упоминание, рекомендация, ссылка или переход?
2. Какие AI-поверхности и режимы важны для российского рынка и конкретного продукта?
3. Как собрать prompt bank и не перепутать его с семантическим ядром?
4. Как зафиксировать baseline и знаменатель метрик?
5. Когда достаточно ручной проверки, а когда нужен регулярный мониторинг?
6. Как интерпретировать источники и конкурентов, показанные рядом с ответом?
7. Какие ограничения есть у повторных запусков и причинных выводов?

Это не предполагаемая трассировка Google, Алисы, ChatGPT или любой другой системы. Это проверяемый план человеческого решения. Если подзадача не меняет выбор читателя и не требует отдельного доказательства, не превращайте её в секцию или URL.

Как сопоставить подзадачи с существующими страницами

Сначала сделайте таблицу «подзадача → лучший существующий ответ → пробел». Новая страница оправдана, когда вопрос самостоятельный, материал не дублирует соседний URL и у команды есть данные, метод или первичный источник для честного ответа.

Один URL может закрывать несколько близких подзадач через H2-разделы. Но нельзя склеивать в нём несовместимые задачи, например объяснение метрики, юридическую гарантию и коммерческий рейтинг без единого метода.

Как выбрать формат, доказательство и следующий шаг

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

В исследовании Киберкошки по сохранённому коммерческому срезу часто встречались страницы, решающие прикладные задачи: инструкции, списки вариантов, объяснения и сравнения. Это наблюдение о конкретной выборке, а не правило, по которому AI выбирает источники. Поэтому искусственный рейтинг или FAQ ради формата не закрывает доказательный пробел.

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

Как не превратить карту в фабрику страниц

Признаки, что новый URL создавать рано:

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

Google прямо указывает, что для AI-функций применяются обычные требования Search: страница должна быть индексирована и пригодна для показа сниппета, а специальных файлов, разметки или новых технических требований нет. Это причина улучшать полезность и связность существующих страниц до расширения количества URL.

Как проверить карту после публикации

Проверка не начинается с вопроса «попали ли мы в ответ». Сначала убедитесь, что канонический URL доступен, основной текст виден, внутренние ссылки ведут на него, а факты, даты и schema согласованы. Затем дождитесь обнаружения изменения и повторите заранее утверждённый срез с теми же вопросами, системами и правилами разметки.

Отдельно фиксируйте:

• доступность и индексирование страницы;
• показ URL в источниках;
• корректность описания бренда;
• упоминание и рекомендацию бренда;
• переходы и бизнес-результат, если их можно измерить.

Эти события не взаимозаменяемы. Одна ссылка не доказывает рекомендацию, а одно совпадение во времени не доказывает, что её вызвала новая статья.

Рабочий результат контент-плана

Готовая карта содержит исходный вопрос, 5–8 подзадач, существующие URL, подтверждённые пробелы, нужный тип доказательства, владельца, дату проверки и метрику следующего среза. Начните с одной P1-задачи, которую можно честно закрыть; затем свяжите её с методикой, данными и соседними страницами. Так контентная архитектура остаётся полезной и человеку, и поисковому контуру — без обещания результата в конкретном AI-ответе.