Многосайтовость Битрикс: общее ядро и разные витрины

Редакция Romanov Lab · Опубликовано 13 октября 2026

Две витрины могут отличаться логотипом и адресом, но зависеть от одного обновления модуля, одной базы и одной ошибки обработчика. Это ключевой вопрос при выборе многосайтовости. Она удобна, когда общие данные и единая команда действительно нужны. Если независимость проектов важнее совместного управления, экономия на первоначальной настройке может обернуться сложным обслуживанием.

Что именно объединяет многосайтовость

В Битрикс несколько сайтов могут работать в одной установке с общей базой, ядром и модулями. Публичные адреса размещают в подпапках одного домена либо на разных доменах. Система различает сайты по настройкам домена и папки. Общая схема описана в руководстве по многосайтовости.

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

Не выбирайте архитектуру по одному признаку «контент похож». Спросите, могут ли команды согласовывать обновления, кто принимает общее окно работ, допустимы ли общие администраторы и как будут восстанавливать данные. Если владельцы требуют независимого выпуска и строгой границы доступа, рассмотрите отдельные установки и явный обмен общими данными.

Учебный пример: розница и дилерская витрина

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

• Общие данные: технические свойства моделей, документы, базовые изображения, справочники.
• Данные витрины: рекламные тексты, меню, контакты отдела, подборки, условия обслуживания.
• Правила продажи: типы цен, доступность покупки, минимальные количества, способы оплаты и доставки.
• Пользовательские данные: регистрация, принадлежность к дилерской группе, заказы и право просмотра документов.
• Эксплуатация: обновления модулей, резервирование, журналы, фоновые задания и ответственные.

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

Составьте паспорт каждой витрины

У каждой витрины должны быть явно записаны идентификатор сайта, домены, публичная папка, шаблон, язык, адрес отправителя и ответственные. Справка по объекту «Сайт» описывает отдельную запись сайта и его настройки. Сохраните паспорт в проектной документации вместе со схемой размещения; одних заметок в панели хостинга недостаточно.

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

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

Общий контент требует правил публикации

Один инфоблок с техническими данными уменьшает дублирование, но не отвечает на вопрос, где показывать запись. Ассортимент может совпадать лишь частично. Заведите понятное правило включения в каждую витрину и проверьте, что оно применяется в списке, карточке, поиске, рекомендациях и выгрузках.

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

Обратная крайность — две полные копии каталога с ручным обновлением. Она уменьшает случайные пересечения, но создаёт риск расхождения характеристик и документов. Выбор между общими и отдельными записями делайте для каждого типа данных. У рекламных материалов и технических паспортов разные требования к совместному использованию.

Проверяйте переходы и пользовательский контекст

Авторизация, корзина и восстановление доступа должны иметь согласованное поведение при переходе между витринами. Возможность общей идентификации пользователя описана в руководстве по многосайтовости, но проекту всё равно нужна собственная приёмка. Не обещайте одинаковое поведение во всех браузерах без теста фактической схемы доменов.

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

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

Обновления и восстановление планируйте для всей установки

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

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

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

Приёмочный список для второй витрины

1. Каждый разрешённый домен и путь открывает нужный сайт и шаблон.
2. Контакты, ссылки и отправитель писем соответствуют витрине.
3. Права проверены прямым доступом к объекту и запросам, а не только видом меню.
4. Выборка ассортимента согласована во всех публичных компонентах.
5. Прогретый кэш не переносит сведения между витринами.
6. Фоновые операции используют явный контекст и правильного получателя.
7. Общий выпуск проходит проверки всех сайтов, а восстановление учитывает их новые данные.

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