Настройка ЧПУ в Битрикс: как сделать человекопонятные адреса без потери позиций

После включения ЧПУ у сайта на 1С-Битрикс меняется каждый адрес: /catalog/index.php?ELEMENT_ID=133 превращается в /catalog/mebel/stol-oreh/. Для поисковика это две разные страницы, и если переключить URL без плана, за пару недель можно потерять треть органического трафика. Настройка ЧПУ Битрикс требует определённого порядка действий: сначала шаблоны компонентов и правила в urlrewrite.php, потом транслитерация кодов разделов, и только в конце - карта 301 редиректов со старых адресов на новые. Разбираю каждый шаг так, как делаю это на реальных проектах, от каталога на 200 товаров до магазина с историей индексации в несколько тысяч страниц.

Где в Битриксе включается ЧПУ и что проверить перед стартом

ЧПУ включается в Настройки -> Настройки продукта -> Модули -> Главный модуль, вкладка с урлами (в старых редакциях она называлась «ЧПУ»). Там два ключевых чекбокса: «Включить поддержку ЧПУ» и обработка 404 ошибки отдельной страницей. Второй пункт обязателен, иначе несуществующий адрес будет отдавать код 200 с текстом «страница не найдена», а поисковик воспримет это как рабочую страницу и начнёт плодить дубли в индексе.

Перед тем как что-то менять на проде, я делаю три вещи. Смотрю в Яндекс.Вебмастере и Google Search Console, сколько страниц сайта реально в индексе, и выгружаю список URL. Проверяю в панели хостинга, что модуль mod_rewrite у Apache (или аналог у Nginx) включён и подключён файл .htaccess в корне сайта. И поднимаю копию проекта на staging-домене, потому что тестировать смену адресов на боевом магазине с работающим трафиком не стоит.

Шаблоны URL для инфоблоков и компонентов каталога

Компонентный ЧПУ включается параметром SEF_MODE=Y в настройках компонента и работает через набор шаблонов: отдельная строка на список разделов, на конкретный раздел, на карточку товара, на поиск и на сравнение. В параметре SEF_FOLDER задаётся корень раздела, например /catalog/, а дальше движок сам подставляет символьные коды по маске.

Символьный код раздела и элемента формируется из поля «Код» в инфоблоке, а оно, в свою очередь, чаще всего заполняется автогенерацией из названия по правилам транслитерации. Если структура каталога рваная, с разной глубиной вложенности для разных брендов, или в проекте несколько инфоблоков с пересекающимися разделами, стандартных настроек компонента обычно не хватает, и приходится дописывать разработку кастомных правил ЧПУ под конкретную структуру каталога.

Правила в urlrewrite.php для нестандартных адресов

Когда шаблонов компонента мало, например нужен адрес без привязки к инфоблоку или редирект с legacy-страницы на новый раздел, правила прописываются в файле /bitrix/php_interface/urlrewrite.php. Каждое правило - это массив с ключами CONDITION (регулярное выражение для входящего URL), RULE (какие параметры вытащить из адреса), ID (какой компонент обработает запрос) и PATH (путь к файлу-обработчику).

После любого изменения этого файла я прогоняю список ключевых адресов через curl, чтобы увидеть реальный код ответа, а не поверить визуально открывшейся странице в браузере:

curl -I -s https://example.ru/catalog/mebel/stol-oreh/
curl -I -s https://example.ru/catalog/index.php?ELEMENT_ID=133

Первый запрос должен вернуть 200 на новом адресе, второй, если старый URL уже выведен из оборота, 301 с корректным Location. Ошибка, которую вижу чаще всего: старый и новый адрес одновременно отдают 200, оба попадают в индекс, и Битрикс сам не помечает их как дубли.

Транслитерация кириллицы и символьные коды разделов

Правила замены символов при транслитерации задаются в общих настройках информационных блоков, и настроить их нужно до того, как в каталоге появится хотя бы сотня разделов. По умолчанию Битрикс превращает «щ» в «shh», а не в более читаемое «sch», «ц» и «ч» тоже конвертирует не всегда так, как хочется видеть в адресной строке. Поменять схему транслитерации после того, как коды уже сгенерированы и проиндексированы, дороже: придётся переименовывать существующие разделы, а это снова цепочка 301 редиректов.

Вторая практическая деталь: код раздела не должен зависеть от названия, которое меняется. Если раздел «Акции лето 2026» получает код akcii-leto-2026, а через год маркетолог переименует его в «Акции лето 2027», автогенерация кода потянет за собой смену адреса. Для сезонных и часто редактируемых разделов я фиксирую код руками один раз и снимаю галочку автогенерации в инфоблоке.

Перенос на новую структуру ЧПУ без потери позиций

Основная потеря трафика при смене адресов случается не из-за самого ЧПУ, а из-за пропущенных редиректов. Порядок, которого придерживаюсь на проектах с уже накопленной индексацией:

• Выгружаю список проиндексированных URL из Вебмастера и Search Console, плюс реальные заходы за последние 3 месяца из логов сервера или Метрики - именно эти адреса важнее всего не потерять.
• Составляю таблицу соответствия «старый адрес - новый адрес» в отдельном файле, а не держу в голове.
• Прописываю 301 редиректы пакетно через urlrewrite.php или прямые правила в .htaccess, проверяю каждый пул адресов curl-ом на staging.
• Обновляю sitemap.xml с новыми адресами и повторно отправляю его в Яндекс.Вебмастер и Google Search Console.
• Проверяю canonical-теги на новых страницах: если старый шаблон компонента прописывал canonical на старый URL, поисковик продолжит держать в индексе именно его.

По срокам: настройка шаблонов и urlrewrite.php на среднем каталоге занимает 1-2 дня, тестовый прогон редиректов на staging - ещё день, а после переноса на продакшн 2-4 недели уходит на мониторинг 404 и позиций, потому что поисковик переиндексирует адреса не мгновенно. Если структуру нужно спроектировать с нуля и сверить с текущей индексацией, аудит и план миграции адресов я обычно делаю как отдельную консультацию от 3 000 ₽, до того как трогать боевой сайт.

Частые ошибки при настройке человекопонятных адресов

Собрал то, что регулярно вижу при разборе чужих проектов после смены ЧПУ:

• Отключена обработка 404 ошибки - несуществующие страницы отдают 200, и в индексе накапливается мусор.
• Старый и новый адрес отдают одинаковый контент без 301, вместо этого стоит редирект через meta refresh или JS - поисковик такой редирект учитывает не так, как серверный код ответа.
• После смены правил транслитерации не пересчитаны коды у существующих элементов инфоблока, и часть карточек товаров осталась на старых адресах вперемешку с новыми.
• Кириллица в адресной строке не проверена на percent-encoding: ссылки в письмах, соцсетях или внешних каталогах ведут на некорректно закодированный URL и отдают 404.
• ЧПУ включили сразу на продакшне, без staging и без готовой таблицы редиректов, а потом чинили индексацию постфактум.
• Внутренние ссылки в меню, хлебных крошках и шаблонах не обновлены на новые адреса и продолжают тянуть трафик через цепочку редиректов вместо прямой ссылки.

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

Сколько времени занимает настройка ЧПУ в Битриксе?

На каталоге до 500-700 товаров с одним инфоблоком настройка шаблонов и urlrewrite.php занимает 1-3 дня. На крупном магазине с историей индексации счёт идёт на 2-3 недели, потому что большую часть времени занимает не сама настройка, а сбор таблицы редиректов и мониторинг после переноса.

Просядут ли позиции после включения ЧПУ?

Краткая просадка на 1-2 недели возможна почти всегда, поисковик заново обходит и переиндексирует адреса. Если 301 редиректы настроены на все проиндексированные страницы и sitemap обновлён сразу, позиции обычно восстанавливаются в течение месяца. Провал на несколько месяцев чаще всего связан не с самим ЧПУ, а с пропущенными редиректами.

Можно ли включить ЧПУ на работающем магазине без остановки продаж?

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

Что делать, если после включения ЧПУ появились дубли страниц?

Проверить canonical на дублирующихся адресах, убедиться, что старый URL действительно отдаёт 301, а не 200, и через Вебмастер/Search Console отправить старые адреса на переобход. Если дублей много и вручную не разобрать, я собираю список через парсинг структуры сайта и свожу правила редиректов одним пакетом.