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

Разработка многосайтовой структуры на 1С-Битрикс — единственное разумное решение, когда клиент запускает второй бренд. Двойная лицензия, двойной обмен с 1С, двойная админка. Через месяц выясняется: товарная база общая, менеджеры в разных админках, синхронизация остатков летит. Мы проектируем многосайтовые архитектуры с 2014 года и знаем все подводные камни: от протекающего кэша до некорректного sitemap. Получите консультацию — оценим ваш проект за 2 дня.

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

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

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

Архитектура: общая база 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(). При 5 сайтах с общим каталогом из 50 000 товаров время полного обновления кэша сокращается на 60%, если правильно настроить ключи.
• Права доступа — группы пользователей общие. Менеджер контента сайта A может случайно отредактировать инфоблок сайта B, если не выстроена матрица прав на уровне инфоблоков.
• Модуль SEO — sitemap.xml генерируется через seo.sitemap.run. Нужно создавать отдельную карту для каждого SITE_ID, иначе в карту сайта A попадут URL сайта B.

Раздельные базы

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

Как решается проблема общего кэша?

В многосайтовой структуре кэш — главная головная боль. Без привязки к SITE_ID один сайт может показывать данные другого. Решение — на уровне разработчика: в result_modifier.php добавляем SITE_ID в ключ кэша через $arParams['CACHE_GROUPS'] и CPHPCache::SetCache(). Для композитного кэша настраиваем отдельный домен в модуле "Композитный сайт". Это гарантирует, что HTML-снимок сайта A не отдастся на домене B.

Подробнее о механизмах cookie — Wikipedia.

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

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

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

• SSO через токен — при переходе между доменами передаём одноразовый токен в URL, на принимающей стороне создаём сессию. Модуль socialservices или кастомный обработчик.
• Общий домен верхнего уровня — .company.com, cookie ставится на .company.com, работает для a.company.com и b.company.com.
• 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. Аудит текущей инфраструктуры и интеграций.
2. Проектирование архитектуры: матрица сайтов, инфоблоков, прав доступа, шаблонов.
3. Настройка ядра: создание сайтов, привязка доменов, настройка сессий и кэширования.
4. Разработка шаблонов: общий базовый шаблон + индивидуальные шаблоны сайтов.
5. Миграция контента и настройка SEO-модуля для каждого домена.
6. Настройка обмена с 1С (если требуется).
7. Тестирование кросс-сайтовых сценариев: авторизация, кэш, sitemap.
8. Обучение редакторов работе в единой админке.
9. Мониторинг после запуска.

Как сравнить общую базу с раздельными?

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

Сроки ориентировочно

Стоимость рассчитывается индивидуально после детального анализа — оценим ваш проект за 2 дня.

Типичные сложности и их решения

Свяжитесь с нами для оценки вашего проекта. Закажите консультацию — подберём оптимальную архитектуру без переплат.

Как правильно проектировать инфоблоки?

Мы видим десятки проектов, где неправильная структура инфоблоков превращает сайт в тормоз. Типичный сценарий: заказчик просит «каталог товаров». Разработчик создаёт один инфоблок catalog, закидывает туда 15 свойств. Через полгода — 40 свойств, 8 из которых используются только для одной категории. Фильтр тормозит, таблица b_iblock_element_property разрослась до миллионов строк, CIBlockElement::GetList выполняется 3 секунды. Последствия — падение конверсии, потеря клиентов, дополнительные затраты на оптимизацию. В одном проекте после рефакторинга каталога время генерации страницы снизилось с 4,2 до 0,8 секунды, а стоимость поддержки сократилась на 250 000 рублей в год — за счёт устранения избыточных запросов и агентов.

Наш подход: проектируем инфоблоки до первой строки кода. Отдельные инфоблоки под сущности (товары, категории, бренды), свойства-справочники через highload-блоки, торговые предложения для SKU. Это закладывает производительность на годы вперёд. Если хотите получить предварительный аудит вашей схемы инфоблоков — свяжитесь с нами, разберём типовые ошибки и дадим рекомендации бесплатно.

Почему 1С-Битрикс выгоднее альтернатив?

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

• Нативный обмен с 1С — модуль catalog.import.1c обеспечивает двусторонний обмен товарами, ценами, остатками и заказами через CommerceML. Без сторонних модулей. Это в 5 раз быстрее, чем разработка собственного обмена на OpenCart или WordPress. Подробнее о формате — в Wikipedia. Экономия на интеграции составляет в среднем 150 000–300 000 рублей по сравнению с кастомными решениями.
• Проактивная защита — модуль security включает WAF, контроль целостности файлов, защиту от SQL-инъекций, двухфакторную аутентификацию. Для проектов с требованиями ФСТЭК — сертифицированное решение.
• Модульная архитектура — подключаем только нужные модули: iblock, catalog, sale, search. Меньше модулей — меньше запросов к БД на каждый хит.
• Регулярные патчи — вендор выпускает security-патчи, закрывая уязвимости быстрее, чем open-source проекты (среднее время исправления CVE — 2 недели). Официальная документация по модулям — dev.1c-bitrix.ru.

Что дают HL-блоки и как мы ускоряем каталог

Highload-блоки — это альтернатива расширенным свойствам инфоблоков, когда список значений может расти до тысяч записей. Типичный пример: производители, страны, цвета. Если хранить их как свойства-списки в инфоблоке, каждая фильтрация вызывает полное сканирование таблицы b_iblock_property_enum. С HL-блоками выборка идёт по индексу — время ответа фильтра снижается с 1–2 секунд до 50 мс. Мы используем HLB компонент и кастомные запросы через Bitrix\Highloadblock\DataManager. Это особенно критично для каталогов с 100 000+ товарами.

Из нашей практики — проект интернет-магазина с 500 000 товаров. Стандартный фильтр по бренду выполнялся 4 секунды. Сервер не выдерживал нагрузку в 50 одновременных запросов — страницы падали. Мы перевели справочник брендов в HL-блок, добавили тегированное кэширование на 15 минут и настроили агент для сброса кэша при изменении. После доработки время фильтрации составило 120 мс, средний LCP страницы — 1,8 секунды. Проект работает стабильно без сбоев.

Что входит в разработку сайта на 1С-Битрикс

Каждый проект включает полный комплект документации и артефактов, исключающий потерю знаний после передачи.

• Техническое задание — user stories, диаграммы инфоблоков, схемы интеграций.
• Исходный код в Git — с историей коммитов, тегами релизов, правилами ветвления.
• Административная документация — описание кастомных компонентов, инструкции по разворачиванию, перечень агентов и событий.
• Обучение сотрудников — до 3 часов вебинара: панель управления, работа с заказами, настройка цен. Записываем, чтобы можно было пересмотреть.
• Доступ к staging на время разработки — тестируете сами до деплоя на продуктив.
• Гарантийная поддержка — исправление ошибок кода в течение 30 дней после запуска. Постгарантийные абонентские пакеты с SLA (реакция 2 часа, решение 8 часов).

Наш процесс и технологии

Стек: вёрстка mobile-first, тестируем на физических устройствах (iPhone, iPad, Android). Используем BrowserStack для Safari на iOS. Производительность — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаем композитный сайт (composite), CDN, тегированное кэширование, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерация sitemap.xml модулем seo, canonical и hreflang для мультиязычных версий. robots.txt закрываем /bitrix/ от индексации. CI/CD — Git, автодеплой через GitLab CI, staging. Миграции базы — модуль sprint.migration с версионированием.

Процесс работы:

1. Аналитика — изучаем конкурентов, собираем требования, рисуем прототипы в Figma. На выходе — ТЗ с user stories.
2. Дизайн — UI/UX с дизайн-системой. Компоненты переиспользуются.
3. Разработка — пишем компоненты с кастомными шаблонами в local/templates/. Бизнес-логику выносим в модули local/modules/.
4. Тестирование — функциональное, кроссбраузерное, нагрузочное (до 1000 запросов). Критичные баги исправляем до запуска.
5. Запуск — деплой на прод, мониторинг через UptimeRobot, алерты в Telegram. Устраняем первые 48 часов.

Интеграции, мультиязычность и редизайн

• Полная локализация через языковые файлы lang/ и механизм SITE_ID. hreflang для каждой версии. Региональные версии с разными ценами и контентом — определение по IP (main.geo) или ручной выбор. Мультидоменность — единое управление несколькими доменами.

• Редизайн без потери позиций: аудит производительности (PageSpeed, WebPageTest), SEO (Screaming Frog). Новый шаблон в local/templates/ с сохранением URL-структуры. 301-редиректы только если URL меняется существенно. Обновление ядра, переход на D7 ORM, реструктуризация инфоблоков, миграция через sprint.migration с Git.

Гарантия и поддержка

Мы работаем с 1С-Битрикс 12+ лет, реализовали 500+ проектов. В штате сертифицированные разработчики. Фиксированная стоимость в договоре — без сюрпризов. Гарантийный период покрывает ошибки кода. После — абонентские пакеты с SLA (время реакции — 2 часа, решение — 8 часов). Мониторинг доступности 24/7, алерты в Telegram. Получите консультацию и предварительный расчёт: свяжитесь с нами через форму на сайте или напишите в чат — ответим в течение часа. Закажите разработку под ключ — мы спроектируем инфоблоки, интегрируем 1С и разгоним каталог. Если уже есть сайт на другой CMS — закажите аудит производительности и миграцию на Битрикс.