Розробка сайту-каталогу без кошика на 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 не підключається.

  Чому для B2B-каталогу не потрібен кошик?

  У B2B-продажах угода часто потребує переговорів та індивідуальних умов. Ціна може залежати від обсягу партії, регіону або курсу валюти. Крім того, у багатьох товарів складні характеристики — 15+ параметрів, вибір за специфікацією. У таких сценаріях кошик тільки створює ілюзію простоти, а на ділі збільшує відсоток відмови при оформленні. Каталог з формами запитів дає контекст для якісної комерційної пропозиції.

  Каталог 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, передача в експлуатацію

  Масштаб	Терміни
  Каталог до 500 позицій, без інтеграцій	3-5 тижнів
  Каталог 1-10К позицій, фільтр, порівняння	5-8 тижнів
  Каталог 10-50К, обмін з 1С, особистий кабінет	8-12 тижнів

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

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