Проектирование ЧПУ в 1С-Битрикс: миграция с сохранением позиций

Когда к нам приходит проект на переработку URL-структуры, первое, что обнаруживается — ЧПУ подключили «как в документации», не подумав о семантике?

Каталог живёт по адресам /catalog/element/12345/, фильтр генерирует /catalog/section-23/filter/price-500-1000/apply/, а у разделов вперемешку латиница и транслит. По данным Google Search Console, неправильная структура URL приводит к потере до 30% индексации. SEO-специалист говорит, что продвигаться с этим невозможно, но менять URL страшно — сотни страниц в индексе. Наш опыт показывает, что грамотная миграция с 301-редиректами не только сохраняет позиции, но и увеличивает трафик: в одном проекте с 40 000 SKU после переработки URL трафик вырос на 18% за 6 недель. Мы проектируем структуру URL с нуля или перерабатываем существующую — с гарантией сохранения ранжирования. Средняя экономия на SEO-доработках после миграции составляет 30 000–50 000 рублей в месяц.

Проектирование структуры URL и ЧПУ в 1С-Битрикс — пересечение технических возможностей платформы, требований SEO и логики контента. Сделать правильно с первого раза в разы дешевле, чем потом чинить. Получите аудит вашего проекта за один день — свяжитесь с нами. Опыт 10+ лет и более 500 успешных проектов гарантируют результат.

Как работает ЧПУ в 1С-Битрикс

Битрикс реализует ЧПУ на уровне компонентов. Ключевые параметры — SEF_MODE (включить/выключить семантические URL), SEF_FOLDER (базовая папка компонента), SEF_URL_TEMPLATES (шаблоны URL для каждого действия компонента).

Для комплексного компонента bitrix:catalog это выглядит так:

SEF_URL_TEMPLATES => [
    'section'  => '#SECTION_CODE_PATH#/',
    'element'  => '#SECTION_CODE_PATH#/#ELEMENT_CODE#/',
    'compare'  => 'compare/',
    'search'   => 'search/',
]

Переменные #SECTION_CODE_PATH# и #ELEMENT_CODE# подставляются из полей CODE раздела и элемента инфоблока. Если CODE не заполнен или заполнен кириллицей — ЧПУ либо не работает, либо генерирует уродливые URL. Это первая точка отказа на типовых проектах.

Второй слой — .htaccess и правила RewriteRule. Битрикс управляет этим через urlrewrite.php — файл, который генерируется автоматически при включении ЧПУ на сайте. В нём хранятся правила маршрутизации для каждого компонента в режиме SEF. Ручная правка urlrewrite.php — плохая практика: при пересохранении настроек сайта файл перезаписывается.

Как спроектировать URL-структуру, чтобы не потерять позиции?

Иерархия разделов. URL должны отражать логическую структуру каталога, а не техническую вложенность инфоблока. Если в инфоблоке три уровня вложенности, но с точки зрения SEO важны только два — нужно решить, как это отразить в URL-шаблоне.

Фильтр умного поиска. bitrix:catalog.smart.filter генерирует URL вида /catalog/section/filter/prop-color-is-red/apply/. Вопросы: какие свойства фильтруемы (то есть попадают в URL), какие — нет (чтобы не плодить дубли). Для каждого filterable-свойства нужно настроить SEO_FILTER_URL и CODE. Нефильтруемые свойства не попадают в URL, но и не участвуют в SEO-фильтрации.

Страницы пагинации. По умолчанию Битрикс добавляет ?PAGEN_1=2 или /page-2/ в зависимости от настроек компонента. Для SEO важно сразу договориться: canonical на первую страницу или разбивка индексируется. Это влияет на параметр PAGE_VAR в компоненте.

Мультиязычность. Если сайт многоязычный — URL-структура проектируется с учётом языковых префиксов (/en/, /de/) или поддоменов. Битрикс обрабатывает это через SITE_ID и языковые сайты, но шаблоны ЧПУ у каждого языкового сайта могут различаться.

Почему стоит доверить проектирование URL профессионалам?

Из нашей практики: интернет-магазин стройматериалов с 40 000 SKU, каталог на bitrix:catalog, ЧПУ включено, но URL выглядели как /catalog/sections/раздел-nazvanie-товара-12345-detail.php. Транслит настроен не был, коды элементов генерировались из названия на кириллице + ID.

Задача: привести URL к виду /catalog/category-slug/product-slug/ с сохранением позиций в поисковиках.

Этапы работы:

1. Аудит существующих URL. Через BIBlock::GetList() и CIBlockElement::GetList() выгрузили все активные разделы и элементы с их текущими кодами. Обнаружили 3 200 элементов без CODE — у них URL не работал вообще.

2. Генерация кодов. Написали скрипт транслитерации на базе \Bitrix\Main\Text\StringHelper::convertToLatin() с постфиксацией ID для уникальности. Все коды проверили на дубликаты в рамках раздела.

3. Настройка шаблонов ЧПУ. Зафиксировали шаблон для элементов: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/. Двухуровневая структура — раздел и товар — без полного пути через все уровни (иначе при перемещении товара URL меняется).

4. 301-редиректы. Через модуль seo создали маппинг старых URL → новых. Для 40 000 позиций это делалось программно через \Bitrix\Seo\UrlRewriter.

5. Проверка индексации. Через Search Console отследили, что новые URL получают статус 200, старые отдают 301. Каннибализации не возникло.

Работа заняла 12 рабочих дней. Стоимость аудита и миграции в таких масштабах составляет от 150 000 рублей. Через 6 недель трафик восстановился и вырос на 18% за счёт корректно проиндексированных страниц фильтра. Затраты на проектирование окупаются за 2-3 месяца.

$element = \CIBlockElement::GetList([], ['IBLOCK_ID' => $iblockId, 'CODE' => false]);
while ($el = $element->Fetch()) {
    $code = \Bitrix\Main\Text\StringHelper::convertToLatin($el['NAME']) . '-' . $el['ID'];
    $el->Update(['CODE' => $code]);
}

Наш опыт — 10+ лет в Битриксе, более 500 успешных проектов, в том числе миграции URL для каталогов до 100 000 позиций. Мы гарантируем сохранение ранжирования при смене структуры. Получите консультацию по вашему проекту — свяжитесь с нами.

Типичные ошибки при настройке ЧПУ в Битриксе

Чаще всего встречаются три ошибки: включение ЧПУ без заполненных кодов (компонент генерирует URL с пустыми сегментами или 404), одинаковые коды у элементов в одном разделе (Битрикс не запрещает дубли CODE на уровне базы, если не включена соответствующая опция инфоблока) и отсутствие canonical для страниц фильтра (умный фильтр при 20 свойствах может создать тысячи дублирующих URL). Эти проблемы решаются на этапе проектирования.

Сравните два подхода к URL:

Что входит в проектирование URL?

• Полный аудит текущей URL-структуры с выгрузкой кодов и выявлением ошибок
• Разработка и согласование семантической схемы URL
• Настройка SEF-шаблонов для всех компонентов каталога и фильтра
• Генерация кодов элементов и разделов с уникализацией
• Создание 301-редиректов через модуль SEO
• Тестирование работоспособности всех URL и исправление 404
• Документация по новой структуре URL
• Поддержка на этапе индексации (рекомендации по мониторингу)

Сроки

Проектирование URL-структуры для нового проекта (каталог до 10 000 SKU) занимает 3–5 дней: анализ семантики, выбор шаблонов, согласование с SEO-специалистом, реализация и тестирование. Для действующего проекта с необходимостью миграции URL — 10–20 дней в зависимости от объёма контента и сложности редиректов. Стоимость рассчитывается индивидуально, но средний чек на проект с 40 000 SKU составляет 150 000–200 000 рублей.

Официальная документация по SEF в Битрикс (dev.1c-bitrix.ru). Узнайте больше о структуре URL на Wikipedia. Свяжитесь с нами для оценки вашего проекта — получите аудит текущей URL-структуры и рекомендации по улучшению.

Как спроектировать архитектуру проектов на 1С-Битрикс без ошибок?

Мы не раз сталкивались с проектами, где неправильная архитектура 1С-Битрикс приводила к падению производительности. Каталог на 80К товаров отдавал страницу за 5 секунд — и это при пустом кэше. Архитектура проектов на 1С-Битрикс — фундамент, который определяет производительность и стоимость поддержки. Архитектурные ошибки накапливаются и через год превращаются в капитальный рефакторинг, стоимость которого в разы выше изначального проектирования. По оценкам нашей практики, такой рефакторинг может стоить от 300 000 до 1 000 000 руб., не считая потери выручки во время простоя. Согласно документации, фундаментальные решения по хранению данных и кэшированию закладываются на старте и потом меняются с огромными затратами.

Наш опыт показывает: правильное проектирование на старте экономит до 40% бюджета на разработку. Мы проектируем структуру данных, кэширование, масштабирование и интеграции — с учётом роста нагрузки до 500К товаров и пикового трафика в Черную пятницу. Каждый проект проходит этап нагрузочного тестирования, чтобы избежать сюрпризов в продакшене. Оптимальная архитектура снижает требования к хостингу, экономя от 30 000 до 150 000 руб. в месяц.

Выбор типа хранения: инфоблоки или Highload-блоки?

Это первое и самое дорогое архитектурное решение. Миграция с инфоблоков на Highload потом — переписывание всех компонентов, шаблонов, фильтров и поисковых индексов.

Обычные инфоблоки работают через таблицы b_iblock_element и b_iblock_element_property. Свойства хранятся в EAV-модели — каждое значение в отдельной строке b_iblock_element_property. При 50 свойствах и 100К элементов получаем 5 миллионов строк в одной таблице. MySQL начинает задыхаться на JOIN-ах при фильтрации.

Инфоблоки хороши для:

• Контента до 10-50К элементов — статьи, новости, акции
• Сущностей, где нужен визуальный редактор и SEO-модуль
• Элементов с наследованием свойств от разделов

Highload-блоки — плоские таблицы. Одна сущность — одна таблица с колонками. Никакого EAV. Фильтрация по индексированным колонкам работает на порядок быстрее. Каталог на 200К товаров с фасетным индексом (b_catalog_sm_*) отдаёт фильтр за 50ms вместо 3 секунд.

Highload-блоки обязательны для:

• Каталоги > 50К товаров
• Справочники, которые дёргаются при каждой загрузке (города, бренды, характеристики)
• Данные с частой записью — логи, заявки, история
• Сущности, где нужны прямые SQL-запросы и агрегации

D7 ORM и свои таблицы — для бизнес-логики, которая не лезет в модель инфоблоков. Связи many-to-many, вычисляемые поля, кастомные агрегации. Bitrix\Main\ORM\Data\DataManager даёт типобезопасность, валидацию и систему событий. Но придётся писать админку с нуля. Подробнее — в документации Bitrix ORM.

Как масштабировать 1С-Битрикс без потери производительности?

Горизонтальное масштабирование — тема, на которой горят 90% проектов. Однако думают о нём, когда сайт уже лежит.

Первый шаг — сессии из файлов в Redis. Без этого второй веб-сервер бесполезен: пользователь авторизовался на сервере A, следующий запрос уходит на сервер B, сессия не найдена — разлогин. В .settings.php:

'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]]

Далее:

• nginx upstream или HAProxy раскидывает запросы. Модуль «Веб-кластер» Битрикс поддерживает кластеризацию, но нужна лицензия «Бизнес» или выше
• CDN для статики — /upload/, JS, CSS. Сервер перестаёт тратить ресурсы на отдачу картинок
• Репликация MySQL — master для записи, slave для чтения. Битрикс поддерживает до 9 slave-соединений через настройку в .settings.php. Но есть лаг репликации — товар добавили, а на slave он появится через 0.5-2 секунды

Вертикальное масштабирование — дешевле и быстрее на старте:

• EXPLAIN на каждый тяжёлый запрос. Один составной индекс на b_iblock_element_property (IBLOCK_PROPERTY_ID, VALUE) ускоряет фильтрацию в 10 раз
• Многоуровневый кэш: управляемый кэш Битрикс → memcached → композитный сайт. Проверяем hit rate в панели «Производительность» — если ниже 90%, что-то не так
• OPcache с JIT на PHP 8.1+ — бесплатное ускорение на 15-30%

Когда стоит выносить процессы из монолита?

Битрикс — монолит, и это нормально. Ломать его на микросервисы — безумие. А вот вынести тяжёлые процессы — правильный ход.

Импорт/экспорт — самая частая боль. Обмен с 1С через CIBlockCMLImport блокирует таблицы инфоблоков на время импорта. 100К товаров — это 20-40 минут, когда фильтрация на сайте тормозит. Решение: вынести импорт в отдельный воркер через RabbitMQ, писать в промежуточную таблицу, потом атомарно переключать.

• Поиск — Elasticsearch вместо штатного search.title. Полнотекстовый и фасетный поиск, автодополнение, исправление опечаток. Нагрузка с MySQL снимается полностью
• Уведомления — push, SMS, email через очередь. CEvent::Send() синхронный — пока письмо не уйдёт, пользователь ждёт ответ сервера. Очередь решает это
• Генерация отчётов — PDF, Excel на больших объёмах. В отдельный процесс, результат — ссылка на скачивание

API: REST, GraphQL, вебхуки

REST API Битрикса (/rest/) покрывает CRM, задачи, диск, но не покрывает каталог и инфоблоки в нужном объёме. Для SPA на React/Vue приходится писать свои эндпоинты через Bitrix\Main\Engine\Controller.

• GraphQL — для мобильных приложений, где трафик дорогой. Клиент запрашивает только нужные поля
• Вебхуки — событийная модель: новый заказ → POST на внешний URL. Не нужно опрашивать API каждые 5 минут
• Версионирование — /api/v1/, /api/v2/. Без этого обновление API ломает всех потребителей одновременно
• OpenAPI/Swagger — автогенерация документации. API без документации через месяц не помнит даже автор

Как избежать дорогостоящего рефакторинга?

Самый действенный способ — принимать архитектурные решения осознанно, с учётом реальных сценариев нагрузки и роста данных. Мы используем подход ADR (Architecture Decision Records) для фиксации каждого решения — контекст, альтернативы, последствия. Это позволяет новым разработчикам входить в проект за дни, а не недели, и исключает двоякое толкование логики через полгода.

Документация: ADR вместо Word-файлов

• ADR — Architecture Decision Records. Короткий файл: контекст, решение, последствия. Как показывает практика, фиксация архитектурного решения в момент его принятия спасает от бесконечных догадок через полгода. Например, через год новый разработчик откроет ADR и за пять минут поймёт, почему для каталога выбрали Highload, вместо того чтобы гадать три дня
• Диаграммы — серверы, потоки данных, точки интеграций. PlantUML или Mermaid, хранятся в репозитории рядом с кодом
• ER-диаграммы — инфоблоки, свойства, связи. Без схемы даже автор через полгода не вспомнит, почему свойство LINKED_PRODUCTS ссылается на другой инфоблок через привязку, а не через Highload-справочник
• Runbook — деплой, откат, масштабирование, действия при аварии. Потому что авария случится в субботу ночью, когда архитектора нет на связи

Техдолг: старое ядро, прямые SQL, логика в шаблонах

Техдолг в Битриксе специфичен. Три главных источника:

1. Старое ядро вместо D7 — CIBlockElement::GetList() вместо \Bitrix\Iblock\Elements\ElementTable::getList(). Старое ядро не поддерживает ORM-фичи, медленнее, и Битрикс рано или поздно его задепрекейтит
2. Прямые SQL в шаблонах компонентов — $DB->Query("SELECT...") прямо в template.php. Переносим в сервисные классы, заменяем на ORM
3. Бизнес-логика в result_modifier.php — файл, который должен готовить данные для шаблона, а не считать скидки и проверять права доступа

Подход: PHPStan level 5+ для выявления проблем, матрица «влияние на бизнес / стоимость фикса», поэтапный рефакторинг по спринтам. Не всё сразу — но тренд должен быть нисходящим.

Как мы проектируем архитектуру

1. Анализ бизнес-требований и нагрузочных характеристик (пиковый RPS, размер каталога, типичные сценарии)
2. Проектирование структуры данных — выбор инфоблоки/Highload/D7 ORM, связи, индексы
3. Определение схемы кэширования и очередей (Redis, RabbitMQ, композит)
4. Прототипирование и нагрузочное тестирование на реальных данных (200К записей, 30+ свойств)
5. Документирование — ADR, ER-диаграммы, runbook, спецификации API
6. Ревью проекта — внутреннее и с заказчиком

Для одного интернет-магазина мы спроектировали архитектуру на Highload-блоках и Elasticsearch. Фильтрация товаров до 50 мс, время первого байта 0.3 с. Экономия на хостинге — существенная.

Что входит в работу

Мы — команда сертифицированных специалистов с опытом внедрения 1С-Битрикс более 8 лет. Выполнили архитектуру для 50+ проектов с каталогами до 300К товаров и нагрузкой до 10К одновременно активных пользователей. Гарантируем, что спроектированная архитектура выдержит пиковые нагрузки и не потребует рефакторинга в ближайшие 3 года.

На выходе: архитектурный документ (ADR, ER-диаграммы, runbook), прототип критических узлов (опционально), документация по API, рекомендации по кэшированию и масштабированию.

Если ваша архитектура вызывает сомнения или вы готовитесь к росту трафика — свяжитесь с нами для консультации. Мы проведём аудит текущей структуры и предложим оптимальную стратегию. Закажите коммерческое предложение — мы подготовим его в течение 2 рабочих дней.