Многосайтовость на Битрикс: как вести сеть магазинов из одной админки

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

Что такое многосайтовость на Битрикс и какую задачу она решает

Многосайтовость на Битрикс — это режим работы нескольких витрин (брендов, регионов, языков) на одном ядре и одной базе данных. Управление идёт из общей админ-панели, но у сайтов разные домены или папки, шаблоны, контент и настройки.

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

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

Когда сеть магазинов выгоднее вести на одной установке

Многосайтовость подходит, когда витрины воспринимаются как части одного проекта, а не как чужие друг другу ресурсы. Типичные сценарии:

• несколько брендов с общим складом и общей номенклатурой;
• региональные витрины с разными ценами, условиями доставки и контактами;
• оптовое и розничное направления на одном каталоге;
• языковые версии для разных рынков;
• тематические разделы, которые логичнее вынести на отдельный домен или поддомен.

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

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

Когда лучше делать независимые проекты

Многосайтовость — не универсальное решение. Есть ситуации, когда отдельные установки предпочтительнее, и их стоит честно назвать до старта.

Отдельные проекты разумнее, если:

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

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

Как устроена многосайтовость: общее ядро, общая база, разные витрины

Технически сайт в системе — это учётная запись в базе данных с набором параметров. К основным относятся:

• идентификатор сайта;
• доменное имя (одно или несколько);
• папка сайта — путь к каталогу с публичной частью;
• название сайта и URL сервера по умолчанию;
• адрес электронной почты по умолчанию;
• язык и региональные настройки: форматы даты и времени, первый день недели, формат имени, кодировка, направление текста;
• условия подключения шаблонов оформления.

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

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

Лицензирование и ограничения: что можно и что нельзя

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

Есть и прямой запрет, который важно понимать до проектирования: на одной копии продукта нельзя создавать независимые сайты с отдельной копией ядра, отдельной административной панелью и отдельной базой данных — как на разных серверах, так и на одном.

Технические ограничения архитектуры:

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

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

Как система различает сайты: домены, папки и зеркала

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

Многосайтовость на одном домене

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

Многосайтовость на разных доменах

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

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

Не копируйте общие папки ядра вручную для второго сайта. Это приведёт к конфликтам при обновлении (база данных изменится, а папки останутся старыми) и нарушает лицензионное соглашение.

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

Схема многосайтовости: как выглядит конфигурация

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

Согласуйте схему письменно: она станет основой для оценки стоимости и приёмки работ. Отсутствие схемы до старта — повод уточнить подход подрядчика.

Что это даёт бизнесу

Ценность многосайтовости — не в самой технологии, а в том, как она меняет ежедневную работу.

• Каталог ведётся один раз. Товар заводится в общей номенклатуре и показывается на нужных витринах.
• Обновления применяются один раз на всю сеть, а не отдельно по каждому сайту.
• Запуск новой витрины идёт на готовой основе: не нужно поднимать ещё одну установку и переносить данные.
• Статистику можно смотреть в разрезе по сайтам, оставаясь в единой системе.
• Управление сосредоточено в одной административной панели.

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

Подводные камни и типовые ошибки

Большинство проблем в многосайтовых проектах связано не с технологией, а с решениями, принятыми слишком поздно.

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

Отдельная тема — резервное копирование. В многосайтовой конфигурации копия делается иначе, чем на одиночном сайте, и проверять восстановление нужно с учётом всех витрин. Как это устроено, разбирает материал Резервное копирование сайта на Битрикс — хранение и восстановление.

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

Учебный пример. Данные условные и приведены для иллюстрации логики, а не как статистика.

Входные условия. Компания ведёт три витрины: розничный магазин в Москве, розничный магазин в Санкт-Петербурге и оптовое направление. Каталог общий, склад один, учётная система одна. Цены и условия доставки различаются по регионам, у опта — отдельная логика заказа. Оформление у витрин разное, новости и акции свои.

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

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

Что фиксируется до работ:

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

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

Как проверить решение на своём проекте

Перед тем как принимать решение о многосайтовости, пройдите по списку. Он не требует технических знаний и помогает отделить реальную потребность от модной формулировки.

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

Если хотя бы один пункт вызывает сомнение, это не повод отказываться от идеи, а повод уточнить требования до начала разработки. Переделка после запуска обходится дороже, чем проработка на старте.

Что поручить подрядчику и как принять работу

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

1. Обследование. Подрядчик изучает витрины, каталог, учётные системы и требования к доступу, после чего предлагает режим: одна установка или отдельные проекты. 2. Проектирование. Появляется схема: что общее, что разделяется, как различаются сайты, как устроена авторизация. 3. Реализация. Настройка конфигурации, перенос публичных частей, подключение шаблонов, проверка прав. 4. Проверка. Прогон сценариев по каждой витрине, проверка общих данных и восстановления из копии. 5. Передача. Регламенты правок, доступы, документация по конфигурации.

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

Коротко: что запомнить о многосайтовости

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

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