Налаштування багатодоменної конфігурації 1С-Бітрікс

Налаштування багатодоменної конфігурації 1С-Бітрікс

Багатодоменна конфігурація — це ситуація, коли один сайт Бітрікса доступний по кількох доменних іменах. Не плутати з мультисайтовістю: там різні сайти (різний контент, шаблони), тут — один сайт, кілька точок входу. Типові сценарії: example.com та www.example.com, регіональні домени example.ru / example.by / example.kz з єдиним контентом, або переїзд зі старого домена на новий з збереженням працездатності обох.

Проблема, яку вирішує багатодоменність

Без коректного налаштування Бітрікс при зверненні по «невідомому» домену або видає 404, або працює з помилками: посилання генеруються з неправильним доменом, авторизація слітає через невідповідність cookie-домена, sitemap містить URL старого домена, а canonical указує не туди. Кожна з цих проблем б'є по SEO та користувацькому досвіду.

Налаштування на рівні Бітрікса

Основний домен задається у налаштуваннях сайту: Налаштування → Налаштування продукту → Сайти → поле SERVER_NAME. Це домен, який Бітрікс використовуватиме для генерації абсолютних URL — у листах, sitemap, og:url тощо.

Додаткові домени Бітрікс сам по собі не зберігає. Система визначає сайт по SERVER_NAME з HTTP-заголовка Host. Якщо вхідний Host не збігається з жодним сайтом — вибирається сайт за замовчуванням. Це працює, але без явного контролю.

Для явного управління використовується файл urlrewrite.php або init.php:

// /local/php_interface/init.php
$host = $_SERVER['HTTP_HOST'] ?? '';
$domainMap = [
    'example.ru'     => 's1',
    'example.by'     => 's1',
    'example.kz'     => 's1',
    'www.example.ru' => 's1',
];
if (isset($domainMap[$host])) {
    define('SITE_ID', $domainMap[$host]);
}

Налаштування на рівні веб-сервера

Кожний домен потребує окремого server-блоку (nginx) або VirtualHost (Apache), що вказує на той же DOCUMENT_ROOT.

Nginx:

server {
    server_name example.ru example.by example.kz www.example.ru;
    root /home/bitrix/www;
    include /etc/nginx/conf.d/bitrix.conf;
}

Редиректи — обов'язкові. Без канонічного редиректу пошукувачи індексують дублі. Стандартна схема:

• www.example.ru → 301 → example.ru (або навпаки — вибрати один варіант)
• http:// → 301 → https://
• Регіональні домени — або 301 на основний, або hreflang-розмітка

SSL-сертифікати

Кожний домен вимагає валідного SSL. Варіанти:

• Wildcard-сертифікат *.example.ru — покриває піддомени, але не example.by
• SAN-сертифікат (Subject Alternative Name) — один сертифікат на кілька доменів. Let's Encrypt підтримує до 100 SAN через certbot --domains example.ru,example.by,example.kz
• Окремі сертифікати — якщо домени в різних зонах, простіше управляти

Cookie та авторизація

Критичний момент: cookie PHPSESSID та авторизаційні cookie Бітрікса (BITRIX_SM_LOGIN, BITRIX_SM_UIDH) прив'язані до домена. Користувач, авторизований на example.ru, не буде авторизований на example.by.

Якщо потрібна наскрізна авторизація між доменами — це окрема задача, вирішувана через SSO-модуль або токенний механізм з редиректом. Для більшості багатодоменних конфігурацій (редирект / дзеркала) це не вимагається — достатньо 301 на каноничний домен.

Чеклист після налаштування

• SERVER_NAME у налаштуваннях сайту відповідає основному домену
• Усі неосновні домени мають 301-редирект на каноничний
• SSL валідний для всіх доменів
• canonical на сторінках указує на основний домен
• Sitemap містить URL тільки основного домена
• Поштові сповіщення містять коректні посилання (перевірити тестовим замовленням)

Налаштування займає близько одного робочого дня, включаючи конфігурацію веб-сервера та тестування редиректів.