Проектування навігаційної структури сайту 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 проектів з навігації. Отримайте консультацію, щоб обговорити ваше завдання.

Типові помилки при проектуванні архітектури проектів на 1С-Бітрікс

Ми не раз стикалися з проектами, де неправильна архітектура 1С-Бітрікс призводила до падіння продуктивності. Каталог на 80К товарів віддавав сторінку за 5 секунд — і це при порожньому кеші. Архітектура проектів на 1С-Бітрікс — фундамент, який визначає продуктивність і вартість підтримки. Помилки накопичуються і через рік перетворюються на капітальний рефакторинг, вартість якого в рази вища за початкове проектування. За оцінками нашої практики, такий рефакторинг може коштувати значно, не рахуючи втрати виручки під час простою. Фундаментальні рішення щодо зберігання даних та кешування закладаються на старті — потім змінюються з величезними витратами.

Правильне проектування на старті економить до 40% бюджету на розробку. Ми проектуємо структуру даних, кешування, масштабування та інтеграції — з урахуванням зростання навантаження до 500К товарів та пікового трафіку в Чорну п’ятницю. Кожен проект проходить етап навантажувального тестування, щоб уникнути сюрпризів у продакшені. Оптимальна архітектура знижує вимоги до хостингу, заощаджуючи значну суму щомісяця.

Вибір типу зберігання: інфоблоки або Highload-блоки?

Це перше і найдорожче архітектурне рішення. Міграція з інфоблоків на Highload потім — переписування всіх компонентів, шаблонів, фільтрів та пошукових індексів.

Звичайні інфоблоки працюють через таблиці b_iblock_element і b_iblock_element_property. Властивості зберігаються в EAV-моделі — кожне значення в окремому рядку b_iblock_element_property. При 50 властивостях і 100К елементів отримуємо 5 мільйонів рядків в одній таблиці. MySQL починає задихатися на JOIN-ах при фільтрації.

Інфоблоки гарні для:

• Контенту до 10-50К елементів — статті, новини, акції
• Сутностей, де потрібен візуальний редактор та SEO-модуль
• Елементів з успадкуванням властивостей від розділів

Highload-блоки — плоскі таблиці. Одна сутність — одна таблиця з колонками. Жодного EAV. Фільтрація за індексованими колонками працює на порядок швидше. Каталог на 200К товарів з фасетним індексом (b_catalog_sm_*) віддає фільтр за 50ms замість 3 секунд. Highload-блоки з індексованими колонками фільтрують дані в 10 разів швидше, ніж EAV-модель інфоблоків.

Highload-блоки обов'язкові для:

• Каталоги > 50К товарів
• Довідники, які викликаються при кожному завантаженні (міста, бренди, характеристики)
• Дані з частою записом — логи, заявки, історія
• Сутності, де потрібні прямі SQL-запити та агрегації

D7 ORM та свої таблиці — для бізнес-логіки, яка не вписується в модель інфоблоків. Зв'язки many-to-many, обчислювані поля, кастомні агрегації. Bitrix\Main\ORM\Data\DataManager дає типобезпеку, валідацію та систему подій. Але доведеться писати адмінку з нуля.

Як масштабувати 1С-Бітрікс без втрати продуктивності?

Горизонтальне масштабування — тема, на якій горять 90% проектів. Однак думають про нього, коли сайт вже лежить.

Перший крок — сесії з файлів у Redis. Без цього другий веб-сервер марний: користувач авторизувався на сервері A, наступний запит йде на сервер B, сесію не знайдено — розлогін. У .settings.php:

'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]]

Далі:

• nginx upstream або HAProxy розподіляє запити. Модуль «Веб-кластер» Бітрікс підтримує кластеризацію, але потрібна ліцензія «Бізнес» або вище
• CDN для статики — /upload/, JS, CSS. Сервер перестає витрачати ресурси на віддачу зображень
• Реплікація MySQL — master для запису, slave для читання. Бітрікс підтримує до 9 slave-з'єднань через налаштування в .settings.php. Але є лаг реплікації — товар додали, а на slave він з'явиться через 0.5-2 секунди

Вертикальне масштабування — дешевше і швидше на старті:

• EXPLAIN на кожен важкий запит. Один складовий індекс на b_iblock_element_property (IBLOCK_PROPERTY_ID, VALUE) прискорює фільтрацію в 10 разів
• Багаторівневий кеш: керований кеш Бітрікс → memcached → композитний сайт. Перевіряємо hit rate в панелі «Продуктивність» — якщо нижче 90%, щось не так
• OPcache з JIT на PHP 8.1+ — безкоштовне прискорення на 15-30%

Коли варто виносити процеси з моноліту?

Бітрікс — моноліт, і це нормально. Ламати його на мікросервіси — безумство. А от винести важкі процеси — правильний хід.

Імпорт/експорт — найчастіший біль. Обмін з 1С через CIBlockCMLImport блокує таблиці інфоблоків на час імпорту. 100К товарів — це 20-40 хвилин, коли фільтрація на сайті гальмує. Рішення: винести імпорт в окремий воркер через RabbitMQ, писати в проміжну таблицю, потім атомарно перемикати.

• Пошук — Elasticsearch замість штатного search.title. Повнотекстовий та фасетний пошук, автодоповнення, виправлення помилок. Навантаження з MySQL знімається повністю
• Сповіщення — push, SMS, email через чергу. CEvent::Send() синхронний — поки лист не піде, користувач чекає відповідь сервера. Черга вирішує це
• Генерація звітів — PDF, Excel на великих обсягах. В окремий процес, результат — посилання на завантаження

API: REST, GraphQL, вебхуки

REST API Бітрікса (/rest/) покриває CRM, завдання, диск, але не покриває каталог та інфоблоки в потрібному обсязі. Для SPA на React/Vue доводиться писати свої ендпоінти через Bitrix\Main\Engine\Controller.

• GraphQL — для мобільних додатків, де трафік дорогий. Клієнт запитує тільки потрібні поля
• Вебхуки — подієва модель: нове замовлення → POST на зовнішній URL. Не потрібно опитувати API кожні 5 хвилин
• Версіонування — /api/v1/, /api/v2/. Без цього оновлення API ламає всіх споживачів одночасно
• OpenAPI/Swagger — автогенерація документації. API без документації через місяць не пам'ятає навіть автор

Як уникнути дорогого рефакторингу?

Найдієвіший спосіб — приймати архітектурні рішення усвідомлено, з урахуванням реальних сценаріїв навантаження та зростання даних. Ми використовуємо підхід ADR (Architecture Decision Records) для фіксації кожного рішення — контекст, альтернативи, наслідки. Це дозволяє новим розробникам входити в проект за дні, а не тижні, та виключає двояке тлумачення логіки через півроку.

Документація: ADR замість Word-файлів

• ADR — Architecture Decision Records. Короткий файл: контекст, рішення, наслідки. Як показує практика, фіксація архітектурного рішення в момент його прийняття рятує від нескінченних здогадок через півроку. Наприклад, через рік новий розробник відкриє ADR і за п'ять хвилин зрозуміє, чому для каталогу обрали Highload, замість гадати три дні
• Діаграми — сервери, потоки даних, точки інтеграцій. PlantUML або Mermaid, зберігаються в репозиторії поруч з кодом
• ER-діаграми — інфоблоки, властивості, зв'язки. Без схеми навіть автор через півроку не згадає, чому властивість LINKED_PRODUCTS посилається на інший інфоблок через прив'язку, а не через Highload-довідник
• Runbook — деплой, відкат, масштабування, дії при аварії. Бо аварія станеться в суботу вночі, коли архітектор не на зв'язку

Техборг: старе ядро, прямі SQL, логіка в шаблонах

Техборг в Бітріксі специфічний. Три головних джерела:

1. Старе ядро замість D7 — CIBlockElement::GetList() замість \Bitrix\Iblock\Elements\ElementTable::getList(). Старе ядро не підтримує ORM-фічі, повільніше, і Бітрікс рано чи пізно його задепрекейтить
2. Прямі SQL в шаблонах компонентів — $DB->Query("SELECT...") прямо в template.php. Переносимо в сервісні класи, замінюємо на ORM
3. Бізнес-логіка в result_modifier.php — файл, який повинен готувати дані для шаблону, а не рахувати знижки та перевіряти права доступу

Підхід: PHPStan level 5+ для виявлення проблем, матриця «вплив на бізнес / вартість фікса», поетапний рефакторинг по спринтах. Не все одразу — але тренд повинен бути низхідним.

Як ми проектуємо архітектуру

1. Аналіз бізнес-вимог та навантажувальних характеристик (піковий RPS, розмір каталогу, типові сценарії)
2. Проектування структури даних — вибір інфоблоки/Highload/D7 ORM, зв'язки, індекси
3. Визначення схеми кешування та черг (Redis, RabbitMQ, композит)
4. Прототипування та навантажувальне тестування на реальних даних (200К записів, 30+ властивостей)
5. Документування — ADR, ER-діаграми, runbook, специфікації API
6. Рев'ю проекту — внутрішнє та з замовником

Для одного інтернет-магазину ми спроектували архітектуру на Highload-блоках та Elasticsearch. Фільтрація товарів до 50 мс, час першого байта 0.3 с. Економія на хостингу — суттєва.

Що входить в роботу

Ми — команда сертифікованих спеціалістів з досвідом впровадження 1С-Бітрікс понад 8 років. Виконали архітектуру для 50+ проектів з каталогами до 300К товарів та навантаженням до 10К одночасно активних користувачів. Гарантуємо, що спроектована архітектура витримає пікові навантаження і не потребуватиме рефакторингу в найближчі 3 роки.

На виході: архітектурний документ (ADR, ER-діаграми, runbook), прототип критичних вузлів (опціонально), документація по API, рекомендації щодо кешування та масштабування.

Якщо ваша архітектура викликає сумніви або ви готуєтеся до зростання трафіку — зв'яжіться з нами для консультації. Ми проведемо аудит поточної структури і запропонуємо оптимальну стратегію. Замовте комерційну пропозицію — ми підготуємо її протягом 2 робочих днів. Щоб отримати персональну консультацію щодо вашого проекту, напишіть нам — розкажемо, які архітектурні рішення підійдуть саме вам.