Розробка сайту-каталогу без кошика на 1С-Бітрікс

Ми розробляємо сайти-каталоги на 1С-Бітрікс без кошика — коли товари демонструють, але не продають в онлайні. Типові кейси: промислове обладнання, будматеріали, автозапчастини, нерухомість. Ціна залежить від обсягу, регіону або курсу — публікувати фіксовану безглуздо. Або товар штучний: один екскаватор, один об'єкт — кошик тут абсурд.

З точки зору Бітрікса це принципово інша архітектура. Не «інтернет-магазин мінус кошик», а окремий клас проєкту зі своїми рішеннями на кожному рівні — від ліцензії до структури інфоблоків.

Ліцензія: «Старт» vs «Стандарт»

Перше питання, що впливає на бюджет. Редакція «Старт» не включає модулі sale та catalog. Це означає: немає торгових пропозицій (SKU), немає типів цін, немає кошика, немає замовлень. Для каталогу без кошика — саме те, що потрібно. Редакція «Стандарт» включає catalog, але дозволяє використовувати його вибірково: увімкнути властивості торгового каталогу для інфоблоку, але не підключати sale. Це дає торгові пропозиції та множинні ціни без кошика.

Економія на ліцензії: редакція «Старт» коштує від 5 400 руб., «Стандарт» — від 35 000 руб. При каталозі до 5 000 позицій вибір «Старту» зекономить до 50% бюджету на ліцензію.

Вибір залежить від сценарію:

На «Старті» каталог будується цілком на модулі iblock. Товар — елемент інфоблоку, категорія — розділ. Властивості інфоблоку — характеристики товару. Все. Жодних торгових обгорток.

Структура інфоблоків без SKU

Каталог без торгових пропозицій

Один інфоблок — один каталог. Немає зв'язки «товар → SKU» через PROPERTY_CML2_LINK. Немає таблиці b_catalog_product. Немає b_catalog_price.

Типова структура для каталогу промислового обладнання:

Інфоблок «Каталог обладнання» (тип catalog, API-код equipment):

• Розділи — категорії (Насоси → Відцентрові → Горизонтальні)
• Елементи — товарні позиції
• Властивості:
  • MANUFACTURER (довідник, прив'язка до Highload-блоку) — виробник
  • ARTICLE (рядок, індексоване) — артикул
  • POWER (число) — потужність, кВт
  • WEIGHT (число) — маса, кг
  • MATERIAL (список) — матеріал корпусу
  • DOCS (файл, множинне) — PDF-документація
  • GALLERY (файл, множинне) — фотографії
  • PRICE_ON_REQUEST (чекбокс) — ціна за запитом
  • IN_STOCK (список: «В наявності», «Під замовлення», «Знято з виробництва»)

Довідники — в Highload-блоках. Виробники, одиниці виміру, країни. HLBlock для довідника «Виробники» — таблиця b_hlbd_manufacturers з полями UF_NAME, UF_LOGO, UF_COUNTRY, UF_WEBSITE. Прив'язка з інфоблоку через властивість типу «Довідник».

Ключовий момент: без SKU немає таблиці b_iblock_element_property з множником варіацій. Якщо товар має 15 властивостей і немає SKU — це 15 рядків в EAV на елемент. З SKU по 5 варіацій — 75 рядків. На 10К товарів різниця між 150К і 750К рядків відчутна при фільтрації.

Фільтрація: catalog.smart.filter без модуля catalog

Компонент bitrix:catalog.smart.filter працює на інфоблоках і без модуля catalog. Але є нюанс: фасетні індекси (b_catalog_sm_*) доступні лише при підключеному модулі catalog. На «Старті» фасетів немає.

Без фасетів фільтрація виконується через прямі запити до b_iblock_element_property. На каталозі до 10-15К позицій з 10 фільтруваними властивостями — прийнятно, 100-300ms. На 50К+ — вже боляче, 2-5 секунд.

Альтернативи фільтру без фасетів:

1. Кастомний фільтр на D7 ORM — Bitrix\Iblock\Elements\ElementXxxTable (де Xxx — API-код інфоблоку). Генерується автоматично, дозволяє будувати запити через ::getList() з filter, select, runtime. Плюс: повний контроль над SQL, можна додати кешування результатів фільтрації.
2. Elasticsearch / Sphinx — для каталогів від 50К позицій. Індексація через агент або обробник події OnAfterIBlockElementUpdate. Фільтрація — 5-20ms на будь-якому обсязі. Мінус: додаткова інфраструктура.
3. Фільтр на Highload-блоці — якщо каталог перенесено в HLBlock, фільтрація йде по пласкій таблиці з індексами. Швидко, але втрачаються штатні SEO-компоненти інфоблоків.

Рекомендація для більшості проєктів: стандартний catalog.smart.filter + правильні індекси в БД. Кастом — тільки коли дані доводять необхідність.

CIBlockElement::GetList vs D7 ORM

Старе API: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). Працює, документовано, прикладів тисячі. Проблема — немає строгої типізації, немає автодоповнення в IDE, фільтри через масиви-угоди (">=PROPERTY_POWER" => 100).

D7 API: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). Строгі типи, fluent-інтерфейс, runtime-поля, registerRuntimeField() для computed-колонок. IDE розуміє структуру, рефакторинг безпечний.

Практичне правило: новий код — на D7, існуючий — не переписувати заради переписування. CIBlockElement::GetList нікуди не дінеться, Бітрікс підтримує зворотну сумісність десятиліттями. Але якщо будуєте фільтр або агрегацію з нуля — D7 дає передбачуваний SQL і можливість профілювати кожен запит через \Bitrix\Main\Diag\SqlTracker. D7 ORM генерує передбачуваний SQL, що зазвичай дає приріст продуктивності в 2–3 рази порівняно з CIBlockElement::GetList на складних фільтрах.

SEO для каталогу на інфоблоках

Модуль iblock має вбудовані SEO-шаблони. Налаштовуються на рівні інфоблоку: вкладка «SEO» → шаблони для розділів та елементів. Змінні:

• {=this.Name} — назва елемента/розділу
• {=this.PreviewText} — анонс
• {=this.property.MANUFACTURER} — значення властивості
• {=parent.Name} — назва батьківського розділу

Шаблон <title> для товару: {=this.Name} — купити {=parent.Name} від {=this.property.MANUFACTURER}. Для каталогу без кошика «купити» замінюємо на «характеристики та ціна» або «замовити».

ЧПУ налаштовуються через шаблон URL в параметрах компонента catalog.section / catalog.element:

• Розділ: /catalog/#SECTION_CODE#/
• Елемент: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/

SECTION_CODE та ELEMENT_CODE генеруються автоматично з назви (транслітерація) при увімкненій опції інфоблоку «Транслітерувати символьний код під час додавання елемента».

Мікророзмітка — Schema.org Product без Offer (немає ціни для покупки). Вказуємо name, description, image, brand, sku (артикул). Для «ціна за запитом» — пропускаємо offers або використовуємо priceSpecification з priceCurrency без price. Google зрозуміє, Яндекс прийме через Вебмастер.

Порівняння товарів без модуля sale

Штатне порівняння в Бітріксі (bitrix:catalog.compare.list) залежить від модуля catalog. На «Старті» не працює. Рішення — кастомний компонент порівняння.

Зберігання: масив ID вибраних товарів у $_SESSION['COMPARE_LIST'][IBLOCK_ID] або в cookie (для незалогінених). Виведення: CIBlockElement::GetList за масивом ID з вибіркою всіх властивостей, рендер в таблицю «властивість — значення по товарах». Реалізація — 8-12 годин розробки, включаючи JS для додавання/видалення без перезавантаження сторінки.

На React-фронті (headless/SPA-підхід) — порівняння зберігається в state або localStorage, дані тягнуться через REST API /rest/iblock.element.get або кастомний контролер.

«Запитати ціну» замість «Купити»

Центральний UX-патерн каталогу без кошика. Реалізація через веб-форму (webform модуль) або кастомний обробник.

Форма прив'язується до елемента каталогу: в прихованому полі передається ELEMENT_ID та ELEMENT_NAME. Менеджер отримує листа: «Запит ціни на [назва товару], артикул [XXX], від [ім'я, телефон, email]». Дані зберігаються в інфоблоці заявок або в Highload-блоці — щоб відстежувати конверсію.

Варіанти CTA-кнопок залежно від галузі:

• Обладнання: «Запитати комерційну пропозицію»
• Нерухомість: «Записатися на перегляд»
• Автозапчастини: «Уточнити наявність та ціну»
• Меблі на замовлення: «Розрахувати вартість»

Обмін з 1С без модуля sale

Модуль catalog підтримує обмін через CommerceML (/bitrix/admin/1c_exchange.php). На «Старті» цього немає. Альтернатива — кастомний імпорт через CSV/XML або REST API.

Для каталогу без кошика обмін зазвичай односторонній: 1С → сайт. Номенклатура, залишки, характеристики. Реалізується через:

• Агент (CAgent) за розкладом, що парсить XML-вивантаження з 1С
• Cron-задача, що викликає скрипт імпорту через CLI
• REST API, якщо 1С вміє надсилати HTTP-запити (через обробку HTTPСоединение)

При використанні «Стандарту» з модулем catalog — штатний обмін CommerceML працює повноцінно, просто модуль sale не підключається.

Каталог vs магазин

Каталог без кошика виправданий, якщо виконується хоча б дві умови:

• Ціни непублічні або залежать від контексту (обсяг, регіон, договір)
• Угода потребує переговорів — не можна оформити за 2 кліки
• Асортимент складний: товар описується 15+ характеристиками, вибирається за специфікацією
• Немає складської логістики на стороні сайту

Якщо через півроку знадобиться кошик — перехід з каталогу на магазин при правильній архітектурі (інфоблоки, розділення логіки) займає 2-4 тижні: підключення модуля sale, додавання типів цін, налаштування платіжних систем і служб доставки. Дані каталогу залишаються без змін.

Що входить у розробку

• Технічне завдання та прототипи
• Структура інфоблоків і HL-блоків
• Дизайн каталогу, картки товару, фільтра
• Верстка та інтеграція з Бітрікс
• Налаштування фільтрації, порівняння, форм заявок
• SEO-шаблони та мікророзмітка
• Імпорт даних та обмін з 1С (при необхідності)
• Тестування та передача в експлуатацію

Етапи та терміни

1. Проектування (3-5 днів) — структура інфоблоків, карта фільтруваних властивостей, прототипи в Figma
2. Дизайн (1-2 тижні) — каталог, картка товару, фільтр, порівняння, форми заявок
3. Розробка (2-5 тижнів) — верстка, інтеграція з Бітрікс, налаштування фільтра, форми зворотного зв'язку, SEO
4. Наповнення та імпорт (3-7 днів) — завантаження товарів, налаштування обміну з 1С при необхідності
5. Тестування та запуск (3-5 днів) — кросбраузерність, мобільна версія, PageSpeed, передача в експлуатацію

Ми на ринку більше 5 років, реалізували 40+ каталогів на Бітрікс. Досвід у промисловості, будівництві, дистрибуції. Документація Бітрікс.

Зв'яжіться з нами, щоб обговорити ваш проєкт. Замовте розробку каталогу — отримайте оферту протягом дня.

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.