Какие запросы ставить на мониторинг: контрольное ядро проекта

Семантика собрана, в выгрузке 3 000 запросов. Дальше возникает вопрос, который решают по-разному и обычно молча: ставить на съём всё или не всё? Поставить всё технически проще, и именно поэтому так чаще всего и делают.

Разберём, как отбирают контрольное ядро и что при этом отсекается.

Зачем вообще снимать

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

Отсюда и критерий отбора. Правильный вопрос к каждому запросу звучит так: что я сделаю, если увижу, что он просел? Если ответа нет, запросу на съёме делать нечего.

Что попадает в контрольное ядро

Коммерческие запросы с посадочной страницей. То, по чему приходят с деньгами и куда человека есть куда привести. Если страницы нет, запрос пока не для мониторинга, а для контент-плана.

Запросы под KPI. Если в договоре есть список, он идёт на съём целиком и в полном составе, вне зависимости от вашего мнения о его качестве.

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

Конкурентные ориентиры. Пять-десять запросов, где вы стоите рядом с сильными конкурентами и где движение будет заметно раньше остального ядра.

Что не попадает

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

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

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

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

Отбор на условном проекте

Было 3 000 запросов. Сначала группируем по разделам сайта — получается, скажем, 40 групп, где каждая соответствует существующей или планируемой странице.

Дальше в каждой группе оставляем один-два маркера: 40 групп × 2 = 80 запросов. К ним добавляем список под KPI, допустим 50 запросов, и десяток конкурентных ориентиров. Итого 80 + 50 + 10 = 140 запросов на постоянном съёме вместо трёх тысяч.

Разница не только в счёте за съём — она в читаемости. Отчёт на 140 строк можно просмотреть глазами и увидеть картину. Отчёт на 3 000 строк просматривают по диагонали, то есть не просматривают.

Группы и пересборка ядра

Группы стоит заводить сразу по схеме «раздел → страница → запросы», а не по алфавиту или частотности: тогда динамика читается по разделам, и в отчёте клиенту будет что показать, кроме списка фраз.

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

Где этот подход не работает

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

Граница примерно такая: если по запросу решение принимается вручную, он кандидат в контрольное ядро; если решения принимаются пачками по категории, снимать нужно категорию целиком и смотреть на видимость, а не на отдельные строки.

Что в итоге

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