Компания растёт, и вместе с ней растёт зоопарк сайтов. Основной корпоративный портал, отдельный лендинг под линейку продуктов, сайт дочерней структуры, версия для другого региона. Каждый живёт на своей CMS, у каждого свой подрядчик и свой счёт за хостинг, а каталог товаров ведётся в трёх местах руками. К моменту, когда кто-то в компании считает суммарную стоимость этого хозяйства, обычно уже поздно: переделывать дороже, чем терпеть.
Мультисайтовость в 1С-Битрикс решает ровно эту задачу. Несколько сайтов работают на одной установке продукта, с одной базой и одной панелью управления. Дальше о том, как это устроено технически, в каких случаях подход оправдан и когда он приносит больше проблем, чем экономии.
Что означает «несколько сайтов в одной админке»
Многосайтовость в терминологии вендора — это возможность системы управлять разными сайтами из единой панели управления. Ядро продукта одно, база данных общая, а сайты различаются структурой разделов, шаблонами и привязкой контента.
Практический смысл в том, что администратор заходит в одну админку и видит все проекты сразу. Не надо помнить пять паролей, не надо держать пять комплектов обновлений и пять лицензий. Контент, который должен быть общим, ведётся один раз.
Вендор перечисляет, что становится общим при такой конфигурации. Единая авторизация: пользователь регистрируется один раз и получает доступ ко всем проектам в соответствии с правами. Общая база пользователей. Единая статистика по каждому проекту и по всем сразу. Единое рекламное пространство для управления баннерами. Централизованное управление структурой контента и правами доступа. Отдельно упоминается технология распознавания посетителей между сайтами.
При этом каждый сайт может иметь собственный домен или целый набор доменных имён. Снаружи это выглядит как несколько независимых проектов, изнутри — как одна система.
Два способа конфигурации
Документация 1С-Битрикс описывает две схемы, и выбор между ними определяется тем, на каких адресах должны жить сайты.
Многосайтовость на одном домене
Прежнее название — многосайтовость по первому способу. Продукт и все сайты работают под управлением одной копии веб-сервера Apache, а каждый сайт размещается в отдельной подпапке корневой директории.
Структура папок допускает два варианта: равноправные папки вида /www/s1/ и /www/s2/ либо вложенное размещение, когда второй сайт лежит внутри первого. Настройки веб-сервера при этом менять не нужно, достаточно создать папки и задать параметры сайтов в разделе настроек продукта, где ведётся список сайтов.
Для каждого сайта указывается папка сайта относительно корня, URL сервера с учётом подпапки, а поле доменного имени остаётся пустым. Путь к корневой папке сайта тоже оставляют пустым: в конфигурации на одном домене этот параметр не используется, он нужен только для схемы с разными доменами. Продукт поставляется уже настроенным под этот сценарий, поэтому работы сводятся к созданию папок и правке настроек.
Эта схема хорошо подходит, когда сайты логически связаны и адреса вида company.kz/shop/ и company.kz/service/ никого не смущают. Например, разные направления одной компании под общим брендом.
Многосайтовость на разных доменах
Прежнее название — второй способ. Каждый сайт работает под управлением отдельной копии веб-сервера Apache или отдельного виртуального сервера. Именно эта схема нужна, когда у проектов должны быть полноценные самостоятельные домены.
Технически она устроена так: ядро продукта устанавливается в директорию одного сайта, а остальные сайты обращаются к общим ресурсам через символические ссылки. Общими являются папки /bitrix, /local и /upload. Символическая ссылка — это специальный файл, для которого файловая система не хранит ничего, кроме текстовой строки с путём к настоящему файлу.
Документация описывает два варианта реализации. В первом создаётся общая директория, куда переносятся папки ядра, а в каждом сайте создаются ссылки на неё. Во втором символические ссылки создаются в папке второго сайта с помощью PHP-скрипта.
Настройки в админке для каждого домена задаются отдельно: доменное имя, папка сайта, URL сервера, путь к корневой папке документов. Важный нюанс: параметр «папка сайта» у обоих сайтов имеет одно и то же значение /, потому что сайты обслуживаются разными виртуальными серверами из разных директорий.
Настройку самого веб-сервера Apache, как и в схеме с одним доменом, документация относит к зоне ответственности хостинг-провайдера. Это стоит учитывать при выборе площадки: не каждый хостинг разрешит создавать символические ссылки между каталогами разных сайтов.
Чего делать нельзя
Документация прямо предупреждает против соблазна, который возникает у каждого второго администратора: просто скопировать папку с сайтом и получить второй проект.
Копирование папок нарушает лицензионные условия и приводит к проблемам синхронизации базы данных после обновлений. Внешне сайт-копия может работать месяцами, а сломается в момент установки очередного обновления ядра, когда две инсталляции начнут разъезжаться. Разбирать такую ситуацию задним числом дорого, потому что придётся вручную сверять состояние двух баз.
Если нужен второй сайт, он создаётся штатными средствами многосайтовости либо ставится как отдельная лицензия. Третьего варианта нет.
Что общего у сайтов, а что своё
Вопрос, который на практике определяет, подойдёт вам такая конфигурация или нет. Граница проходит не там, где её обычно ожидают.
Общими остаются ядро продукта, база данных, набор установленных модулей и обновления. Обновить ядро для одного сайта из связки и не трогать остальные нельзя, они живут на одной инсталляции. Общая и база пользователей: учётная запись одна на все проекты, доступ разграничивается правами.
Своими у каждого сайта могут быть домен или несколько доменов, шаблон оформления, структура разделов, набор языковых настроек, а также привязка контента. Инфоблоки в 1С-Битрикс имеют настройку принадлежности к сайтам, и именно она позволяет одному каталогу показываться на трёх проектах, а новостной ленте оставаться на одном.
Из этого следует важный вывод для планирования. Многосайтовость экономит там, где сайты должны делить данные и команду. Там, где проекты по сути независимы и делят только счёт за хостинг, экономия оказывается мнимой: вы получаете общие риски без общей выгоды.
Лицензии: сколько сайтов разрешено
Тут всё определяется редакцией продукта. Владельцы редакций «Стандарт», «Малый бизнес» и «Бизнес» могут создавать неограниченное количество сайтов в рамках одной лицензии. Ограничения на количество страниц нет.
У редакции «Старт» лимит жёсткий: не более двух сайтов на одну лицензию. Это важный момент для планирования, потому что компании часто покупают «Старт» под первый проект, а через год обнаруживают, что для третьего сайта нужен апгрейд редакции.
Экономия здесь считается просто. Одна лицензия старшей редакции против трёх-четырёх отдельных лицензий младшей плюс отдельные обновления, отдельная поддержка и отдельные подрядчики. На горизонте двух лет разница обычно получается заметной. Если нужно посчитать конкретно ваш случай, это часть работ, которые мы делаем на этапе проектирования, посмотрите наши услуги по разработке сайтов.
Когда мультисайтовость оправдана
По нашей практике подход хорошо работает в нескольких сценариях.
Сеть филиалов или региональных версий. Один каталог товаров, одни описания, разные контакты, цены и склады. Контент-менеджер редактирует карточку товара один раз, изменение видно везде. Без общей базы это превращается в бесконечную ручную синхронизацию, где через полгода никто уже не помнит, какая версия описания правильная.
Холдинг с несколькими юрлицами под общим брендом. Сайты выглядят самостоятельно, но команда, которая их ведёт, одна. Единая авторизация здесь особенно ценна: сотрудник заходит под одной учётной записью и работает с теми проектами, к которым у него есть права. При смене сотрудника доступы закрываются в одном месте, а не собираются по пяти админкам.
Основной сайт плюс сателлиты под направления. Крупный корпоративный сайт и несколько промо-проектов под отдельные услуги или продукты. Промо-сайты запускаются и закрываются быстро, и держать под каждый отдельную инсталляцию слишком накладно. В общей связке запуск нового направления сводится к созданию сайта в настройках и подготовке шаблона.
Двуязычные и многоязычные проекты. Языковые версии часто делают именно через механизм многосайтовости, когда каждая версия оформлена как отдельный сайт со своей структурой. Это даёт больше свободы, чем перевод в рамках одного сайта, особенно если версии различаются не только языком, но и набором разделов. Для казахстанских компаний сценарий типовой: русская и казахская версии редко совпадают один в один по содержанию.
Когда лучше отказаться
Общая база и общее ядро дают экономию, но создают и общие точки отказа. Есть ситуации, где эти минусы перевешивают.
Первая — проекты с принципиально разной нагрузкой. Если один сайт из связки собирает основной трафик и время от времени попадает под пиковые нагрузки, он утянет за собой остальные. Разделять их потом сложнее, чем разнести сразу.
Вторая — разные владельцы или разные подрядчики. Общая админка означает, что администратор одного проекта технически имеет доступ к системе целиком. Права разграничиваются, но полностью изолировать проекты друг от друга не получится. Для сайтов разных юридических собственников это часто неприемлемо.
Третья — сильно различающаяся функциональность. Если один сайт представляет собой интернет-магазин со сложной логикой, а второй — простую визитку, они всё равно будут обновляться вместе и падать вместе. Обновление, нужное магазину, придётся протестировать и на визитке.
Четвёртая — планы продать или выделить один из проектов. Отделить сайт из многосайтовой конфигурации в самостоятельную инсталляцию можно, но это отдельный проект с миграцией данных, а не операция в пару кликов. Если такой сценарий вероятен, продумайте его заранее.
Как это выглядит в работе контент-менеджера
Техническая сторона понятна из документации, а вот повседневная работа с многосайтовой конфигурацией обычно вызывает больше вопросов, чем настройка.
Главное изменение в привычках: почти у каждого элемента появляется вопрос «для какого сайта». Раздел структуры, инфоблок, элемент каталога, шаблон, форма обратной связи — всё это имеет привязку к сайту. Пока контент-менеджер этого не осознал, он будет регулярно публиковать новость не там, где планировал, и удивляться, почему её не видно.
Отсюда практическое правило, которое мы закладываем при запуске: сделать привязку сайта максимально заметной в интерфейсе. Колонка с сайтом должна быть видна в списках элементов сразу, без залезания в настройки отображения. Полминуты работы при внедрении экономят десятки ошибок за год.
Второй момент — шаблоны. Каждый сайт имеет собственный шаблон оформления, и правка общего компонента может внезапно изменить внешний вид всех проектов сразу. Это работает и в плюс, и в минус. В плюс, когда нужно поменять форму заявки везде одним движением. В минус, когда правка под один сайт ломает вёрстку на соседнем. Поэтому изменения в общих компонентах обязательно проверяются на всех сайтах связки, а не только на том, ради которого их делали.
Третий момент касается поиска и фильтров в админке. На связке из пяти сайтов список заказов, список пользователей и журнал событий превращаются в общую свалку, если не пользоваться фильтрами по сайту. Научить команду этому лучше на старте, вместе с передачей проекта.
Что учесть на этапе проектирования
Перевод существующего зоопарка сайтов в многосайтовую конфигурацию почти всегда сложнее, чем запуск такой конфигурации с нуля. Несколько вещей стоит решить до начала работ.
Определите, какой контент общий, а какой принадлежит конкретному сайту. В инфоблоках есть привязка к сайтам, и от того, как вы её спроектируете, зависит вся дальнейшая работа контент-менеджеров. Ошибка здесь обходится дорого: переносить уже наполненные разделы между инфоблоками неприятно.
Продумайте структуру прав. Единая база пользователей удобна, но требует аккуратной настройки групп: контент-менеджер регионального сайта не должен править главную головного портала.
Заранее выберите схему конфигурации. Переход с одного домена на разные домены после запуска требует перестройки структуры каталогов и настройки веб-сервера, а также правки всех внутренних ссылок. Решать это на старте дешевле.
И проверьте хостинг. Схема с разными доменами опирается на символические ссылки и на возможность настроить виртуальные серверы, а это доступно не на каждом тарифе. Уточняйте это у провайдера до покупки лицензии.
Переезд существующих сайтов в одну связку
Отдельный сюжет, с которым к нам приходят чаще всего: сайты уже есть, работают годами, и теперь их хотят свести вместе. По объёму это полноценный проект миграции, и недооценка его сложности остаётся главной причиной, по которой такие переезды затягиваются на месяцы.
Первым делом в реальность упираются разные структуры данных. На одном сайте каталог товаров устроен так, на втором иначе, поля называются по-разному, у третьего вообще самописное хранилище. Свести их в общие инфоблоки означает спроектировать единую структуру и написать конвертацию для каждого источника. Объём этой работы обычно превышает саму настройку многосайтовости в несколько раз.
Второе — адреса страниц. У каждого сайта своя история индексации, накопленные позиции и ссылочная масса. При переезде часть URL неизбежно меняется, и без карты редиректов трафик просядет. Карту делают до переезда, а не после, когда позиции уже просели и восстанавливать их придётся месяцами.
Третье — учётные записи пользователей. Если на сайтах были личные кабинеты, при объединении баз всплывают дубли: один и тот же человек зарегистрирован на двух проектах с разными паролями, а иногда и с разными почтами. Решение принимается заранее: сливаем записи по почте, оставляем как есть или просим пользователей пройти регистрацию заново. Каждый вариант имеет цену, и лучше выбрать её осознанно.
Четвёртое — очерёдность. Переносить всё разом рискованно. Мы обычно начинаем с наименее критичного сайта, отлаживаем на нём процесс и структуру данных, и только потом трогаем основной проект, который приносит деньги. Такой порядок удлиняет проект, зато делает откат возможным на каждом шаге.
И отдельно про сроки. Переезд трёх сайтов средней сложности редко укладывается в месяц, если делать его с тестированием и сохранением позиций. Планы вида «объединим за две недели» обычно заканчиваются либо потерянным трафиком, либо параллельной работой старых сайтов ещё полгода, потому что переключить их так и не решились.
Частые вопросы
Сколько сайтов можно сделать на одной лицензии 1С-Битрикс?
В редакциях «Стандарт», «Малый бизнес» и «Бизнес» количество сайтов не ограничено, ограничения по числу страниц тоже нет. В редакции «Старт» на одной лицензии допускается не более двух сайтов.
Можно ли просто скопировать папку сайта и получить второй проект?
Нет. Документация прямо предупреждает, что копирование папок нарушает лицензионные условия и вызывает проблемы синхронизации базы данных после обновлений. Второй сайт создаётся штатными средствами многосайтовости.
Обязательно ли, чтобы сайты были на одном хостинге?
Да. Многосайтовость предполагает общую базу данных, поэтому все сайты связки размещаются на одной площадке. Разнести их по разным хостингам, сохранив единую админку, не получится.
Чем схема на одном домене отличается от схемы на разных доменах?
В первой все сайты работают под управлением одной копии веб-сервера и лежат в подпапках корневой директории, доменное имя в настройках сайта остаётся пустым. Во второй каждый сайт обслуживается отдельной копией веб-сервера или отдельным виртуальным сервером, а доступ к общим папкам ядра организуется через символические ссылки.
Можно ли потом выделить один сайт в отдельную инсталляцию?
Технически да, но это полноценный проект миграции: перенос данных, перенастройка, отдельная лицензия. Если такой сценарий вероятен, лучше не заводить этот проект в общую конфигурацию с самого начала.
Решение о многосайтовости определяется устройством бизнеса, а не удобством администратора. Связанные направления одной компании выигрывают от общей базы и общей команды: данные ведутся один раз, обновления ставятся один раз, доступы закрываются в одном месте. Проекты с разными владельцами, разной нагрузкой и разной судьбой лучше держать порознь, даже если суммарный счёт за лицензии получится выше. Разделить их потом, когда общая инсталляция уже обросла данными, стоит заметно дороже, чем не объединять с самого начала.