Классический сценарий: сайт уже запущен, каталог наполнен, а через год выясняется, что структура мешает расти — разделы дублируют друг друга по смыслу, у части кластеров запросов вообще нет отдельной страницы, а перестройка меню означает переделку инфоблоков, потерю накопленного веса страниц и просадку трафика на месяцы. Правильный момент спроектировать SEO-архитектуру — до того, как программист начал вёрстку, а не после того, как менеджер спросил «а почему у нас нет позиций по этому запросу».
Ниже — практический подход к проектированию структуры сайта на 1С-Битрикс: как превратить список ключевых запросов в карту разделов, сколько уровней вложенности закладывать, как спланировать перелинковку и URL так, чтобы через год не пришлось всё переделывать. Это выжимка из наших проектов по разработке сайтов с SEO-структурой — без теории ради теории.
Коротко
- SEO-архитектуру проектируют до разработки — на основе кластеризованной семантики, а не «как удобно верстальщику».
- Оптимальная глубина — 3–4 уровня от главной до карточки; лишние уровни размывают вес и путают робота.
- Каждый кластер запросов с реальным спросом должен получить свою страницу, а не делить URL с соседним кластером.
- Перелинковку и URL-схему планируют параллельно со структурой — переделывать их после запуска дорого.
- Карта разделов ложится в основу структуры инфоблоков Битрикса — рассинхрон между ними потом аукается годами.
Что такое SEO-архитектура и зачем проектировать её заранее
SEO-архитектура — это иерархическая карта разделов и страниц сайта, построенная от кластеризованной семантики: какой раздел за какой пул запросов отвечает, как разделы вложены друг в друга и как связаны между собой ссылками. Это не дизайн меню и не схема навигации в привычном смысле — меню может (и часто должно) отличаться от полной SEO-карты, потому что не все посадочные страницы нужно выносить в видимую навигацию.
Почему это нельзя делать «по ходу» разработки. Структура каталога в 1С-Битрикс — это структура инфоблоков и разделов, а инфоблоки завязаны на компоненты вывода, фильтры, типы цен, права доступа. Изменить глубину вложенности или логику группировки товаров после того, как каталог наполнен и в боевом обмене с 1С, — не косметическая правка, а миграция данных с риском потерять историю индексации страниц. Спроектировать архитектуру заранее в разы дешевле, чем чинить её постфактум.
Здесь работает простое правило: сначала спрос, потом структура, потом дизайн. Сначала выясняем, что и в каком объёме ищут пользователи (семантическое ядро), затем группируем это в кластеры и превращаем кластеры в карту разделов, и только после этого рисуем макеты и передаём задание на разработку. Нарушение порядка — самая частая причина, по которой сайты «дорастают» до нужной структуры только через год-два жизни.
Цена ошибки: что происходит, если структуру не спланировали
Если сайт растёт органически — разделы добавляются по мере того, как появляется новый товар или услуга, без опоры на карту спроса, — типично возникают три проблемы одновременно.
- Каннибализация запросов. Два и больше разделов конкурируют за одни и те же ключевые слова, потому что при их создании никто не сверялся с кластерами. Поисковик не может решить, какую страницу показывать выше, и в итоге обе ранжируются хуже, чем могли бы поодиночке.
- Пустоты в покрытии спроса. Есть кластеры запросов с реальным трафиком, для которых на сайте вообще нет посадочной страницы — просто потому что при проектировании каталога их не закладывали. Это упущенный трафик, который конкуренты забирают себе.
- Дорогая переделка. Через год-два накопленных несоответствий приходится делать редизайн структуры: сливать разделы, переносить товары между инфоблоками, настраивать сотни 301-редиректов. Даже при аккуратном переезде это временная просадка видимости, а при неаккуратном — потеря позиций на месяцы.
Стоимость исправления архитектуры после запуска обычно на порядок выше, чем стоимость её проектирования до старта разработки — просто потому что после запуска в структуру уже вложены накопленные ссылки, индексация, поведенческие метрики и связка с обменом 1С.
Кластеризация запросов: от списка ключей к карте разделов
Сбор семантического ядра даёт плоский список запросов с частотностью. Сам по себе он ничего не говорит о структуре сайта — нужен промежуточный шаг, который превращает список в иерархию: кластеризация. Смысл в том, чтобы сгруппировать запросы с одинаковым интентом (тем, что реально хочет получить пользователь) в кластер, и каждый такой кластер сделать одной страницей — не больше и не меньше.
Практический алгоритм кластеризации для будущей структуры сайта:
- Соберите семантику. Выгрузите частотность запросов по тематике целиком — сервисами сбора семантики или через анализ выдачи конкурентов, без ограничения на «уже придуманные» разделы.
- Сгруппируйте по интенту, а не по формальному сходству слов. Запросы «купить диван угловой» и «угловые диваны каталог» — один интент. А «диван угловой» и «диван угловой раскладной» могут быть разными интентами, если у второго свой устойчивый спрос и своя аудитория (тот, кто ищет именно раскладной механизм).
- Оцените объём спроса каждого кластера. Кластеры с околонулевым суммарным спросом не заслуживают отдельного раздела — их можно закрыть внутри родительской страницы через фильтр или упоминание в тексте.
- Определите иерархию между кластерами. Часть кластеров — родительские (широкие: «диваны»), часть — дочерние, уточняющие (узкие: «диваны угловые», «диваны угловые серые»). Это будущая вложенность разделов.
- Сверьте кластеры с бизнес-логикой каталога. Кластер должен соответствовать не только спросу, но и тому, как физически устроен ассортимент или услуги компании — иначе структура спроса разойдётся со структурой данных.
Результат этого шага — не таблица ключевых слов, а дерево: родительские узлы и дочерние узлы, где у каждого узла указан пул запросов, примерный суммарный спрос и статус («точно отдельная страница» / «фильтр внутри раздела» / «не выносим, спроса недостаточно»).
Глубина вложенности и правило трёх кликов
Чем глубже спрятана страница, тем меньше веса перелинковки она получает от главной и тем реже её обходит поисковый робот при ограниченном краулинговом бюджете. Практический ориентир для среднего интернет-магазина или корпоративного сайта — 3–4 уровня от главной страницы до самой глубокой посадочной: Главная → Категория → Подкатегория → Карточка товара/услуги.
| Глубина | Пример | Когда уместно |
|---|---|---|
| 2 уровня | Главная → Карточка услуги | Небольшой сайт-услуга с узким ассортиментом (10–30 позиций) |
| 3 уровня | Главная → Категория → Карточка | Типовой каталог среднего размера, большинство сайтов |
| 4 уровня | Главная → Категория → Подкатегория → Карточка | Крупный каталог с чёткой товарной иерархией |
| 5+ уровней | Категория → Подкатегория → Под-подкатегория → … | Почти никогда не оправдано — сигнал, что кластеризацию стоит переделать |
Если после кластеризации у вас получается 5 и более уровней вложенности, это почти всегда означает, что кластеры раздроблены слишком мелко: часть узких кластеров с низким спросом стоит не выносить в отдельный раздел, а закрыть фильтром внутри более широкого раздела. Глубина считается не по красивому URL, а по числу переходов, которое нужно сделать из главной — и именно так её измеряет краулер поисковика.
Проектирование URL-структуры и ЧПУ
URL — прямое отражение архитектуры: чем более плоский и предсказуемый адрес, тем понятнее пользователю и поисковику, где он находится. Правило простое — URL повторяет иерархию разделов карты структуры, без лишних технических сегментов и без транслита длиннее, чем нужно для читаемости.
- Короткие сегменты.
/catalog/divany/uglovye/лучше, чем/catalog/mebel-dlya-doma/myagkaya-mebel/divany-i-kresla/divany/uglovye-modeli/— каждый лишний сегмент добавляет длину и не даёт пропорционального выигрыша в релевантности. - Стабильность при обмене с 1С. Символьный код раздела и товара, из которого строится ЧПУ, не должен меняться при обычном обновлении данных из 1С — иначе каждый обмен будет ломать накопленную индексацию страниц.
- Один интент — один URL. Не допускайте, чтобы один и тот же набор товаров был доступен по двум разным постоянным адресам — это прямой путь к внутренним дублям.
Детально механику построения ЧПУ в 1С-Битрикс — символьные коды, правила urlrewrite, транслитерацию — мы разбираем отдельно в статье «ЧПУ в 1С-Битрикс: человекопонятные URL для каталога и фильтра»: там про техническую реализацию, здесь — про то, откуда вообще берётся список URL, которые нужно превратить в ЧПУ.
Топология внутренней перелинковки
Перелинковка распределяет «вес» страниц по сайту — приблизительно то, что раньше называли PageRank внутри одного домена. Страница, на которую ведёт больше внутренних ссылок из значимых мест (с главной, из меню, из карточек товаров), получает больше сигналов важности, чем страница, до которой можно добраться только через глубокую вложенность без единой прямой ссылки.
При проектировании архитектуры перелинковку планируют как отдельный слой поверх иерархии разделов:
- Вертикальные связи. Родитель ссылается на детей (категория — на подкатегории и топовые товары), ребёнок — на родителя (хлебные крошки, ссылка «назад в категорию»).
- Горизонтальные связи. Смежные разделы одного уровня ссылаются друг на друга там, где это естественно для пользователя — «похожие категории», кросс-категорийные блоки.
- Приоритетные узлы. Ключевые кластерные страницы (с наибольшим спросом) получают дополнительные ссылки — из блога, с главной, из смежных статей — сверх стандартной иерархии.
На практике перелинковку удобно закладывать сразу в структуру шаблонов: карточка товара автоматически ссылается на свою категорию и на похожие товары, категория — на родительский раздел и на топ-подкатегории. Так перелинковка работает «сама», без ручной расстановки ссылок редактором в каждой карточке.
Типы страниц: категории, фильтры, теги и карточки
Карта структуры — это не только «жёсткие» разделы каталога. В неё стоит закладывать сразу несколько типов страниц с разной ролью в индексации.
| Тип страницы | Источник | Индексация |
|---|---|---|
| Категория / раздел каталога | Узел карты структуры (кластер верхнего или среднего уровня) | Всегда индексируется, приоритетный URL |
| Страница фильтра (ЧПУ-комбинация) | Узкий кластер, закрытый через умный фильтр | Индексируется точечно, только под реальный спрос |
| Карточка товара / услуги | Листовой узел дерева, конкретная позиция | Индексируется, если есть уникальный контент и спрос |
| Служебная сортировка / пагинация | Техническая вариация URL | Canonical на основную страницу, не индексируется отдельно |
Отдельного внимания требуют страницы, которые рождаются из умного фильтра — комбинации «бренд + категория» или «услуга + город» технически могут стать полноценными индексируемыми ЧПУ-страницами, если под ними есть спрос. Как именно превратить комбинацию фильтра в SEO-страницу с уникальными метатегами — отдельная механика, которую стоит закладывать в архитектуру заранее, а не пристраивать потом.
Порядок работы над SEO-архитектурой
- Соберите и кластеризуйте семантику. Полный список запросов по тематике, сгруппированный по интенту в кластеры с оценкой спроса каждого.
- Постройте дерево кластеров. Определите родительско-дочерние связи между кластерами — это будущая иерархия разделов.
- Сверьте с моделью данных. Проверьте, как дерево кластеров ложится на реальную структуру ассортимента или услуг — где кластер прямо соответствует категории данных, а где нужен компромисс.
- Спроектируйте глубину и URL. Зафиксируйте, сколько уровней вложенности допустимо, и пропишите шаблон URL для каждого типа узла.
- Спланируйте перелинковку. Опишите, какие связи между разделами появятся автоматически через шаблоны, а какие нужно расставить вручную.
- Передайте карту в разработку. Карта структуры становится техническим заданием на инфоблоки, разделы и свойства — а не отдельным документом, который живёт своей жизнью.
Как это выглядит в админке 1С-Битрикс
Готовая карта структуры превращается в разделы инфоблока каталога — обычно через раздел «Контент → Торговый каталог» или «Контент → Инфоблоки», где заранее созданная иерархия разделов задаёт ровно ту вложенность, которая была спроектирована на этапе SEO-архитектуры.
От карты структуры к инфоблокам
На практике карта структуры транслируется в модель данных 1С-Битрикс по нескольким правилам, которые стоит проговорить с разработчиком ещё на этапе проектирования.
- Широкие родительские кластеры обычно становятся разделами верхнего уровня инфоблока — с собственным
SECTION_PAGE_URL, метатегами и, при необходимости, отдельным дизайном landing-блока. - Узкие уточняющие кластеры с достаточным спросом становятся дочерними разделами или — если признак повторяется у многих товаров (например, цвет, материал) — свойствами инфоблока, которые позже участвуют в умном фильтре и превращаются в ЧПУ-страницы фильтра.
- Кластеры без самостоятельного спроса не становятся ни разделами, ни отдельными свойствами для фильтра — они закрываются упоминанием в тексте родительской страницы.
Решение «раздел или свойство фильтра» напрямую влияет на глубину URL и на то, попадёт ли страница в основную навигацию сайта или будет доступна только как комбинация фильтра. Принимать это решение нужно на этапе архитектуры, а не оставлять на усмотрение того, кто в итоге настраивает умный фильтр — иначе получится структура, которая не соответствует изначальной карте кластеров.
Рост каталога без передела структуры
Хорошо спроектированная архитектура должна выдерживать рост ассортимента без полной перестройки. Для этого в структуру закладывают запас — родительские разделы, под которые заведомо попадут будущие подкатегории, даже если сейчас в них мало товаров.
Практический приём — резервировать место в иерархии под кластеры с околопороговым спросом: сейчас у них недостаточно запросов для отдельного раздела, но при росте ассортимента (например, компания вводит новую линейку товаров) они станут полноценным узлом дерева без изменения глубины остальной структуры. Это дешевле, чем закладывать «максимально плоскую» структуру и потом резко углублять её при росте каталога.
Частые ошибки при проектировании
- Начали разработку без кластеризации семантики — структуру придумали «на глаз», по интуиции менеджера или по структуре сайта конкурента.
- Скопировали структуру меню у конкурента, не сверяя её с собственной кластеризацией спроса и ассортиментом.
- Заложили 5–6 уровней вложенности «для порядка», хотя кластеризация не требовала такой глубины.
- Не разделили роли «раздел каталога» и «свойство для фильтра» — часть узких кластеров превратили в разделы, раздув структуру и размыв перелинковку.
- Спроектировали структуру без учёта модели данных 1С-Битрикс — потом карта разошлась с реальными инфоблоками, и часть решений пришлось принимать заново уже в коде.
- Не заложили перелинковку как отдельный слой — понадеялись, что «ссылки появятся сами» через меню.
- Не оставили запас на рост каталога — через полгода после запуска пришлось резко перестраивать вложенность под новые товарные линейки.
- Меняли URL-схему при последующем обмене с 1С — символьные коды разделов оказались не зафиксированы, и адреса «поплыли» после первого же массового импорта.
Чек-лист перед стартом разработки
Сведём всё в практический список, по которому удобно принимать готовность SEO-архитектуры перед передачей в разработку:
- Семантика собрана и кластеризована. Запросы сгруппированы по интенту, у каждого кластера есть оценка спроса.
- Дерево кластеров построено. Определены родительско-дочерние связи, глубина не превышает 3–4 уровня.
- Решение «раздел или свойство фильтра» принято по каждому кластеру. Узкие кластеры не превращены в лишние разделы каталога.
- URL-схема прописана. Шаблон адреса зафиксирован для каждого типа узла, символьные коды стабильны при обмене с 1С.
- Перелинковка спланирована. Понятно, какие связи между разделами формируются автоматически шаблонами, а какие — вручную.
- Карта сверена с моделью данных. Разработчик подтвердил, что структура ложится на инфоблоки без компромиссов.
- Заложен запас на рост. В структуре есть место для кластеров, которые появятся при расширении ассортимента.
- Карта передана как техническое задание. Разработка ведётся по зафиксированной структуре, а не «по ходу дела».
Вывод
SEO-архитектура — это карта разделов, построенная от кластеризованной семантики и заложенная в проект до начала разработки, а не подогнанная под уже готовый сайт. Спроектируйте её в правильном порядке — семантика, кластеры, дерево разделов, URL и перелинковка, модель данных — и структура выдержит рост каталога на годы вперёд без дорогостоящих переделок.
