Меню каталога и мегаменю на 1С-Битрикс: навигация, которая ведёт к товару

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

В этой статье разберём по-инженерному, как устроена навигация магазина: какие бывают типы меню (верхнее, каталожное дерево разделов, мегаменю с колонками, промоблоками и картинками), как строить меню из разделов инфоблока через компонент bitrix:menu и свой шаблон, зачем и как кэшировать меню, какой глубины и группировки держаться, как делать удобное мобильное меню и sticky-шапку, встраивать поиск и хлебные крошки в навигацию, не забывать про доступность (клавиатура, ARIA) и скорость (кэш, ленивая подгрузка мегаменю), а также про популярные разделы и персонализацию. Материал опирается на нашу практику оптимизации конверсии (CRO) и разработки интернет-магазинов на 1С-Битрикс — без выдуманных «процентов роста», зато с рабочими принципами. Рубрика «Конверсия и UX» — про то, как магазин превращает визиты в заказы, и навигация здесь одна из опор.

Навигация и конверсия: короткий путь к товару

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

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

Есть три сценария, как покупатель ищет товар, и навигация должна поддерживать все три:

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

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

Типы меню в интернет-магазине

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

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

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

Верхнее (главное) меню

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

Что обычно попадает в верхнее меню:

• Каталог. Главная точка входа в ассортимент — часто отдельной заметной кнопкой, раскрывающей каталожное дерево или мегаменю.
• Акции и распродажи. Ходовой раздел, который многие ищут специально, — ему место на виду.
• Доставка и оплата. Один из главных вопросов покупателя перед заказом; ссылка снимает сомнения.
• О компании / гарантии. Сигнал доверия, особенно для новых покупателей.
• Контакты. Телефон, адрес, форма связи — то, что ищут, когда нужна помощь.

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

Технически в 1С-Битрикс верхнее меню — это классический случай применения компонента bitrix:menu с типом меню (например, top), а пункты хранятся в файле .top.menu.php. Это статичные пункты, которые редко меняются, поэтому их удобно держать в файле меню и править вручную через редактор структуры или прямо в коде. В отличие от каталожного дерева, здесь автоматическая генерация из инфоблока обычно не нужна: разделы сайта стабильны.

Каталожное меню: дерево разделов

Каталожное меню — сердце навигации магазина. Оно показывает структуру ассортимента: разделы, подразделы, а иногда и третий уровень. Именно через него идёт покупатель, который знает категорию, но не конкретный товар: «нужны кроссовки» → раздел «Обувь» → подраздел «Кроссовки» → выдача с фильтром.

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

Форма каталожного меню зависит от ширины ассортимента:

• Узкий каталог. Хватает обычного выпадающего меню: наводишь на раздел — выпадает список подразделов одной колонкой.
• Широкий каталог. Нужно мегаменю: широкая панель с несколькими колонками, которая показывает сразу много разделов и подразделов.
• Очень глубокий каталог. Часто удобнее «каталог с переходами вглубь»: клик по разделу ведёт на страницу раздела, где уже показаны подразделы и фильтр, — вместо попытки уместить всё дерево в меню.

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

Мегаменю: колонки, промоблоки, картинки

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

Из чего складывается хорошее мегаменю:

• Колонки разделов. Основной объём панели — понятно сгруппированные разделы и подразделы. Их читают глазами по колонкам, а не ищут в длинном списке.
• Картинки популярных категорий. Визуальные превью ходовых разделов ускоряют узнавание: образ считывается быстрее текста.
• Промоблок. Один аккуратный блок с акцией, хитами или новинками, ведущий в реально ходовые разделы, — как дополнение, а не как половина панели.
• Понятная реакция. Мегаменю раскрывается предсказуемо (по наведению на десктопе, по тапу на сенсоре) и не «прыгает», не перекрывает контент невпопад.

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

Меню из разделов инфоблока каталога

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

Способов построить меню из разделов несколько, и выбирают их по задаче:

• Каталожные компоненты вывода разделов. В 1С-Битрикс есть готовые компоненты для вывода списка разделов (например, catalog.section.list), которые обходят дерево и отдают разделы; их шаблон и превращают в меню или мегаменю.
• Генерация пунктов через API инфоблоков. Разделы получают программно (API инфоблоков / D7), собирают в массив пунктов нужного формата и передают в шаблон меню. Гибко, но требует аккуратного кэширования.
• Генерация файла .menu.php из разделов. По разделам инфоблока формируют файл меню, который дальше выводит стандартный bitrix:menu. Пересобирают файл по событию изменения разделов.

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

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

Компонент bitrix:menu и свой шаблон меню

Стандартный инструмент вывода меню в 1С-Битрикс — компонент bitrix:menu. Он читает пункты (из файлов .menu.php или из переданного массива), учитывает уровни вложенности и выводит их через шаблон. Всё оформление — разметка, классы, поведение выпадения — задаётся в шаблоне компонента, а не в его логике. Это удобно: чтобы сделать из обычного меню мегаменю, ядро трогать не нужно — достаточно своего шаблона.

Как устроена работа с меню на практике:

1. Определяют тип меню. Верхнее (top), левое, каталожное — у каждого свой тип и свой источник пунктов. Верхнее берут из файла, каталожное — из разделов инфоблока.
2. Готовят пункты. Для каталожного меню собирают дерево разделов в массив пунктов (название, ссылка, уровень, при необходимости — картинка, счётчик, метка).
3. Копируют и правят шаблон компонента. Шаблон bitrix:menu копируют в свой (в local/templates/...) и верстают под нужный вид: горизонтальное меню, выпадающее, мегаменю с колонками и промоблоком.
4. Добавляют поведение. Раскрытие по наведению и по тапу, клавиатурную навигацию, ARIA-атрибуты, sticky-поведение шапки — всё это в шаблоне и его скриптах/стилях.
5. Включают кэш. Кэширование компонента и, при генерации пунктов из инфоблока, кэш самого построения меню, чтобы дерево разделов не обходилось на каждом хите.

Важный принцип — работать через свой шаблон, а не переписывать логику компонента и уж тем более не лезть в ядро. Битрикс регулярно обновляется, и правки в стандартных компонентах при обновлении затираются или ломаются. Свой шаблон меню в local/templates живёт отдельно, переживает обновления и не мешает поддержке. Это то же правило, что действует для каталога, карточки и корзины: кастомизируем шаблоны, а не ядро.

Отдельно про мегаменю. С точки зрения bitrix:menu мегаменю — это тот же вывод пунктов, но с более богатым шаблоном: пункты верхнего уровня становятся «вкладками» каталога, а их дети раскладываются в колонки внутри широкой панели, к которой добавляют картинки и промоблок. Иногда мегаменю собирают не на bitrix:menu, а на каталожном компоненте вывода разделов — если нужен доступ к свойствам разделов (картинкам, счётчикам). Выбор зависит от того, насколько богатое содержимое нужно в панели: чем больше данных о разделах, тем чаще берут каталожный компонент, а не файловое меню.

Кэш меню: почему без него меню тормозит

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

Откуда берётся торможение:

• Обход дерева разделов на каждом хите. Каталог с сотнями разделов — это десятки запросов к базе и рекурсивный обход. Без кэша это повторяется при каждом открытии любой страницы сайта.
• Тяжёлое содержимое мегаменю. Картинки категорий, счётчики товаров, метки «хит/новинка» — каждое поле добавляет выборки. Собирать это заново каждый раз — дорого.
• Меню на всех страницах. В отличие от каталога, который тяжёл только на страницах каталога, меню грузится и на главной, и в карточке, и в статьях, и в корзине.

Как правильно кэшировать меню:

• Кэш компонента. Стандартный bitrix:menu кэшируется штатно; при генерации пунктов из инфоблока кэшируют и само построение (кэш результата обхода дерева).
• Управляемый кэш и теги. Кэш меню привязывают к разделам инфоблока, чтобы он сбрасывался автоматически при изменении разделов, а не «протухал» по таймеру или висел устаревшим.
• Композитный сайт. Шапка с меню — идеальный кандидат в статическую часть композита: она почти неизменна и отдаётся мгновенно из кэша.
• Единый кэш для всех страниц. Меню одинаково почти везде, поэтому его кэш переиспользуется между страницами — не нужно собирать его заново для каждой.

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

Глубина и группировка: не перегружать

Самая частая беда навигации — не техника, а перегруз. Магазин растёт, разделов становится всё больше, и меню незаметно превращается в лабиринт, где покупатель тонет. Здесь работают два принципа: разумная глубина и понятная группировка.

Глубина: один-три клика до раздела

Покупатель должен доходить до нужного раздела за один-три клика, не проваливаясь в бесконечную вложенность. На практике в навигации показывают два, максимум три уровня разделов: раздел → подраздел → (иногда) под-подраздел. Этого хватает, чтобы охватить широкий каталог. Более глубокие ветки не тащат в меню — их раскрывают уже внутри раздела: на странице категории с подразделами-плитками и умным фильтром. Меню задаёт крупную структуру, а тонкую настройку выбора берёт на себя фильтр.

Группировка: колонки по смыслу, а не длинный список

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

Что помогает не перегружать навигацию:

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

Промоблоки и баннеры в мегаменю

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

Что уместно в промоблоке мегаменю:

• Хиты и бестселлеры. Блок с ходовыми товарами или разделами ловит тех, кто «просто присматривается», и уводит их в реально покупаемое.
• Акции и распродажи. Аккуратный промо со ссылкой на активную акцию — если акция действительно есть и ведёт в ходовые разделы, а не «висит для вида».
• Новинки. Для магазинов с обновляемым ассортиментом блок новинок в меню помогает постоянным покупателям следить за поступлениями.
• Картинки-категории. Ряд превью популярных разделов — это тоже своего рода промо, но навигационное: оно ускоряет узнавание и переход.

Как не превратить меню в баннер:

• Один блок, а не пять. В панели достаточно одного промоблока; несколько конкурируют между собой и вытесняют навигацию.
• Меньшая доля площади. Промо занимает край панели, а не её центр; основной объём — под разделы.
• Ведёт вглубь, а не в никуда. Клик по промо ведёт в конкретный раздел или на страницу акции, а не на общую заглушку.
• Не тормозит открытие. Картинки промо — лёгкие и по возможности подгружаются лениво, чтобы не задерживать раскрытие панели.

Хиты, новинки и акции — отдельная большая тема: как их формировать, автоматизировать и выводить в каталоге и меню. Мы разбираем её в материале про хиты, новинки и акции в каталоге на 1С-Битрикс. Для навигации же главное правило простое: промоблок — это приправа, а не основное блюдо. Он усиливает меню, помогая покупателю, но не заменяет собой структуру разделов.

Мобильное меню: бургер и аккордеон

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

Что важно в мобильном меню:

• Понятная точка входа. Иконка бургера — крупная и привычная; рядом обычно логотип, поиск и корзина. Это стандартная мобильная шапка, которую узнают без объяснений.
• Раскрытие по шагам. Дерево разделов не вываливают целиком: разделы разворачиваются аккордеоном или открываются «вглубь» с кнопкой «назад», чтобы не заставлять бесконечно скроллить.
• Крупные тап-зоны. Пункты меню — большие, с воздухом между ними; палец не должен промахиваться. Никакой опоры на наведение курсора, которого на телефоне нет.
• Предсказуемое поведение. Меню открывается и закрывается очевидно: понятный крестик, реакция на касание вне панели, без «прыжков» и перекрытия контента.

Мобильная навигация — часть большой темы мобильного UX, где важны и тап-зоны, и sticky-панели, и скорость. Мы разбираем её целиком в статье про мобильную версию магазина на 1С-Битрикс; здесь же подчеркнём: мобильное меню — это не «уменьшенное десктопное», а отдельно спроектированный интерфейс, где мегаменю превращается в аккордеон, а наведение — в тап.

Приоритет пунктов: главное выше

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

Как расставлять приоритеты в мобильном меню:

• Каталог — первым. Основной путь к товарам должен быть в самом верху панели или прямо в шапке отдельной кнопкой.
• Ходовые разделы и акции — выше. То, что реально ищут (популярные категории, распродажи), — в верхней части, а не в хвосте списка.
• Доставка, оплата, контакты — на видном месте. Вопросы, которые определяют решение о покупке, не прячут в самый низ.
• Служебное — вниз. Вакансии, реквизиты, политика, карта сайта — в конце меню или в подвале.

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

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

Поиск как часть навигации

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

Что важно для поиска в навигации:

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

Технически в 1С-Битрикс за поиск отвечают модуль поиска и компоненты вроде search.title (быстрые подсказки в шапке) и страниц результатов. На большом каталоге штатный поиск иногда усиливают внешними движками ради скорости и качества выдачи. Эту тему — как устроен поиск, индексация и ускорение — мы разбираем в отдельном материале про поиск по сайту на 1С-Битрикс и Sphinx. Для навигации же главное: поиск — полноправная её часть, и он должен быть на виду, умным и быстрым.

Хлебные крошки как навигация

Хлебные крошки (breadcrumbs) — цепочка ссылок «Главная → Раздел → Подраздел → Товар» над заголовком страницы. Их часто недооценивают, считая мелочью, но это полноценный навигационный инструмент, который решает сразу несколько задач.

Что дают хлебные крошки:

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

В 1С-Битрикс хлебные крошки выводятся штатно (компонент bitrix:breadcrumb) и обычно уже настроены в типовых решениях: на страницах раздела и товара цепочка строится автоматически по дереву разделов. Задача — не сломать её при кастомизации шаблона и убедиться, что путь корректный: товар ведёт в свой раздел, раздел — в родителя, и так до главной. Полезно также разметить крошки микроразметкой (BreadcrumbList) — это стандартная практика, помогающая поисковику показывать путь в сниппете.

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

Липкое (sticky) меню

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

Что важно в sticky-шапке:

• Компактность. Закреплённая шапка должна быть невысокой, иначе на маленьком экране она съедает место под контент. Часто при прокрутке шапку «ужимают» до логотипа, кнопки каталога, поиска и корзины.
• Ключевые действия под рукой. В липкой шапке держат самое нужное: вход в каталог, поиск, корзину. Не всё меню целиком, а точки входа.
• Не перекрывать якоря и контент. Sticky-шапка не должна наезжать на заголовки при переходе по якорям и на первый экран; для этого закладывают отступы.
• Предсказуемость. Шапка ведёт себя стабильно: не мигает, не прыгает, не появляется-исчезает хаотично при малейшем движении прокрутки.

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

Доступность: клавиатура, фокус и ARIA

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

Что делает меню доступным:

• Клавиатурная навигация. По меню можно двигаться клавишей Tab и стрелками, открывать подменю Enter или стрелкой, закрывать Esc — без мыши. Фокус движется в логичном порядке.
• Видимый фокус. Активный пункт всегда обведён заметной рамкой (outline). Убирать обводку фокуса «ради красоты» — распространённая ошибка, которая ломает клавиатурную навигацию.
• ARIA-разметка. Роли и атрибуты (aria-expanded, aria-haspopup, связи по id) объясняют скринридеру, что перед ним меню, какой пункт раскрыт и что за ним подменю.
• Не только hover. Всё, что раскрывается по наведению, должно раскрываться и по фокусу/клику — иначе меню недоступно ни с клавиатуры, ни с сенсорного экрана.

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

Скорость: кэш меню и ленивая подгрузка

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

Кэш: не собирать меню на каждом хите

Главный рычаг — кэширование. Результат построения меню (особенно обход дерева разделов и сборка мегаменю) сохраняют в кэш и отдают готовым, а пересобирают только при изменении разделов. Кэш привязывают к разделам инфоблока, чтобы он сбрасывался автоматически. Шапку с меню включают в композитный сайт как статическую часть — тогда она отдаётся мгновенно. Правильно закэшированное меню открывается без задержки даже на огромном каталоге.

Ленивая подгрузка мегаменю

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

• Картинки категорий — loading="lazy". Пока панель закрыта, превью не грузятся; они подтягиваются при раскрытии или по мере надобности.
• Содержимое по требованию. В некоторых реализациях само мегаменю (или его тяжёлые части) подгружают по первому наведению/тапу на «Каталог», а не в момент загрузки страницы.
• Лёгкая базовая разметка. Каркас меню (текстовые ссылки) отдают сразу и быстро, а «богатство» (картинки, промо) — вторым слоем.

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

Популярные разделы и персонализация

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

Популярные разделы

Самый безопасный и полезный шаг — отражать в навигации реальный спрос. Разделы, которые открывают чаще и откуда чаще переходят к покупкам, ставят выше и заметнее; в мегаменю их выносят в блок «Популярные категории» с картинками. Это не персонализация в строгом смысле, а настройка приоритета по агрегированным данным — она помогает всем, потому что показывает востребованное на видном месте. Источник данных — аналитика: отчёты по популярным разделам, страницам входа, внутренним переходам.

Персонализация

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

• Не ломать привычную структуру. Персонализация добавляет подсказки поверх стабильного меню, а не тасует разделы так, что покупатель каждый раз ищет их заново.
• Не в ущерб скорости. Персональные блоки — динамические, их выносят из кэшируемой части (или подгружают отдельно), чтобы не ломать кэш всего меню.
• С понятной ценностью. Персонализация должна реально помогать (быстрее находить нужное), а не создавать ощущение слежки без пользы.
• По данным, а не по догадкам. Что выносить и кому — решают на основе аналитики и, при возможности, проверки гипотез, а не интуиции.

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

Реализация в 1С-Битрикс: bitrix:menu и шаблоны

Соберём техническую картину воедино. Навигация магазина на 1С-Битрикс держится на нескольких штатных компонентах, которые кастомизируют через шаблоны, а не через правку ядра.

Ключевые принципы реализации:

• Кастомизация через шаблоны. Мегаменю, мобильный бургер, sticky-шапку верстают в своих шаблонах компонентов в local/templates, а не переписывают ядро. Так навигация переживает обновления платформы.
• Каталожное меню — из инфоблока. Дерево разделов не дублируют руками; пункты берут из инфоблока, чтобы меню синхронно менялось со структурой каталога.
• Кэш обязателен. Построение меню кэшируют и привязывают к разделам; шапку включают в композит. Без кэша меню тормозит на каждой странице.
• Доступность и мобильность — в шаблоне. Клавиатурная навигация, ARIA, аккордеон для телефона, крупные тап-зоны — всё это реализуют в шаблоне и его стилях/скриптах.

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

Путь к товару и оценка навигации

Всё, о чём мы говорили, сходится в одном измеримом показателе — за сколько кликов и как быстро покупатель доходит до товара. Хорошая навигация делает этот путь коротким и понятным на любом сценарии: и через меню, и через поиск, и через популярные разделы.

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

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

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

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

• Огромное мегаменю без группировки. Сотня пунктов сплошным списком без колонок и заголовков — покупатель тонет вместо того, чтобы найти нужное.
• Меню-баннер. Промоблоки и картинки занимают половину панели, а под сами разделы места почти нет; навигация подменена рекламой.
• Слишком глубоко. Четыре-пять уровней прямо в меню; до раздела нужно проваливаться кликами, вместо того чтобы увести детали в фильтр.
• Дерево дублируется вручную. Пункты меню пишут руками отдельно от каталога — и они рассинхронизируются: в каталоге раздел есть, в меню нет, или наоборот.
• Меню без кэша. Дерево разделов обходится на каждом хите, меню тормозит на каждой странице сайта, а причину ищут в каталоге.
• Мегаменю тормозит открытие. Тяжёлые картинки и запросы грузятся синхронно, панель раскрывается с задержкой — покупатель не дожидается.
• Опора на hover. Меню раскрывается только по наведению курсора; на телефоне и с клавиатуры оно недоступно.
• Всё в бургере на мобильном. Даже поиск и корзина спрятаны в меню — до нужного действия лишние касания.
• Мобильное дерево вываливается целиком. Вместо аккордеона по шагам — бесконечный список всех разделов, по которому приходится долго скроллить.
• Нет хлебных крошек или они ведут не туда. Покупатель, пришедший на товар из поиска, теряет ориентацию и не может подняться в раздел.
• Недоступное меню. Убрана обводка фокуса, нет клавиатурной навигации и ARIA — меню не работает без мыши.
• Sticky-нагромождение. Закреплены сразу несколько панелей, и на экране под товар почти не остаётся места.

Чек-лист навигации магазина

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

1. Короткий путь к товару. До нужного раздела — один-три клика через меню, поиск или популярные разделы; не заставляем блуждать.
2. Разделены типы меню. Верхнее (про сайт) и каталожное (про товары) — из разных источников; всё второстепенное — в подвал, а не в шапку.
3. Каталожное меню из инфоблока. Дерево разделов строится из инфоблока автоматически, а не дублируется руками; синхронно с каталогом.
4. Мегаменю сгруппировано. Колонки по смыслу с заголовками, картинки категорий, один аккуратный промоблок — а не баннер вместо навигации.
5. Разумная глубина. Два-три уровня в меню, детали — в странице раздела и умном фильтре; ничего лишнего в дереве.
6. Кэш меню включён. Построение меню кэшируется и привязано к разделам; шапка в композите; меню не пересобирается на каждом хите.
7. Ленивое мегаменю. Тяжёлые картинки и промо подгружаются лениво; базовая навигация открывается мгновенно.
8. Мобильное меню. Бургер + аккордеон, раскрытие по шагам, крупные тап-зоны, поиск и корзина на виду, а не в бургере.
9. Приоритет пунктов. Главное выше: каталог, ходовые разделы, акции, доставка и контакты — на видном месте.
10. Поиск в навигации. На виду, с автоподсказками, ищет по товарам и разделам, по артикулу, быстро откликается.
11. Хлебные крошки. Корректный путь по дереву, разметка BreadcrumbList, удобны и на мобильном.
12. Sticky-шапка. Одна компактная закреплённая шапка с ключевыми действиями; не перекрывает контент и якоря.
13. Доступность. Клавиатурная навигация, видимый фокус, ARIA, работа по тапу — меню доступно без мыши.
14. Кастомизация через шаблоны. Меню сделано в своих шаблонах bitrix:menu в local/templates, ядро не тронуто.
15. Проверено на данных. Популярные разделы вынесены по аналитике; путь к товару и скорость проверены на реальном сайте и устройствах.

Вывод

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

В 1С-Битрикс инструменты для этого есть штатно: компонент bitrix:menu и свои шаблоны, построение каталожного меню из разделов инфоблока, кэш и композит для скорости, хлебные крошки, поиск в шапке. Задача — грамотно собрать их в систему: строить каталожное меню из инфоблока, обязательно кэшировать, группировать разделы по смыслу, делать мегаменю помощником, а не баннером, проектировать мобильное меню отдельно, не забывать про доступность и подгружать тяжёлое лениво. Сделайте это — и навигация перестанет быть местом, где покупатель теряется и уходит, а начнёт стабильно и быстро вести его к товару и заказу.