Product Catalog Structure Design for 1C-Bitrix
The most costly mistake in a Bitrix e-commerce project is discovering incorrect catalog structure six months after launch. Restructuring iblocks with live data, a configured 1C exchange, and a running site is not a "rework" — it is effectively a new project with migration. That is why catalog structure design happens before the first line of code is written and before the 1C sync is configured.
Modules Involved in the Catalog
The product catalog in Bitrix is not a single module — it is the interaction of several:
-
iblock— storing products and their properties -
catalog— commerce logic: prices, stock, discounts, product types (b_catalog_product,b_catalog_price,b_catalog_store_amount) -
sale— cart and checkout -
search— full-text search
The catalog structure is designed with all modules in mind, not only iblock. For example, if multi-warehouse stock is planned, warehouses must be defined in b_catalog_store, and this affects how stock levels are displayed on the product card.
"Single iblock" vs. "Multiple iblocks" Schema
A classic dilemma. Using separate iblocks for different product categories looks attractive (each category has its own properties), but creates problems:
- The filter cannot work across properties from different iblocks
- The 1C sync must be configured separately for each iblock
- Full-catalog search requires merging results
A single iblock for the entire catalog is the default rule. Properties specific to certain categories are added to the shared schema and remain empty for products in other categories. This looks "wasteful" only at first glance: empty values in b_iblock_element_property are not stored.
Exception: a catalog with fundamentally different data structures (e.g., physical products and digital services in the same store) — then two iblocks are justified, but with a unified search system and separate components.
Section Hierarchy and Nesting Depth
Catalog sections (b_iblock_section) form a category tree. Designed with:
- SEO: URL structure like
/catalog/electronics/smartphones/or/catalog/smartphones/ - Navigation: how many levels are visible in the menu
- Filtering: at which level the facet is applied
Practical rule: no more than 4 levels of nesting. Deeper creates problems with SEF URL generation, breadcrumbs, and admin panel management.
Sections vs. properties for classification: if a product belongs to multiple categories (e.g., "HDMI Cable" — both in "Cables" and "TV Equipment") — linking to only one section loses the second classification. In such cases, the additional classification is stored in a reference property, not in sections.
Trade Offers (SKU): When and How
Trade offers are needed when a product has variants with different prices or stock levels. Bitrix implementation: a parent element in the main iblock + a linked offers iblock, connected via the Catalog.Offers setting in the catalog module.
A key design decision: which properties belong to the product and which to the trade offer. Color and size are offer properties (each variant has its own). Brand and description are parent product properties. Violating this logic causes filtering errors: the color filter must operate at the offer level.
Prices, Discounts, Price Types
The pricing structure is designed at the start:
- How many price types are needed (
b_catalog_price_type): base, wholesale, dealer? - How discounts are applied: discount rules (
b_catalog_discount) or loyalty programs (b_catalog_discount_coupon)? - How prices are linked to user groups?
For a B2B store with individual pricing per client, the standard price type system is insufficient — custom logic via catalog module event handlers is required.
Case Study: Catalog Design for a Custom Furniture Manufacturer
A cabinet furniture manufacturer. The specifics: the product is not a standard item but a configurable piece (height, width, facade material, hardware). The price depends on the configuration.
The standard SKU schema was not suitable: too many combinations to pre-create offers.
Design solution:
- "Collections" iblock — parent elements (sliding wardrobe "Modern", kitchen "Classic")
- HL-block
hl_materials— 48 material variants with price coefficients (UF_PRICE_COEF) - HL-block
hl_hardware— 120 hardware variants - Configurator component — custom-built, calculates the final price in JavaScript from HL-block data via the Bitrix REST API
- The cart item includes the configuration composition as JSON in an order property
The catalog has been running for 3 years, with 240 collections, and the structure has not changed.
What Catalog Structure Design Includes
- Analysis of the product range and business requirements
- iblock schema: main catalog, offers, auxiliary iblocks
- Section hierarchy design
- Property schema with types and facet participation
- Trade offers design
- Price and price type structure
- 1C sync schema: field mapping, frequency, direction
- Volume estimates and load projections
Timeline: from 1 week for a standard catalog to 3–4 weeks for complex configurable products or a multi-brand marketplace.