Как настроить 301 редирект в 1С-Битрикс без потери SEO?

После смены ЧПУ в каталоге 1С-Битрикс Google Search Console показывает "Страница с переадресацией", а часть URL отдает 302 вместо 301. Типичная ловушка: в корневом .htaccess правило Redirect 301 /info/ стоит выше точечного /info/faq/, и вложенные разделы превращаются в site.rufaq. Параллельно глобальный http→https рвет ночной обмен 1С на /bitrix/admin/1c_exchange.php. За один проход вы выберете правильный уровень редиректа, настроите сценарий без цепочек и проверите ответ через curl.

HTTP 301 (Moved Permanently) - постоянное перенаправление: браузер и робот переходят на новый URL, а поисковик переносит сигналы со старой страницы. На 1С-Битрикс:Управление сайтом настраивается через .htaccess (блок #Редиректы), модуль "Поисковая оптимизация" (пары старый→новый URL), LocalRedirect($url, false, '301 Moved Permanently') или D7 \Bitrix\Main\Engine\Response\Redirect - в зависимости от того, нужен ли редирект до или после загрузки PHP. Сегодня откройте .htaccess, проверьте порядок частных правил выше общих и прогоните curl -I на старый URL.

На Битриксе редирект - не одна кнопка. .htaccess срабатывает до загрузки CMS, LocalRedirect - когда нужна логика из PHP, а urlrewrite.php вообще про маршрутизацию ЧПУ, не про SEO-переезд. Путаница трех уровней - главная причина, почему "я прописал Redirect 301", а в выдаче все еще старый адрес. Речь про 1С-Битрикс:Управление сайтом на своем хостинге, а не про Bitrix24 CRM.

Если вы только переезжаете с конструктора на коробку, сначала соберите карту URL - об этом в гайде Битрикс или конструктор для бизнеса. Здесь - практика на уже работающем сайте.

Разберите, что такое 301 редирект и когда нужен 302

301 - "адрес сменился навсегда". Поисковик переносит вес на новый URL. 302 - "временно зайдите сюда": робот не склеивает страницы. На Битрикс-сайте 301 нужен при смене ЧПУ, переходе http→https, выборе www или переезде домена. 302 - для A/B-теста, временной акции или авторизации, когда старый URL должен вернуться.

Делайте: для SEO-переезда везде один код 301. Не делайте: сваливать все старые URL на главную - Яндекс и Google ждут аналогичные страницы один к одному.

Выберите инструмент: .htaccess, SEO-модуль, LocalRedirect или urlrewrite

Четыре инструмента решают разные задачи: .htaccess - до PHP, модуль SEO - пары URL из админки, LocalRedirect - логика из базы, urlrewrite - маршрутизация ЧПУ, не HTTP-301. LocalRedirect() по умолчанию отдает 302; для SEO нужен третий параметр "301 Moved Permanently" (с версии 8.5.1).

Делайте: глобальные правила - в .htaccess, точечные пары - в SEO-модуле, условия из PHP - в LocalRedirect. Не делайте: путать urlrewrite с SEO-переездом и дублировать одно правило в трех местах.

Настройте 301 в .htaccess: блок #Редиректы и порядок правил

Глобальные правила - в блок #Редиректы корневого .htaccess, до rewrite Битрикс. Перед правкой сделайте бэкап; на VPS проверьте mod_rewrite - на старте часто хватает VPS у Beget с поддержкой .htaccess.

1. Откройте корневой .htaccess по FTP или SSH и найдите комментарий #Редиректы. Новые правила вставляйте туда, а не в середину блока urlrewrite.php.
2. Для простой пары "старый путь → новый путь" на том же домене используйте Redirect 301 /old-path/ /new-path/. Например, после смены ЧПУ правило Redirect 301 /info/ /info-new/ должно стоять ниже Redirect 301 /info/faq/ /info/faq-new/ — иначе вложенные разделы уедут не туда.
3. Для http→https и www объедините условия в один RewriteRule с флагом [R=301,L] - так меньше цепочек и ошибки ERR_TOO_MANY_REDIRECTS.
4. Добавьте исключение для обмена 1С: RewriteCond %{REQUEST_URI} !^/bitrix/admin/1c_exchange\.php$ [NC] - до правила https, иначе ночная выгрузка уйдет в редирект-цикл.
5. Если после редиректа нужны UTM-метки (?utm_source=...), используйте RewriteRule с флагом QSA - директива Redirect query string не сохраняет (подробнее в гайде как настроить UTM-метки).
6. Сохраните файл и сразу проверьте curl -I на старый URL - до массового списка из десятков правил.

Пример глобального https с исключением обмена:

#Редиректы
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/bitrix/admin/1c_exchange\.php$ [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]

Делайте: тестируйте www и без www отдельно до полного списка Redirect. Не делайте: смешивать Redirect и RewriteRule для одного и того же URL - получите двойной hop или бесконечный цикл.

Добавьте пары URL в модуле "Поисковая оптимизация"

Штатный UI - для десятков пар URL без SSH. Путь: Маркетинг → Поисковая оптимизация → редиректы (старый→новый, тип 301). Это не "Обработка адресов" (urlrewrite для ЧПУ).

1. Откройте админку → Маркетинг → Поисковая оптимизация.
2. Добавьте пару: полный путь старой страницы и канонический новый URL на том же домене.
3. Выберите тип 301 (постоянный), сохраните и сразу проверьте curl -I: модуль должен отдать один 301 без промежуточных hop. Для сотен URL из миграции рассмотрите импорт или .htaccess; маркетплейс-модули - только если штатных средств не хватает.

Делайте: вести таблицу старый→новый в Excel до заливки в админку. Не делайте: дублировать те же пары в .htaccess и в модуле SEO одновременно.

Настройте LocalRedirect и D7 Redirect с явным кодом 301

PHP-редирект - когда адрес зависит от свойств элемента или старого CODE. В component_epilog.php:

LocalRedirect('/catalog/new-section/', false, '301 Moved Permanently');

В D7 - \Bitrix\Main\Engine\Response\Redirect. Делайте: https в .htaccess, не в init.php без 301. Не делайте: массовый переезд только через LocalRedirect. При смене структуры через CUrlRewriter заранее планируйте разработку на 1С-Битрикс с картой URL.

Отделите urlrewrite.php от SEO-переезда

urlrewrite.php и $arUrlRewrite связывают ЧПУ с обработчиком: браузер остается на /catalog/ с кодом 200, адрес в строке не меняется. CUrlRewriter::Add добавляет правило маршрутизации, но не отдает HTTP 301 для переезда. Админка: Настройки → Обработка адресов. После смены ЧПУ обязательно пропишите 301 со старых проиндексированных путей - иначе робот продолжит ходить по устаревшим URL.

Делайте: после смены правил ЧПУ добавьте 301 со старых путей. Не делайте: ожидать, что urlrewrite сам "переедет" позиции в Google.

Проверьте редирект: curl, цепочки и query string

На практике один корректный редирект выглядит так: curl -I https://site.ru/old-url/ → HTTP/1.1 301 → Location: https://site.ru/new-url/. Цепочка 301→301→200 дает ERR_TOO_MANY_REDIRECTS и теряет crawl budget. Объединяйте www+https в одном RewriteRule, не дублируйте правила в .htaccess и PHP.

1. Выполните curl -I "https://example.ru/staryj-put/" и убедитесь в одном 301 и правильном Location.
2. Для проверки цепочки: curl -I -L --max-redirs 3 "https://example.ru/staryj-put/" - не больше одного редиректа до финального 200.
3. Проверьте URL с ?utm_source=test - query string должен сохраниться, если вы настраивали QSA.
4. Откройте инструмент "Ответ сервера" в Яндекс Вебмастере и URL Inspection в Google Search Console.
5. Убедитесь, что robots.txt и sitemap указывают на канонический https-домен - иначе робот увидит конфликт зеркал (см. robots.txt и sitemap на Битрикс).

Делайте: фиксируйте результат curl в таблице миграции. Не делайте: запускать "Переезд сайта" в Вебмастере, пока старые URL не отдают стабильный 301 на аналогичные новые.

Свяжите 301 с переездом в Вебмастере и GSC

Workflow: старый URL → один 301 → новый → "Переезд сайта" в Вебмастере (www/домен) → мониторинг в GSC. 301 - на аналогичные страницы, не на главную. В GSC свойство должно совпадать с каноническим https. Вопросы по аудиту - контакты mv-blog.ru.

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

Автор: Максим Мольков, digital-стратег, автор mv.digital.
Источники: документация LocalRedirect, обработка адресов urlrewrite, переезд сайта в Яндекс Вебмастере, редиректы Google Search Central.

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

Больше практики по сайту на Битрикс - в разделе создание и разработка сайта на mv-blog.ru.