Переименование раздела в меню и смена его символьного кода — разные изменения. Символьный код — короткое обозначение вроде accessories, которое может использоваться в адресе раздела. Новый видимый текст может не менять адреса. Новый код способен изменить пути раздела и товаров, если они используют этот код. До сохранения нужно установить, какие URL действительно зависят от поля.
Инструкция относится к «1С-Битрикс: Управление сайтом». Собственные шаблоны, комплексные компоненты и решения Marketplace могут строить ссылки по-разному. Поэтому правильное действие начинается с небольшого списка реальных адресов, а не с массового пересоздания правил.
Как определить, какие ссылки изменятся
Откройте нужный раздел в административной панели и запишите его символьный код. Затем сохраните публичный адрес раздела и несколько товарных URL, полученных из его списка. Добавьте вложенный раздел и товар, который принадлежит двум разделам, если такие случаи существуют.
Разработчик проверяет шаблоны URL инфоблока: SECTION_PAGE_URL для раздела и DETAIL_PAGE_URL для элемента. Их назначение описано в справке Bitrix о полях инфоблоков. Рядом нужно проверить параметры компонента каталога: он может использовать собственные шаблоны вместо ожидаемых значений инфоблока.
Если ссылка использует путь разделов, изменение одного кода может затронуть дочерние страницы. Если товарный адрес построен только из кода элемента или ID, его путь может остаться прежним. Нельзя заранее объявить, что переименование меняет весь каталог или совсем не влияет на товары. Это проверяемое свойство настройки конкретного сайта.
Учебный пример: accessories стал spare-parts
Представим каталог, где раздел /catalog/accessories/ переименовывают в /catalog/spare-parts/. Карточка крепления имеет старый адрес /catalog/accessories/mount-10/. Это иллюстративный пример, а не история переноса клиента.
До изменения сохраняют соответствия:
| Объект | Старый адрес | Ожидаемый новый адрес |
|---|---|---|
| Раздел | /catalog/accessories/ | /catalog/spare-parts/ |
| Крепление | /catalog/accessories/mount-10/ | /catalog/spare-parts/mount-10/ |
| Дочерний раздел | /catalog/accessories/steel/ | /catalog/spare-parts/steel/ |
После смены кода ссылки списка должны вести на новые адреса, новые страницы — открывать правильные объекты, старые — работать по согласованному правилу переноса. Если новый товарный URL показывает раздел вместо карточки, формирование ссылки и обработка запроса разошлись.
Отдельная контрольная карточка, чей адрес не включает раздел, должна сохранить прежний URL. Эта строка защищает от слишком широкого изменения, при котором разработчик перенаправляет весь каталог по одному непроверенному шаблону.
Что проверить у ЧПУ и urlrewrite
В режиме ЧПУ компонент каталога анализирует виртуальные пути. Система обработки адресов направляет запрос к физическому PHP-файлу. Общий механизм описан в документации Bitrix по обработке адресов. У этих двух уровней разные обязанности: открыть нужный обработчик и определить конкретный раздел либо товар.
Разработчик должен проверить SEF_FOLDER, шаблоны компонентов и правило для каталога. После изменения только символьного кода внутри существующей папки каталог может продолжать обрабатываться прежним общим правилом. Пересоздание urlrewrite не является обязательным ответом на каждое изменение кода: сначала нужно показать, какая настройка перестала соответствовать маршруту.
Пересоздание правил особенно важно рассмотреть, если изменили физическую страницу подключения или папку ЧПУ через файловую загрузку. Перед ним сохраняют действующий файл и проверяют собственные правила. Официальная документация отличает автоматически пересоздаваемые правила компонентов от пользовательских правил без заполненного ID.
Новая обработка пути не создаёт автоматически перенаправление со старого URL. Это отдельная часть задачи. Не принимайте сообщение «ЧПУ пересобрано» как подтверждение сохранности старых ссылок из поиска и рекламы.
Как подготовить перенос старых адресов
Для каждого изменившегося URL определите соответствующую новую страницу. Обычно это тот же раздел или товар, а не главная сайта. Если часть товаров удалена, согласуйте их поведение отдельно: релевантная замена, сообщение об отсутствии либо другой предусмотренный ответ.
Разработчик выбирает место перенаправления с учётом действующей конфигурации сервера и CMS. Владельцу важно получить конкретную матрицу старого и нового адресов, а не универсальный фрагмент .htaccess без проверки окружения. Правило, подходящее одному каталогу Apache, нельзя без разбора переносить в другую конфигурацию.
При работе со вложенными разделами проверьте границы шаблона переноса. Подстановка должна сохранять необходимую часть пути и не затрагивать соседний раздел с похожим названием. Также проверьте старый URL с меткой рекламной кампании: он должен попадать на ту же нужную карточку, а не на ошибку маршрутизации.
Где искать оставшиеся старые ссылки
После изменения откройте меню, хлебные крошки, списки товаров, блоки рекомендаций и внутренний поиск. Ссылка из каждого места должна вести на выбранный основной URL. То, что старый адрес перенаправляет, не делает старые внутренние ссылки удобным итогом работы.
Если хлебные крошки размечены для поисковых систем, проверьте также адреса в их структурированных данных. При смене CMS вместо одного кода потребуется таблица переноса каталога.
Проверьте sitemap и canonical карточек. Они должны согласованно указывать новые основные адреса, если адреса действительно изменились. Карта может строить URL из шаблона инфоблока, а публичный список — из параметров компонента; именно поэтому эти источники проверяют отдельно.
Смотрите страницы без авторизации и после применимой очистки кеша. Если меню обновилось, а рекомендации остались со старым путём, найдите кеш соответствующего компонента. Не меняйте повторно символьный код ради исчезновения старой ссылки: это не устранит источник устаревших данных.
Что проверить у выгрузок каталога
Если старые адреса использует товарный фид, прайс или интеграция партнёра, добавьте эти источники в список проверки. Меню может уже показывать новые пути, а следующий файл обмена — снова раздавать старые. Сохраните по одному URL из каждой действующей выгрузки и сравните с таблицей переноса. Не добавляйте проверку несуществующих интеграций: сначала выясните, какие источники реально работают на вашем сайте.
Как принять изменение раздела
В задаче укажите реальный ID раздела, старый и новый код, контрольные товары, таблицу адресов и правила для старых URL. Попросите показать, какие шаблоны изменены, а какие сохранены. Дата выпуска нужна для последующего сравнения с обходом поисковой системы.
Условия приёмки учебного примера: новый раздел открывается; крепление показывает ту же карточку; дочерний раздел работает; старые адреса ведут на согласованные новые страницы; ссылки, canonical и sitemap обновлены; контрольная карточка вне изменённого пути сохранила URL.
Для проверки опубликованных страниц используйте технический аудит сайта, а смежные инструкции собраны в блоге. Изменение индекса Google или Яндекса проверяют позже по их свежим данным. Непосредственный результат разработки — рабочие адреса и воспроизводимые переходы, а не обещание сохранить каждую поисковую позицию после переименования.