Настройка нужна, чтобы у сайта был один канонический домен и поисковики не считали зеркала разными. В Битрикс чаще всего это делается на уровне веб-сервера через конфиг и через файл htaccess. Важно избежать циклов редиректа (когда запрос перескакивает туда-сюда и браузер “крутит” бесконечно).
Ниже - рабочий вариант для типичной схемы VMBitrix с Nginx и отдельной логикой Битрикс, а также запасные варианты для Apache.
Что чаще всего ломает редирект
1) Конфликт между редиректом на уровне Nginx и редиректом в htaccess, когда оба пытаются приводить домен к одному и тому же правилу, но в разное время или с разной схемой (http/https). В итоге получаются циклы.
2) Неправильные директивы “под протоколом”, когда редирект для http делает переход на https, а потом Nginx снова меняет схему или имя хоста.
3) Путают порядок правил в htaccess, и более раннее правило уводит запрос в другую ветку (для Битрикс это заметно при URLRewrite).
4) Нет теста на конкретной связке URL: http://www... и https://www..., а проверяют только один вариант.
Вариант для VMBitrix (Nginx + конфиги Битрикс): только на Nginx, плюс .htsecure
Если у вас VMBitrix (Nginx) и Битрикс сам управляет частью перенаправлений (часто через наличие файла-ключа), самый надежный способ - сделать редирект для имени на Nginx и не получить конфликт из htaccess.
1) Проверьте, что редиректами обрабатываются оба протокола
В конфиге Nginx для сайта добавьте правила для обоих портов. Идея такая: если пришли на домен с www, возвращаем 301 на домен без www, сохраняя путь и параметры.
Для порта 80:
server {
listen 80;
server_name www.example.ru;
return 301 http://example.ru$request_uri;
}
Для порта 443 (если есть отдельный SSL-конфиг):
server {
listen 443;
server_name www.example.ru;
return 301 https://example.ru$request_uri;
}
После правок перезапустите Nginx:
systemctl restart nginx
2) Создайте ключевой файл .htsecure в корне сайта Битрикс
Создайте пустой файл:
touch /home/bitrix/www/.htsecure
Зачем: в типовой конфигурации Битрикс на VMBitrix при наличии .htsecure включается режим, когда htaccess-логика работает корректно по задумке, и не провоцируется конфликт с редиректами на Nginx. Этот прием неоднократно используется, когда редирект с www и без www “вступает в спор” с https-логикой.
После этого заново проверьте редирект в браузере: нужны корректные ответы и один переход.
Как проверить, что редирект не зациклился
Проверяйте обе схемы и оба направления:
| Что проверить | Ожидаемый результат |
|---|---|
| http://www.example.ru/ | 301 на http://example.ru/ |
| https://www.example.ru/ | 200 или 301 на нужную каноническую страницу без www |
| https://www.example.ru/some-page | 301 на https://example.ru/some-page |
| Любой URL не должен “прыгать” бесконечно | 3xx должны быть один раз, затем конечный ответ |
Самый простой способ - посмотреть цепочку редиректов:
curl -I -L http://www.example.ru/some-page
Если в выводе видно повторение одного и того же домена/URL - это цикл.
Вариант для Apache (если у вас Битрикс на Apache, без Nginx)
В Apache редирект между зеркалами обычно делается в htaccess в корне сайта.
Поставьте 301 с www на без www:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]
Если https у вас пока не везде, замените целевой протокол на http и отдельно настраивайте https позже.
В Битрикс обязательно учитывайте, что htaccess может иметь внутренние правила rewrite. Поэтому размещайте директивы редиректа выше остальных правил, чтобы они срабатывали первой веткой.
Частые ошибки, которые дают “бесконечный редирект”
- На Nginx стоит правило, которое редиректит в сторону без www или в сторону https, а в htaccess есть обратное правило или правило для другой схемы.
- В одном месте редирект настроен на http, а в другом на https.
- Правила в htaccess стоят после rewrite-логики Битрикс и срабатывают не там, где вы ожидаете.
- Нет отдельной проверки для http://www... и https://www....
Итоговый чек-лист
1) Выбрано, какой домен канонический: без www.
2) Редирект на www сделан с кодом 301.
3) Обработаны обе схемы: http и https (или настроено так, чтобы не было цикла).
4) При VMBitrix добавлен файл .htsecure в корне Битрикс, если редирект в htaccess конфликтует с Nginx-логикой.
5) Проверена цепочка редиректов curl -L.
Источники
- Обсуждение типовых причин бесконечного редиректа и влияния связки nginx + Битрикс: dev.1c-bitrix.ru (треды сообщества) https://dev.1c-bitrix.ru/community/forums/forum32/topic59702/
- Пример подхода с правилом через Nginx и use .htsecure для снятия конфликта: webdevhelp.ru https://webdevhelp.ru/solutions/301-redirect-to-non-www-using-nginx-bitrixvm/
- Примеры 301 редиректа между www и без www для сценариев с Битрикс: Intervolga https://www.intervolga.ru/blog/marketing/301-redirect-bitrix/