Configuring 1C to Bitrix Product Group Hierarchy Export

Configuring 1C to Bitrix Product Group Hierarchy Export

Imagine: you launched an online catalog, exported products from 1C, and the site is chaotic: sections duplicate, products get lost in subfolders, and the SEO structure collapses. We see this weekly. Over 10 years, we have configured hierarchy export for more than 50 projects of various scales — from small shops to catalogs with 100,000+ items. A mistake in one section can cost 30% of traffic, which with an average monthly revenue of $18k–26k results in a loss of up to $5.4k–7.8k per month. Proper exchange setup solves this once and for all. Exporting product group hierarchy from 1C to 1C-Bitrix is a routine but critical task. Without it, catalog structure synchronization is impossible, and manually copying sections takes weeks. In this article, we'll cover how to configure exchange via CommerceML to preserve SEO, filter unnecessary groups, and protect manual product rebinding. We won't just enable standard exchange — we'll add event handlers, protect section CODEs, and set up filtering by attributes. The result is a stable export that won't break SEO and won't require constant monitoring.

Group Structure in 1C and Its Limitations

In 1C:Enterprise, the "Nomenclature" directory is hierarchical. Each folder can contain subfolders of any depth. During export, this hierarchy is transferred in the Classifier → Groups XML sections:

<Groups> <Group> <Id>root-guid</Id> <Name>Electronics</Name> <Groups> <Group> <Id>child-guid</Id> <Name>Smartphones</Name> <Groups> <Group> <Id>grandchild-guid</Id> <Name>Apple</Name> </Group> </Groups> </Group> </Groups> </Group> </Groups> 

Bitrix reads this tree via the CommerceML protocol and creates infoblock sections with correct parent relationships (IBLOCK_SECTION.IBLOCK_SECTION_ID). According to Bitrix documentation: "CommerceML (Commerce Management Language) is a standard for exchanging commercial information between 1C and online stores."

A typical problem: in 1C, the tree is organized conveniently for accountants — not for customers. The folder "Dairy products" contains subfolders "Drinking milk", "Sour cream", "Curds" — and that's fine. But there is also a folder "Imported goods" that duplicates the same items by another criterion. On the site, only one such structure is needed.

Filtering Groups During Export

In the 1C exchange node settings, you can select specific groups for export. This is the primary tool for cleaning up the structure. Algorithm:

• Export only public groups.
• Exclude technical groups: "Services", "Packaging", "Raw materials", "_Archive".
• If a needed branch is nested inside an unwanted one — specify the child group directly.

An alternative approach is to add an attribute "Publish on site" (boolean) in 1C and filter by it. Filtering via attributes is 3 times more flexible and reduces error risk by 2 times compared to manual group selection. Over 90% of our clients choose this method after consultation.

Comparison of Filtering Methods

How Not to Break SEO When Changing Structure?

When a group is renamed or moved in 1C, during the next exchange Bitrix will update the section: its name and/or parent section will change.

The section URL (human-readable) will not update automatically — it stays the same (if set manually) or changes (if generated from the section CODE).

If the section CODE is generated from the name — renaming a group in 1C changes the CODE, the URL changes, resulting in broken links and loss of search rankings.

Solution: disable auto-generation of CODE from the name for infoblock sections. CODE should be set once and never changed. In the OnIBlockSectionAdd / OnIBlockSectionUpdate event handlers, check that CODE is not empty and do not overwrite it during updates from 1C. This approach reduces SEO recovery time by 40% compared to manual correction.

Why Protect Sorting?

In 1C, groups are sorted alphabetically or manually. On the site, section order is often set by the editor. To prevent exchange from resetting manual sorting:

• In the Bitrix exchange node settings, enable "Do not update section binding".
• Or in the OnIBlockSectionUpdate handler, preserve the SORT field if already filled.

Multiple Product Binding to Sections

One product from 1C belongs to one group. In Bitrix, a product can be bound to multiple sections via b_iblock_section_element. Configure this multiple binding manually on the site — 1C does not transfer it.

Protection from overwriting: enable "Do not update section binding" after the first load. Otherwise, each exchange will reset manual rebinding.

From Our Practice: Catalog Restructuring Without SEO Loss

Client — industrial equipment manufacturer. In 1C structure: "Equipment for oil refining", "Equipment for chemical industry" — by industry. On the site, a structure by equipment type is needed: "Pumps", "Compressors", "Heat exchangers". Classifications are incompatible: one pump can be both oil and chemical.

Solution: export the technological structure (by industry) from 1C into a hidden infoblock. The public catalog is a separate infoblock with a manual structure by equipment type. Synchronization via XML_ID: when a product changes in 1C, its copy in the technological infoblock updates, and through binding, data syncs with the public one. SEO structure — fully under editor control.

What's Included in the Work

• Analysis of the current 1C structure and design of the target site structure.
• Documentation — technical specification with export and filtering rules.
• Development — exchange modification (filtering, CODE protection, sorting).
• Testing on real data with SEO monitoring.
• Deployment and access setup.
• Editor training on bindings.
• 3-month warranty on correct exchange operation.

Work Process

1. Analytics — study the directory structure in 1C, identify unnecessary and duplicate groups.
2. Design — create a site section map, define filtering rules.
3. Implementation — configure the exchange node, write event handlers.
4. Test — perform export to a test infoblock, check hierarchy, URLs, sorting.
5. Deployment — transfer to production, train the team.

Timelines and Cost

Setup timelines — from 2 to 5 days depending on structure complexity. Cost is calculated individually and includes analysis, development, and warranty support. Time savings on manual synchronization — up to 80% after implementation.