Структура каталога в 1С-Битрикс: разделы, вложенность и хлебные крошки

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

В этой статье разберём структуру каталога в 1С-Битрикс без общих слов: как устроены разделы инфоблока и дерево категорий, какая глубина вложенности оптимальна и почему обычно хватает 2–3 уровней, где проходит граница между разделом и фильтром, как формируются ЧПУ разделов и хлебные крошки на компоненте bitrix:breadcrumb, что такое посадочные разделы под SEO-запросы, как выводить и сортировать разделы, как работать с картинками и описаниями категорий, что делать с мультисортиментом и пересечениями, как структура влияет на индексацию и перелинковку и как всё это связано с обменом из 1С. Материал — выжимка из наших внедрений по разработке каталога товаров на 1С-Битрикс, где грамотное дерево разделов закладывается в самую основу проекта.

Что такое структура каталога

Под структурой каталога понимают две связанные вещи. Первое — это дерево разделов (категорий) товарного инфоблока: как ассортимент разбит на группы и подгруппы, что вложено во что, в каком порядке идёт. Второе — правила раскладки товаров по этим разделам: в какой категории лежит товар, попадает ли он в несколько категорий, где его основной раздел. Вместе это и есть каркас магазина.

Почему структуру называют фундаментом? Потому что из неё автоматически вырастает почти всё, что видят покупатель и поисковая система: пункты меню каталога, адреса страниц категорий (ЧПУ), хлебные крошки на каждой странице, посадочные страницы под запросы, внутренняя перелинковка между категориями и товарами, логика умного фильтра, который работает в границах раздела. Ошибётесь в дереве — и ошибка отразится сразу везде: в навигации, в URL, в индексации, в конверсии.

Отсюда главный практический принцип: структуру проектируют первой, до витрины, дизайна и фильтра, и относятся к ней как к архитектуре здания. Переставить категории на живом каталоге, где страницы уже в индексе и на них идёт трафик, — это не «поправить в админке за пять минут», а операция с редиректами, пересборкой фасета и риском временной просадки позиций. Дешевле и безопаснее заложить дерево правильно на старте.

Разделы инфоблока: дерево категорий

Технически разделы — это записи в отдельной таблице инфоблока, организованные в дерево. Каждый раздел знает своего родителя, и вместе они образуют иерархию произвольной глубины: «Электроника → Смартфоны → Флагманы». Внутри Битрикс хранит это дерево по модели вложенных множеств (nested sets) — схеме, которая позволяет одним запросом получить всё поддерево категории без рекурсии. Для витрины это значит, что операция «показать все товары раздела вместе с подразделами» работает быстро даже на глубоком дереве.

У каждого раздела есть набор полей, которые вы будете использовать при проектировании структуры:

• Название — как категория подписана в меню и крошках.
• Символьный код (CODE) — из него собирается ЧПУ раздела; задаётся осмысленным и стабильным.
• Родительский раздел — определяет место в дереве и глубину вложенности.
• Индекс сортировки — порядок вывода среди соседних разделов.
• Активность — показывать раздел на витрине или нет (служебные разделы отключают).
• Картинка и анонсная картинка — иконка/обложка категории для плиток меню.
• Описание — SEO-текст и вводный абзац категории.
• Свойства раздела и UF-поля — произвольные доп-данные категории (например, метатеги, флаг «показывать в меню»).

Товар (элемент инфоблока) привязывается к разделу через основную привязку и, при необходимости, к дополнительным разделам. Эта модель — дерево разделов плюс раскладка элементов — и есть та структура, которую мы дальше проектируем. Как устроены сами инфоблоки и хранение свойств, мы подробно разбирали в статье про инфоблоки 2.0 и highload-каталог; здесь фокус именно на разделах и навигации.

С чего начинать проектирование дерева

Главная методическая ошибка — проектировать каталог «от склада»: взять группы номенклатуры из 1С или прайс поставщика и перенести их на сайт один в один. Складская структура удобна бухгалтеру и кладовщику, но покупателю и поисковику нужна другая логика — логика спроса. Люди ищут «игровые ноутбуки», «беспроводные наушники», «стиральные машины с сушкой», а не «Товарная группа 04.2».

Поэтому дерево строят от трёх источников, в таком порядке приоритета:

1. Семантика (что ищут). Собирают семантическое ядро: какие категории и как формулируют в поиске, какие есть частотные уточнения (бренд, назначение, тип). Кластеры запросов подсказывают, какие разделы вообще нужны и как их называть.
2. Логика покупателя (как выбирают). Смотрят, как человек рассуждает, выбирая товар: сначала тип, потом бренд, потом характеристики. Верхние уровни дерева должны совпадать с первыми шагами этого выбора.
3. Ассортимент (что есть в наличии). Уже поверх спроса и логики накладывают реальный ассортимент: не создают разделы под то, чего нет, и не дробят на пустые категории.

Результат этого этапа — не картинка «красиво», а карта категорий, где у каждого раздела есть основание существовать: спрос, место в логике выбора и товары внутри. Такое дерево одновременно удобно покупателю, понятно поиску и не разваливается при росте. Кстати, именно с проектирования продающей структуры начинается наша услуга по созданию сайта с SEO-структурой — потому что от неё зависит и трафик, и продажи.

Оптимальная глубина вложенности

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

Рабочий ориентир: 2–3 уровня разделов для большинства магазинов, до 4 — в крупных и сложных каталогах. Распределение ролей по уровням обычно такое:

Почему глубокое дерево — это плохо? Причин несколько, и они бьют одновременно по пользователю и по SEO:

• Длинный путь до товара. Каждый лишний уровень — лишний клик и шанс, что покупатель уйдёт, не дойдя.
• Громоздкие хлебные крошки. Цепочка из шести звеньев не помещается и не помогает ориентироваться.
• Удалённость от главной. Чем глубже страница, тем меньше на неё «веса» по внутренним ссылкам и тем хуже она индексируется.
• Пустые и слабые разделы. Дробление до последнего плодит категории с двумя-тремя товарами, которые не имеют самостоятельного спроса и только размывают структуру.
• Сложность поддержки. Глубокое дерево тяжело держать в порядке при обмене и наполнении.

Если ассортимент хочется дробить сильнее, чем позволяют 3 уровня, это почти всегда сигнал: дальше должен работать не раздел, а фильтр. О границе между ними — следующий раздел.

Раздел или фильтр: как решить

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

Работает простой набор проверочных вопросов. Если группа товаров проходит их — это раздел:

• Есть ли самостоятельный спрос? Люди ищут именно эту группу как категорию («смартфоны», «мойки высокого давления»)?
• Есть ли отдельный поисковый запрос? Под группу можно собрать посадочную страницу, которая будет ранжироваться?
• Логично ли вести её из меню? Категорию естественно показать в главном меню каталога?
• Нужен ли ей свой контент? У страницы будет уместен заголовок, вводный текст, своя подборка?

Если же речь об одной из осей, по которым перебирают товары внутри уже выбранной категории, — это фильтр (фасет):

• Цвет, бренд, объём памяти, диапазон цены, диагональ, материал — это характеристики, а не категории.
• Их комбинируют между собой («Samsung И чёрный И от 128 ГБ») — разделами так не сделаешь, а фильтром естественно.
• Их много, и под каждое значение отдельный раздел создавать бессмысленно.

Практический критерий: категория — это то, чем товар является; характеристика — это какой он. «Ноутбук» — категория (раздел), «игровой», «серебристый», «16 ГБ» — характеристики (фильтр). Есть и гибрид: некоторые ходовые сочетания фильтров («игровые ноутбуки», «смартфоны Samsung») выгодно оформить как посадочные страницы — об этом в разделе про SEO-разделы ниже. Как устроен сам фасетный механизм, мы подробно разбирали в статьях про умный фильтр в 1С-Битрикс и фасетную навигацию и SEO.

ЧПУ разделов и символьные коды

Из символьного кода раздела формируется его человекопонятный URL (ЧПУ). Вместо /catalog/index.php?SECTION_ID=42 покупатель и поисковик видят /catalog/smartfony/, а для вложенной категории — /catalog/smartfony/flagmany/. Адрес повторяет путь по дереву, и это одна из причин, почему структура так важна для SEO: дерево разделов буквально превращается в структуру URL сайта.

Несколько правил работы с ЧПУ разделов, которые экономят позиции и нервы:

• Транслитерация и осмысленность. Код генерируют из названия по правилам транслитерации, но следят, чтобы он был коротким и читаемым: stiralnye-mashiny, а не gruppa-04-2.
• Стабильность после индексации. Менять код у категории, которая уже в поиске, — значит менять её URL, ловить 404 и терять позиции. Если менять приходится — обязателен 301-редирект со старого адреса на новый.
• Латиница, цифры, дефисы. В коде — только строчная латиница, цифры и дефисы; без пробелов, кириллицы и подчёркиваний.
• Уникальность в пределах уровня. Внутри одного родителя коды не должны повторяться, иначе URL начнут конфликтовать.
• ЧПУ включают правилами обработки адресов. На стороне Битрикса за красивые адреса каталога отвечают правила обработки URL (urlrewrite) и параметры компонента каталога — их настраивают один раз при запуске.

Отдельная тонкость — вложенные адреса. Хорошая практика для каталога — «человеческие» ЧПУ, где путь URL повторяет путь по разделам (/catalog/электроника-транслитом/подраздел/). Это делает адрес самодокументируемым и усиливает связь URL со структурой. Подробно про формирование адресов, редиректы и типичные ловушки — в статье про ЧПУ и URL в 1С-Битрикс.

Хлебные крошки: bitrix:breadcrumb

Хлебные крошки — это навигационная цепочка от главной до текущей страницы: Главная → Каталог → Смартфоны → Флагманы → iPhone. Они решают сразу две задачи: помогают человеку понять, где он находится и быстро подняться на уровень выше, и передают поисковику структуру сайта (через микроразметку BreadcrumbList, из-за которой крошки часто показываются прямо в сниппете выдачи).

В 1С-Битрикс за крошки отвечает штатный компонент bitrix:breadcrumb. Обычно он вызывается один раз в шаблоне сайта — в прологе (файле header.php), — и строит цепочку из «навигационной цепочки» страницы. Ключевой момент: на страницах каталога звенья разделов в эту цепочку добавляют сами компоненты каталога. Компонент списка/детального просмотра при выводе раздела вызывает метод, который добавляет в навигационную цепочку звено ($APPLICATION->AddChainItem()), поэтому крошки автоматически повторяют путь по дереву разделов.

Что важно проверить в реализации хлебных крошек:

• Крошки повторяют путь по разделам. Цепочка должна идти по дереву каталога, а не быть «плоской». Это работает, если компоненты каталога настроены добавлять разделы в цепочку.
• Каждое звено — рабочая ссылка. Промежуточные звенья ведут на реальные URL разделов; битых ссылок и звеньев на «пустоту» быть не должно.
• Последнее звено — не ссылка. Текущая страница в крошках отображается текстом, а не кликабельной ссылкой на саму себя.
• Корректная микроразметка. Шаблон компонента должен размечать цепочку как BreadcrumbList (Schema.org), чтобы крошки попадали в сниппет.
• Согласованность с меню и URL. Путь в крошках, адрес страницы и положение в меню должны совпадать — это признак чистой структуры.

Кастомизируют крошки, копируя шаблон компонента bitrix:breadcrumb в свой шаблон сайта и правя вёрстку и разметку. Логику наполнения цепочки при этом трогают редко — её обеспечивают компоненты каталога. Если крошки на каталоге «плоские» или показывают не тот путь, причина почти всегда в том, что компонент каталога не добавляет разделы в цепочку или структура товара привязана не к тому основному разделу.

Посадочные разделы под SEO-запросы

Посадочный раздел — это категория, созданная специально под конкретный поисковый спрос. Помимо базовых «Смартфоны» и «Ноутбуки» люди ищут более узкие вещи: «смартфоны Samsung», «игровые ноутбуки», «холодильники до 30000», «беспроводные наушники с шумоподавлением». Под каждый такой устойчивый запрос выгодно иметь готовую страницу — с ЧПУ, заголовком, вводным текстом и подборкой товаров. Это и есть посадочные разделы, и именно они часто приносят основной трафик каталога, потому что точно отвечают на запрос.

В Битриксе посадочные страницы делают двумя основными способами, и выбор между ними — важное проектное решение:

Правило простое. Если группа — это самостоятельная товарная сущность, которой нужен свой текст, своя ручная подборка и место в меню, делайте её разделом. Если это предзаданное сочетание фильтров без потребности в ручном контенте — делайте SEO-страницу умного фильтра с человекочитаемым URL и уникальными метатегами. Технику SEO-страниц фасета мы разбирали в материале про фасетную навигацию и SEO.

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

Сортировка и вывод разделов

Спроектировать дерево — половина дела; второе — правильно вывести разделы на витрину: в меню каталога, на страницах категорий (плитки подразделов), в фильтрах. Порядок вывода разделов управляется несколькими механизмами.

• Индекс сортировки. У каждого раздела есть числовое поле сортировки (по умолчанию 500). Меньше значение — выше в списке. Это основной инструмент, чтобы ходовые категории шли первыми, а не в алфавитном порядке.
• Сортировка по названию. При равных индексах разделы можно сортировать по имени — удобно для длинных однородных списков (например, бренды).
• Активность. Неактивные разделы не выводятся на витрине — так прячут служебные и сезонно отключённые категории.
• Ограничение вложенности. В компонентах вывода задают, на сколько уровней вглубь показывать разделы (например, только прямые подразделы текущего).

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

• bitrix:catalog.section.list — список подразделов текущего раздела (плитки категорий на странице каталога и категории).
• Комплексный компонент bitrix:catalog — включает вывод разделов и элементов и берёт на себя маршрутизацию и крошки.
• bitrix:menu с деревом на основе разделов — для главного и бокового меню каталога.

Важнейший практический момент — кэширование. Дерево разделов меняется редко (при обмене или ручной правке), а читается на каждой странице сайта тысячами посетителей. Поэтому вывод разделов и меню обязательно кэшируют: включают кэш компонентов, а лучше — управляемый кэш с тегами, который сам сбрасывается при изменении разделов. Без кэша каждый вывод меню — это лишний обход дерева в базе на каждом хите.

Картинки и описания разделов

Раздел — это не только название в дереве, но и полноценная страница категории, у которой есть своё оформление и своё SEO. Два поля раздела отвечают за это напрямую: картинка и описание.

Картинки разделов

У раздела есть два поля изображений: анонсная картинка (для плиток в списке категорий) и детальная (для шапки страницы категории). Их используют, чтобы меню каталога и страницы разделов выглядели как витрина с иконками и обложками, а не как голый текстовый список. Картинки разделов подгружают через компоненты вывода и обязательно оптимизируют по весу и размеру — они грузятся на видных местах и влияют на скорость.

Описания и SEO-текст

Поле описания раздела (детальное и анонсное) — это место для вводного текста категории и SEO-контента. Хороший текст категории решает две задачи: помогает покупателю сориентироваться (что здесь есть, как выбирать) и даёт поисковику уникальное содержание страницы, без которого категория рискует остаться «тонкой». Текст обычно выводят под товарами или сворачивают, чтобы он не мешал покупателю, но присутствовал в коде страницы.

Метатеги категории

Title, Description и H1 категории — отдельная важная деталь. В Битриксе для разделов инфоблока есть механизм SEO-полей (шаблоны и значения метатегов на уровне раздела), который позволяет задавать заголовки и описания как вручную для важных категорий, так и шаблоном для массовых. Уникальные, осмысленные метатеги категорий — обязательное условие ранжирования; шаблон «название категории — купить в интернет-магазине» лучше, чем пустой Title, но у ключевых разделов метатеги прописывают руками.

Итог: каждый значимый раздел стоит рассматривать как посадочную страницу, у которой есть картинка, вводный текст, уникальные метатеги и осмысленный H1. Разделы «только с названием» — упущенная возможность и для конверсии, и для SEO.

Основной раздел и канонические URL

У элемента инфоблока есть понятие основного раздела (основной группы). Даже если товар привязан к нескольким разделам, один из них — основной, и именно он определяет «главный» путь к товару: адрес карточки, хлебные крошки, положение в дереве. Это важнейшая настройка, от которой напрямую зависит, не появятся ли на сайте дубли страниц товара.

Проблема возникает так. Товар лежит в разделах «Смартфоны» и «Новинки». Если карточка доступна и по адресу /catalog/smartfony/iphone/, и по /catalog/novinki/iphone/, то для поисковика это две страницы с одинаковым содержимым — дубли, которые размывают вес и путают индексацию. Решение — жёстко определить канонический адрес карточки и указать его в теге <link rel="canonical">.

Правила, которых мы придерживаемся:

• Канонический URL — через основной раздел. Настраивают так, чтобы карточка товара имела один основной адрес (обычно по основному разделу), и на него указывает canonical.
• Хлебные крошки — по основному разделу. Путь в крошках на карточке строится по основному разделу, а не по случайному из дополнительных.
• Дополнительные разделы — для навигации, не для отдельных URL карточки. Привязка к «Новинкам» показывает товар в этой подборке, но не создаёт второй канонический адрес.
• Единая настройка ЧПУ. Правила обработки URL каталога настраивают так, чтобы карточка не открывалась одновременно по разным путям как самостоятельные страницы.

Аккуратная работа с основным разделом и canonical — это то, что отличает каталог, который хорошо индексируется, от каталога, тонущего в дублях. При проектировании структуры этот вопрос решают заранее, а не когда поиск уже нашёл сотни дублей.

Мультисортимент и пересечения

Реальный ассортимент редко раскладывается по дереву идеально: один товар логично отнести сразу к нескольким категориям. Смартфон — это и «Смартфоны», и «Новинки», и «Товары со скидкой»; чехол — это и «Аксессуары», и раздел конкретной модели телефона. Такие пересечения — норма, и Битрикс их поддерживает через дополнительные привязки к разделам.

Как это работает и где грабли:

• Основной + дополнительные разделы. У товара один основной раздел (определяет URL и крошки) и сколько угодно дополнительных (товар в них показывается, но канонический адрес не меняется).
• Подборки и виртуальные категории. «Новинки», «Хиты», «Распродажа» удобно делать либо дополнительными разделами, либо через свойство-флаг и вывод по фильтру — второй способ часто чище, потому что не смешивает «навигационные» разделы с товарной структурой.
• Осторожно с дублями. Каждое пересечение — потенциальный дубль URL. Спасает жёсткий канонический адрес по основному разделу (см. предыдущий раздел).
• Товар без основного раздела. Товар, забытый в дереве (не привязанный ни к одной категории), выпадает из навигации и часто из фильтра. При приёмке каталога проверяют, что «бесхозных» товаров нет.

Хорошая практика — разделять два типа группировок: товарная структура (что есть товар — категории дерева, по которым строятся URL и крошки) и маркетинговые подборки (акции, новинки, хиты — их лучше собирать фильтром или флагами, а не плодить в основном дереве). Тогда дерево остаётся чистым и продающим, а подборки живут отдельно и не создают дублей.

Скрытые и служебные разделы

Не все разделы каталога предназначены для покупателя. В любом развитом магазине есть служебные разделы, которые нужны для работы, но не должны попадать ни в меню, ни в индекс. Типичные примеры:

• Технические категории обмена. Разделы, которые создаёт обмен с 1С под служебные группы номенклатуры, не имеющие смысла на витрине.
• «Архив», «Снятые с производства». Товары, которые нельзя удалять (нужны для истории заказов), но не нужно показывать.
• Черновики и подготовка. Разделы, в которых собирают товары перед публикацией.
• Внутренние подборки. Группы для внутренних нужд, не для покупателя.

Управляют видимостью такими способами:

• Активность раздела. Неактивный раздел не выводится компонентами витрины — базовый способ спрятать категорию.
• Флаг «показывать в меню». Отдельное UF-поле или свойство раздела, по которому меню фильтрует, что выводить, а компонент каталога — что показывать в списке подразделов.
• Закрытие от индексации. Служебные разделы, которые всё же доступны по URL, закрывают от поиска (через noindex/robots), чтобы они не попадали в выдачу.
• Права доступа. Для внутренних разделов ограничивают доступ так, чтобы их видели только сотрудники.

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

Структура, индексация и перелинковка

Структура каталога напрямую определяет, как сайт индексируется и как внутри него распределяется ссылочный вес. Это, пожалуй, главная причина, почему SEO-специалист вовлечён в проектирование дерева наравне с проектировщиком UX.

Как структура влияет на индексацию

Поисковый робот обходит сайт по ссылкам. Чем логичнее дерево и чем ближе страницы к главной, тем полнее и быстрее они индексируются. Плоская, хаотичная или слишком глубокая структура приводит к тому, что часть категорий и товаров робот находит поздно или не находит вовсе. Дополнительно на индексацию влияет чистота структуры: дубли из-за пересечений разделов, тонкие пустые категории и служебные разделы в индексе «съедают» краулинговый бюджет и мешают роботу дойти до важных страниц.

Перелинковка через структуру

Хорошее дерево само по себе — это перелинковка. Меню каталога, плитки подразделов, хлебные крошки, ссылки «вверх по дереву» и связанные категории образуют естественную сеть внутренних ссылок, которая распределяет вес от главной к категориям и товарам. Что усиливает эту сеть:

• Хлебные крошки на каждой странице — ссылки вверх по дереву на всех карточках и категориях.
• Меню каталога — ссылки с любой страницы на ключевые разделы.
• Блоки связанных категорий и подкатегорий — горизонтальные связи между разделами одного уровня.
• Ссылки на посадочные разделы из текста категорий и с родительских страниц.

Отдельно стоит следить, чтобы страницы пагинации, сортировки и фильтров не «размывали» перелинковку и не плодили дубли: это решается каноническими адресами и правильной обработкой параметров фасета. В связке структура + чистые URL + хлебные крошки поисковик получает ясную карту сайта, а вес концентрируется на продающих категориях. Именно поэтому мы объединяем проектирование дерева и техническое SEO в одну услугу — сайт с SEO-структурой.

Навигация и меню каталога

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

• Горизонтальное меню с выпадающими списками. Подходит для небольшого дерева: разделы первого уровня в строке, подразделы — в выпадашке.
• Мега-меню (большая панель). Для крупных каталогов: при наведении открывается панель с колонками подразделов, иконками и промо. Показывает сразу два-три уровня.
• Боковое меню (каталог-рубрикатор). Вертикальное дерево разделов сбоку от витрины — классика для магазинов с большим числом категорий.
• Плитки категорий на странице. На главной каталога и в разделах выводят подкатегории карточками с картинками — это и навигация, и перелинковка.

Технически меню каталога реализуют либо компонентом bitrix:catalog.section.list (список разделов), либо bitrix:menu на основе дерева, либо кастомным компонентом, который читает разделы через API и отдаёт нужную структуру. В любом случае действуют общие правила хорошей навигации:

• Меню отражает дерево, но не обязано показывать его целиком. В меню выводят то, что важно покупателю: обычно один-два уровня, глубже человек проваливается уже на странице категории.
• Единый источник правды. Меню строится из тех же разделов, что и URL, и крошки, — тогда навигация согласована.
• Флаг «в меню». Не каждый раздел нужен в меню; служебные и мелкие категории помечают флагом и не выводят.
• Кэширование обязательно. Меню читается на каждой странице — его кэшируют, чтобы не обходить дерево в базе на каждом хите.
• Мобильная версия. На телефоне мега-меню превращают в аккуратное раскрывающееся дерево — навигация не должна ломаться на маленьком экране.

Связь структуры с обменом 1С

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

Как это работает. При стандартном обмене через коммерческую информацию (формат CommerceML) разделы каталога на сайте создаются из групп номенклатуры в 1С. Дерево групп в учётной системе выгружается и воспроизводится на сайте. Товары раскладываются по разделам согласно их принадлежности к группам в 1С. Отсюда типовая проблема: структура склада (удобная бухгалтеру) переносится на витрину (где нужна логика спроса), и получается каталог с непонятными покупателю категориями и служебными группами в меню.

Что с этим делать — есть несколько стратегий:

1. Привести группы в 1С к продающему виду. Самый чистый путь: договориться, что дерево групп номенклатуры в 1С проектируется как витринное, — тогда обмен переносит уже правильную структуру. Подходит, когда учётную систему можно перестроить.
2. Настроить соответствие при обмене. Если менять 1С нельзя, настраивают правила: какие группы в какие разделы сайта попадают, какие игнорируются, какие объединяются. Обмен раскладывает товары по «сайтовому» дереву, не копируя склад один в один.
3. Разделить «структуру обмена» и «витринную структуру». Часть проектов держит техническое дерево для обмена скрытым (служебные разделы) и строит витрину поверх него через дополнительные привязки, флаги и фильтр.

И общее правило, критичное при любом сценарии: символьные коды разделов должны быть стабильными и не зависеть от капризов обмена. Если обмен при каждой выгрузке пересоздаёт разделы с новыми кодами, ЧПУ категорий «поедут», страницы отдадут 404, а позиции обвалятся. Поэтому обмен настраивают так, чтобы он сопоставлял группы с разделами по стабильному внешнему коду (XML_ID), а не создавал их заново. Как устроены сами инфоблоки, из которых обмен собирает каталог, — в статье про инфоблоки 2.0.

Пошагово: проектируем структуру

Сведём всё в практическую последовательность — так мы проектируем структуру каталога на реальных проектах, от первого этапа до приёмки.

1. Собрать семантику. Составить семантическое ядро: какие категории ищут, какими словами, какие есть частотные уточнения. Кластеры запросов — это черновик дерева разделов.
2. Нарисовать дерево от спроса. На основе семантики и логики выбора построить дерево категорий: 1-й уровень — направления, 2-й — категории, 3-й — узкие подкатегории. Проверить «правилом трёх кликов».
3. Развести разделы и фильтры. Для каждой группы решить: это раздел (свой спрос, запрос, место в меню) или это фильтр (ось перебора внутри категории). Спорные ходовые сочетания отметить как посадочные.
4. Задать символьные коды. Прописать осмысленные, короткие, латинские коды разделов. Зафиксировать их как стабильные — они станут ЧПУ и менять их будет нельзя.
5. Спланировать посадочные разделы. Под подтверждённые спросом запросы решить, где будет отдельный раздел, а где — SEO-страница умного фильтра.
6. Настроить основной раздел и canonical. Определить правило основного раздела для товаров и канонические URL, чтобы пересечения не давали дублей.
7. Настроить обмен с 1С. Согласовать соответствие групп номенклатуры и разделов сайта, сопоставление по XML_ID, защиту символьных кодов от пересоздания.
8. Вывести навигацию. Собрать меню каталога, плитки категорий, хлебные крошки на bitrix:breadcrumb; настроить сортировку, картинки и описания разделов; включить кэширование.
9. Заполнить SEO категорий. Прописать метатеги и вводные тексты хотя бы для ключевых разделов; для массовых — шаблоны.
10. Проверить и принять. Пройти по чек-листу: нет бесхозных товаров, крошки повторяют путь, дублей нет, служебные разделы скрыты, меню согласовано с URL, фасет построен.

Заметьте: собственно «нарисовать дерево» — это лишь второй шаг из десяти. Основная работа — до (семантика, логика) и после (коды, canonical, обмен, навигация, SEO, приёмка). Именно поэтому структуру нельзя «накидать за вечер»: это инженерно-маркетинговая задача, от которой зависит и трафик, и продажи на годы вперёд.

Реализация в компонентах Битрикса

Соберём в одном месте, какими штатными средствами Битрикса реализуется всё описанное, — чтобы было понятно, что где настраивается.

Отдельно про хлебные крошки в коде. Компонент bitrix:breadcrumb вызывают в прологе один раз, а звенья дерева в цепочку добавляют компоненты каталога методом AddChainItem(). Если нужен нестандартный путь в крошках (например, для посадочной страницы), звено добавляют вручную в коде страницы тем же методом до вывода крошек. Кастомизацию вида крошек делают копированием шаблона компонента в свой шаблон сайта. Таким образом, вся навигация — меню, крошки, списки разделов — собирается из одного дерева разделов штатными компонентами, а задача разработчика — правильно спроектировать это дерево и аккуратно настроить вывод и кэш.

Частые ошибки

• Структура скопирована из 1С «как есть». Дерево групп номенклатуры удобно бухгалтеру, но не покупателю и не поиску. Витринную структуру проектируют от спроса, а не от склада.
• Слишком глубокая вложенность. 5–6 уровней разделов путают покупателя и вредят SEO. Держитесь 2–3 уровней, до 4 в больших каталогах; глубже — работа фильтра.
• Разделы вместо фильтра. Отдельная категория под каждый бренд, цвет и объём памяти раздувает дерево пустыми страницами. Характеристики — это фильтр, а не разделы.
• Смена символьных кодов после индексации. Меняет ЧПУ, ломает URL, роняет позиции. Коды задают на старте и не трогают; при вынужденной смене — 301-редирект.
• Пересечения без canonical. Товар в нескольких разделах, доступный по нескольким URL, создаёт дубли. Нужен канонический адрес по основному разделу.
• Хлебные крошки не повторяют путь. «Плоские» крошки или крошки не по тому разделу дезориентируют покупателя и поиск. Крошки строят по основному разделу через компоненты каталога.
• Бесхозные товары. Товар без основного раздела выпадает из навигации и фильтра. При приёмке проверяют, что таких нет.
• Служебные разделы в индексе и меню. Технические группы обмена и «архивы» не должны быть в меню и в поиске — их скрывают и закрывают от индексации.
• Тонкие категории без контента. Разделы «только с названием», без текста, метатегов и товаров, не ранжируются. Значимый раздел — это посадочная страница с содержанием.
• Обмен пересоздаёт разделы. Если обмен с 1С заново создаёт категории с новыми кодами, ЧПУ «едут». Настраивают сопоставление по XML_ID.
• Нет кэша на выводе дерева. Меню и списки разделов без кэша обходят дерево в базе на каждом хите. Кэш компонентов и managed cache обязательны.

Чек-лист по структуре каталога

Сведём в практический список то, что проверяют при проектировании и приёмке структуры каталога перед запуском.

1. Дерево от спроса. Категории названы словами покупателя, опираются на семантику, а не скопированы из групп 1С.
2. Глубина в норме. 2–3 уровня разделов (до 4 в больших каталогах); до любого товара — 3–4 клика от главной.
3. Разделы и фильтры разведены. Категории — это «чем товар является»; характеристики (цвет, бренд, память) — это фильтр.
4. Символьные коды заданы. Осмысленные, латинские, уникальные, стабильные; ЧПУ повторяют путь по дереву.
5. Хлебные крошки корректны. Повторяют путь по основному разделу, каждое звено — рабочая ссылка, последнее звено — не ссылка, размечено как BreadcrumbList.
6. Посадочные разделы спланированы. Под подтверждённый спрос — отдельные разделы или SEO-страницы фильтра; тонких пустых категорий нет.
7. Основной раздел и canonical. У каждого товара есть основной раздел; канонический URL один; пересечения не дают дублей.
8. Служебные разделы скрыты. Технические и «архивные» категории неактивны или помечены «не в меню» и закрыты от индексации.
9. Картинки и SEO категорий. У ключевых разделов есть картинка, вводный текст, уникальные метатеги и H1.
10. Навигация согласована. Меню, URL и крошки строятся из одного дерева; сортировка разделов задана с шагом; вывод кэшируется.
11. Обмен с 1С настроен. Сопоставление групп и разделов по XML_ID; коды не пересоздаются; витринное дерево не «уезжает» после выгрузки.

Вывод

Структура каталога — это не «дерево категорий в админке», а фундамент, из которого автоматически вырастают навигация, адреса страниц, хлебные крошки, посадочные страницы и вся внутренняя перелинковка. Спроектируете её от спроса, с разумной глубиной в 2–3 уровня, с чёткой границей между разделом и фильтром, с осмысленными и стабильными ЧПУ, с корректными крошками и продуманными посадочными разделами — и каталог будет одинаково удобен покупателю, понятен поиску и устойчив к росту. Ошибётесь на этом уровне — и ошибка отразится сразу везде: в конверсии, в индексации, в позициях.

Практический вывод один: структуру закладывают правильно с самого начала, потому что переделывать дерево на живом каталоге, где страницы уже в индексе, — дорого и рискованно. Дерево — от семантики и логики выбора; глубина — 2–3 уровня; характеристики — в фильтр, а не в разделы; символьные коды — стабильные; хлебные крошки — по основному разделу; обмен с 1С — под контролем, а не «как выгрузилось». Сделайте это аккуратно — и каталог будет вести покупателя к товару, а поисковик к вашим категориям. А если структуру нужно спроектировать с нуля или переработать под рост и SEO, мы помогаем с этим в рамках разработки каталога товаров на 1С-Битрикс и создания сайта с SEO-структурой. Больше разборов по теме — в рубрике «Каталог и поиск».