Why the catalog breaks as the nomenclature grows
A catalog of 200 items works fast on any configuration. Problems begin at 5–10 thousand: a category page takes seconds to load, characteristic filters time out, and the 1C export grows with every synchronization.
The cause is almost always the same — haphazard design of infoblock properties, when characteristics were added as tasks arose, without an overall data model.
A typical scenario: a separate property was created for each new parameter, some multiple, some as a string, some as a link to a reference book.
Duplicate characteristics appear — "Color" and "Product color," "Power, W" and "Power (W)" — and along with them a bloated catalog structure, where several dozen values hang on a single product, half of which are empty.
Selecting products from such an infoblock goes through many joins of property tables, and response time grows not linearly but by a multiple of the number of filters in the query.
Infoblock design mistakes are rarely visible at the start — they surface when the nomenclature grows severalfold and marketing needs yet another filter dimension.
Reworking a live catalog is more expensive: values must be migrated, page URLs preserved, and search positions not lost. That is why the property model is designed in advance — for the current assortment and for how it will grow.
We break down how this is solved: which property structure withstands the load, where the boundary lies between a property and a reference book, and how the 1C export stops bloating the tables.
Infoblock Property Schema: Types, Bindings, Storage Modes
Property Types and Their Impact on Queries
A single property is stored as one row in the main values table — querying it goes directly, without intermediate joins. A multiple property is split into separate records, and when rendering a list of elements this turns into an additional JOIN for each property in the filter.
The practical rule: multiplicity is justified where a set of values is genuinely needed (a gallery, multiple phone numbers, tags), and harmful where the business logic allows a single value — a "just in case, make it multiple" gives a manifold performance drop on catalogs of several thousand items and up.
Binding to Sections and SKUs
Binding properties to sections allows keeping a different set of characteristics for different categories: for laptops — screen diagonal and matrix type, for accessories — compatibility.
Without it, the card grows over with empty fields, and edit forms become unreadable for a content manager.
SKU properties are inherited from the product differently — they should be designed as a separate set, otherwise a filter by color or size starts working through the product rather than through the SKU, and the output breaks.
Storage Modes: When to Use Which
| Option | When it fits | Limitations |
|---|---|---|
| Separate values table | Bulk properties, frequent filters and sorting | Requires indexes, grows linearly with the number of values |
| Serialization into a single field | Rare technical data not involved in queries | Cannot be filtered or sorted by core means |
| Reference book (binding to an element) | Repeating values: brand, city, author | Additional JOIN, reference book synchronization needed |
| SKU property | Variation characteristics: size, color | Inheritance from the product, separate output logic |
1C-Bitrix provides ready-made mechanisms for each mode, but the choice between them is a decision about load, not about editor convenience.
On projects with a catalog of tens of thousands of items, we lock in the storage mode before filling begins: changing the schema on a live catalog requires migrating values and reindexing the search.
How we design and implement the property structure
Designing infoblock properties starts not with creating new fields, but with taking inventory of what already works in production.
On live projects, properties accumulate over the years: some are duplicated, some are not used by any template, some store data in a format that breaks exports to 1C.
Until this picture is assembled, any change to the structure is a risk of breaking the exchange or losing content.
- Infoblock audit. We map it out: which infoblocks exist, which properties are actually used in components, templates, and the exchange with 1C, and which are dead weight. We record types, multiplicity, binding to sections, and relationships between properties.
- Property schema. We design the target structure for business tasks: unified reference lists instead of duplicates, meaningful property codes, separation of fields for filters and for storage. The schema is agreed upon before work begins — edits at this stage are cheaper than after migration.
- Property migration plan. We break the transition into steps while keeping the site operational: where value transfer is needed, where reindexing is needed, where temporary duplication of fields is needed during the transition.
- Infoblock setup. We build the structure on the staging environment, run the exchange with 1C, check exports, filters, and sections. Only after data reconciliation do we move it to production.
- Verification on real data. We compare samples before and after, monitor the completeness of the transfer and the correctness of relationships between sections and elements.
- Maintenance regulations. We hand over the rules: how to create new properties, which types are allowed, who approves changes, so that the structure does not sprawl again.
- Documentation handover. The schema, property map, and regulations remain with the client's team — further edits are made without archaeology through the code.
This order removes the main risk — data loss during restructuring. Describe your task: we will come back with an estimate and a plan for your project.
How does an infoblock property differ from a trade offer characteristic?
An infoblock property is an attribute of the product itself: SKU, brand, country of origin, composition. A trade offer characteristic is what distinguishes the variants of a single item: color, size, volume, bundle.
The difference between properties and characteristics becomes apparent at the moment when the buyer selects a specific variant: properties describe the card as a whole, characteristics describe each trade offer within it.
If you move color into a product property, you will end up with a separate card for each shade, and the catalog will balloon by an order of magnitude.
The key criterion is the attribute by which the buyer selects and filters. An attribute that narrows the choice within a single model goes into the trade offer. An attribute that describes the product itself and is the same for all its variants remains an infoblock property.
A mistake in designing infoblock properties is costly: the wrong fork leads to duplicate cards, breaks the end-to-end export of characteristics to 1C, and forces filters to be rewritten from scratch.
Filtering by properties and by characteristics works differently. An infoblock property is filtered directly by products, a characteristic — through trade offers, and a smart filter must be able to collect values from both levels.
If color resides in a property and size in a characteristic, the "color + size" filter will return empty result sets until the logic is consolidated into a single query across two infoblocks.
A separate pain point is the exchange with 1C. Trade offer characteristics are exported from the nomenclature reference book differently than product properties: they have their own structure, their own trade offers, and their own matching rules.
When an attribute is mistakenly left as a property, the export of characteristics arrives empty or duplicated, and managers fix the catalog by hand after every exchange.
A practical rule: first we model on paper which attribute will drive the selection and the filter, then we lay them out across levels. We design the structure so that filters, exports, and the exchange with 1C work without manual edits.
Case: restructuring catalog properties without stopping sales
A catalog of 40,000 items lived on a "flat" scheme: 60+ properties in a single information block, some characteristics duplicated in trade offers, some — in the product description as text.
A filter by three parameters assembled a selection in 4-6 seconds, and managers created new items with different markup — hence discrepancies in characteristics for identical products.
Stopping the store for reindexing was not an option: the share of orders from the site during the season is too high.
We split the catalog into linked information blocks: a base product, trade offers, and a separate characteristics reference with its own properties.
Duplicates were collapsed into the reference, and only those properties that participate in the filter and exports were left on the card.
We performed the property migration without downtime in four steps: prepared the new structure alongside the old one, transferred data in batches with logging of discrepancies, switched the templates and filter components, then removed the outdated properties.
Each stage was rollback-able: until the new scheme passed reconciliation, traffic went to the previous templates.
Results by metrics: the filter selection dropped from 4-6 seconds to 0.8-1.2, the share of duplicate characteristics fell by roughly 70%, and the time for a manager to create a new item was halved — some fields are pulled from the reference.
The reorganization of information blocks also affected the exchange with 1С: the export became predictable, because property matching now goes by stable codes rather than by names.
We worked on the platform's standard core and its caching mechanisms — without third-party add-ons that would have to be maintained separately.
1C-Bitrix provides ready-made tools for this: linked information blocks, managed cache, and step-by-step agents, which is what we used to complete the restructuring.
If your catalog is growing while the filter and exports are slowing down — describe the task, and we'll come back with an estimate and a plan for restructuring the properties.
Compatibility, rollback, and access: what to discuss before the start
Compatibility of infoblock properties with already working content is the main risk during design: new custom properties must not break existing output templates, filters, and exchange with 1C.
Therefore, before the start, we determine which properties are already used in queries, which are included in the export, and which can be added without changes to the public-facing part.
If a property is involved in the exchange, we check the mapping on the 1C side and the synchronization order — otherwise, after the very first exchange, the values will be overwritten.
What if everything needs to be reverted?
We plan for rollback of changes in advance: before making edits, we take a dump of the infoblock and the property structure, and we carry out changes in separate steps so that each one can be undone individually, without rolling back the entire site.
We differentiate access to infoblocks by roles — content manager, integrator, administrator — with an action log so that structure edits are not lost and can be traced.
How is the property schema delivered and what should be done with it next?
We deliver the schema as a table: property code, type, multiplicity, binding to sections, participation in the exchange and in filters. Using it, your developer or content manager can add a property independently without breaking the output logic.
The property documentation comes together with the access settings and rollback instructions — this is sufficient for handing the project over to another team.
The client receives:
- a map of infoblock property compatibility with current templates and the exchange;
- a schema of custom properties with codes, types, and purpose;
- a regulation for access to infoblocks by roles;
- instructions for rolling back changes and save points;
- property documentation for content managers;
- a protocol for verifying the exchange with 1C after edits.
Describe your task — we will get back to you with an estimate and a work plan for your project.
Timeline for the stages of implementing a new property schema
The timeline depends not on the amount of code, but on the number of information blocks, the relationships between them, and how actively content managers edit data during the migration.
Below is a guideline for a typical project: a catalog with trade offers, several content sections, and one integration with an accounting system.
For large portals with dozens of information blocks and warehouse stock, the ranges shift to the right proportionally to the number of entities.
| Stage | What happens | Estimated timeline |
|---|---|---|
| Audit of the current schema | Inventory of information blocks, properties, bindings to sections and trade offers, search for duplicates and unused fields | 3–5 business days |
| Property design | Agreement on types, multiplicity, binding to sections, inheritance rules, and output templates | 4–7 business days |
| Migration and data transfer | Scripts for transferring values, mapping old and new property codes, test run on a copy | 5–10 business days |
| Verification and rollback | Reconciliation of selections, testing of filters and the smart filter, control of exports to search, rehearsal of returning to the old schema | 3–5 business days |
| Handover and training | Documentation on the schema, regulations for adding properties, instructions for content managers | 2–3 business days |
The duration of the audit directly determines how much time will go into the migration: if at this stage duplicate properties and fields that are not displayed anywhere are found, the design immediately reduces the volume of data to be transferred.
We build the work schedule for information blocks so that the migration proceeds in blocks — first the catalog, then the content, then the integration exports — and each block can be verified separately without stopping the entire site.
The timelines indicated are estimates and are not tied to calendar dates: they are recalculated after the audit, when the real volume of entities and the quality of the current data are visible.
If some of the information blocks are already described correctly, the corresponding stages go faster.