Сайт на Бітріксі відкривається за кількома доменами — регіональними (.ru, .by, .kz) або після зміни основного домену. У підсумку SEO-трафік падає, користувачі втрачають авторизацію при переході, а пошуковики індексують дублі сторінок. Це типова проблема багатодоменної конфігурації без правильного налаштування. Ми вирішуємо її для проєктів із десятками тисяч відвідувачів, де кожна хвилина простою обходиться у втрату замовлень. Наш досвід — понад 10 років і 50+ успішних інтеграцій з регіональними доменами. Отримайте консультацію: розкажемо, як налаштувати вашу конфігурацію без помилок.
Проблеми, які вирішуємо
Без робочого механізму редиректів сторінки дублюються на кожному домені — пошуковики вважають їх копіями та знижують рейтинг. Cookie PHPSESSID прив'язуються до одного домену: користувач втрачає сесію, кошик або особистий кабінет при переході. Sitemap містить URL усіх доменів, а canonical-тег вказує невірно. Після налаштування кількість проіндексованих сторінок скорочується на 30–50%, а відвідуваність основного домену зростає на 15–25%. Економія на SEO-трафіку окупає роботи за 2–3 місяці (вартість розраховується індивідуально).
Одна з частих складнощів — авторизація між доменами. Наприклад, на проєкті з example.ru та example.by ми впровадили модуль єдиного входу на основі REST API. Сесія стала безшовною: користувач входить один раз і залишається авторизованим на всіх доменах.
Як налаштувати багатодоменну конфігурацію 1С-Бітрікс?
Конфігурація веб-сервера
Кожен домен описується окремим блоком у nginx або VirtualHost в Apache, що вказує на один DOCUMENT_ROOT. Обов'язково правило 301 редиректу з неосновних доменів на канонічний:
server { server_name www.example.ru; return 301 https://example.ru$request_uri; } server { server_name example.by example.kz; return 301 https://example.ru$request_uri; } server { server_name example.ru; root /home/bitrix/www; include /etc/nginx/conf.d/bitrix.conf; } Додатково налаштовуємо www-редирект і примусовий HTTPS. SSL-сертифікат краще використовувати SAN-сертифікат — він покриває всі домени в одному сертифікаті. Let's Encrypt дозволяє додати до 100 імен через certbot. Якщо регіональні домени належать до різних зон, wildcard-сертифікат не підходить (він тільки для піддоменів).
Налаштування Бітрікса
У налаштуваннях сайту задаємо SERVER_NAME — основний домен. Додаткові домени маппимо через 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_NAME критичний для генерації абсолютних URL у листах, sitemap та og:url. Без нього можлива некоректна видача посилань з неосновного домену.
Чому виникають дублі сторінок?
Пошуковики бачать кілька URL з однаковим контентом і вважають їх копіями. Canonical-тег повинен вказувати на основний домен, а редиректи — склеювати решту. Без цього трафік розпорошується, а PageRank падає. Після налаштування canonical-тег автоматично формується з правильним доменом, а sitemap містить URL тільки одного домену.
Як працює наскрізна авторизація?
Cookie (BITRIX_SM_LOGIN, BITRIX_SM_UIDH) прив'язані до домену. Для єдиної сесії потрібне SSO або токенний редирект. У нашому проєкті з example.ru та example.by ми впровадили модуль єдиного входу на основі REST API — авторизація стала безшовною. Користувач входить на одному домені й одразу отримує доступ до особистого кабінету на всіх доменах без повторної аутентифікації.
Процес роботи
| Етап | Що робимо | Очікуваний час |
|---|---|---|
| Аудит | Перевіряємо поточну конфігурацію, виявляємо дублі, помилки canonical | 0.5 дня |
| Налаштування веб-сервера | Прописуємо server-блоки, редиректи, SSL | 1 день |
| Конфігурація Бітрікса | Задаємо SERVER_NAME, init.php, перевіряємо cookie | 0.5 дня |
| Тестування | Перевіряємо редиректи, sitemap, авторизацію | 0.5 дня |
| Документація | Фіксуємо конфігурацію для подальшої підтримки | 0.5 дня |
Чеклист після налаштування
- SERVER_NAME у налаштуваннях сайту відповідає основному домену
- Усі неосновні домени мають 301-редирект на канонічний
- SSL валідний для всіх доменів
- canonical на сторінках вказує на основний домен
- Sitemap містить URL тільки основного домену
- Поштові сповіщення містять коректні посилання
Порівняння: багатодоменність vs мультисайтовість
| Параметр | Багатодоменна конфігурація | Мультисайтовість |
|---|---|---|
| Контент | Єдиний для всіх доменів | Різний для кожного домену |
| Навантаження на сервер | Низьке (один екземпляр) | Високе (кілька екземплярів) |
| SEO | Вимагає редиректів та canonical | Природна незалежність |
| Застосування | Регіональні домени, заміна старого домену | Різні продукти/бренди |
Багатодоменність ефективніша за мультисайтовість приблизно в 3 рази за навантаженням на сервер. Якщо вам потрібні різні сайти з різним контентом — обирайте мультисайтовість. Для єдиного контенту на кількох доменах — багатодоменність.
Що входить у роботу
- Аудит поточної конфігурації: перевірка доменних імен, SSL, редиректів та canonical
- Налаштування веб-сервера (nginx/Apache) з правилами 301
- Конфігурація Бітрікса: SERVER_NAME, init.php, теговане кешування
- Встановлення та оновлення SSL-сертифікатів (SAN або wildcard)
- Налаштування редиректів: www→без www, HTTP→HTTPS, регіональні
- Тестування авторизації, sitemap, canonical-тегів
- Документація конфігурації та інструкція з підтримки
Замовте налаштування зараз, щоб позбутися дублів і проблем з авторизацією. Зв'яжіться з нами — ми підготуємо оцінку за один день. Досвід 10+ років гарантує надійне рішення для вашого проєкту.