Перейти к содержимому
BXWiki

Смена домена сайта - настройки, куки, защита, редиректы

Переводим сайт на новый домен: настройки сайта, доступ в админку, ссылки в контенте, редиректы и внешние сервисы.

Механика

Домен на платформе живёт не в одном месте, и в этом вся сложность задачи. Он записан в настройках сайта, в настройках главного модуля, в ограничениях проактивной защиты, в куке авторизации, в контенте и в конфигурации веб-сервера.

Текущий сайт определяется по домену на самом раннем этапе запроса. Если ни одна запись не подошла, страница открывается без нужного шаблона и без правильных настроек, и выглядит это как «слетела вёрстка», а не как ошибка настройки.

Проактивная защита умеет отбрасывать запросы, пришедшие с незнакомых ей хостов, и делает это молча. Она сравнивает адрес запроса со своим списком и уводит редиректом на известный ей домен, из-за чего в админку на новом адресе попасть не получается вовсе.

Вход в админку держится на куке, а у куки есть свой домен. Когда он остался старым, браузер отдаёт куку не тому адресу, и админка либо не открывается, либо перестаёт сохранять изменения.

Контент сайта помнит старый домен лучше всех остальных частей проекта, включая шаблоны писем. Абсолютные ссылки в описаниях, в почтовых шаблонах и во включаемых областях остаются рабочими ровно до того дня, когда старый домен перестанет отвечать.

Внешние сервисы знают старый адрес отдельно от сайта. Точка обмена с учётной системой, адреса возврата платёжных систем, обратные вызовы соцсетей и вебхуки живут в чужих личных кабинетах, и сами они о переезде не узнают.

Поисковая выдача переносится редиректом, а не переносом файлов. Постоянный редирект со старого домена на тот же путь нового - единственное, что сохраняет позиции; временный код ответа тут не годится совсем.

Лицензия продукта к доменному имени не привязана, и это заметно упрощает переезд. Переоформлять её при смене адреса не нужно, и это одна из немногих вещей в задаче, о которой можно не думать.

Шаги

  1. Заполнить новый домен во всех полях записи сайта и проверить сортировку.
  2. Разрешить новый хост в проактивной защите до того, как закроется старый.
  3. Поменять домен куки авторизации и проверить вход в административный раздел.
  4. Найти и заменить абсолютные ссылки в контенте, шаблонах и настройках.
  5. Поставить постоянный редирект со старого домена на тот же путь нового.
  6. Обновить адреса во внешних сервисах: обмен, платежи, вебхуки, счётчики.

Код

Правим домен в записи сайта:

\Bitrix\Main\SiteTable::update('s1', [
    'SERVER_NAME' => 'new.example.org',
    'SORT' => 100,          // при нескольких сайтах побеждает меньшая сортировка
]);
\Bitrix\Main\Config\Option::set('main', 'server_name', 'new.example.org');
// эта настройка нужна фоновым заданиям: текущего сайта у них нет вовсе
// поля домена заполняют все: пустое поле у одного из сайтов ломает определение

Незаполненный домен - самая частая причина «пропавшего шаблона». Платформа не находит подходящую запись, берёт сайт по умолчанию и отдаёт страницу с чужими настройками и чужим шаблоном.

Смотрим, какой сайт определился на самом деле:

echo SITE_ID, ' ', \Bitrix\Main\Context::getCurrent()->getSite(), "\n";
foreach (\Bitrix\Main\SiteTable::getList([
    'select' => ['LID', 'SERVER_NAME', 'SORT', 'ACTIVE', 'DEF'],
])->fetchAll() as $row) {
    print_r($row);      // видно сразу: чей домен совпал и какая у него сортировка
}

Возвращаем доступ в админку при жёсткой блокировке:

// /bitrix/modules/security/lib/hostrestriction.php - аварийная мера на время правки
// в методе onPageStart временно ставят return; и правят список хостов в настройках
// после правки список приводят в порядок, а изменение файла ядра откатывают

Ограничение по хостам уводит на старый домен молча. Новый адрес добавляют на странице хостов проактивной защиты; при мультисайтовости там перечисляют домены всех сайтов, иначе часть из них начнёт отвечать отказом.

Проверяем домен куки авторизации:

Окно терминала
php -i | grep session.cookie_domain            # домен куки на стороне языка
grep -rn "cookie_domain\|auth_domain" bitrix/.settings.php local/ | head
# прописанный руками старый домен ломает вход и сохранение в админке

Куку с чужим доменом браузер просто не отдаёт. Симптом при этом обманчивый: страница входа открывается, пароль принимается, а следующая страница снова просит авторизацию.

Ищем старый домен в контенте и настройках:

SELECT COUNT(*) FROM b_iblock_element WHERE DETAIL_TEXT LIKE '%old.example.org%';
SELECT COUNT(*) FROM b_event_message WHERE MESSAGE LIKE '%old.example.org%';
-- сначала считают, потом правят скриптом и обязательно с резервной копией
SELECT COUNT(*) FROM b_iblock_element WHERE PREVIEW_TEXT LIKE '%old.example.org%';

Абсолютные ссылки правят осознанно, а не одним запросом на всю базу. Часть таких адресов ведёт на чужие сайты и в старые документы, и слепая замена по всей базе ломает их вместе с нужными.

Ищем домен в коде и в настройках модулей:

Окно терминала
grep -rn "old.example.org" local/ bitrix/php_interface/ | head -20
# адреса точки обмена, вебхуков и внешних сервисов лежат ещё и в их кабинетах

Ставим постоянный редирект со старого домена:

server {
    server_name old.example.org;
        return 301 https://new.example.org$request_uri;   # тот же путь, постоянный код
}
# отдельный блок нужен и для варианта без www: склеивают оба написания сразу

Редирект сохраняет и посетителей, и позиции в поиске. Держать его стоит не меньше года: ссылки на старый адрес остаются в письмах, документах и на чужих сайтах гораздо дольше, чем кажется.

Сбрасываем кэш и пересобираем карту сайта:

Окно терминала
php local/tools/cache-clear.php
# карту сайта пересобирают заново: в ней остались адреса старого домена
# счётчики, панели вебмастеров и файл robots.txt правят следом

Ограничения

В штатном веб-окружении домен меняют его же меню, а не переименованием папки. Сайт в пуле привязан к имени, и «просто переименовать» не выйдет: переезд делают добавлением нового хоста и переносом на него.

Все пользователи разлогинятся после смены домена куки, включая менеджеров и администраторов магазина. Это нормально и неизбежно, но предупредить менеджеров стоит заранее, иначе первый рабочий день на новом адресе уйдёт на разговоры о сломанной админке.

Почтовые записи домена придётся настраивать заново. Подписи отправителя, разрешения на отправку и обратные записи привязаны к домену, и без них письма с нового адреса первое время уходят в спам.

Внешние интеграции переносят по списку, а не по памяти. Точка обмена с учётной системой, адреса возврата платёжных систем, обратные вызовы входа через соцсети и вебхуки сторонних сервисов перечисляют письменно и проверяют по одному.

Старый домен нельзя закрывать сразу после переключения сайта на новый адрес. Пока по нему идут переходы из поиска, писем и закладок, он обязан отвечать редиректом, а не ошибкой соединения.

Поисковые системы переносят сайт на новый адрес далеко не мгновенно, а неделями. Позиции возвращаются неделями, и в этот период не стоит менять ещё и структуру адресов: два переезда подряд обходятся дороже одного.

Типичные проблемы

После смены домена страницы открываются без шаблона.

Домен не заполнен во всех полях записи сайта, и подходящая запись не нашлась. Проверяют поля домена и сортировку у всех сайтов копии.

Новый домен редиректит на старый, в админку не попасть.

Проактивная защита держит список разрешённых хостов и уводит запросы на известный ей адрес. Домен добавляют на странице хостов заранее, а при мультисайтовости перечисляют домены всех сайтов.

Вход выполняется, но следующая страница снова просит пароль.

Домен куки авторизации остался старым, и браузер её не отдаёт. Значение правят в настройках языка и в настройках платформы, а потом проверяют вход.

Часть ссылок на сайте ведёт на старый домен.

В контенте и почтовых шаблонах записаны абсолютные адреса. Их считают запросом и правят скриптом с резервной копией.

Обмен с учётной системой перестал работать.

Адрес точки обмена остался старым на стороне учётной системы. Внешние адреса меняют отдельным списком, они о переезде не узнают.

Позиции в поиске просели после переезда.

Со старого домена нет постоянного редиректа на тот же путь нового. Временный код ответа или редирект на главную дают тот же результат.

Частые вопросы

Нужно ли переоформлять лицензию при смене домена?

Нет: лицензия привязана к копии продукта, а не к доменному имени. Менять её при переезде не требуется, и это единственный пункт задачи, о котором можно не думать.

Можно ли просто переименовать сайт в веб-окружении?

Нет: сайт в пуле привязан к имени хоста, и штатного переименования не предусмотрено. Добавляют новый хост и переносят на него сайт, а старый оставляют для редиректа.

Почему после смены домена не открывается административный раздел?

Чаще всего мешает ограничение по хостам в проактивной защите: оно уводит запросы на известный ей домен. Реже виноват старый домен в куке авторизации - тогда вход выполняется, но не запоминается.

Как заменить старый домен в текстах и описаниях?

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

Сколько держать редирект со старого домена?

Не меньше года, а лучше столько, сколько домен продлевается. Ссылки на старый адрес остаются в письмах, счетах и на чужих сайтах и приносят переходы ещё долго после переезда.

Смежное

Первоисточник