Проектирование навигационной структуры сайта 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С-Битрикс — фундамент, который определяет производительность и стоимость поддержки. Архитектурные ошибки накапливаются и через год превращаются в капитальный рефакторинг, стоимость которого в разы выше изначального проектирования. По оценкам нашей практики, такой рефакторинг может стоить от 300 000 до 1 000 000 руб., не считая потери выручки во время простоя. Согласно документации, фундаментальные решения по хранению данных и кэшированию закладываются на старте и потом меняются с огромными затратами.

Наш опыт показывает: правильное проектирование на старте экономит до 40% бюджета на разработку. Мы проектируем структуру данных, кэширование, масштабирование и интеграции — с учётом роста нагрузки до 500К товаров и пикового трафика в Черную пятницу. Каждый проект проходит этап нагрузочного тестирования, чтобы избежать сюрпризов в продакшене. Оптимальная архитектура снижает требования к хостингу, экономя от 30 000 до 150 000 руб. в месяц.

Выбор типа хранения: инфоблоки или 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-блоки обязательны для:

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

D7 ORM и свои таблицы — для бизнес-логики, которая не лезет в модель инфоблоков. Связи many-to-many, вычисляемые поля, кастомные агрегации. Bitrix\Main\ORM\Data\DataManager даёт типобезопасность, валидацию и систему событий. Но придётся писать админку с нуля. Подробнее — в документации Bitrix ORM.

Как масштабировать 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 рабочих дней.