Многосайтовость на 1С-Битрикс: несколько сайтов на одном ядре

Бизнес растёт, и однажды один сайт превращается в два: к рознице добавляется опт, к основному бренду — второй, к русской версии — англоязычная, к головному магазину — региональные витрины. Возникает вопрос: заводить отдельную установку под каждый сайт и потом мучиться с синхронизацией каталога и клиентов — или собрать всё на одном ядре? 1С-Битрикс отвечает на это механизмом многосайтовости: несколько самостоятельных сайтов работают на одной установке, одной базе и под одной панелью управления.

Эта статья — разбор многосайтовости на Битриксе для тех, кто проектирует такую систему или разбирается в готовой. Пройдём по всему: что такое несколько сайтов на одном ядре и одной БД, чем отличаются два режима (на разных доменах и в разных папках), как обстоит дело с лицензированием («два сайта одна лицензия» — обзорно, со ссылкой на условия), где контент общий, а где раздельный, как работает привязка инфоблоков к сайту через LID, как устроить единый каталог для нескольких витрин (розница и опт, B2C и B2B), общие или раздельные пользователи и заказы, разные шаблоны и настройки, домены и языки, а также SEO мультисайта и частые ошибки. Материал — выжимка из наших проектов по разработке мультимагазина на 1С-Битрикс.

Зачем нужна многосайтовость и кому она подходит

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

Типичные сценарии, где многосайтовость оправдана:

• Розница и опт. Один товарный каталог, но два лица: розничная витрина для физлиц и оптовый B2B-портал с другими ценами и правилами.
• Несколько брендов одной компании. Разные домены и дизайн, но общая команда, общие клиенты и единое администрирование.
• Языковые версии. Русская и англоязычная версии как отдельные сайты со своими переводами и доменами.
• Региональные витрины. Версии под города с разными ценами, складами и контактами, живущие на общем ядре.
• Основной сайт и лендинги/поддомены проектов, которым нужна общая база и единое обновление.

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

Что такое многосайтовость: одно ядро и одна база

Технически многосайтовость означает, что один установленный экземпляр 1С-Битрикс обслуживает несколько сайтов. «Один экземпляр» — это одна папка ядра (bitrix), одна база данных, один набор модулей и одна административная панель. Поверх этого единого фундамента живут несколько сайтов, каждый со своими настройками, дизайном и адресом.

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

Именно этот раздел на «общее» и «своё» — ключ к пониманию всей многосайтовости. Как только вы держите в голове, что база и ядро одни, а сайтов много, становятся очевидны и главные плюсы (обновляем один раз, данные ведём в одном месте), и главные риски (сбой общего слоя бьёт по всем сайтам, и контент легко перемешать при неверной привязке). Всё дальнейшее в статье — детализация того, что именно попадает в общий слой, а что настраивается на каждый сайт.

Один экземпляр, много сайтов: как это работает

Разберём механику определения сайта. При каждом запросе платформа должна понять, какой из нескольких сайтов сейчас отдать посетителю. Делает она это по двум признакам в зависимости от режима: по имени домена (для режима разных доменов) или по началу пути в адресе (для режима папок). Определив активный сайт, ядро подставляет его настройки: шаблон, набор привязанных данных, параметры модулей.

Каждый сайт в системе описан набором параметров. Ключевые из них:

• Идентификатор (LID) — короткий код сайта (s1, s2), которым помечаются все привязки.
• Доменные имена — список хостов, по которым узнаётся этот сайт.
• Путь к корню сайта (DOCUMENT_ROOT/DIR) — где физически лежат публичные файлы сайта.
• Шаблон сайта — какое оформление применять, с правилами по условию.
• Язык и кодировка, формат даты, символ валюты по умолчанию и прочие локальные настройки.

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

Два режима: на разных доменах и в разных папках

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

Коротко: если сайтам нужны отдельные домены (разные бренды, языковые или региональные версии с собственными адресами) — это режим разных доменов. Если несколько логических сайтов должны жить под одним доменом в разных разделах — это режим папок. Ниже разберём каждый подробнее, потому что у них разная настройка веб-сервера и разные последствия для SEO.

Режим на разных доменах

В режиме разных доменов каждый сайт получает собственный домен, а его публичные файлы лежат в отдельной корневой папке. Для посетителя это полностью независимые сайты: site-a.ru и site-b.ru открываются со своих главных, у каждого свой корень «/». Платформа определяет активный сайт по имени хоста, с которым пришёл запрос.

Ключевой момент — настройка веб-сервера. Оба (или все) домена должны указывать на одну установку Битрикса, но при этом корневой каталог каждого домена нужно направить в папку соответствующего сайта, а ядро (/bitrix/) сделать общим для всех через символические ссылки или алиасы. Упрощённо конфигурация выглядит так:

# Домен A → своя корневая папка, общее ядро
server {
    server_name site-a.ru;
    root /var/www/project/site_a;   # публичные файлы сайта A
    # /bitrix — симлинк на общее ядро установки
}

# Домен B → своя корневая папка, то же общее ядро
server {
    server_name site-b.ru;
    root /var/www/project/site_b;   # публичные файлы сайта B
    # /bitrix — тот же общий симлинк
}

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

Режим в разных папках одного домена

В режиме папок все сайты живут под одним доменом, но в разных подкаталогах: site.ru/shop/ — один сайт, site.ru/corp/ — другой. Платформа определяет активный сайт по началу пути в URL: запрос в /shop/… отдаёт первый сайт, в /corp/… — второй. Корнем каждого сайта служит его подкаталог, а не «/».

Настройка веб-сервера здесь проще: домен один, отдельные хосты не нужны. Но появляется нюанс с корнем домена — сам site.ru/ должен куда-то вести (обычно на один из сайтов как основной или на страницу выбора). Публичные файлы каждого сайта лежат в своей папке-подкаталоге, а ядро по-прежнему общее.

Режим папок выбирают, когда несколько логических сайтов должны оставаться под одним доменом. Классический пример — большой портал, где под общим адресом соседствуют несколько разделов-«сайтов» со своей логикой. Но для магазинов этот режим применяют реже: чаще опт и розницу или бренды всё же хотят видеть на отдельных доменах. Важное следствие для SEO: поисковик воспринимает папки как разделы одного сайта, а не как разные сайты, — и это иногда именно то, что нужно, а иногда, наоборот, мешает разводить проекты.

Лицензирование: сколько сайтов на одну лицензию

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

Общий ориентир, который стоит держать в голове при проектировании:

• Младшие редакции обычно рассчитаны на один сайт в рамках лицензии.
• Старшие редакции допускают несколько сайтов на одном ядре — именно они и предназначены для многосайтовых проектов.
• Точное число и условия — вопрос текущей лицензионной политики вендора для конкретной редакции.

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

LID: идентификатор сайта и привязки

Центральное понятие всей многосайтовости — LID, идентификатор сайта. Это короткий код (s1, s2 и так далее), который платформа присваивает каждому сайту. Смысл LID в том, что практически любой объект в системе можно привязать к одному или нескольким сайтам через этот код — и именно привязки определяют, что где показывается.

Что помечается через LID:

Из этой таблицы видно, насколько LID пронизывает систему. Он же — источник самой частой проблемы многосайтовости: если объект привязан не к тому сайту (или сразу к обоим по недосмотру), контент «перетекает» между сайтами. Инфоблок случайно привязали к обоим сайтам — товары одного всплыли на другом. Компонент вызвали без фильтра по текущему LID — вывелись чужие данные. Поэтому дисциплина привязок — не бюрократия, а фундамент чистоты мультисайта.

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

<?php
// Текущий сайт (LID) из контекста
$siteId = \Bitrix\Main\Context::getCurrent()->getSite();  // напр. 's1'

// Выбор новостей только текущего сайта — привязка через LID инфоблока
$res = CIBlockElement::GetList(
    ['SORT' => 'ASC'],
    [
        'IBLOCK_ID'  => $newsIblockId,
        'ACTIVE'     => 'Y',
        'LID'        => $siteId,   // фильтр по сайту, чтобы не смешать контент
    ]
);

Общий и раздельный контент: инфоблоки и разделы

Главное проектное решение в многосайтовости — какой контент общий, а какой раздельный. Механизм один и тот же (привязка по LID), но результат разный: инфоблок, привязанный к нескольким сайтам, — общий контент; привязанный к одному — раздельный. Комбинируя привязки, вы строите нужную конфигурацию.

Правильная конфигурация вытекает из бизнес-логики. Если сайты — это розница и опт одного бренда, каталог логично сделать общим (товары те же, различаются цены и правила). Если это два разных бренда с непересекающимся ассортиментом, каталоги делают раздельными. Между этими полюсами — множество промежуточных вариантов: общий каталог, но своя лента новостей у каждого сайта; общий товарный справочник, но разные разделы-витрины.

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

Единый каталог для нескольких витрин

Самый ценный сценарий многосайтовости для магазинов — единый каталог, несколько витрин. Товары ведутся в одном месте (один инфоблок каталога), обмен с 1С идёт в один справочник, а показываются эти товары на нескольких сайтах-витринах, каждая со своим лицом. Это избавляет от боли синхронизации: не нужно копировать товары между установками и следить, чтобы остатки и цены сходились.

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

• Цены. Разные типы цен на один товар: розничная — для B2C-витрины, оптовая — для B2B-портала. Витрина показывает свой тип цены.
• Наборы разделов. Одна витрина раскрывает один набор категорий, другая — свой, хотя справочник товаров общий.
• Шаблоны вывода. Своя вёрстка карточки и списка на каждой витрине через шаблоны компонентов.
• Доступность и правила. Часть товаров можно скрывать на одной витрине и показывать на другой — свойствами и фильтрами.

Именно так устроены большинство связок «розница + опт» на Битриксе: один товарный движок, две витрины. Как строить сам единый справочник с торговыми предложениями, свойствами и разными витринами — тема нашего разбора про многоязычный каталог в 1С-Битрикс, где принципы общего каталога для разных версий разобраны детально и хорошо переносятся на мультисайт.

Опт и розница, B2C и B2B как разные сайты

Разберём связку «розница + опт» подробнее, потому что это самый частый мультисайт в e-commerce. Идея в том, чтобы оформить B2C-магазин и B2B-портал как два сайта на одном ядре с общим каталогом. Посетитель попадает на розничную витрину со своими ценами и оформлением; оптовый клиент — на B2B-портал с оптовыми ценами, условиями и, возможно, закрытой авторизацией.

Что при этом делают общим, а что разделяют:

• Каталог — общий. Один товарный справочник, привязанный к обоим сайтам. Обмен с 1С идёт в один инфоблок.
• Цены — раздельные типы. Розничная цена на B2C, оптовая — на B2B; товар один, цен несколько.
• Оформление и логика заказа — своё. На B2B — оптовые правила, минимальные партии, отсрочка; на B2C — обычная корзина.
• Клиенты — по модели. Либо общий кабинет (розничный клиент может стать оптовым), либо строгое разделение групп.
• Дизайн — свой на каждый сайт. B2B часто строже и «функциональнее», B2C — маркетингово ярче.

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

Пользователи: общие или раздельные

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

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

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

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

Заказы и корзина в мультисайте

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

Отсюда вытекают практические возможности:

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

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

Разные шаблоны и настройки на каждый сайт

Хотя ядро общее, внешне сайты могут не иметь ничего общего — за это отвечают шаблоны сайта и настройки на уровне LID. Каждому сайту назначается свой шаблон оформления (или несколько с правилами применения по условию), поэтому розничная витрина и оптовый портал выглядят и ведут себя по-разному, оставаясь на одном ядре.

Что настраивается индивидуально на каждый сайт:

• Шаблон оформления — своя шапка, подвал, стили, сетка. Технически это разные папки шаблонов, назначенные разным сайтам.
• Название сайта, логотип, контакты — через настройки сайта и включаемые области.
• Язык, кодировка, формат даты, валюта — локальные параметры сайта.
• Часть настроек модулей — значения, которые модуль хранит per-site (например, параметры магазина, почтовые события).
• Меню и структура — свои файлы меню в папке каждого сайта.

Как именно устроены шаблоны сайта и шаблоны компонентов — отдельная большая тема; если нужно освежить, у нас есть подробный разбор про шаблоны и компоненты 1С-Битрикс. В контексте многосайтовости важно помнить: шаблон — это «лицо» сайта, и именно назначением разных шаблонов разным LID вы делаете сайты визуально независимыми. При этом компоненты и их логика — общие из ядра, различается только вёрстка и параметры вызова на каждом сайте.

Домены, языки и кодировки

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

Ключевые параметры на уровне сайта:

Отдельно стоит различать «язык сайта» в смысле локализации интерфейса и «языковую версию контента». Язык сайта задаёт, на каком языке выводятся системные сообщения и подписи из языковых файлов. А вот сам контент (тексты страниц, названия товаров) на каждой языковой версии ведут отдельно — обычно через раздельные инфоблоки или разделы, привязанные к нужному сайту. То есть многосайтовость даёт каркас для мультиязычности, но наполнение переводами — это уже работа с контентом, а не только настройка сайта.

Связь с мультиязычностью и мультирегиональностью

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

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

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

Если же речь именно о полноценных региональных сайтах с раздельным контентом и настройками, это отдельная услуга — мультирегиональный сайт на 1С-Битрикс, где мы проектируем связку регионов под конкретный бизнес: где хватит поддоменов, а где нужна полноценная многосайтовость.

SEO многосайтовости

Для поисковой оптимизации выбор режима многосайтовости имеет прямые последствия, и их важно понимать заранее. Главный принцип: разные домены поисковик воспринимает как разные сайты, а папки одного домена — как разделы одного сайта. Это определяет и стратегию продвижения, и риски.

Что это значит на практике:

• Режим разных доменов = разные сайты для поиска. Каждый домен индексируется и ранжируется самостоятельно, набирает свой траст и ссылки. Это плюс, когда сайты действительно разные (бренды, регионы), и требует отдельной SEO-работы по каждому.
• Режим папок = один сайт для поиска. Все разделы делят авторитет одного домена. Подходит, когда витрины — части одного проекта, а не самостоятельные бренды.
• Риск дублей. Если на разных сайтах общий каталог с одинаковыми текстами и товарами, важно не создать дублирующийся контент между доменами — нужны уникализация, корректные canonical и разведение по назначению витрин.
• Технические сигналы per-site. У каждого сайта свои robots, sitemap, микроразметка, счётчики — их настраивают раздельно по сайтам.

Особое внимание — общему каталогу на разных доменах. Когда один товарный справочник питает две витрины на разных доменах, есть риск, что поисковик увидит одинаковые карточки товаров на двух сайтах. Для розницы и опта это обычно не проблема (аудитории и запросы разные), но требует продуманной работы с мета-тегами и уникальным контентом витрин. Тонкости продвижения региональных и многодоменных конфигураций мы разбираем в материале про мультирегиональность, поддомены и SEO.

Администрирование и обновление одного ядра

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

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

Но у этой медали есть обратная сторона — связанность, и её нужно осознавать:

• Обновление затрагивает все сайты. Если апдейт что-то сломал, проблема появляется сразу на всех сайтах — тестировать нужно тщательно, желательно на копии.
• Сбой ядра или сервера роняет все сайты. Общая инфраструктура — общая точка отказа. Резервирование и мониторинг критичны.
• Ошибка в общем коде видна везде. Правка компонента или события, общего для сайтов, влияет на все витрины.
• Нагрузка общая. Пиковый трафик одного сайта расходует ресурсы, которые делят все.

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

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

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

Логика выбора сводится к двум осям: насколько сайты делят данные и насколько они делят команду и обновления. Чем сильнее пересечение по каталогу, клиентам и людям — тем весомее многосайтовость: одно ядро экономит на поддержке, а общие данные не надо синхронизировать. Чем автономнее сайты (разный бизнес, разные команды, отдельные требования к безопасности и релизам) — тем сильнее аргументы за отдельные установки, где сбой и обновление одного сайта не касаются другого.

Отдельная развилка — регионы. Если региональные версии различаются только ценами, складом и контактами при общем контенте, обычно выгоднее поддомены на одном сайте, а не полноценная многосайтовость: меньше сущностей и проще поддержка. Полноценные сайты на регион нужны, когда у каждого региона свой ассортимент, дизайн и логика. Именно этот выбор мы помогаем сделать в рамках мультирегионального сайта на 1С-Битрикс — под конкретный бизнес, а не по шаблону.

Порядок настройки многосайтовости

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

1. Проверьте лицензию. Убедитесь, что редакция и условия лицензии покрывают нужное число сайтов. Это первый и обязательный шаг.
2. Выберите режим. Разные домены или разные папки — исходя из задач и SEO-стратегии. Решение влияет на всю дальнейшую настройку.
3. Создайте сайт в админке. Заведите новый сайт: задайте LID, домены, путь к корню, язык, кодировку, валюту.
4. Назначьте шаблон. Создайте или подключите шаблон оформления для нового сайта и правила его применения.
5. Настройте веб-сервер. Для доменов — хосты и симлинки на общее ядро; для папок — правила по пути. Проверьте доступ к /bitrix/ и /upload/.
6. Разложите публичные файлы. Создайте корневую папку сайта с индексом, разделами и меню.
7. Настройте привязки контента. Привяжите инфоблоки к нужным сайтам (общие — к нескольким LID, раздельные — к своему), проверьте разделы.
8. Настройте модули per-site. Магазин, почтовые события, формы — задайте значения для нового сайта, где это требуется.
9. Проверьте изоляцию. Убедитесь, что контент одного сайта не всплывает на другом: пройдитесь по привязкам и фильтрам компонентов по LID.
10. Настройте SEO per-site. Свои robots, sitemap, мета-теги, счётчики для каждого сайта.

Особое внимание — шагам 7 и 9. Именно неверные привязки и отсутствие проверки изоляции дают самую частую проблему многосайтовости — перемешанный контент. Лучше потратить время на аккуратную настройку привязок и их проверку, чем потом ловить «чужие» товары и тексты на живом сайте.

Частые ошибки

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

• Перемешался контент сайтов. Товары или тексты одного сайта всплывают на другом. Причина почти всегда — неверная привязка инфоблока по LID (привязан к обоим сайтам по недосмотру) или компонент без фильтра по текущему сайту.
• Не тот LID в компоненте. Компонент вызван с жёстко прописанным LID вместо текущего сайта — на втором сайте выводятся данные первого. Используйте текущий сайт из контекста, а не константу.
• Игнор лицензии. Запуск нескольких сайтов на редакции, которая их не покрывает. Проверяйте условия лицензии до, а не после запуска.
• Симлинки на ядро не настроены. В режиме доменов второй сайт «не видит» /bitrix/ или /upload/ — белый экран или битые загрузки. Проверьте алиасы и ссылки на общее ядро.
• Общий контент там, где нужен раздельный. Включаемая область (телефон, текст) сделана общей, и на втором сайте показывается чужой контакт. Разводите такие области по сайтам.
• Раздельный контент там, где выгоден общий. Каталог продублирован под каждый сайт, и товары приходится вести дважды. Для связанных витрин делайте единый каталог на несколько LID.
• Обновление сразу на бой. Апдейт ядра накатили без теста — сломалось на всех сайтах разом. В мультисайте обновления обязательно проверяют на копии.
• Дубли контента между доменами. Общий каталог на разных доменах без уникализации и canonical создаёт дублирующиеся карточки для поиска. Разводите витрины по назначению и мета-тегам.
• Одна модель авторизации задним числом. Решение «сквозная или раздельная авторизация» отложили, а потом переделывают на живой базе клиентов. Определяйте модель пользователей на старте.
• Нет резервирования общей инфраструктуры. Одно ядро — общая точка отказа, а бэкапы и мониторинг настроены слабо. Сбой роняет все сайты сразу.

Чек-лист по многосайтовости

Короткий список, по которому удобно свериться при проектировании и запуске нескольких сайтов на одном ядре:

• Редакция и условия лицензии проверены и покрывают нужное число сайтов.
• Выбран режим (разные домены / разные папки) осознанно, с учётом SEO-стратегии.
• Для каждого сайта заданы LID, домены, путь к корню, язык, кодировка, валюта.
• В режиме доменов настроены симлинки/алиасы на общее ядро /bitrix/ и /upload/.
• Граница «общее/раздельное» проведена по бизнес-логике: каталог, новости, области, пользователи.
• Общий каталог привязан к нескольким LID; раздельные инфоблоки — каждый к своему сайту.
• Компоненты фильтруют данные по текущему сайту, а не по жёстко прописанному LID.
• Модель пользователей (сквозная / раздельная) выбрана на старте под бизнес.
• Заказы, статусы, склады и почтовые шаблоны настроены per-site, где нужно.
• Каждому сайту назначен свой шаблон и локальные настройки.
• Проверена изоляция: контент одного сайта не всплывает на другом.
• SEO настроено раздельно: robots, sitemap, мета, счётчики на каждый сайт; дубли между доменами исключены.
• Обновления ядра идут через тестовую копию; общая инфраструктура зарезервирована и под мониторингом.

Вывод

Многосайтовость на 1С-Битрикс — это способ держать несколько самостоятельных сайтов на одном ядре, одной базе и под единой панелью управления. Работает она в двух режимах — на разных доменах или в разных папках одного домена, — а сколько сайтов покрывает лицензия, зависит от редакции и её условий, которые всегда сверяют с официальной политикой вендора. Внутри всё держится на LID: инфоблоки, разделы, включаемые области, пользователи и заказы привязаны к сайтам, и именно эти привязки определяют, что общее, а что раздельное. Самый ценный сценарий для магазина — единый каталог на несколько витрин: розница и опт, B2C и B2B ведут товары один раз, различаясь ценами, оформлением и логикой.

Практический стержень многосайтовости — дисциплина границ. Держите по-настоящему общее общим (ядро, каталог, клиентов там, где это оправдано), а различия — в шаблонах, настройках и привязках. Проверяйте лицензию до старта, выбирайте режим под SEO-стратегию, следите за LID, чтобы контент сайтов не перемешивался, и помните про обратную сторону единого ядра — связанность и общую точку отказа, которую компенсируют тестовыми копиями и резервированием. Тогда несколько сайтов на одном ядре дают ровно то, ради чего затевались: экономию на поддержке и общие данные без мучительной синхронизации. Если нужна такая система под ваш бизнес, мы проектируем и настраиваем её в рамках мультимагазина на 1С-Битрикс и мультирегионального сайта на 1С-Битрикс. Другие материалы по архитектуре собраны в рубрике «Разработка и архитектура».