1С Битрикс · 6 мин чтения

ЧПУ Битрикс: настройка SEF-правил без ошибок 404

ЧПУ Битрикс SEF правила всплывают у меня в работе регулярно: клиент переносит каталог на новый домен, включает человекопонятные урлы, и тут начинаются письма из Яндекс.Вебмастера про рост ошибок 404. Модуль урлов в 1С-Битрикс устроен не как плагин пермалинков в WordPress, а как связка настроек инфоблока, компонента и файла urlrewrite.php, и одна опечатка в шаблоне ломает сразу весь раздел каталога.

Что такое SEF-правила и зачем включать ЧПУ в Битрикс

SEF расшифровывается как Search Engine Friendly, и в терминологии Битрикс это режим, при котором компонент сам генерирует человекопонятный урл вместо адреса вида /index.php?ELEMENT_ID=128. Без ЧПУ поисковик видит технические параметры, а не структуру каталога, и ссылки на карточки товаров выглядят одинаково бессмысленно что для Яндекса, что для покупателя, который пересылает ссылку в мессенджер.

SEF-правила задаются не в одном месте, а в трёх точках одновременно: в настройках компонента (обычно catalog.section или news.detail), в поле «ЧПУ включено» инфоблока и в файле urlrewrite.php, куда Битрикс пишет соответствие между шаблоном урла и физическим путём к компоненту. Если поменять что-то в одном месте и забыть про остальные два, получаешь ровно ту ситуацию, из-за которой обычно и открывают эту статью: сайт вроде бы работает, а часть страниц отдаёт 404.

Где включать ЧПУ: настройки инфоблока и компонента

Включение начинаю с инфоблока: «Контент» → «Инфоблоки» → нужный инфоблок → вкладка «ЧПУ». Там два поля, которые путают чаще всего:

  • «ЧПУ для раздела» - шаблон урла для страницы категории, обычно вида #SECTION_CODE_PATH#/
  • «ЧПУ для элемента» - шаблон для карточки товара или новости, вида #SECTION_CODE_PATH#/#ELEMENT_CODE#/

После сохранения инфоблока идёт настройка компонента на странице каталога: параметр SEF_MODE должен стоять в «Y», а в блоке SEF_URL_TEMPLATES прописываются те же переменные, что и в инфоблоке, только применительно к конкретной странице сайта, включая раздел «Фильтр» и постраничную навигацию, если используется компонент catalog с умным фильтром. Расхождение шаблонов между инфоблоком и компонентом - вторая по частоте причина 404 после банального опечатанного слэша.

Синтаксис SEF-правил: шаблоны и переменные

Шаблон ЧПУ строится из статичных сегментов пути и переменных в решётках. Самые ходовые:

  • #SECTION_CODE_PATH# - вложенная цепочка кодов разделов, собирается автоматически по дереву каталога
  • #ELEMENT_CODE# - символьный код элемента, который лежит в поле «ЧПУ-код» карточки
  • #ELEMENT_ID# - числовой идентификатор, использую как запасной вариант, если у элементов не заполнены символьные коды
  • #SECTION_ID# - тот же принцип, но для раздела

Пример правила для карточки товара

В urlrewrite.php Битрикс сам создаёт запись при сохранении компонента, но иногда её приходится править руками, например при переносе каталога с другим deep-линком.

array(
  "CONDITION" => "#^/catalog/([^/]+)/([^/]+)/#",
  "RULE" => "SECTION_CODE_PATH=\$1&ELEMENT_CODE=\$2",
  "ID" => "bitrix:catalog.element",
  "PATH" => "/catalog/detail.php",
),

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

Пример правила для раздела каталога

Для разделов логика та же, только без второй переменной:

array(
  "CONDITION" => "#^/catalog/([^/]+)/#",
  "RULE" => "SECTION_CODE_PATH=\$1",
  "ID" => "bitrix:catalog.section",
  "PATH" => "/catalog/index.php",
),

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

Бесплатный материал

🎁 Полезный скрипт в подарок

Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.

Без спама. Отписка в 1 клик.

Частые причины 404 после включения ЧПУ

За несколько лет работы с проектами на Битрикс причины 404 после смены ЧПУ повторяются с завидным постоянством:

Причина Где искать Как чиню
Расхождение шаблона в инфоблоке и компоненте Настройки инфоблока и параметры SEF_URL_TEMPLATES компонента Привожу шаблоны к одному виду в обеих точках
Пустой символьный код у элемента Поле «ЧПУ-код» карточки товара или новости Массово пересчитываю коды через агент на CIBlockElement
Кэш компонента отдаёт старый урл Настройки кэширования компонента и HTML-кэш сайта Сбрасываю кэш через «Настройки» → «Автокэширование»
Правило раздела стоит выше правила элемента Порядок записей в urlrewrite.php Меняю очерёдность вручную в файле
Изменили ЧПУ-код после индексации История правок в карточке товара Ставлю 301-редирект со старого урла на новый

301-редиректы со старых адресов на новые ЧПУ-урлы

Переезд на новую схему урлов без редиректов - гарантированная просадка трафика на несколько недель, пока Яндекс и Google переиндексируют сайт. Проверяю через Метрику или Search Console список старых адресов с накопленным трафиком и на каждый прописываю правило в .htaccess или, если сайт на «1С-Битрикс: Управление сайтом», через модуль «Настройка перенаправлений» в административной панели.

Для точечных случаев (переименовали раздел, поменяли код товара) хватает одиночного правила redirect 301. Для массового переноса каталога, где меняется структура сразу у тысяч карточек, пишу скрипт на PHP, который сопоставляет старый ID с новым ЧПУ-урлом по таблице соответствий и заливает результат одним файлом в блок редиректов. Ручной перебор такого объёма урлов физически нереален, а гуглить каждую страницу вручную занимает недели там, где скрипт отрабатывает за час.

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

Проверка и отладка SEF-правил перед публикацией

Перед тем как выкатывать новые ЧПУ-правила на продакшн, прогоняю три проверки:

  • Открываю 15-20 случайных карточек и разделов вручную, включая самые вложенные уровни каталога, где чаще всего теряются переменные пути
  • Смотрю логи сервера на 404 за сутки после выкладки - именно там видно урлы, которые реальные пользователи и боты запрашивают, а не только те, что я предположил при тестировании
  • Проверяю robots.txt и файл sitemap.xml на предмет старых адресов, которые давно пора убрать, чтобы поисковик не тратил краулинговый бюджет на несуществующие страницы

Отдельно смотрю на дубли: если ЧПУ и старый технический урл (index.php?ELEMENT_ID=) одновременно открываются без редиректа, поисковик видит две страницы с одинаковым содержимым, и это бьёт по позициям сильнее, чем разовая 404. Проверяется командой canonical в исходном коде страницы - если тег указывает на ЧПУ-версию, значит правило редиректа с технического урла ещё не стоит и его нужно добавить.

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

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

Чаще всего у элемента пустое поле «ЧПУ-код», и шаблон урла не может его собрать. Проверяю карточку в админке: если код не заполнен, Битрикс подставляет число вместо символьного значения, и урл не совпадает ни с одним правилом в urlrewrite.php.

Нужно ли вручную редактировать urlrewrite.php или Битрикс справляется сам?

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

Как проверить, что SEF-правила не конфликтуют между собой?

Открываю urlrewrite.php и читаю сверху вниз, представляя, что я сервер, который ищет первое совпадение по CONDITION. Если два правила теоретически подходят под один и тот же урл, побеждает то, что стоит выше, и это нужно проверять руками, автоматической валидации внутри админки для этого нет.

Что делать, если после смены ЧПУ упал трафик из поиска?

Сначала проверяю, стоят ли 301-редиректы со старых адресов на новые, затем смотрю Search Console на предмет ошибок индексации и обновляю sitemap.xml. Если старые страницы отдают 404 без редиректа, поисковик какое-то время держит их в индексе как битые, и это тянет вниз весь раздел, а не только конкретные урлы.

Есть задача?

Обсудим в мессенджере

Расскажите, что нужно сделать — отвечу в течение 4 часов в рабочее время. Первая консультация бесплатно.

Продолжая пользование настоящим сайтом Вы выражаете своё согласие на обработку Ваших персональных данных (файлов куки) с использованием Yandex.Metrika.
Понятно