Imagine: after launch, the product filter by characteristics times out, and the import from 1C creates duplicates in every element. The reason is incorrectly designed info blocks. Mistakes at this stage are costly: restructuring after launch may require migrating thousands of elements, stopping the catalog for several days, and additional development costs. With us, you will get a structure that will last for years without changes. 10+ years of experience in Bitrix, certified specialists, 1C-Bitrix partner. Proper design of 1C-Bitrix info block structure is an investment in the stability and performance of your catalog.
A typical design mistake: using a single info block for all entities — products, articles, banners, directories. This leads to a bloated b_iblock_element_property table, slower filtering, and caching difficulties. The solution: separate data domains into different info block types.
How to Choose the Right Property Type?
Each info block property has a type, and this decision cannot be changed without data migration. Below is a table with main types and recommendations:
| Property Type | Purpose | When to use |
|---|---|---|
| String | Text values without repetition | For unique fields (article, name) |
| Number | Numeric values for range filtering | Price, weight, power |
| List | Fixed set of values | Statuses, size categories |
| Directory (HL-block) | Dynamic directories | Brands, countries, metro (multiple) |
| File | Images and documents | Additional photos (if >2) |
| Binding to elements | Element links | Related products, kits |
According to 1C-Bitrix documentation, choosing the right property type is the foundation of catalog performance. Strings without indexes and duplicates in b_iblock_element_property are a common cause of slowdowns. The facet index solves the problem, but only for numeric, list, and directory properties.
Info Block Type Structure
An info block type is a grouping without technical significance, but critical for manageability. Rule: one info block type = one data domain. "Catalog", "Articles", "Banners", "Directories" is a correct grouping. "Site" as the only type for everything is an antipattern.
For an online store, a typical type structure:
-
catalog— product catalog and SKU info blocks -
content— news, articles, FAQ -
references— directories (used as source for list-type properties, if not HL-blocks) -
landing— landing blocks, banners
How Section Depth Affects Performance
Sections (b_iblock_section) are stored in Bitrix's native tree. Practical limitation: nesting depth of more than 5–6 levels causes problems with breadcrumbs, SEO-friendly URLs, and navigation. If the business requires a deeper hierarchy (e.g., spare parts for equipment: manufacturer → model → series → unit → part), consider replacing the hierarchy with properties using filtering instead of section navigation.
Multiple Properties and Performance
A multiple property stores several values in b_iblock_element_property — one row per value. 10,000 elements × a property with 5 values = 50,000 rows in the table just for this property. For multiple directory properties, the facet index handles them correctly, but the load during index rebuilding is higher.
Rule: if a property is rarely filled (filled in 10% of elements), empty records are not stored, reducing table size. If a property is filled in all elements and rarely changes, consider moving it to a separate HL-table via DataManager.
Why is it Important to Split Data into Different Info Block Types?
Proper separation by types avoids query slowdowns when mixing heterogeneous data. For example, products and banners have different property sets and update frequencies. If combined, when selecting banners, product records are also scanned, increasing load. Agencies that neglect this rule often face increased execution time of the catalog component.
Case: Designing Info Blocks for a Real Estate Aggregator
A platform for sale and rental property listings. Initial solution: one info block "Properties" with 40 properties, including string address, district, metro.
Problems under load:
- Filtering by metro worked as text search (LIKE), not by index
- Duplicate values: "m. Arbatskaya", "Arbatskaya", "arbatskaya" — three different records
- Radius search from metro impossible without geocoordinates
Restructured schema:
-
catalogtype: info block "Properties" + info block "Residential complexes" - HL-block
hl_metrowith fields:UF_NAME,UF_LINE,UF_LAT,UF_LON— 342 records instead of text values - HL-block
hl_district— districts with binding to city - Properties "Area", "Floor", "Floors" — type "Number" for range filtering
- Property "Metro" — directory (HL), multiple (several stations)
Facet index after restructuring: created in 3 minutes for 85,000 objects, filtering by metro and type — 0.15 seconds. Our client achieved over 50x improvement in filter speed. This saved budget on server resources and reduced user wait time. More about facet index on Wikipedia.
What is Included in Info Block Structure Design
- Domain analysis — list of entities and relationships (1–2 days).
- Property schema design — choosing types, HL-blocks, facet index (1–3 days).
- Section hierarchy design — optimal depth, replacement with properties if necessary (0.5–1 day).
- Documentation — table schema for each info block (0.5–1 day).
- Approval — schema approval with the client (0.5 day).
- Optional: implementation — structure deployment, data migration (from 2 days).
| Stage | Duration | Result |
|---|---|---|
| Domain analysis | 1-2 days | List of entities and relationships |
| Schema design | 1-3 days | Info block structure document |
| Approval | 0.5 day | Approved schema |
| Implementation (optional) | from 2 days | Working structure with data migration |
Timeline: from 3 to 10 working days depending on the number of info blocks and domain complexity. Cost is calculated individually after analyzing the technical specifications. Get a consultation — contact us to discuss your project. Ensure reliability: many years of experience, performance guarantee on the designed structure. Order the design — and your system will run without failures for years. A designed structure reduces maintenance and new feature development costs.