Разработка многосайтовой структуры на 1С-Битрикс

Разработка многосайтовой структуры на 1С-Битрикс

На одной установке Битрикса можно запустить десяток сайтов с разными доменами, шаблонами, контентом и даже языками. Механизм SITE_ID встроен в ядро — каждый запрос определяет, к какому сайту относится, и подтягивает нужный шаблон, контент, языковые файлы. Звучит просто. На практике — кеш одного сайта «протекает» в другой, права доступа перемешиваются, а SEO-модуль генерирует sitemap со ссылками на чужой домен.

Когда многосайтовость оправдана

Холдинг с пятью брендами. Франшиза с региональными представительствами. Группа компаний, где у каждого направления свой домен, но товарная база общая. В этих случаях альтернатива — пять отдельных установок Битрикса, пять лицензий, пять серверов, пять обменов с 1С. Многосайтовость на одной установке — один сервер, одна лицензия (начиная с редакции «Бизнес»), одна админка.

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

Архитектура: общая база vs раздельные

Битрикс поддерживает два режима многосайтовости.

Общая база, общие файлы — все сайты живут в одной базе MySQL и одной файловой системе. Разделение — через SITE_ID в таблицах. Инфоблок можно привязать к нескольким сайтам через b_iblock_site. Пользователь, зарегистрированный на сайте A, автоматически авторизован на сайте B (общая таблица b_user, общие сессии).

Подводные камни:

• Кеш компонентов — если не указать SITE_ID в ключе кеша, компонент news.list на сайте B отдаст данные, закешированные для сайта A. Стандартные компоненты Битрикса обычно учитывают SITE_ID, а вот кастомные — нет, пока не добавишь $this->arParams['CACHE_GROUPS'] и не включишь SITE_ID в getAdditionalCacheID()
• Права доступа — группы пользователей общие. Менеджер контента сайта A может случайно отредактировать инфоблок сайта B, если не выстроена матрица прав на уровне инфоблоков
• Модуль SEO — sitemap.xml генерируется через seo.sitemap.run. Нужно создавать отдельную карту для каждого SITE_ID, иначе в карту сайта A попадут URL сайта B

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

Домены и маршрутизация

В настройках сайта (Настройки → Настройки продукта → Сайты) указываются:

• Домен — brand-a.com, brand-b.com
• Каталог сайта — корень / или подкаталог /brand-b/
• Шаблон по умолчанию — каждый сайт может использовать свой шаблон из local/templates/

Маршрутизация работает через модуль ядра: Битрикс сопоставляет HTTP_HOST с полем SERVER_NAME в таблице b_lang. Если домен не найден — подставляется сайт по умолчанию. Для поддоменов (spb.company.com, msk.company.com) механизм тот же — каждый поддомен = отдельный SITE_ID.

Нюанс с HTTPS и CDN. Если перед Битриксом стоит nginx или Cloudflare, заголовок HTTP_HOST может приходить некорректно. Проверяем $_SERVER['HTTP_X_FORWARDED_HOST'] и настраиваем SITE_SERVER_NAME в dbconn.php.

Шаблоны: общее vs уникальное

Три стратегии:

1. Один шаблон, разные CSS-темы. Общий HTML-каркас в local/templates/main/, переключение стилей через SITE_ID. Быстро, дёшево, но дизайн сайтов будет похож
2. Отдельные шаблоны. local/templates/brand-a/, local/templates/brand-b/. Полная свобода дизайна, но дублирование кода компонентов. Выход — общие шаблоны компонентов в local/templates/.default/components/
3. Базовый шаблон + наследование. Основные компоненты и layout в базовом, кастомные — в шаблоне сайта. header.php и footer.php специфичны для каждого сайта, а шаблоны компонентов переиспользуются

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

Общая пользовательская база

Главное преимущество общей базы — единая авторизация. Пользователь регистрируется на brand-a.com, заходит на brand-b.com — уже авторизован. Это работает через общую таблицу b_user и общие сессии.

Но есть подвох. Сессии хранятся в файлах по умолчанию — в /bitrix/sessions/. При двух доменах cookie PHPSESSID не передаётся между ними (разные домены — разные cookie). Решения:

• Общий домен верхнего уровня — .company.com, cookie ставится на .company.com, работает для a.company.com и b.company.com
• SSO через токен — при переходе между доменами передаём одноразовый токен в URL, на принимающей стороне создаём сессию. Модуль socialservices или кастомный обработчик
• Redis для сессий — сессии хранятся централизованно, но проблема cookie остаётся. Redis решает другую задачу — горизонтальное масштабирование, не кросс-доменную авторизацию

Контент: что делить, что разделять

Инфоблоки привязываются к сайтам через настройку в админке. Один инфоблок может быть доступен на нескольких сайтах. Типичный сценарий: каталог товаров — общий (SITE_ID: s1, s2, s3), новости — у каждого сайта свои.

Важный момент — свойства инфоблока общие. Нельзя добавить свойство «Акция» только для сайта A, если инфоблок привязан к сайтам A, B, C. Все три сайта увидят это свойство. Решение — использовать множественное свойство типа «Привязка к сайту» и фильтровать в компоненте.

Торговый каталог. Модуль catalog позволяет настроить разные типы цен для разных сайтов. Сайт для оптовиков показывает оптовые цены, розничный — розничные. Складские остатки — общие или раздельные через привязку к магазинам (b_catalog_store).

SEO-настройки — шаблоны META через iblock.type.edit задаются на уровне инфоблока, не сайта. Для разных сайтов с одним инфоблоком придётся генерировать META программно в result_modifier.php, подставляя нужные значения по SITE_ID.

Частые проблемы при масштабировании

• Обмен с 1С — модуль catalog.import.1c импортирует товары в инфоблоки. Если каталог общий на три сайта, импорт один. Если у каждого сайта свой каталог — три отдельных обмена, три профиля в 1С. При 50К+ товаров каждый обмен блокирует таблицы на 15-30 минут. Разносим по крону, чтобы не пересекались
• Поиск — штатный search.title индексирует все сайты в одну таблицу b_search_content. Результаты фильтруются по SITE_ID, но индекс общий. На 5 сайтах с 100К страниц каждый — индекс на полмиллиона записей, переиндексация занимает часы. Elasticsearch вместо штатного поиска — если объём данных существенный
• Композитный кеш — модуль composite работает корректно с многосайтовостью, но требует отдельной настройки для каждого домена. Без этого HTML-снимок сайта A может отдаться на домене B

Этапы внедрения

1. Аудит текущей инфраструктуры (3-5 дней) — какие данные общие, какие уникальные, какие интеграции затронуты
2. Проектирование структуры (1-2 недели) — матрица сайтов, инфоблоков, прав доступа, шаблонов. ER-диаграмма связей
3. Настройка ядра (3-5 дней) — создание сайтов, привязка доменов, настройка сессий и кеширования
4. Разработка шаблонов (2-6 недель) — зависит от количества сайтов и степени различий в дизайне
5. Миграция контента (1-2 недели) — перенос данных, настройка привязок, SEO-аудит
6. Тестирование (1 неделя) — кросс-сайтовые сценарии, авторизация, кеш, SEO

Стоимость зависит от количества сайтов, степени уникальности каждого и сложности интеграций. Определяется после детального анализа.