Сбор семантического ядра: полный процесс за 9 этапов

Ядро на 40 тысяч запросов, собранное за два дня выгрузкой из трёх сервисов, – это не ядро. Это таблица, по которой невозможно принять ни одного решения о структуре сайта.

Дальше – весь процесс от первого списка слов до документа, по которому программист заводит страницы, а редактор берёт темы в работу.

Короткий ответ

Семантическое ядро собирается в девять этапов – сиды, расширение из источников, чистка, снятие частотности, кластеризация по топам, разметка интента, проверка каннибализации, оценка потенциала и сборка карты релевантности. Результат работы – не список запросов, а таблица соответствия «кластер – URL – тип страницы», по которой строится структура сайта.

Для кого этот текст и чего в нём нет

Текст для тех, кто собирает ядро руками или принимает работу у подрядчика и хочет понимать, за что платит. Для маркетологов, которым отдали файл на 40 тысяч строк, и они не знают, что с ним делать.

Чего здесь нет – обзора сервисов с ценами и кнопками. Инструменты меняются, механика – нет. Где инструмент важен, я его называю, но статья не про то, куда нажимать.

Ещё одной вещи здесь нет – обещания, что после сбора ядра вырастет трафик. Ядро само по себе не приносит ничего. Оно определяет, какие страницы вообще имеет смысл делать, и цена ошибки на этом этапе – не «недобрали запросов», а «полгода писали не про то».

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

Что такое ядро и чем оно не является

Ядро – это не список запросов. Список запросов получается на третьем этапе из девяти, и сам по себе он бесполезен.

Ядро – это решение о структуре сайта, обоснованное спросом. Ответ на вопрос «какие страницы должны существовать и что на каждой написано». Всё остальное – промежуточные артефакты.

Отсюда простой тест на качество чужой работы. Вам сдали ядро. Возьмите любую строку и спросите – на какой странице этот запрос продвигается? Если ответа в файле нет, работа не сделана, сколько бы строк там ни было.

Второй тест. Возьмите структуру сайта и спросите – какой спрос закрывает вот этот раздел? Если раздел придуман из логики «так у конкурентов» или «так удобно нам», он в лучшем случае не принесёт трафика, в худшем – размоет вес между страницами, которые конкурируют между собой.

Для тех, кто не в теме – спрос и структура связаны в обе стороны. Ядро показывает, чего люди хотят, структура показывает, что вы им отдаёте. Расхождение между этими двумя вещами и есть большая часть работы SEO-специалиста.

Как поиск вообще сопоставляет запрос с документом и почему пул кандидатов формируется до ранжирования – разобрано в статье про архитектуру поисковой системы. Здесь важна одна мысль оттуда: запрос перед встречей с индексом нормализуется, расширяется синонимами и получает взвешивание терминов. Поэтому собирать ядро «по вхождениям» бессмысленно – поиск давно работает не так.

Этап 1. Сиды – первый список, которого обычно не хватает

Сиды – это стартовые слова, от которых пойдёт расширение. Обычно их 30–200 штук, и качество всей дальнейшей работы упирается в них.

Откуда берутся сиды:

1. Номенклатура бизнеса. Что продаёте, какими словами это называется у вас в прайсе и в 1С.
2. Как это называют клиенты. Почти всегда иначе, чем в прайсе. Разрыв между внутренней терминологией и языком спроса – главный источник упущенного трафика.
3. Структура конкурентов. Не для копирования – для проверки, не пропустили ли вы категорию целиком.
4. Синонимы и профессиональный жаргон. «Натяжной потолок» и «потолок ПВХ», «ЧПУ» и «человекопонятный урл».
5. Сленг, ошибки, транслит. «Кондей», «айфон 15» и «iphone 15» – три разные строки в статистике.
6. Бренды и модели, если продаёте чужое.

Самая частая ошибка на этом этапе – собрать сиды у клиента и на этом закончить. Клиент называет вещи так, как принято в его отрасли. Покупатель ищет так, как говорит дома.

Пример из нашей практики. Клиент – подрядчик по монтажу инженерных систем. Услугу он так и называл – «монтаж инженерных систем», и сайт был построен вокруг этой формулировки.

Спрос шёл по другим словам. «Установка кондиционеров», «монтаж вентиляции», «отопление дома» – три разные потребности, которые человек ищет по отдельности и никогда не складывает в одно словосочетание.

По нашей оценке, из-за расхождения терминологии мимо прошло около 60% всего объёма ядра. Не 60% трафика – 60% запросов, которых в стартовом списке не было вообще, потому что их неоткуда было взять при опоре на прайс.

Практический приём – собрать сиды в три колонки. «Как называем мы», «как называет клиент», «как называет поиск». Третью колонку заполнить подсказками из поисковой строки: вводите сид и смотрите, чем его продолжают. Это бесплатно и занимает полчаса, а на выходе даёт слова, которых не было ни в первой, ни во второй колонке.

Этап 2. Расширение – двенадцать источников и их порядок

Расширение – это превращение сидов в сырой массив. На выходе может быть от нескольких тысяч до сотен тысяч строк, и на этом этапе мусор не страшен. Страшно пропустить целый пласт спроса.

Источники я делю на три группы по природе данных.

Группа 1. Статистика поисковых систем

Wordstat. Основной источник для Яндекса. Даёт левую колонку (что ещё искали с этим словом) и правую (что искали те же люди). Правая колонка недооценена – она вытаскивает соседние потребности, до которых по левой не добраться.

Планировщик Google Ads. Показывает диапазоны вместо точных чисел, если в аккаунте нет активных кампаний с расходом. Это не повод его игнорировать – группировка по темам там неплохая, а на диапазоны можно опираться при сравнении масштабов.

Search Console и Яндекс.Вебмастер. Самый честный источник из всех, если сайт уже работает. Здесь лежат запросы, по которым вас уже показывают, – в том числе те, которых нет ни в одном сервисе, потому что частотность у них околонулевая. Отчёт по запросам за 12 месяцев с фильтром по показам больше нуля и позиции ниже десятой – готовый список тем, где вы уже почти есть.

Группа 2. Подсказки и агрегаторы поведения

Поисковые подсказки. Собираются перебором сид + буква, сид + буква + буква. Дают живой язык и свежие формулировки быстрее, чем статистика, – подсказки обновляются чаще, чем Wordstat.

Блоки «Вместе с этим ищут» и «Похожие запросы». Внизу выдачи. Механически близки к правой колонке Wordstat, но по Google.

Автодополнение YouTube. Отдельный сюжет. Люди ищут там иначе – больше «как» и «почему», меньше коммерции. Для информационной части ядра источник сильный.

Автодополнение маркетплейсов. Если продаёте товары, подсказки Wildberries, Ozon и Amazon показывают, какими словами люди выбирают товар в момент покупки, а не в момент изучения.

Группа 3. Источники, которые почти никто не использует

Здесь лежит то, что даёт отстройку. Первые две группы доступны всем, и все собирают из них одно и то же.

Логи внутреннего поиска по сайту. Люди пишут в вашу строку поиска ровно то, что не нашли в структуре. Каждый запрос с нулевым результатом – это либо отсутствующая страница, либо отсутствующий товар, либо ваша терминология не совпала с их.

Тикеты поддержки и переписка отдела продаж. Вопросы, которые задают до покупки, – это готовые темы для информационных страниц. Выгрузка за год, частотный анализ по биграммам, и у вас есть список того, что реально мешает людям купить.

Отзывы на маркетплейсах и агрегаторах. Не свои – чужие. В отзывах люди описывают проблему своими словами и без фильтра. Оттуда достаются формулировки, которых нет в статистике, потому что их ещё не начали искать массово.

Форумы, профильные сообщества, комментарии. Особенно для сложных товаров и B2B.

Транскрипты продающих звонков. Если в компании пишут звонки – это лучший источник языка клиента, который вообще существует. Полчаса чтения расшифровок дают больше, чем день в сервисах.

Порядок сбора имеет значение. Сначала группа 3 – она расширяет список сидов. Потом группы 1 и 2 – они масштабируют то, что вы нашли. Если сделать наоборот, вы получите массив вокруг тех слов, которые придумали сами, и не узнаете о существовании остальных.

Разбор нестандартных источников с методикой выгрузки.

Отдельно про LLM

Языковые модели расширяют семантику хорошо и врут при этом уверенно. Модель выдаст сорок формулировок, из которых десять – настоящие запросы, а тридцать никто никогда не вводил.

Рабочая схема одна: модель генерирует гипотезы, а частотность подтверждает существование. Гипотеза без проверки в ядро не попадает никогда. Схемы промптов и обязательная валидация.

По нашему опыту 30–40% сгенерированных моделью запросов после проверки частотности отправляются в мусор – они либо нерелевантны, либо не существуют как спрос.

При этом на обратной задаче модель окупается. Первичная чистка массива руками занимала 5–10 часов, со скриптами и моделью – 1,5–2. Ускорение примерно пятикратное, и это единственное место в процессе, где автоматизация даёт такой выигрыш без потери качества.

Этап 3. Чистка – два часа, которые решают судьбу всей работы

Здесь массив превращается в список. Работа скучная, автоматизируется частично и определяет, будет ли ядро рабочим документом или свалкой.

Что выбрасывается:

Мусорные вхождения по стоп-словам. Бесплатно, скачать, торрент, своими руками, б/у, отзывы сотрудников, вакансии, реферат. Список стоп-слов собирается под нишу и переиспользуется, но проверять его нужно каждый раз – в одной нише «своими руками» мусор, в другой это основной коммерческий спрос.

Чужая география. Если работаете по Москве, запросы с «в спб», «казань», «краснодар» – не ваши. Но осторожно: запросы без гео и запросы с вашим гео – это часто разные страницы, а не дубли.

Витальные запросы конкурентов. Название чужой компании плюс услуга. Продвигаться по ним технически можно, коммерчески – почти всегда нет.

Нерелевантная омонимия. Классика – «ключ» для замка и «ключ» для API. Ловится глазами, автоматика тут ошибается.

Мусор от сервисов. Обрезанные фразы, дубли с разным порядком слов, запросы с опечатками сервиса, а не человека.

Что не выбрасывается, хотя рука тянется:

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

Приём, который экономит часы. Чистка идёт не построчно, а по группам. Сортируете массив по вхождению слова, помечаете всю группу, отправляете в стоп-лист или в работу. За один проход по частотному словарю биграмм убирается процентов семьдесят мусора, дальше уже руками.

Порядок величин на нашем последнем проекте – из 15 000 сырых запросов после чистки осталось 1 100–1 200. То есть выброшено больше 90%, и это нормальная пропорция, а не признак плохого сбора.

По времени сама чистка недолгая – 1,5–2 часа автоматикой и стоп-словами. Долгим будет следующий этап: ручная доработка кластеров забирает ещё 10–15 часов, и часть решений о мусоре принимается уже там, когда видно, во что запрос собрался.

Этап 4. Частотность – и почему все три типа врут

В Яндексе снимается три вида частотности, и разница между ними больше, чем кажется.

Базовая частотность – самая бесполезная и самая цитируемая. Запрос «двери» с базовой частотностью в сотни тысяч включает межкомнатные, входные, автомобильные, «двери в Нарнию» и картинку двери для презентации. Планировать по ней нельзя.

Дальше – почему врут и остальные.

Сезонность. Снятая в августе частотность по кондиционерам и снятая в феврале – разные вселенные. Wordstat отдаёт данные за последний месяц, а решение вы принимаете на год. Смотреть нужно историю по месяцам, а не срез.

Накрутка. Частотность в Wordstat – это число запросов, а не число людей. Автоматические проверки позиций, парсеры и чужие сервисы тоже попадают в статистику. По конкурентным коммерческим запросам завышение бывает заметным, и особенно это видно на запросах с явно нерыночным соотношением частотности и числа кликов.

Регион. Частотность без региональной нарезки складывает города, где вы не работаете. Для локального бизнеса это ошибка в разы, а не в процентах.

Zero-click. Часть показанной частотности не превращается в переходы ни для кого. Запрос «сколько стоит доллар» имеет огромную частотность и нулевой трафиковый потенциал – ответ отдаётся прямо в выдаче. Про то, как SERP-фичи съедают клики, – в статье про архитектуру и в отдельном материале.

Отдельно про нулевую частотность. Запрос, у которого Wordstat показывает 0, вводили – просто реже, чем порог отображения, или он новый. В B2B, медицине и сложных услугах такие запросы дают самую высокую конверсию, потому что человек, который формулирует проблему в восемь слов, знает, чего хочет. Собранные в кластер, они дают трафика больше, чем один высокочастотник, за который бьётся весь рынок. Разбор.

Развёрнутый разбор всех типов частотности, включая работу с историей и региональной нарезкой,.

Этап 5. Кластеризация по топам

Самый важный этап и самый непонятый.

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

Почему не по смыслу

Логика «сгруппируем похожее по значению» ломается на первом же примере. «Купить пластиковые окна» и «пластиковые окна цена» – по смыслу почти одно и то же. Выдача по ним может отличаться на половину, и тогда это две страницы, а не одна.

И наоборот. «Ремонт квартир» и «отделка квартир под ключ» – разные слова, а топ-10 совпадает на восемьдесят процентов. Значит, поиск считает это одной потребностью, и делать две страницы – значит создать себе конкурента внутри собственного сайта.

Как это устроено технически

Берётся топ-10 по каждому запросу. Дальше считается пересечение – сколько URL совпадает у двух запросов. Если совпадений больше порога, запросы попадают в один кластер.

Два подхода:

Hard. Каждый запрос кластера пересекается с каждым по порогу. Кластеры получаются маленькие, чистые, надёжные. На выходе – много кластеров и много страниц.

Soft. Каждый запрос пересекается с центром кластера, но не обязательно с остальными. Кластеры крупнее, страниц меньше, риск затащить в одну кучу разные интенты выше.

Мой рабочий выбор – hard для коммерции, где цена ошибки в структуре высокая, и soft для информационных разделов, где допустимо собрать широкую статью. Но это предпочтение, а не закон.

Порог 3 против порога 5

Порог – это число совпадающих URL в топ-10, при котором запросы считаются родственными.

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

При пороге 3 сайт получается компактным. Риск – в один кластер съезжаются запросы с разными интентами, и одна страница пытается ранжироваться по всему сразу, не выигрывая ни по чему.

При пороге 5 сайт получается широким – кластеров больше, каждый уже, посадочных страниц заметно больше. Риск обратный – наплодить страниц, которые конкурируют между собой и не набирают веса.

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

Практический ориентир: чем конкурентнее ниша, тем выше порог. В нише, где топ занят агрегаторами и маркетплейсами, пересечения будут высокими по всем запросам подряд – низкий порог там склеит всё в один ком.

Полная методика с разбором ошибок.

Что кластеризация не умеет

Она не понимает, что вы продаёте. Если в топе по вашему запросу стоят информационные статьи, а вы хотите продать услугу, кластеризатор честно соберёт вам кластер под статью. Решение о том, что с этим делать, принимает человек.

Она врёт на низкочастотке. Топ по запросу с частотностью 3 нестабилен, пересечения случайны. Такие запросы прикрепляются к кластерам вручную или по смыслу.

Она зависит от даты съёма. Выдача меняется, и кластеризация трёхмесячной давности может уже не соответствовать реальности. Перед большой перестройкой структуры топы снимаются заново.

Этап 6. Интент и тип страницы

У каждого кластера теперь нужно определить, какую страницу он требует.

Классическая модель «информационный, навигационный, транзакционный, коммерческий» устарела и не помогает принимать решения. Реальная разметка подробнее:

• изучение проблемы – человек ещё не знает, что ему нужно («почему трескается штукатурка»);
• выбор решения – знает проблему, выбирает способ («чем выровнять стены»);
• сравнение вариантов – выбрал способ, выбирает между продуктами («гипсокартон или штукатурка»);
• выбор исполнителя – выбрал продукт, выбирает подрядчика («штукатурка стен цена за м2»);
• готов купить – ищет, где заказать прямо сейчас («заказать штукатурку стен москва»);
• навигационный – ищет конкретную компанию или страницу;
• после покупки – инструкции, гарантия, доставка.

Дальше каждому интенту сопоставляется тип страницы:

Проверка тут одна и она бесплатная – открыть выдачу. Если по вашему коммерческому запросу в топ-10 восемь статей и два агрегатора, то поиск считает интент информационным, и коммерческая страница туда не встанет, как бы вы её ни оптимизировали.

Это я всё к чему – интент определяется не вашим желанием продать, а тем, что уже стоит в топе. Спорить с выдачей можно, но это отдельный дорогой проект, а не задача на этапе сбора ядра.

И ещё. Интент дрейфует. Выдача переписывается вслед за поведением людей, сезоном, новостями. Раз в полгода стоит пересматривать кластеры, по которым позиции просели без видимых причин, – возможно, изменился не ваш сайт, а вопрос. Расширенная классификация с подтипами.

Этап 7. Проверка на каннибализацию – до того, как написан текст

Каннибализация – это когда две ваши страницы борются за один запрос. Поиск выбирает одну, и часто не ту, и обе стоят ниже, чем стояла бы одна.

Лечить её после публикации дорого – склейки, редиректы, переписывание. Поэтому проверка делается до создания страниц, прямо на ядре.

Механика простая. Берёте два кластера, которые кажутся близкими, и сравниваете:

1. Пересечение топ-10 между главными запросами кластеров. Высокое пересечение – скорее всего, это одна страница.
2. Совпадение типа результатов. Если по одному кластеру в топе категории, а по другому – статьи, это точно разные страницы, даже при похожих словах.
3. Набор SERP-фич. Разные блоки в выдаче – разный интент.

По итогам – одно из трёх решений: слить кластеры, оставить раздельно, оставить раздельно и явно развести по содержанию и перелинковке.

Отдельная разновидность проблемы – когда кластер физически можно закрыть и категорией каталога, и статьёй, и то и другое нужно бизнесу. Тогда страницы разводятся по интенту жёстко: категория забирает коммерческие формулировки, статья – вопросительные и обучающие, и они ссылаются друг на друга.

Тест на каннибализацию до создания контента. Диагностика и лечение уже случившейся, по данным Search Console,.

Этап 8. Оценка потенциала кластера

Здесь принимается решение, в каком порядке всё это делать. Ресурс всегда меньше, чем список.

Формула «частотность умножить на CTR первой позиции» даёт красивое число и не имеет отношения к реальности. Она игнорирует четыре вещи.

SERP-фичи. Если над органикой стоят четыре объявления, блок карт и AI-ответ, доля кликов в органику падает кратно. Два кластера с одинаковой частотностью могут отличаться по реальному трафику в несколько раз только из-за состава выдачи.

Долю брендового спроса. В частотности «купить iphone» сидит спрос, который весь уйдёт на официальных продавцов и маркетплейсы. Ваша доля там не считается по CTR-кривой.

Реальные кривые кликабельности по тематике. Усреднённые таблицы CTR по позициям гуляют от исследования к исследованию и по нишам расходятся сильно. Свои цифры лежат в Search Console – там видно, какой CTR у вас на каких позициях по вашим типам запросов. Это единственная кривая, которой можно доверять.

Достижимость. Кластер с частотностью 10 тысяч, где в топе восемь агрегаторов с историей в десять лет, – не потенциал, а мечта. Оценка сложности должна входить в расчёт, иначе приоритизация уводит ресурс в самые тяжёлые темы.

Рабочая модель на практике выглядит как таблица, где для каждого кластера считается ожидаемый трафик с поправками и рядом ставится оценка сложности и коммерческой ценности. Дальше сортировка по отношению ценности к сложности.

Наша рабочая формула выглядит так:

Ожидаемый трафик = частотность × CTR по позиции × индекс сезонности × поправка на SERP-фичи

От наивного варианта она отличается двумя последними множителями, и именно они решают.

Что подставляем:

• CTR первой позиции – 25–30%, пятой – около 10%. Это усреднение, по нишам разброс большой, поэтому свои значения из Search Console всегда лучше наших;
• индекс сезонности – снимается по истории Wordstat за 12 месяцев, а не по текущему месяцу;
• поправка на SERP-фичи – от 0,3 до 0,7 в зависимости от того, насколько забита выдача.

Последний коэффициент мы ставим руками. Открываем выдачу по главному запросу кластера и считаем, сколько элементов стоит над органикой – объявления, блок ответов, карты, видео, AI-ответ. Чем плотнее верх, тем ниже коэффициент. Автоматизировать это пробовали, получается хуже, чем глазами.

Пример, ради которого поправка вообще появилась. Кластер с частотностью 10 000. По наивной формуле выходило 2 500 переходов – десять тысяч умножить на CTR первой позиции. После выхода в топ он дал около 400.

Расхождение в шесть раз. Причина обнаружилась при первом же взгляде на выдачу – четыре объявления Директа, блок карт и AI-ответ, органика уехала ниже сгиба экрана.

И тут оговорка, без которой формула выглядела бы обещанием точности. Если бы мы применили поправку по нижней границе, прогноз был бы около 750 переходов – всё равно не 400. Поправка не делает модель точной, она снижает ошибку с шестикратной до примерно двукратной. Для решения о приоритете кластера этого достаточно, для обещания трафика клиенту – нет, и я бы такими числами в коммерческом предложении не размахивал.

Развёрнутая модель.

Этап 9. Карта релевантности – то, ради чего всё собиралось

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

Обязательные поля:

Автопроверка, которая ловит большую часть ошибок:

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

Последний пункт важнее, чем кажется. Хвост, который «не влез», – это обычно несколько сотен запросов, и половина из них потом собирается в нормальные кластеры при следующем пересмотре.

Формат карты и автопроверки.

Сколько это занимает по времени

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

Сайт услуг на 30–50 страниц:

Общий срок – 2–3 рабочих дня. Часов тут больше, чем помещается в два восьмичасовых дня, и это не описка: этапы идут внахлёст и не одним человеком. Пока аналитик доводит кластеры, заголовки и мета-теги делает другой.

С магазином всё иначе, и масштабируется оно нелинейно. Тысяча товаров – это 2–3 недели. Пять тысяч SKU и больше – от месяца до двух, 25–35 рабочих дней, а объём ядра уходит за 20 000 запросов. Причина роста не в числе строк, а в том, что кластеризовать приходится отдельно категории, отдельно фильтры и отдельно карточки, и каждый слой живёт по своим правилам.

Что видно из таблицы и обычно удивляет. Расширение – самая быстрая часть, час-другой. Дольше всего идут два этапа, которые в коммерческих предложениях чаще всего отсутствуют: подбор маркеров и ручная доработка кластеров. Вместе они забирают около трёх четвертей всего времени.

Это я всё к чему – спорить надо не со сроком, а с тем, что внутри него. Два дня выгрузки из трёх сервисов и два дня, в которых лежит тридцать часов работы двух человек, называются одинаково. Разница вся в тех двух этапах, которые я только что назвал, – и именно их не видно в коммерческом предложении, пока не спросишь про часы.

Что должно быть в смете, чтобы работа была сделана целиком

Это полезнее любой цифры – по этому списку проверяется чужое предложение, не только наше.

1. Сбор сидов с участием вашей стороны, а не только по прайсу. Отдельной строкой – выгрузка внутренних источников: логи поиска по сайту, тикеты, звонки.
2. Расширение с указанием источников. В сдаче у каждой строки должно быть видно, откуда она взялась.
3. Чистка руками. Часы на неё – главный индикатор. Если их нет в смете, чистки не будет.
4. Съём частотности с региональной нарезкой и историей по месяцам, а не один срез за текущий месяц.
5. Кластеризация с явно названным порогом и датой съёма топов.
6. Разметка интента вручную по выдаче. Автоматика этого не делает.
7. Проверка каннибализации против существующих страниц сайта.
8. Карта релевантности с колонкой URL и типом страницы.
9. Дата пересмотра и регламент добора запросов из Search Console.

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

Тот самый подрядчик по инженерным системам, с которого начинался пример про сиды. Разбираю его целиком, потому что там сработали разом три вещи из этой статьи – расхождение терминологии, внутренние источники и ошибка с порогом кластеризации.

Что было на старте. Сайт на 15 посадочных страниц, около 800 сессий в месяц из органики, 12 запросов в топ-10. Структура построена по внутренней логике бизнеса – ровно так, как услуги перечислены в прайсе.

Что нашли. Спрос жил в других словах, и его пришлось доставать оттуда, где его никто не ищет:

• поисковые подсказки дали 40% новых формулировок, и это полчаса работы без единого платного сервиса;
• логи внутреннего поиска по сайту вскрыли 23 запроса с нулевым результатом. Каждый – либо отсутствующая страница, либо несовпадение нашей терминологии с человеческой;
• выгрузка 180 обращений в поддержку за год после частотного разбора дала 15 тем для информационных страниц.

Результат.

Срок – 6 месяцев с момента внедрения новой структуры. Не с момента сдачи ядра, а с момента, когда страницы реально появились на сайте. Разница между этими двумя датами на многих проектах составляет ещё пару месяцев, и она целиком на стороне клиента.

Где мы ошиблись. На кластеризации взяли порог 3 вместо 5. В один кластер съехались коммерческие и информационные запросы, и одна страница пыталась ранжироваться одновременно по «купить кондиционер» и «как выбрать кондиционер».

Не вышло ни то, ни другое. Поиск не смог определить, что это за страница, и обе группы запросов остались за топом.

Переделка заняла две недели и около 40 часов работы аналитика и редактора. Перекластеризовали с порогом 5, развели запросы по типам страниц – коммерческие на категории, информационные в блог. Сделали за свой счёт, потому что ошибка была наша.

Трудозатраты по плану: аналитик – 35 часов на сбор и кластеризацию, технический специалист – 20 часов на внедрение структуры, редактор – 40 часов на ТЗ для 32 новых страниц. Девяносто пять часов. Плюс сорок на переделку сверху – значит, по факту около ста тридцати пяти.

И сразу честно про норматив из таблицы выше. Там на ядро для сайта услуг заложено 22–33 часа, а здесь только сбор и кластеризация заняли 35. Норматив не сработал по двум причинам – внутренних источников оказалось больше обычного, их разбор занял лишний день, а потом добавилась наша ошибка с порогом. Таблица показывает типовой проект, а типовых проектов меньше, чем хотелось бы.

Чем снимать данные на каждом этапе

Чем работаем мы. На расширении – Key Collector, Wordstat и Букварикс. На кластеризации – Rush Analytics и встроенный кластеризатор Key Collector. Цены не привожу намеренно, они меняются чаще, чем эта статья.

Два места заменены своими скриптами, и оба окупились быстро. Парсер поисковых подсказок на Python перебирает сид плюс букву и сид плюс две буквы – экономит 3–4 часа ручного сбора на проект. Скрипты чистки по стоп-словам дают большую часть того пятикратного ускорения, о котором я писал выше.

Ни то, ни другое не требует сложного кода. Если у вас в команде есть человек, который пишет на Python хотя бы на уровне обработки таблиц, эти две вещи стоит собрать в первую очередь.

Оговорка про сервисы кластеризации. Все они делают одно и то же – считают пересечение топов. Разница между ними в удобстве, скорости и цене, а не в качестве кластеров. Если результаты двух сервисов на одном ядре расходятся сильно, дело почти всегда в разном пороге или в разной дате съёма выдачи, а не в «умном алгоритме» одного из них.

Три частых вопроса

Можно ли собрать ядро один раз и забыть? Нет. Спрос меняется, формулировки стареют, выдача переписывается. Рабочий цикл – полный пересбор раз в год-полтора и добор новых запросов из Search Console раз в квартал. Второе занимает час и приносит больше, чем кажется.

Что делать, если сайт уже есть, а ядра не было? Начинать не с сервисов, а с выгрузки своих запросов за 12 месяцев из Search Console и Вебмастера. Это готовая карта того, где вы уже видны. Дальше – кластеризовать её, наложить на существующие URL и найти места, где два ваших адреса делят один кластер. Обычно это первая же находка, и она бесплатная.

Сколько запросов должно быть в нормальном ядре? Вопрос не имеет ответа, и это важно. Для сайта услуг рабочее ядро может быть на 800 запросов, для магазина – на 200 тысяч. Число строк не показывает качество работы. Показывает его число кластеров, у которых есть URL, тип страницы и понятный интент.

Ошибки, которые видно чаще других

Ядро собрано, структура не изменилась. Самая частая. Работу сделали, файл отдали, сайт остался прежним. Ядро без внедрения – это расход без результата.

Кластеризация по смыслу вместо топов. Дальше – страницы, которые конкурируют между собой, и удивление, почему обе не в топе.

Один высокочастотник как цель раздела. Раздел строится под кластер, а не под запрос. Запрос может выпасть из выдачи, кластер – нет.

Игнорирование существующих страниц. Ядро собрали с нуля, а на сайте уже сто страниц с трафиком. Дальше – новые URL, которые каннибализируют старые. Начинать надо со снятия текущей картины из Search Console и Вебмастера.

Ядро как разовая работа. Спрос меняется, появляются новые формулировки, старые умирают. Ядро без даты пересмотра устаревает за год-полтора.

Наша собственная ошибка, которую стоит назвать. Порог 3 вместо 5 на проекте из раздела выше. Коммерция и информационка в одном кластере, одна страница под два интента, обе группы запросов мимо топа. Две недели и 40 часов на перекластеризацию и разведение страниц. Ошибка стоит ровно в том месте, где кластеризация кажется технической настройкой, а на деле определяет структуру сайта.

Где этот процесс не работает

Новый рынок без спроса. Если продукт новый, его никто не ищет по имени. Ядро собирается вокруг проблемы, а не решения, и объёмы будут маленькими. Это нормально, но планировать трафик по такому ядру нельзя.

Медиа и новости. Там скорость реакции важнее семантики. Полный цикл из девяти этапов для новостника – трата ресурса.

Очень узкий B2B. Когда весь рынок – двести компаний, спроса в поиске почти нет, и ядро перестаёт быть основным инструментом. Работают другие каналы, а SEO закрывает узкие информационные запросы под длинный цикл сделки.

Ниши, где топ занят агрегаторами наглухо. Кластеризация покажет высокие пересечения по всему подряд, и структура из неё получится бесполезная. Там сначала решается вопрос, можете ли вы вообще конкурировать, и только потом собирается ядро.

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

Выводы

• Ядро – это решение о структуре сайта, а не список запросов. Тест простой: если по строке нельзя сказать, на какой странице она продвигается, работа не закончена.
• Кластеризация делается по пересечению топов, а не по смыслу. Поиск уже ответил, что чему соответствует, – это нужно прочитать, а не придумать заново.
• Порог кластеризации меняет число посадочных страниц в разы. Это решение, а не настройка по умолчанию.
• Частотность врёт всегда – из-за сезонности, региона, накрутки и zero-click. Планировать по базовой частотности нельзя вообще.
• Самые ценные источники семантики лежат не в сервисах, а внутри компании – в логах внутреннего поиска, тикетах и записях звонков.
• Каннибализация лечится на этапе ядра бесплатно, а после публикации – дорого.

Следующий шаг

Дальше по кластеру логично читать разбор кластеризации с порогами и типовыми ошибками и материал про источники семантики, которые не использует почти никто.

Если у вас уже есть собранное ядро и вы не уверены, что структура сайта ему соответствует, – начните с проверки на дубли URL внутри карты релевантности. Это пятнадцать минут и самая частая находка.

Разбираем такие вещи в канале – там же выкладываем шаблоны и разборы реальных проектов. Подписывайтесь, если тема рабочая.

PS: если ядро вам собирал подрядчик и в сдаче нет колонки с URL – это не придирка к оформлению. Это значит, что этап принятия решений пропущен, а сделана только выгрузка.