Mass Update of Product Properties in 1C-Bitrix

Mass Update of Product Properties in 1C-Bitrix

In a catalog of 15,000 products, you need to add a new "Material" property to 8,000 items in a certain category, fix a typo in a facet filter value for 2,000 products, and remove the "Recommended" flag from half the assortment. Through the product edit form, this would be weeks of work. We solve such tasks with batch updates via API while maintaining data integrity. With over 10 years of experience in Bitrix development, we know how to update properties of thousands of products in hours, not days. On a catalog of 15,000 products, manual updating would take 3-4 weeks; automation reduces it to 1-2 days. Time savings are obvious, and the cost is calculated individually — you pay only for the result.

Where Properties Are Stored

Product properties in Bitrix are stored in several places depending on type:

• Element fields (NAME, PREVIEW_TEXT, ACTIVE, etc.) — b_iblock_element
• Infoblock properties — b_iblock_element_property, where IBLOCK_PROPERTY_ID is the property ID, VALUE is the value
• Multiple properties — several rows in b_iblock_element_property with the same IBLOCK_ELEMENT_ID and same IBLOCK_PROPERTY_ID
• List-type properties — VALUE contains the text value, VALUE_ENUM_ID references b_iblock_property_enum

For trade offers, the structure is similar, but IBLOCK_ID points to the offers infoblock, not the main catalog. Understanding this structure is necessary to choose the optimal update method.

How to Mass Update Product Properties Without Performance Degradation?

For small volumes (up to 1,000 elements), CIBlockElement::SetPropertyValues is suitable. Working code:

$iblockId   = 10; // ID of catalog infoblock
$propertyCode = 'MATERIAL';
$newValue   = 'Cotton 100%';

// Get list of elements in the desired section
$res = \CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => $iblockId, 'SECTION_ID' => 42, 'ACTIVE' => 'Y'],
    false,
    false,
    ['ID']
);

while ($row = $res->Fetch()) {
    \CIBlockElement::SetPropertyValues(
        $row['ID'],
        $iblockId,
        $newValue,
        $propertyCode
    );
}

However, on large volumes this method is slow — it reads current values, compares, updates. Each call involves several SQL queries. For volumes from 1,000 elements, we strongly recommend direct update via D7 ORM.

Fast Update via D7 ORM

For volumes from 1,000 elements, directly update b_iblock_element_property:

use Bitrix\Iblock\ElementPropertyTable;

// First get the property ID
$propertyId = getPropertyIdByCode($iblockId, 'MATERIAL');

// Get element IDs in batches
$elementIds = getElementIdsBySectionBatch($iblockId, $sectionId, 500);

foreach (array_chunk($elementIds, 500) as $chunk) {
    // Check which ones already have a record
    $existing = ElementPropertyTable::getList([
        'filter' => [
            'IBLOCK_PROPERTY_ID' => $propertyId,
            'IBLOCK_ELEMENT_ID'  => $chunk,
        ],
        'select' => ['ID', 'IBLOCK_ELEMENT_ID'],
    ])->fetchAll();

    $existingMap = array_column($existing, 'ID', 'IBLOCK_ELEMENT_ID');

    foreach ($chunk as $elementId) {
        if (isset($existingMap[$elementId])) {
            // Update existing record
            ElementPropertyTable::update($existingMap[$elementId], ['VALUE' => 'Cotton 100%']);
        } else {
            // Insert new record
            ElementPropertyTable::add([
                'IBLOCK_ELEMENT_ID'  => $elementId,
                'IBLOCK_PROPERTY_ID' => $propertyId,
                'VALUE'              => 'Cotton 100%',
            ]);
        }
    }
}

After directly modifying the table, you need to clear the infoblock cache:

\Bitrix\Iblock\InformationBlock::cleanTagCache($iblockId);
\Bitrix\Main\Application::getInstance()->getTaggedCache()->clearByTag('iblock_id_' . $iblockId);

Why Doesn't the Facet Filter Work After Mass Property Update?

After changing properties that are used in the smart filter (catalog.smart.filter), you must rebuild the facet index. Otherwise, values won't update in the filter. We always include reindexing in our work process.

\Bitrix\Iblock\PropertyIndex\Manager::markIblockToReindex($iblockId);
// or force:
$indexer = new \Bitrix\Iblock\PropertyIndex\Indexer($iblockId);
$indexer->startIndex();
$indexer->continueIndex(0);
$indexer->endIndex();

On a catalog of 50,000+ products, reindexing takes several minutes — run it in the background via agent or cron. According to 1C-Bitrix documentation, it is recommended to run reindexing in background processes to avoid blocking users.

Specifics of Updating List Properties

List-type properties (used in facet filter) store the text value in VALUE and the ID from b_iblock_property_enum in VALUE_ENUM_ID. When changing a value, you need to update both fields.

// Find the ID of the new value in the enumeration
$enumRes = \CIBlockPropertyEnum::GetList(
    [],
    ['PROPERTY_ID' => $propertyId, 'VALUE' => 'Blue']
);
$enum = $enumRes->Fetch();
$enumId = $enum['ID'];

// Update
ElementPropertyTable::update($existingPropId, [
    'VALUE'         => 'Blue',
    'VALUE_ENUM_ID' => $enumId,
]);

If the desired value is not yet in the enumeration, first add it via CIBlockProperty::SetEnumValues() or directly into b_iblock_property_enum.

CSV Import as an Alternative

For non-technical users or regular updates, CSV import via Catalog → Import is better. File template: first row — headers with field codes (ID, PROPERTY_MATERIAL, PROPERTY_COLOR). Bitrix updates only those properties whose columns are present in the file.

Limitation of standard import: no support for conditions ("update property only if current value is empty"). For such scenarios, only scripts.

Step-by-Step Plan for Mass Property Update

1. Analyze structure: determine which properties and how many elements need update.
2. Choose method: for <500 items — SetPropertyValues, for larger — D7 ORM.
3. Develop script considering property types (simple, multiple, list).
4. Test on a database copy or small sample (10-20 elements).
5. Run update with logging and error control.
6. Clear infoblock cache and rebuild facet index.
7. Validate: check that properties updated, filter works correctly.

What's Included in Configuring Mass Property Change

Within the scope of work, we:

• Analyze current property structure and data
• Choose optimal update method (API, D7 ORM, CSV import)
• Write scripts with error control and logging
• Test on a small sample
• Run full update and rebuild cache and facet index
• Provide documentation on the process

We guarantee data safety and minimal downtime.

Timelines

Method Comparison

How to Order Configuration

If you need to mass update product properties, contact us. We will assess the scope of work and propose a turnkey solution. Get a consultation — just write. Your catalog will be put in order without pain and downtime.

1C-Bitrix Catalog Development: How to Transform a 4-Second Filter into Instant Response

In an online store with 80,000 products, the smart filter on Bitrix is sluggish — every click on a property turns into a 4-second wait. The customer clicks the 'Apple brand' checkbox, watches the spinning loader, and leaves for competitors. Conversion drops by 20%. This is a familiar pain. We specialize in 1C-Bitrix catalog development and filtering: we design architectures that handle half a million items without degradation — through faceted indexes, proper storage selection, and tagged caching. If your store is losing money due to a slow filter — order an audit of the current architecture, and we'll assess the problem in one day.

How Do Information Blocks Affect Catalog Performance?

Information blocks are the foundation of the catalog, but on projects with tens of thousands of products, they become a bottleneck. The standard bitrix:catalog.smart.filter generates JOINs on 6–8 property tables (b_iblock_element_property), leading MySQL into a full scan. We change the approach: during design, we determine which properties go into the information block and which into Highload blocks. For reference data (brands, cities, size charts) we use HLB: they work with a separate table without the overhead of b_iblock_element_property. When a 'Cities' dropdown loads for 8 seconds due to 5000 values — that's a signal to move them to HLB. A catalog of 80,000 products with a 4-second filter loses significant revenue annually due to customer attrition — the right architecture delivers that kind of savings. Contact us to estimate the benefit for your project.

What Is the Faceted Index and Why Is It Important?

The core performance lies here. Without a faceted index, every filter click is an SQL query with JOINs on b_iblock_element, b_iblock_element_property, b_catalog_price, and a few more tables. On 100,000 products, such a query takes 2–4 seconds. With a faceted index — 30–80 ms. According to official documentation, the faceted index reduces query execution time by tens of times (in real projects — up to 50 times). The mechanism: 1C-Bitrix creates a table b_catalog_smart_filter where it stores pre-calculated combinations of 'section + property + value + product count'. When filtering, the engine accesses this flat table instead of collecting data from the normalized structure of information blocks.

Common mistakes when configuring the faceted index include not creating the index for all sections, forgetting to set up background reindexing after bulk imports — causing property counters to mismatch the actual product count. Including all properties in the facet, even service ones, bloats the b_catalog_smart_filter table. On catalogs with over 300,000 items, its size can exceed a gigabyte — monitoring via SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' is essential. Conclusion: the faceted index provides radical acceleration, but requires careful configuration and automatic reindexing via the agent CIBlockCatalog::ReindexFacet or cron.

Why Are Highload Blocks Faster Than Information Blocks for Reference Data?

In practice, the best architecture is hybrid. Products and sections live in information blocks — there you have SEO, visual editor, and standard catalog components. Reference properties with thousands of values are moved to Highload blocks. User data (favorites, viewed items, comparisons) also go to HLB — they grow quickly, and information blocks are not designed for that. Want to know which architecture to choose for your catalog? Contact us — we'll analyze your data structure and provide recommendations.

SEO Filters: How to Get SEO-Friendly URLs and Not Get Penalized by Yandex?

The standard filter generates ?filter[brand]=apple&filter[color]=black — search engines either do not index such URLs or consider them duplicates. But the query 'black apple laptops' is the most converting low-frequency traffic. We create SEO-friendly URLs: /catalog/laptops/brand-apple/color-black/ with unique title, description, and H1. Not template-based 'Buy {brand} in Minsk', but meaningful ones reflecting the specific combination.

• Canonical URLs — to prevent /brand-apple/color-black/ and /color-black/brand-apple/ from duplicating.
• Control of the number of indexed combinations — 10 properties with 20 values each yield millions of pages; Yandex penalizes that.
• Automatic sitemap for SEO filter pages.
• Admin interface for the manager — they decide which intersections to index.

Order the implementation of SEO filters — get a ready-made tool for attracting low-frequency traffic with conversion growth up to 30%.

What Methods Provide a Significant Performance Boost?

• Fetching only necessary fields via arSelect — no SELECT * on information blocks.
• Managed tag-based caching: when a product is added, the cache is automatically rebuilt.
• Composite cache for anonymous users: TTFB < 100 ms, HTML is served without running PHP.
• Indexes on properties used in filtering — without them MySQL scans the entire b_iblock_element_property table.
• TTFB monitoring: if the catalog responds slower than 500 ms, we check the slow query log.

What Is Included in Comprehensive Catalog Development on 1C-Bitrix

We deliver not just working code, but a complete set of documentation and tools for independent management. Deliverables include:

• Audit of current catalog and filtering architecture.
• Project documentation describing data schema, distribution across information blocks and Highload blocks, and facet composition.
• Ready smart filter with AJAX mode, grouping, and state persistence.
• Configured faceted index with cron reindexing.
• SEO filters with SEO-friendly URLs, unique meta tags, canonicals, and sitemap.
• Integration of quick view and sorting (AJAX, mobile adaptation).
• Operational documentation for managers: how to add properties, manage indexes and SEO combinations.
• 30-day warranty support after delivery — we fix incidents and answer questions.

How We Develop a Catalog: Step-by-Step Plan

We don't just install components. The process includes:

1. Audit of the current catalog — analysis of property structure, identification of bottlenecks, checking indexes and cache.
2. Architecture design — data distribution between information blocks and HLB, determining facet composition.
3. Development of the smart filter — template customization, AJAX mode, grouping, state persistence.
4. Faceted index configuration — creation, cron reindexing, monitoring.
5. SEO filters — SEO-friendly URLs, meta tags, canonicals, sitemap.
6. Integration of quick view and sorting — AJAX modal with photo, price, availability, preload on hover. On mobile — bottom sheet instead of popup.
7. Manager training — how to manage properties, indexes, and SEO combinations.
8. Warranty support — 30 days after delivery.

Implementation Timeline

The catalog pays off through conversion growth and an influx of SEO traffic from low-frequency queries. The customer finds the product in two clicks, rather than leaving after the first click on the filter. Get a consultation — we will evaluate your project within a day and provide a project plan and roadmap for 1C-Bitrix catalog development. Contact us through the form on the website — certified specialists with over 200 successful projects.