1C-Bitrix Catalog Website Without Shopping Cart

We develop catalog websites on 1C-Bitrix without a shopping cart — when products are displayed but not sold online. Typical cases: industrial equipment, building materials, auto parts, real estate. The price depends on volume, region, or exchange rate — publishing a fixed price is pointless. Or the item is one-off: one excavator, one property — a cart is absurd here.

From Bitrix's perspective, this is a fundamentally different architecture. Not an "online store minus cart," but a separate project class with its own solutions at every level — from license to infoblock structure.

License: 'Start' vs 'Standard'

The first question affecting the budget. The 'Start' edition does not include the sale and catalog modules. That means: no SKUs, no price types, no cart, no orders. For a catalog without a cart, that's exactly what's needed. The 'Standard' edition includes catalog, but allows selective use: enable trade catalog properties for an infoblock but not connect sale. This gives SKUs and multiple prices without a cart.

License savings: 'Start' edition starts at 5,400 RUB, 'Standard' from 35,000 RUB. For a catalog up to 5,000 items, choosing 'Start' can save up to 50% of the license budget.

The choice depends on the scenario:

On 'Start', the catalog is built entirely on the iblock module. A product is an infoblock element, a category is a section. Infoblock properties are product characteristics. That's all. No trade wrappers.

Infoblock Structure Without SKUs

Catalog Without SKUs

One infoblock — one catalog. No 'product → SKU' link via PROPERTY_CML2_LINK. No b_catalog_product table. No b_catalog_price.

Typical structure for an industrial equipment catalog: Infoblock 'Equipment Catalog' (type catalog, API code equipment):

• Sections — categories (Pumps → Centrifugal → Horizontal)
• Elements — product items
• Properties:
  • MANUFACTURER (dictionary, linked to Highload-block) — manufacturer
  • ARTICLE (string, indexed) — article number
  • POWER (number) — power, kW
  • WEIGHT (number) — weight, kg
  • MATERIAL (list) — housing material
  • DOCS (file, multiple) — PDF documentation
  • GALLERY (file, multiple) — photos
  • PRICE_ON_REQUEST (checkbox) — price on request
  • IN_STOCK (list: 'In stock', 'On order', 'Discontinued')

  Directories are stored in Highload-blocks. Manufacturers, units of measurement, countries. HLBlock for 'Manufacturers' — table b_hlbd_manufacturers with fields UF_NAME, UF_LOGO, UF_COUNTRY, UF_WEBSITE. Linking from infoblock via property of type 'Directory'.

  Key point: without SKUs there is no b_iblock_element_property table multiplier. If a product has 15 properties and no SKU — that's 15 rows in EAV per element. With SKUs of 5 variations — 75 rows. For 10K items, the difference between 150K and 750K rows is noticeable during filtering.

  Filtering: catalog.smart.filter Without the catalog Module

  The bitrix:catalog.smart.filter component works with infoblocks even without the catalog module. But there is a nuance: facet indexes (b_catalog_sm_*) are only available when the catalog module is connected. On 'Start', there are no facets.

  Without facets, filtering is done via direct queries to b_iblock_element_property. For a catalog up to 10-15K items with 10 filterable properties, it's acceptable: 100-300ms. For 50K+, it hurts: 2-5 seconds.

  Alternatives to filter without facets:

  1. Custom filter on D7 ORM — Bitrix\Iblock\Elements\ElementXxxTable (where Xxx is the infoblock API code). Generated automatically, allows building queries via ::getList() with filter, select, runtime. Advantage: full control over SQL, ability to add caching of filter results.
  2. Elasticsearch / Sphinx — for catalogs from 50K items. Indexing via agent or event handler OnAfterIBlockElementUpdate. Filtering: 5-20ms on any volume. Disadvantage: additional infrastructure.
  3. Filter on Highload-block — if the catalog is moved to HLBlock, filtering uses a flat table with indexes. Fast, but loses standard SEO components of infoblocks.

  Recommendation for most projects: standard catalog.smart.filter + proper indexes in the database. Custom only when data proves necessity.

  CIBlockElement::GetList vs D7 ORM

  Old API: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). Works, documented, thousands of examples. Problem: no strict typing, no autocomplete in IDE, filters via array conventions (">=PROPERTY_POWER" => 100).

  D7 API: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). Strict types, fluent interface, runtime fields, registerRuntimeField() for computed columns. IDE understands structure, refactoring is safe.

  Practical rule: new code on D7, existing code — don't rewrite for the sake of rewriting. CIBlockElement::GetList won't disappear, Bitrix supports backward compatibility for decades. But if you're building a filter or aggregation from scratch, D7 gives predictable SQL and the ability to profile each query via \Bitrix\Main\Diag\SqlTracker. D7 ORM generates predictable SQL, typically yielding a 2-3x performance gain over CIBlockElement::GetList on complex filters.

  SEO for Catalog on Infoblocks

  The iblock module has built-in SEO templates. Configured at the infoblock level: 'SEO' tab → templates for sections and elements. Variables:

  • {=this.Name} — element/section name
  • {=this.PreviewText} — preview text
  • {=this.property.MANUFACTURER} — property value
  • {=parent.Name} — parent section name

  <title> template for a product: {=this.Name} — {=this.property.MANUFACTURER} {=parent.Name}. For a catalog without a cart, replace 'buy' with 'characteristics and price' or 'order'.

  SEO-friendly URLs are configured via URL template in the catalog.section / catalog.element component parameters:

  • Section: /catalog/#SECTION_CODE#/
  • Element: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/

  SECTION_CODE and ELEMENT_CODE are automatically generated from names (transliteration) when the infoblock option 'Transliterate character code when adding element' is enabled.

  Microdata — Schema.org Product without Offer (no price for purchase). Specify name, description, image, brand, sku (article number). For 'price on request' — omit offers or use priceSpecification with priceCurrency without price. Google understands, Yandex accepts via Webmaster.

  Product Comparison Without the sale Module

  The standard comparison in Bitrix (bitrix:catalog.compare.list) depends on the catalog module. On 'Start', it doesn't work. Solution: custom comparison component.

  Storage: array of selected product IDs in $_SESSION['COMPARE_LIST'][IBLOCK_ID] or in cookies (for unauthenticated users). Output: CIBlockElement::GetList by ID array with selection of all properties, rendered as a table 'property — value per product'. Implementation: 8-12 hours of development, including JS for add/remove without page reload.

  On React frontend (headless/SPA approach) — comparison stored in state or localStorage, data fetched via REST API /rest/iblock.element.get or custom controller.

  'Request Price' Instead of 'Buy'

  Central UX pattern of a catalog without cart. Implementation via webform module or custom handler.

  Form is linked to the catalog element: hidden fields pass ELEMENT_ID and ELEMENT_NAME. The manager receives an email: 'Price request for [product name], article [XXX], from [name, phone, email]'. Data saved in an application infoblock or Highload-block — to track conversion.

  CTA button variants by industry:

  • Equipment: 'Request commercial offer'
  • Real estate: 'Book a viewing'
  • Auto parts: 'Check availability and price'
  • Custom furniture: 'Calculate cost'

  1C Exchange Without the sale Module

  The catalog module supports exchange via CommerceML (/bitrix/admin/1c_exchange.php). On 'Start', this is not available. Alternative: custom import via CSV/XML or REST API.

  For a catalog without cart, exchange is usually one-way: 1C → site. Nomenclature, stock balances, characteristics. Implemented via:

  • Agent (CAgent) on schedule, parsing XML export from 1C
  • Cron task calling import script via CLI
  • REST API, if 1C can send HTTP requests (via HTTPСоединение processing)

  When using 'Standard' with the catalog module — standard CommerceML exchange works fully; the sale module is simply not connected.

  Why is a cart not needed for a B2B catalog?

  In B2B sales, a deal often requires negotiations and individual terms. The price may depend on order volume, region, or exchange rate. Additionally, many products have complex characteristics — 15+ parameters, selection by specification. In such scenarios, a cart only creates an illusion of simplicity, while actually increasing the abandonment rate during checkout. A catalog with request forms provides context for a quality commercial offer.

  Catalog vs Store

  A catalog without a cart is justified if at least two conditions are met:

  • Prices are non-public or depend on context (volume, region, contract)
  • The deal requires negotiations — cannot be completed in 2 clicks
  • Assortment is complex: product described by 15+ characteristics, selected by specification
  • No warehouse logistics on the site side

  If a cart is needed six months later, transitioning from catalog to store with proper architecture (infoblocks, separated logic) takes 2-4 weeks: connecting the sale module, adding price types, configuring payment systems and delivery services. Catalog data remains unchanged.

  What's Included in Development

  • Technical specifications and prototypes
  • Structure of infoblocks and HL-blocks
  • Catalog design, product card, filter
  • Layout and integration with Bitrix
  • Configuration of filtering, comparison, request forms
  • SEO templates and microdata
  • Data import and 1C exchange (if needed)
  • Testing and handover for operation

  Stages and Timelines

  1. Design (3-5 days) — infoblock structure, filterable property map, Figma prototypes
  2. Design (1-2 weeks) — catalog, product card, filter, comparison, request forms
  3. Development (2-5 weeks) — layout, Bitrix integration, filter setup, feedback forms, SEO
  4. Content and import (3-7 days) — product loading, 1C exchange setup if needed
  5. Testing and launch (3-5 days) — cross-browser, mobile version, PageSpeed, handover

  Scale	Timelines
  Catalog up to 500 items, no integrations	3-5 weeks
  Catalog 1-10K items, filter, comparison	5-8 weeks
  Catalog 10-50K, 1C exchange, personal account	8-12 weeks

  We have been on the market for over 5 years, implemented 40+ catalogs on Bitrix. Experience in industry, construction, distribution. Bitrix Documentation.

  Contact us to discuss your project. Order catalog development — get an offer within a day.