Как настроить 301-редирект в 1С-Битрикс с URL без слеша на адрес со слешем через .htaccess

При разработке и SEO-оптимизации сайтов на 1С-Битрикс часто возникает задача привести адреса страниц к единому формату. Например, необходимо настроить автоматическое перенаправление с URL без завершающего слеша на аналогичные адреса со слешем.

В результате обращения к странице https://example.ru/catalog пользователь должен автоматически перенаправляться на https://example.ru/catalog/ с HTTP-статусом 301 Moved Permanently.

Рассмотрим, как реализовать такой редирект в Битрикс через файл .htaccess, какие исключения следует предусмотреть и как проверить корректность работы правил.

Зачем нужен редирект на URL со слешем в конце

Один и тот же раздел сайта иногда доступен сразу по двум адресам:

• https://example.ru/catalog
• https://example.ru/catalog/

Если оба URL возвращают HTTP-статус 200 и одинаковое содержимое, поисковые системы могут воспринимать их как дублирующие страницы.

Настройка постоянного 301-редиректа помогает решить несколько задач:

• Привести адреса разделов к единому формату.
• Исключить доступность одинакового содержимого по двум URL.
• Снизить вероятность появления технических дублей в поисковой выдаче.
• Обеспечить единообразие внутренних ссылок.
• Сохранить корректную структуру URL при изменении правил маршрутизации сайта.

Для решения задачи можно использовать стандартные возможности веб-сервера Apache и модуль mod_rewrite. Изменять ядро 1С-Битрикс или устанавливать дополнительные модули не требуется.

1. Где находится файл .htaccess в 1С-Битрикс

Основные правила перенаправления и обработки URL на сайте под управлением 1С-Битрикс обычно находятся в файле .htaccess, расположенном в корневой директории сайта.

Открыть его можно через FTP/SFTP, SSH или файловый менеджер хостинга.

В стандартном файле Битрикс, как правило, уже присутствует блок с директивами:

RewriteEngine On

И правилом передачи запросов механизму маршрутизации Битрикс:

RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

Важно: новые правила перенаправления необходимо разместить после включения RewriteEngine On, но до стандартного правила обработки адресов через /bitrix/urlrewrite.php.

Перед редактированием рекомендуется создать резервную копию существующего файла .htaccess.

2. Настройка 301-редиректа на адрес со слешем

Для автоматического добавления завершающего слеша к адресам страниц можно использовать следующий код:

# Redirect URLs without a trailing slash

# Exclude system directories
RewriteCond %{REQUEST_URI} !^/(bitrix|local|upload|api|rest|\.well-known)(/|$) [NC]

# URL must not already end with a slash
RewriteCond %{REQUEST_URI} !/$

# Exclude URLs with file extensions
RewriteCond %{REQUEST_URI} !\.[^/]+$

# Exclude existing files, symlinks and directories
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d

# Permanent 301 redirect
RewriteRule ^(.+)$ /$1/ [R=301,L]

Добавьте этот код в существующий блок mod_rewrite файла .htaccess, непосредственно перед стандартными правилами маршрутизации Битрикс.

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

Например:

https://example.ru/catalog
        ↓ 301
https://example.ru/catalog/

https://example.ru/catalog/truby
        ↓ 301
https://example.ru/catalog/truby/

https://example.ru/company/about
        ↓ 301
https://example.ru/company/about/

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

3. Как работает правило перенаправления

Разберём основные директивы, используемые в примере.

Проверка завершающего слеша

RewriteCond %{REQUEST_URI} !/$

Условие проверяет, что запрошенный URL не заканчивается символом /. Если слеш уже присутствует, перенаправление не выполняется.

Исключение файлов

RewriteCond %{REQUEST_URI} !\.[^/]+$

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

• /index.php
• /robots.txt
• /sitemap.xml
• /catalog/item.html

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

Следует учитывать, что правило также пропустит адреса разделов, содержащие точку в последнем сегменте, например /catalog/version.2. Если такие URL используются на сайте и должны заканчиваться слешем, условие необходимо адаптировать под фактическую структуру адресов.

Проверка существования файлов и директорий

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d

Эти условия исключают перенаправление запросов к существующим файлам, символическим ссылкам и физическим директориям.

Такой подход позволяет снизить вероятность конфликтов с файловой структурой сайта и стандартными средствами Apache.

Выполнение 301-редиректа

RewriteRule ^(.+)$ /$1/ [R=301,L]

Здесь:

• ^(.+)$ — захватывает относительный путь запроса;
• /$1/ — формирует новый адрес с завершающим слешем;
• R=301 — возвращает статус постоянного перенаправления;
• L — прекращает дальнейшую обработку правил текущего прохода.

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

4. Исключение служебных разделов Битрикс

При настройке глобальных редиректов необходимо учитывать служебные каталоги 1С-Битрикс.

В приведённом примере используется условие:

RewriteCond %{REQUEST_URI} !^/(bitrix|local|upload|api|rest|\.well-known)(/|$) [NC]

Оно исключает из обработки запросы к следующим каталогам:

• /bitrix/ — системные файлы, административная панель и служебные обработчики;
• /local/ — локальные компоненты, шаблоны и пользовательский код;
• /upload/ — загруженные файлы и изображения;
• /api/ и /rest/ — возможные адреса API и интеграций;
• /.well-known/ — служебные URL, используемые различными сетевыми сервисами.

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

Особенно внимательно следует проверять работу AJAX-запросов, REST API, форм и сторонних интеграций, для которых изменение адреса может оказаться нежелательным.

5. Сохранение GET-параметров при редиректе

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

Предположим, пользователь открыл адрес:

https://example.ru/catalog?sort=price&order=asc

После перенаправления должен получиться URL:

https://example.ru/catalog/?sort=price&order=asc

В представленном правиле RewriteRule не задаёт новую строку запроса. Поэтому Apache по умолчанию сохраняет существующие GET-параметры при перенаправлении.

Добавлять флаг QSA для этого примера не требуется.

6. Проверка работы 301-редиректа

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

Проверить HTTP-заголовки можно через командную строку с помощью curl:

curl -I https://example.ru/catalog

При корректной настройке ожидается ответ следующего вида:

HTTP/1.1 301 Moved Permanently
Location: https://example.ru/catalog/

Дополнительно рекомендуется проверить адреса с GET-параметрами, страницы с расширением .html, административную панель и другие разделы сайта.

Для просмотра всей цепочки перенаправлений можно выполнить:

curl -IL https://example.ru/catalog

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

Совет: при первоначальной настройке можно временно использовать статус 302 вместо 301. После проверки правил замените его на постоянный редирект. Это упрощает тестирование, поскольку браузеры могут кешировать 301-перенаправления.

7. Возможные ошибки при настройке редиректа

Ошибка 500 Internal Server Error

Обычно возникает при синтаксической ошибке в .htaccess или использовании директив, запрещённых конфигурацией сервера.

Проверьте добавленный код, журнал ошибок Apache и права на использование правил mod_rewrite.

Редирект не срабатывает

Убедитесь, что модуль mod_rewrite включён, а сервер разрешает обработку директив из .htaccess.

Также проверьте расположение правила. Если перенаправление добавлено после стандартной передачи запросов в /bitrix/urlrewrite.php, оно может не выполняться.

Если сайт обслуживается исключительно Nginx без Apache, файл .htaccess не обрабатывается. В таком случае перенаправление необходимо настраивать в конфигурации Nginx.

Возникает бесконечный редирект

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

Проверьте настройки веб-сервера, компоненты Битрикс и дополнительные модули SEO-редиректов.

Ссылки на сайте продолжают формироваться без слеша

301-редирект исправляет поведение при обращении к адресу, но не изменяет автоматически ссылки, формируемые шаблонами и компонентами.

Для полноценной нормализации URL рекомендуется проверить параметры ЧПУ компонентов, настройки инфоблоков, внутренние ссылки и канонические адреса страниц.

8. Альтернативные способы настройки редиректа

Помимо редактирования .htaccess, реализовать перенаправления можно через конфигурацию Nginx, пользовательский PHP-код или специализированные SEO-модули для 1С-Битрикс.

Однако для сайта на Apache использование mod_rewrite обычно является наиболее простым решением. Перенаправление выполняется на уровне веб-сервера ещё до обработки запроса приложением, что позволяет не создавать дополнительную нагрузку на PHP.

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

Важные замечания перед настройкой редиректа

Приведённый пример рассчитан на типовую конфигурацию сайта на 1С-Битрикс с веб-сервером Apache и включённым модулем mod_rewrite.

Перед внесением изменений на рабочем сайте необходимо проверить существующие правила в файле .htaccess, особенно если уже настроены перенаправления с HTTP на HTTPS, с www на адрес без www (или наоборот), а также собственные правила ЧПУ.

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

Если сайт работает на Nginx без Apache, описанный способ через .htaccess не подойдёт. В таком случае аналогичные правила необходимо настроить непосредственно в конфигурации Nginx.

Рекомендуется: предварительно создать резервную копию файла .htaccess и протестировать перенаправления со статусом 302. После успешной проверки можно заменить временный редирект на постоянный 301.

Заключение

Настроить 301-редирект в 1С-Битрикс с адресов без слеша на URL со слешем можно с помощью нескольких правил в файле .htaccess. Для этого достаточно использовать mod_rewrite, предусмотреть исключения для файлов и служебных каталогов и разместить правило перед стандартной маршрутизацией Битрикс.

При правильной настройке сайт будет использовать единый формат адресов, а существующие страницы, файлы и административные инструменты продолжат работать без изменений.

После внедрения обязательно проверьте HTTP-статусы, сохранение GET-параметров, отсутствие циклических перенаправлений и корректность внутренних ссылок. Это позволит избежать технических ошибок и обеспечить предсказуемую работу URL на сайте.