Как настроить редирект с index.php в 1С-Битрикс

Редирект с index.php в 1С-Битрикс настраивают на уровне веб-сервера с учётом внутренних правил ЧПУ. Основная опасность — перенаправить внутреннее выполнение: сервер получает красивый URL, переписывает его на index.php, а общее правило возвращает браузер обратно. Результат — цикл.

Поэтому нельзя бездумно копировать одну строку конфигурации. Сначала определите сервер, текущие правила, основной формат URL и список исключений.

Составьте карту преобразований

Запишите пары: /index.php → /, /catalog/index.php → /catalog/. Отдельно отметьте реальные скрипты с именем index.php, если к ним должен быть прямой доступ, и административные или служебные маршруты.

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

Различайте редирект и внутренний rewrite

Редирект возвращает браузеру код 301 и новый Location. Внутреннее переписывание незаметно выбирает файл, который обработает запрос. В Битрикс механизм ЧПУ и urlrewrite.php участвуют во втором процессе.

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

Особенности Apache

В конфигурациях с mod_rewrite обычно проверяют переменную исходного запроса и размещают редирект до общих правил Битрикс. Точная запись зависит от контекста .htaccess, базового пути и версии сервера. Не используйте правило, которое совпадает со всем внутренним URI без проверки.

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

Особенности Nginx

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

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

Код и цепочка ответа

Для постоянного основного адреса обычно используют 301. Старый URL должен дать один переход прямо к финальному HTTPS-домену и варианту слеша. Цепочка HTTP → HTTPS → без index.php → со слешем замедляет обход и усложняет отладку.

Сведите нормализацию протокола, хоста и пути к предсказуемому результату.

Параметры запроса

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

• обычный GET-параметр;
• пустая строка;
• несколько параметров;
• закодированные символы;
• форма с POST;
• страница авторизации;
• ошибочный путь.

Не перенаправляйте POST как обычный 301 без проверки процесса: данные формы могут потеряться. Правильнее не отправлять форму на публичный index.php или изменить обработчик.

Canonical и внутренние ссылки

После редиректа исправьте меню, шаблоны, sitemap и canonical. Сайт не должен постоянно ссылаться на старый адрес. Редирект сохраняет совместимость с внешними ссылками, но не является заменой чистой генерации URL.

Тестовый протокол

1. Проверить синтаксис конфигурации.
2. Запросить корневой и вложенный index.php.
3. Проверить новый URL и отсутствие цикла.
4. Посмотреть цепочку заголовков.
5. Проверить параметры и формы.
6. Пройти каталог и авторизацию.
7. Посмотреть журнал ошибок и доступа.

Вносите изменение в согласованное окно и держите план отката. Один неверный шаблон способен перенаправить административные и API-запросы.

Алиса может настроить и протестировать редирект с учётом Битрикс, Apache или Nginx и существующих правил проекта.