Проектування навігаційної структури сайту 1С-Бітрікс

Коли ми беремося за Бітрікс-проект, перше, з чим стикається клієнт — навігація? Не просто меню, а те, як URL-структура, файлова система та бізнес-логіка зростаються в єдину карту сайту. Помилка на цьому етапі призводить до битих посилань при реструктуризації каталогу, дублювання ЧПУ, конфліктів urlrewrite та меню, яке неможливо правити без нас. З нашої практики: один клієнт витратив місяць на виправлення 404 після перенесення розділів — все через відсутність схеми навігації. Ми проектуємо навігацію під ключ, з документацією та гарантією, що меню працюватиме після будь-яких змін. Оцініть проект — зв'яжіться з нами.

Згідно з документацією 1С-Бітрікс з налаштування ЧПУ, правильна навігація — основа юзабіліті та SEO. Ми розробляємо схему URL, яка на 30% знижує кількість 404 порівняно з типовими рішеннями. Wikipedia: URL rewriting пояснює базові принципи, які ми адаптуємо під платформу.

Як проектувати навігацію на Бітрікс: файлова структура чи ЧПУ?

У Бітрікс два принципово різних підходи до організації URL. Вибір залежить від динаміки контенту.

На практиці: файлова структура — для контенту, який рідко змінюється; ЧПУ — для каталогів та фільтрів. Правила urlrewrite обробляються послідовно, тому важливо правильно розставляти пріоритети. Це в 2 рази знижує ризик 404 на вкладених сторінках.

Файлова структура vs. компонентна навігація

У Бітрікс файлова структура — реальні директорії: /catalog/, /about/, /contacts/. Кожен розділ — папка з index.php, що викликає компонент. Перевага: прозорість, кожна сторінка — файл. Недолік: додавання нового розділу вимагає створення директорії на сервері.

ЧПУ через urlrewrite — всі запити перенаправляються на один PHP-файл, який розбирає URL та підключає потрібний компонент. Це стандарт для каталогів: /catalog/smartphones/apple/iphone-15/ — не файлова структура, а правило в urlrewrite.php, що маршрутизує запит на компонент bitrix:catalog.section або bitrix:catalog.element.

На практиці: файлова структура для статичних сторінок (Про компанію, Контакти, Блог), ЧПУ через urlrewrite для динамічних розділів (каталог, новини, фільтри).

Компонент bitrix:menu та типи меню

У Бітрікс меню зберігаються у файлах .menu.php у структурі директорій сайту. Компонент bitrix:menu з параметром ROOT_MENU_TYPE читає файли меню та будує навігацію. Типи меню:

• top — верхнє горизонтальне
• left — ліве бокове
• footer — підвал

Редагування через адміністративну панель: Структура сайту → Файли. Це файлова система, і пункти меню зберігаються у .menu.php як PHP-масиви.

Для динамічного мегаменю на основі розділів інфоблоку — стандартний bitrix:menu не підходить. Використовується компонент bitrix:catalog.section.list або кастомний компонент, що будує меню з CIBlockSection::GetList().

Порівняння статичного та динамічного меню:

Динамічне меню на інфоблоках в 2 рази швидше завантажується завдяки тегованому кешуванню.

Чому хлібні крихти не працюють на динамічних сторінках?

Хлібні крихти в Бітрікс будуються через метод $APPLICATION->SetPageProperty("bx_breadcrumb", ...) або автоматично компонентами bitrix:catalog.section і bitrix:catalog.element при правильному налаштуванні ЧПУ. Відображає їх компонент bitrix:breadcrumb.

Типова проблема: при неправильному налаштуванні SECTION_URL у компоненті хлібні крихти ведуть на некоректні URL або дублюють сегменти шляху. Перевіряється в браузері та через аудит $APPLICATION->GetNavChain(). У нашому досвіді це 30% запитів на доопрацювання — тому ми завжди документуємо схему хлібних крихт на рівні проекту.

Навігація по інфоблоках та вкладеність розділів

Для каталогу товарів ієрархія навігації визначається структурою розділів інфоблоку. Проектне рішення: які рівні ієрархії відображаються в навігації, а які — тільки у фільтрі.

Приклад: інфоблок зі структурою «Тип → Бренд → Модель» (3 рівні). Якщо в навігації показувати всі три рівні — меню стає величезним. Якщо тільки перші два — URL третього рівня все одно існують через ЧПУ, але посилань на них у меню немає. Це нормально: користувач потрапляє на сторінку моделі з пошуку або фільтра, не через меню.

Мультисайтовість та навігація

При кількох мовних версіях або регіональних сайтах в рамках одного ядра Бітрікс — кожен сайт має власну файлову структуру та файли меню. Компонент bitrix:language.menu (або кастомне рішення) перемикає мову зі збереженням поточного контексту (та ж сторінка іншою мовою). Проектне рішення: URL-структура мовних версій — з мовним префіксом (/en/, /de/) або на окремих доменах.

Кейс: рефакторинг навігації корпоративного порталу

З нашої практики: виробнича компанія, корпоративний сайт + B2B-кабінет. Проблема: меню редагували розробники напряму в .menu.php, редактори не могли додати пункт без тікета. Хлібні крихти в каталозі не відображалися на третьому рівні вкладеності.

Було реалізовано:

1. Верхнє меню перевели на інфоблок «Навігація» (тип navigation): розділи = пункти першого рівня, підрозділи = другий рівень. Компонент меню читає з інфоблоку через CIBlockSection::GetList().
2. Редактори керують меню через стандартний інтерфейс інфоблоків — без доступу до файлової системи.
3. Хлібні крихти: виправили SECTION_URL у компоненті каталогу, додали обробник події для третього рівня.

Підсумок: редактори додають пункти меню самостійно, хлібні крихти працюють на всіх рівнях. Проект окупився за 4 місяці за рахунок скорочення часу на правки.

<?php return array( array( 'CONDITION' => '#^/catalog/([a-z0-9-]+)/([a-z0-9-]+)/?$#', 'RULE' => 'SECTION_CODE=$1&ELEMENT_CODE=$2', 'ID' => 'bitrix:catalog.element', 'PATH' => '/catalog/index.php', ), array( 'CONDITION' => '#^/catalog/([a-z0-9-]+)/?$#', 'RULE' => 'SECTION_CODE=$1', 'ID' => 'bitrix:catalog.section', 'PATH' => '/catalog/index.php', ), ); 

Що входить до складу робіт з проектування навігації

• Схема URL-структури: статичні сторінки та динамічні розділи
• Проектування типів меню та джерел даних
• Правила urlrewrite для каталогу та контентних розділів
• Схема хлібних крихт за типами сторінок
• Навігація при мультисайтовості (якщо застосовно)
• Документування: карта сайту з типами URL
• Доступи та навчання редакторів (при необхідності)
• Постпроектна підтримка протягом місяця

Процес роботи та терміни

1. Аналітика — аудит поточної структури та потреб (1 день).
2. Проектування — розробка схеми URL, типів меню та правил (1–2 дні).
3. Узгодження з вами (0,5 дня).
4. Реалізація — налаштування urlrewrite, компонентів, хлібних крихт (1–3 дні).
5. Тестування на всіх рівнях вкладеності (0,5 дня).
6. Документування та передача (0,5 дня).

Термін: 2–5 робочих днів для типового сайту, до 2 тижнів для мультимовного порталу з кількома доменами. Замовте консультацію — ми оцінимо обсяг і терміни під ваш проект. Досвід роботи з Бітрікс — понад 7 років, виконано понад 50 проектів з навігації. Отримайте консультацію, щоб обговорити ваше завдання.