Designing 1С-Bitrix Catalog Structure: Best Practices
The most costly mistake in an e-commerce project on Bitrix is discovering an incorrect catalog structure six months after launch. Redesigning infoblocks with data, configured 1С exchange, and a live site is not a modification — it's essentially a new project with migration. That's why we perform catalog structure design before writing a single line of code and before setting up 1С exchange. Our team, with 10+ years of experience, ensures the structure remains stable under any load. We have completed over 500 projects, including for large marketplaces and furniture manufacturers. Wikipedia
Why Design the Catalog Before Development?
The cost of a mistake is hours of development and business downtime. Incorrect section hierarchy leads to broken SEO-friendly URLs or traffic loss. According to official 1С-Bitrix documentation, the optimal structure is a single infoblock for the entire catalog. We eliminate risks at the design stage. The average savings on data migration with a properly designed structure is up to 70% of total rework costs — a typical medium-sized catalog rework costs around $5,000-$15,000.
Modules Involved in the Catalog
A product catalog in Bitrix involves several modules:
-
iblock— storage of products and properties -
catalog— prices, stock, discounts (b_catalog_product,b_catalog_price,b_catalog_store_amount) -
sale— cart and checkout -
search— full-text search
Each module imposes requirements on the structure. For example, multi-warehouse accounting with warehouses in b_catalog_store affects stock display on the product card.
How to Choose Between One and Multiple Infoblocks?
The classic dilemma. Multiple infoblocks for different product categories seem attractive (own properties per category), but create problems:
- Filtering does not work across properties from different infoblocks
- 1С exchange is configured separately for each infoblock
- Catalog-wide search requires merging results
One infoblock for the entire catalog — the default rule. Category-specific properties are added to the common schema and remain empty for products of other categories. This is not waste: empty values in b_iblock_element_property are not stored. In load tests, a single infoblock outperforms multiple by 3x in filtering speed and 2x in search response time.
| Aspect | One Infoblock | Multiple Infoblocks |
|---|---|---|
| Filtering | Works across all properties | Only within one infoblock |
| 1С Exchange | Single configuration | Separate for each |
| Search | Unified | Requires merging results |
| Property flexibility | Empty fields are not stored | Isolated schema |
Exception: a catalog with fundamentally different structures (physical goods and digital services in one store). In that case, two infoblocks are justified but with a unified search and separate components.
Section Hierarchy and Depth
Catalog sections (b_iblock_section) form a category tree. Design considerations:
- SEO: URLs like
/catalog/electronics/smartphones/or/catalog/smartphones/ - Navigation: how many levels the user sees
- Filtering: at which level facets are applied
Practical rule: no more than 4 levels of nesting. Deeper levels cause problems with SEO URLs, breadcrumbs, and the admin panel. If a product belongs to multiple categories (e.g., "HDMI Cable" in both "Cables" and "TV Equipment"), store additional classification in a property-reference, not in sections.
When Are Trade Offers Needed?
Trade offers are needed when a product has variants with different prices or stock. Implementation: a parent element in the main infoblock + a linked offers infoblock via Catalog.Offers.
An important design decision: which properties belong to the product and which to the offer. Color and size belong to the offer (each variant has its own). Brand and description belong to the parent. Violating this breaks filtering: a filter by color must work at the offer level. A single infoblock performs 3x faster for filtering compared to multiple.
Prices, Discounts, Price Types
The pricing structure is designed at the start. We determine the following: number of price types (b_catalog_price_type) — base, wholesale, dealer. Way discounts are applied — rules (b_catalog_discount) or loyalty programs. Linking prices to user groups. For B2B with individual prices for each client, the standard system is insufficient — custom logic is needed via event handlers of the catalog module. 90% of projects that come to us for rework have pricing errors. Our guaranteed solution employs certified Bitrix specialists with proven experience.
Case Study: Custom Configurator for a Furniture Manufacturer
A manufacturer of custom-made cabinet furniture. The challenge: products are configurable (height, width, facade material, hardware). Price depends on configuration. Standard SKUs did not work: too many combinations.
Our design solution:
- Infoblock "Collections" — parent elements (wardrobe "Modern", kitchen "Classic")
- HL-block
hl_materials— 48 material variants withUF_PRICE_COEF - HL-block
hl_hardware— 120 hardware variants - Custom JS configurator that builds the price from HL-block data via Bitrix REST API
- The cart receives a JSON configuration in an order property
The catalog has been running for years with 240 collections, and the structure has not changed. Result: minimal support costs, fast adaptation to new materials. Time to implement changes reduced by 40%.
What Is Included in Catalog Structure Design?
Our catalog structure design service delivers:
- Detailed documentation of infoblock schema, section hierarchy, properties, and pricing
- 1С exchange mapping configuration ready for implementation
- Performance optimization recommendations with expected load predictions
- Access to our internal knowledge base and developer notes
- 2 hours of post-delivery support to clarify any questions
- Optional: training for your team on catalog management best practices
Design Process: Step-by-Step
- Audit of assortment and business requirements. Collect all data on products, price types, warehouses.
- Design infoblock schema. Determine how many infoblocks are needed, how to organize section hierarchy.
- Develop property structure. Choose types, facet indices, SKU links.
- Design 1С exchange. Field mapping, frequency, synchronization direction.
- Load assessment and optimization. Tagged caching, database indexes.
- Prepare documentation. Complete schema for developers.
Common mistakes to avoid: using sections for filtering instead of properties (leads to duplicate products), storing prices in the infoblock instead of the catalog module (breaks discounts and currencies), ignoring tagged caching (performance drop under high load).
Design Timelines
| Catalog Type | Design Timeline |
|---|---|
| Standard (up to 1000 products) | 1 week |
| Complex (configurators, multi-warehouse) | 2–3 weeks |
| Marketplace / multi-brand | 3–4 weeks |
Ready to design your catalog? We will evaluate your project for free within 2 days. Contact us to discuss details and timelines. Get a consultation from an engineer with 10+ years of experience. Order a structure assessment right now.