Раздутое семантическое ядро интернет-магазина — не признак глубокой проработки, а обычно симптом неправильной сборки: тысячи фраз, часть из которых совпадает по смыслу, часть не соответствует ассортименту, а часть никогда не приведёт покупателя. Чтобы ядро работало, а не превращалось в таблицу на тысячи строк, которую никто потом не открывает, его нужно ограничивать на входе — во время сбора, а не чистить постфактум, когда страницы уже написаны.
Почему ядро разрастается и чем это мешает магазину
Разрастание обычно идёт по одной схеме. Запросы выгружают из сервисов подсказок почти без фильтра, а к каждому товару механически добавляют все мыслимые модификаторы: цвет, размер, бренд, вариант написания слова. На выходе — список на несколько тысяч строк, где реальных уникальных смыслов в разы меньше.
Проблема не в объёме, а в том, что каждая строка подразумевает решение: писать под неё текст, создавать страницу или направить трафик на уже существующую. Когда строк тысячи, команда не успевает принимать эти решения осмысленно. Появляются тонкие страницы без уникального контента, дублирующие друг друга по смыслу, а приоритизация работы превращается в хаос.
Сначала структура каталога, потом запросы
Сбор стоит начинать не с инструментов подсказок, а с каталога. Выпишите фактическую структуру: категории, подкатегории, фильтруемые атрибуты — бренд, цена, размер, цвет, — которые уже реализованы технически или запланированы в близкой перспективе.
Дальше по каждому уровню структуры примите решение: какие комбинации фильтров важны настолько, чтобы заводить под них отдельную индексируемую страницу, а какие лучше закрыть от индексации или схлопнуть через canonical. Это отдельный технический вопрос, но решение по нему нужно принять до, а не после сбора частот.
Такой подход задаёт естественный потолок ядра: если в категории реально существует двадцать осмысленных комбинаций фильтров, ядро по ней не может состоять из двухсот уникальных страничных сущностей, сколько бы формулировок ни нашлось в статистике запросов.
Отсекайте лишнее на входе, а не после сбора тысяч фраз
На этапе выгрузки сразу убирайте четыре категории фраз, не дожидаясь, что они попадут в рабочую таблицу.
Запросы по товарам, которых нет в ассортименте и не появится в обозримой перспективе, — не заносите их в ядро вообще. Фразы, различающиеся только порядком слов, числом или падежом, но совпадающие по смыслу и выдаче, — это не новый кластер, а вариант внутри уже существующего. Информационные запросы без коммерческого намерения обычно ведут в блог, а не на страницу каталога, и смешивать их с коммерческим ядром только мешает расставлять приоритеты. Геопривязанные варианты вида «купить в городе» стоит включать только если у магазина есть реальная логика локальных страниц под каждый город — иначе эту задачу решает не текстовая страница, а карточка локального присутствия.
Объединяйте запросы вокруг одной страницы, а не плодите страницы под каждую фразу
После фильтрации список всё ещё может выглядеть большим, если считать по строкам. Следующий шаг — не удаление, а объединение. Кластер — это группа запросов с одним намерением, для которых поисковая система показывает в целом одну и ту же выдачу.
Группировать нужно не только по общему корню слова, но и по совпадению выдачи и логике покупательского поведения: «беспроводные наушники», «наушники без провода» и «блютуз наушники» в большинстве тематик — один кластер и одна страница, а не три.
Главная ошибка на этом шаге — считать каждый кластер обязательным поводом для новой страницы. Кластер фиксирует намерение, но решение о странице принимается отдельно: иногда правильный ответ — не новая страница, а усиление уже существующей категории дополнительным блоком текста.
Как сопоставить кластеры со страницами каталога
Свести решение в таблицу — самый быстрый способ увидеть, где кластер требует новой страницы, а где его стоит направить на уже существующую сущность.
| Тип страницы каталога | Пример маски запроса | Нужна ли отдельная страница |
|---|---|---|
| Категория верхнего уровня | «садовая техника» | Да, всегда — основа структуры |
| Подкатегория по типу товара | «триммеры бензиновые» | Да, если закреплена в навигации |
| Комбинация фильтров (бренд и атрибут) | «триммеры бензиновые, конкретный бренд» | Только если комбинация частотна и уникальна по смыслу; иначе — фасетный фильтр с canonical |
| Сравнение или подборка | «что лучше, триммер или кусторез» | Отдельная обзорная страница вне товарного ядра |
| Карточка конкретной модели | «триммер определённой модели» | Отдельное ядро не нужно — обслуживается карточкой товара |
Условный пример: ядро для магазина садовой техники
Представим условный магазин садовой техники, который пересобирает ядро по этой логике.
По каталогу выписали структуру: шесть категорий, около тридцати подкатегорий, десять представленных брендов — это каркас, на который дальше накладываются запросы.
Из сервисов подсказок выгрузили около пяти тысяч фраз. После отсечения нерелевантного ассортимента, дублирующих формулировок и информационных запросов осталось около двух тысяч строк. После кластеризации по намерению и выдаче число кластеров сократилось до примерно ста восьмидесяти.
Отдельную страницу решили создавать только для шестидесяти кластеров — там, где сочетание конкретного бренда и типа товара действительно частотно и не покрывается существующей подкатегорией. Остальные кластеры распределили между страницами фильтров и карточками моделей, не создавая новых сущностей.
Итоговый рабочий список — около шестидесяти целевых страниц с понятной задачей для каждой, а не несколько тысяч строк без приоритета.
Частые вопросы
Сколько запросов должно быть в ядре интернет-магазина? Жёсткого норматива тут нет: объём ядра определяется количеством страниц, которые магазин способен уникально наполнить и содержать в рабочем состоянии, а не количеством найденных формулировок.
Нужно ли включать низкочастотные «хвостовые» запросы? Только если фраза образует отдельный кластер с собственным намерением. Если она просто повторяет смысл более частотной фразы другими словами — это вариант внутри существующего кластера, а не новая строка ядра.
Как часто пересматривать собранное ядро? Логичнее привязывать пересмотр не к календарной дате, а к событиям в каталоге — новым брендам, категориям, заметному изменению ассортимента, потому что именно они меняют границы, с которых начинался сбор.
Начните не с нового сбора частот, а с ревизии уже существующего списка: выгрузите текущее ядро, отметьте для каждой строки кластер и реальную страницу каталога, к которой она относится, и удалите строки, для которых такой страницы нет и не планируется.
