Чтобы понять, как собрать семантическое ядро, нужно связать запросы с задачами бизнеса и страницами сайта: взять исходные формулировки из измерителя, очистить список, предложить смысловые группы с помощью ИИ и проверить их по поисковой выдаче. В этом процессе модель предлагает гипотезы, данные измерителя сохраняются с параметрами, а агент проверяет результат по заданным правилам. Ниже — последовательность и учебный пример: частоты в нём неизвестны, выдача не проверена.
Определите страницы и источники запросов
Сначала зафиксируйте, что именно предлагает бизнес, кому, в каком регионе и какое действие должна поддержать страница. Разделите страницы услуг или товаров и информационные материалы. Если предложение, аудитория или география пока неизвестны, оставьте эти поля незаполненными: модель не должна выбирать их за вас.
Затем составьте маски — исходные формулировки, описывающие реальные услуги, товары и вопросы клиентов. Сбор можно вести из нескольких источников, сохраняя происхождение каждой фразы.
- Измеритель запросов нужен, чтобы получить фразы и значения с выбранными параметрами. Например, справка Яндекс Вордстата описывает статистику запросов с заданным словом или сочетанием, динамику и фильтрацию по региону.
- Данные поиска по своему сайту, если доступна такая выгрузка, добавляйте отдельно с названием источника и датой или периодом. Не подменяйте ими измерение всего списка запросов.
- Языковая модель в описанном здесь процессе предлагает гипотезы новых формулировок и предварительные смысловые группы. Идею модели нужно отдельно проверить в источнике данных, прежде чем считать её измеренным запросом.
В предлагаемом процессе измерение поручено Топвизору, а модели — подготовка гипотез. Для автоматизированного пути Топвизора предусмотрены отдельные API-задачи подбора запросов и проверки частоты; агенту для работы нужны доступ к API и отдельная интеграция. Это описание API, а не инструкция по интерфейсу сервиса.
В API-задаче подбора передаются исходные keywords и qualifiers. В документации перечислены настройки поисковой системы и региона, а также параметры, доступность которых зависит от поисковой системы: например, сбор похожих запросов, глубина парсинга и минус-фразы. Метод запускает задачу и возвращает её ID (документация API Топвизора: подбор запросов). Для проверки частоты задаются keywords и qualifiers с поисковой системой, регионом и индексом типа частоты; метод также запускает задачу и возвращает её ID (документация API Топвизора: проверка частоты). Выбирайте параметры по справке и сохраняйте их вместе с результатом. Дату запуска задачи не следует автоматически считать подтверждением свежести данных измерителя: если свежесть неизвестна, так и укажите.
Для каждой фразы сохраните исходный текст, источник, регион, дату или период, параметры измерения и значение. Если значение ещё не получено, укажите null, а не ноль. Кандидаты, предложенные моделью, помечайте отдельно от фраз, полученных из измерителя или выгрузки.
Сохраните частоты и очистите список
Разделите техническую очистку и исключение нерелевантных формулировок. Агент может нормализовать пробелы и регистр, искать дубли по заданному правилу и сохранять исходные варианты. Он же может проверить, указаны ли источник и параметры для каждой измеренной фразы.
Минус-слова задают границы дальнейшего подбора, но не заменяют разбор задачи пользователя. Составьте их из того, что действительно не относится к предложению. Например, если бизнес не ремонтирует определённый тип изделий, соответствующие формулировки можно отправить на исключение с зафиксированной причиной. Не отбрасывайте запрос только потому, что в нём есть слова «цена» или «самому»: сначала разберите, какую задачу описывает фраза и относится ли она к предложению.
Дубли и нерелевантные запросы — разные случаи: дубли объединяют или помечают по принятому правилу, а для исключения нерелевантной фразы сохраняют причину. Частоту храните отдельно для каждой фразы. Если источник, дата или параметры отсутствуют, оставьте соответствующее поле пустым и отправьте запись на проверку.
Агент выполняет технические проверки по правилам и отправляет спорные случаи в очередь. Человек уточняет отсутствующие факты о предложении и решает исключения, для которых этих фактов недостаточно. Обязательная ручная вычитка каждой бесспорной строки не нужна.
Карта запросов без выдуманной частоты
Ниже — полный учебный промпт и заполненный результат в одинаковом формате JSON. Это условный пример: частоты не измерялись, а реальная выдача по указанным фразам не проверялась. Чтобы результат соответствовал входным данным, в них явно задано условное предложение — услуга ремонта рюкзаков — и условное целевое действие. Это допущение для учебного примера, а не подтверждённый факт о конкретном бизнесе. Группы остаются гипотезами; реальные URL не указаны.
Промпт задаёт модели роль и формат ответа. В руководстве Yandex Cloud по промптам рекомендуют заранее указывать структуру результата, например JSON.
Промпт:
Ты — аналитик поисковых запросов. Подготовь предварительную карту запросов и целевых страниц по переданным данным.
Правила:
1. Сохраняй исходную формулировку в raw_query. В cleaned_query исправляй только регистр и лишние пробелы.
2. Самостоятельно анализируй предполагаемую задачу пользователя и предлагай смысловые группы. Объединяй запросы, только если у них может быть общая задача и подходящий тип страницы.
3. Учитывай только переданные границы предложения. Неизвестные бизнес-факты не додумывай. Если запрос может относиться к разным задачам или требует проверки, помести его в review_queue и укажи причину.
4. Группировка только по формулировке — гипотеза. Не называй её подтверждённой кластеризацией по выдаче.
5. Каждый query_id укажи ровно один раз: либо в groups, либо в review_queue.
6. Не придумывай частотность, источник, регион, период, параметры измерения, бизнес-факты, URL и результаты проверки выдачи. Если данных нет, используй null.
7. Установи serp_checked в false, если реальные результаты поиска не переданы и не проверены. Это правило относится к каждой группе и каждому запросу, включая review_queue.
8. Если реальная целевая страница не выбрана, укажи target_page: null и target_page_status: "needs_selection".
9. Верни только JSON по схеме ниже. Не добавляй комментарии и новые поля.
Схема результата:
{
"business_context": {
"offer": null,
"audience": null,
"region": null,
"target_action": null
},
"groups": [
{
"group_id": "",
"intent_hypothesis": "",
"page_type_hypothesis": "",
"target_page": null,
"target_page_status": "needs_selection",
"serp_checked": false,
"queries": [
{
"query_id": "",
"raw_query": "",
"cleaned_query": "",
"frequency": null,
"measurement": {
"source": null,
"region": null,
"period": null,
"measurement_date": null,
"parameters": null
},
"serp_checked": false,
"review_reason": null
}
]
}
],
"review_queue": [
{
"query_id": "",
"raw_query": "",
"cleaned_query": "",
"frequency": null,
"measurement": {
"source": null,
"region": null,
"period": null,
"measurement_date": null,
"parameters": null
},
"serp_checked": false,
"review_reason": ""
}
]
}
Входные данные:
{
"business_context": {
"offer": "Условное предложение для учебного примера: услуга ремонта рюкзаков; гипотеза, не подтверждённый факт о бизнесе",
"audience": null,
"region": null,
"target_action": "Заказ услуги; условное допущение для учебного примера"
},
"queries": [
{"query_id": "Q1", "raw_query": "ремонт молнии рюкзака"},
{"query_id": "Q2", "raw_query": "замена молнии рюкзака цена"},
{"query_id": "Q3", "raw_query": "как починить молнию рюкзака самому"}
],
"frequency_data": null,
"serp_data": null
}
Условный заполненный результат для этого входа:
{
"business_context": {
"offer": "Условное предложение для учебного примера: услуга ремонта рюкзаков; гипотеза, не подтверждённый факт о бизнесе",
"audience": null,
"region": null,
"target_action": "Заказ услуги; условное допущение для учебного примера"
},
"groups": [
{
"group_id": "G1",
"intent_hypothesis": "Поиск услуги ремонта; предварительная гипотеза для условного предложения",
"page_type_hypothesis": "Страница услуги; предварительная гипотеза",
"target_page": null,
"target_page_status": "needs_selection",
"serp_checked": false,
"queries": [
{
"query_id": "Q1",
"raw_query": "ремонт молнии рюкзака",
"cleaned_query": "ремонт молнии рюкзака",
"frequency": null,
"measurement": {
"source": null,
"region": null,
"period": null,
"measurement_date": null,
"parameters": null
},
"serp_checked": false,
"review_reason": null
},
{
"query_id": "Q2",
"raw_query": "замена молнии рюкзака цена",
"cleaned_query": "замена молнии рюкзака цена",
"frequency": null,
"measurement": {
"source": null,
"region": null,
"period": null,
"measurement_date": null,
"parameters": null
},
"serp_checked": false,
"review_reason": null
}
]
}
],
"review_queue": [
{
"query_id": "Q3",
"raw_query": "как починить молнию рюкзака самому",
"cleaned_query": "как починить молнию рюкзака самому",
"frequency": null,
"measurement": {
"source": null,
"region": null,
"period": null,
"measurement_date": null,
"parameters": null
},
"serp_checked": false,
"review_reason": "Запрос о самостоятельном ремонте отличается от условной задачи заказа услуги; проверить границы предложения и подходящую страницу по выдаче"
}
]
}
Здесь Q1 и Q2 предварительно отнесены к группе услуги, а Q3 отправлен в очередь проверки как запрос о самостоятельном ремонте. Такое распределение — учебная гипотеза, а не результат проверки выдачи и не утверждение, что конкретный бизнес оказывает эту услугу. У всех трёх запросов frequency: null и serp_checked: false; каждый ID встречается ровно один раз. Агент может автоматически проверить эти условия и соответствие результата схеме. Если реальные границы предложения отличаются от условных, их уточняет человек, после чего карту нужно сформировать заново.
Проверьте выдачу и границы страниц
Предварительная группировка по формулировкам ещё не показывает, можно ли вести запросы на одну страницу. Для проверки нужны реальные результаты поиска по выбранным запросам и региону, а также доступ к самим страницам. Если инструмент или доступ к выдаче не подключён, оставьте статус serp_checked: false либо отметьте проверку как заблокированную. Не называйте такую карту кластеризацией по выдаче.
Если доступ есть, агент может пройти проверку по заданным критериям:
- Получить результаты поиска для запросов с зафиксированными поисковой системой и регионом.
- Сопоставить типы найденных страниц и задачи, которые они решают.
- Проверить, поддерживает ли выдача предложенную группу и тип целевой страницы.
- Отметить расхождения: разные типы страниц внутри группы, неоднозначную цель или запрос, который может относиться к нескольким страницам.
- После проверки предложить существующую страницу или оставить
target_page: null, если подходящая страница ещё не выбрана.
Агент фиксирует результаты и отправляет неоднозначные случаи в очередь. Человек определяет, соответствует ли найденная страница реальному предложению и где проходят границы услуги. Вручную пересматривать каждую бесспорную строку не требуется, если проверки по заданным правилам пройдены.
Обновляйте ядро по изменениям
Пересмотрите карту, если появляется новый продукт или раздел сайта, меняется выдача по важным запросам либо становится доступна новая выгрузка поисковых данных своего сайта. Частоту плановых проверок выбирайте по темпу изменений проекта: сам календарный интервал не подтверждает, что карта актуальна.
Рабочее ядро отличается от списка идей тем, что у фраз указаны источники и параметры, обработаны дубли и исключения, а группы связаны с целевыми страницами после проверки. Если частота, интент, URL или выдача ещё не проверены, это должно быть видно по статусу. Учебный пример выше остаётся предварительным и не обещает позиций или трафика.
Для подготовки публикаций по карте страниц см. планирование контента с ИИ. Если нужно организовать сбор и проверку как часть более широкого процесса, см. нейросети для маркетинга.
Почему одного чата недостаточно?
Чат может предложить формулировки и предварительные группы, но текстовый ответ сам по себе не является замером спроса и не подтверждает, что реальные страницы в выдаче решают одну задачу. Для этого нужны данные измерителя и результаты поиска, полученные для выбранных условий. Пока их нет, частота остаётся null, а группа — гипотезой.
Что считать ядром, а не списком идей?
Рабочее ядро — это запросы с указанными источниками и параметрами, очищенные от технических дублей и нерелевантных вариантов, сгруппированные по задачам и связанные с целевыми страницами после проверки выдачи. Неизвестные значения и непроверенные решения отмечены, а не представлены как готовый результат.
Карта запросов без выдуманной частоты