Как настроить 301-редиректы на 1С-Битрикс: SEO-модуль, urlrewrite и проверка без петель

Сменили ЧПУ, перенесли раздел или "быстро" воткнули редирект в init.php – и старые адреса уходят в 404, 302 или бесконечную петлю ERR_TOO_MANY_REDIRECTS. На 1С-Битрикс: Управление сайтом (это не Bitrix24) 301 настраивают на одном из трёх слоёв: SEO-админка, сервер (.htaccess/nginx) или код. Ниже – карта "какой слой когда", правильный LocalRedirect без скрытого 302 и проверка curl без цепочек.

После смены структуры URL нужен один прямой hop: старый адрес → сразу актуальный, статус именно 301. Админка SEO удобна для десятков и сотен правил; тысячи и склейки доменов лучше отдавать серверу. LocalRedirect по умолчанию даёт 302 – для SEO статус "301 Moved Permanently" нужно указывать явно третьим параметром. Правила в .htaccess ставьте выше блока urlrewrite.php, иначе Битрикс перехватит запрос раньше редиректа.

ЧПУ (человекопонятные URL) – это маршрутизация через urlrewrite.php, а не таблица постоянных переездов. Путать их опасно: "Обработка адресов" делает красивые пути, а 301 говорит поисковику "страница навсегда переехала". Если задача – только HTTP→HTTPS, смотрите отдельный гайд по установке SSL на Битрикс. Если URL удалили без замены – чаще нужна честная 404, а не редирект на главную: см. настройку страницы 404.

Разведите задачи: когда нужен 301, а когда – другой инструмент

Делайте 301, когда адрес страницы изменился, а контент (или близкий аналог) остался. Не делайте 301 "на всякий случай" со всех битых ссылок на главную – так вы размываете сигналы и путаете пользователя.

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

Настройте 301 через SEO-модуль в админке

Для владельца сайта это самый понятный путь: не лезть в конфиг сервера. В админке откройте Маркетинг → Поисковая оптимизация → раздел редиректов (название пункта зависит от редакции, но живёт в модуле SEO).

1. Соберите список старых адресов из Вебмастера, Search Console и старой карты сайта.
2. Для каждого правила укажите источник и целевой путь на том же сайте (или полный URL, если домен тот же).
3. Где поддерживаются маски – используйте шаблон вроде /old-category/* → /new-category/*, чтобы не копировать сотни строк вручную.
4. Сохраните правило и сразу проверьте один URL через curl (см. чек-лист ниже).
5. Не дублируйте то же правило в .htaccess "на всякий случай" – оставьте один слой.

Ориентир из практики внедрений: до сотен правил админка обычно удобнее; тысячи строк и сложные regex – лучше на nginx map или Apache. Не делайте: править urlrewrite.php вручную "вместо" SEO-таблицы – это ЧПУ, не постоянный переезд.

Схема выбора слоя:
Таблица old→new готова → до ~сотен правил: SEO-админка → тысячи / домены / www: сервер (.htaccess или nginx) → нужна логика PHP (условия, пользователь, корзина): LocalRedirect / D7 с явным 301

Пропишите правила на сервере выше urlrewrite

Штатный .htaccess Битрикс гонит "несуществующие" пути в /bitrix/urlrewrite.php. Если ваш Redirect 301 стоит ниже этого блока, запрос уже ушёл в PHP – и "правило не работает".

Делайте так на Apache:

1. Откройте корневой .htaccess и найдите блок RewriteRule на urlrewrite.php.
2. Выше него добавьте постоянные переезды. Для простого внутрихостового случая часто хватает: Redirect 301 /old/ /new/.
3. Для шаблонов используйте RewriteRule с флагами [R=301,L] – L значит "остановиться, дальше не идти".
4. Склейку www/без-www и редкие межхостовые правила держите после RewriteEngine On, но всё равно до массового ухода в urlrewrite.
5. Сохраните файл и проверьте заголовки без браузера (браузер кеширует 301 агрессивно).

На nginx предпочтительнее return 301, а не тяжёлый rewrite. Массовые пары удобно держать в map $request_uri $new_uri, а роутинг Битрикс – через try_files … /bitrix/urlrewrite.php. Канонизацию index.php/index.html не раздувайте здесь: узкий сценарий уже разобран в базовых редиректах index.php.

Рекомендация: серверный 301 быстрее и надёжнее PHP, если правило статическое. Не делайте: копировать одни и те же пути и в nginx, и в init.php.

Вызовите LocalRedirect и D7 правильно – без скрытого 302

LocalRedirect – функция ядра: "отправь браузер на другой адрес". По официальной справке статус по умолчанию – "302 Found" (временный). Постоянный 301 доступен с версии 8.5.1 и задаётся третьим параметром. Второй параметр – не код ответа, а skip_security_check: защита от фишинга (нельзя молча увести пользователя на чужой домен).

Типичная ошибка с форумов: LocalRedirect($url, "301 Moved Permanently") – второй аргумент воспринимается как skip, статус остаётся 302. Правильный вызов:

LocalRedirect("/new-path/", false, "301 Moved Permanently");

В современном коде D7:

$response = new \Bitrix\Main\Engine\Response\Redirect('/new-path/');
$response->setStatus('301 Moved Permanently');
// вернуть $response из контроллера / обработчика

Делайте программный 301 только когда нужна логика (роль пользователя, условие заказа, динамический путь). Не делайте: редирект HTTP↔HTTPS в init.php параллельно с nginx – классическая петля за прокси (сервер уже отдал HTTPS, PHP думает что HTTP и снова шлёт на https). Смотрите X-Forwarded-Proto и настройки https в .settings.php.

Избегите петель, цепочек и поломки корзины

ERR_TOO_MANY_REDIRECTS в браузере значит: A шлёт на B, B обратно на A (или круг из трёх адресов). Частые причины на CMS:

• Дубль HTTPS: nginx + LocalRedirect на протокол.
• Слеш и index: /catalog ↔ /catalog/ ↔ /catalog/index.php гоняют друг друга.
• Редирект в init.php после логина ломает корзину и личный кабинет.
• Композит: редирект во время композитной отдачи даёт Ajax (error:redirect) – сначала почините hop, потом сбросьте кеш.
• Цепочка A→B→C: поисковик тратит краул-бюджет; сразу ведите A→C.

Рекомендация: перед массовым импортом прогоните 10–20 критичных URL (главная, карточки, корзина, ЛК, 2–3 старых ЧПУ). Не делайте: оставлять "временный" 302 на постоянном переезде – вес и сигналы передаются хуже.

Проверьте результат: curl, Вебмастер и sitemap

Браузер врёт из-за кеша. Проверка "на пальцах":

1. Выполните curl -I https://site.ru/old-url/ – в первой строке должен быть 301, в Location – финальный путь без лишних хопов.
2. Добавьте curl -I -L --max-redirs 5: если упрётесь в лимит – есть петля или длинная цепочка.
3. Убедитесь, что новый URL отдаёт HTTP 200, а не снова 301.
4. Обновите sitemap и отправьте на переобход в Яндекс.Вебмастере и Google Search Console.
5. Через несколько дней сверьте отчёты на "циклические перенаправления" и массовые 404 по старым путям.

Если карта редиректов разрослась после переезда или смены каталога и нужен разбор руками – можно обсудить аудит на контактах. Базовый SEO-контур (модуль, sitemap, индексация) держите по чек-листу SEO на Битрикс.

Что дальше: таблица old→new → один слой правил → curl -I на выборке → обновить sitemap → мониторинг Вебмастер/GSC. Не смешивайте HTTPS, 404 и миграцию в одну "простыню" правил без карты.

Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: официальная справка LocalRedirect и urlrewrite (dev.1c-bitrix.ru), D7 Response\Redirect, защита редиректов в безопасности CMS; практика .htaccess/nginx и проверка curl на проектах Управление сайтом.

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