Проектування ЧПУ в 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-tovaru-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С-Бітрікс — фундамент, який визначає продуктивність і вартість підтримки. Помилки накопичуються і через рік перетворюються на капітальний рефакторинг, вартість якого в рази вища за початкове проектування. За оцінками нашої практики, такий рефакторинг може коштувати значно, не рахуючи втрати виручки під час простою. Фундаментальні рішення щодо зберігання даних та кешування закладаються на старті — потім змінюються з величезними витратами.

Правильне проектування на старті економить до 40% бюджету на розробку. Ми проектуємо структуру даних, кешування, масштабування та інтеграції — з урахуванням зростання навантаження до 500К товарів та пікового трафіку в Чорну п’ятницю. Кожен проект проходить етап навантажувального тестування, щоб уникнути сюрпризів у продакшені. Оптимальна архітектура знижує вимоги до хостингу, заощаджуючи значну суму щомісяця.

Вибір типу зберігання: інфоблоки або 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-блоки з індексованими колонками фільтрують дані в 10 разів швидше, ніж EAV-модель інфоблоків.

Highload-блоки обов'язкові для:

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

D7 ORM та свої таблиці — для бізнес-логіки, яка не вписується в модель інфоблоків. Зв'язки many-to-many, обчислювані поля, кастомні агрегації. Bitrix\Main\ORM\Data\DataManager дає типобезпеку, валідацію та систему подій. Але доведеться писати адмінку з нуля.

Як масштабувати 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 робочих днів. Щоб отримати персональну консультацію щодо вашого проекту, напишіть нам — розкажемо, які архітектурні рішення підійдуть саме вам.