Mass Product Deletion in 1C-Bitrix: Setup and Optimization

The old collection is discontinued — 1200 SKUs need to be removed from the catalog. Or after importing from Excel, duplicates appeared — 300 extra records. Deleting via the standard interface, 20 at a time, would take an hour, with each deletion triggering an avalanche of SQL queries and events. If these cascades are not controlled, performance drops and the database may even fail.

We have been configuring mass product deletion in 1C-Bitrix for over 10 years. During that time, we have cleaned catalogs of up to 50,000 items without a single data loss. Compare: batch deletion with a 1-second pause per 20 items reduces database load by 10 times compared to mass deletion without pauses. And deactivation instead of deletion cuts operation time by 80% and fully preserves order history. Time savings — up to 90%, server resource costs — up to 70%.

If you face the task of cleaning a catalog, contact us — we will prepare a solution for your scenario. We will estimate the scope of work and propose an optimal strategy.

Why is mass deletion dangerous?

According to the documentation, CIBlockElement::Delete deletes an information block element and all related data. Each deletion triggers the OnBeforeIBlockElementDelete and OnAfterIBlockElementDelete events. If CRM, search, or other modules are subscribed to these, each deletion is processed by those handlers. Without control, this causes an avalanche of queries and performance drops. For a catalog of 10,000 products, simply deleting in a loop without pauses can kill the server in 5 seconds.

How to avoid data loss during deletion?

Deleting 1000 elements in one query creates a load spike. The right approach is batch deletion with pauses:

$toDelete = [1001, 1002, /* ... 1000 id */]; $batchSize = 20; foreach (array_chunk($toDelete, $batchSize) as $batch) { foreach ($batch as $id) { \CIBlockElement::Delete($id); } sleep(1); // Pause between batches } 

For very large volumes (10,000+), the operation is run as an agent with progress saved:

// Agent writes remaining IDs to b_option and restarts itself $remaining = unserialize(\Bitrix\Main\Config\Option::get('mymodule', 'delete_queue')); $batch = array_splice($remaining, 0, 20); foreach ($batch as $id) { \CIBlockElement::Delete($id); } \Bitrix\Main\Config\Option::set('mymodule', 'delete_queue', serialize($remaining)); 

When is deactivation better than deletion?

Physical deletion is only justified for duplicates or erroneously created records. For products that may return, deactivation is better — ACTIVE = 'N'. It is 10 times faster and does not affect order history.

Before deletion, check for active orders:

SELECT COUNT(*) FROM b_sale_order_basket sob WHERE sob.PRODUCT_ID IN (1001, 1002, 1003) AND sob.ORDER_ID IN ( SELECT ID FROM b_sale_order WHERE STATUS_ID NOT IN ('F', 'C') ); 

If the query returns a non-zero value, those products must not be deleted — only deactivated.

How to properly delete products with trade offers?

For products with trade offers (type S), first delete all offers (b_iblock_element from the offers infoblock), then the main product. The order matters: when deleting a product, Bitrix does not automatically delete related offers — they remain orphaned.

// Get product offers $offers = \CCatalogSKU::getOffersList( [$productId], $catalogIblockId, [], ['ID'], [] ); if (!empty($offers[$productId])) { foreach ($offers[$productId] as $offer) { \CIBlockElement::Delete($offer['ID']); } } // Delete the main product \CIBlockElement::Delete($productId); 

How to clean up files after mass deletion?

After mass deletion via direct SQL (if someone bypassed CIBlockElement::Delete()), files in /upload/ remain on disk. To clean them, find file IDs in b_file records that are no longer referenced in b_iblock_element_property:

SELECT f.ID, f.SUBDIR, f.FILE_NAME FROM b_file f LEFT JOIN b_iblock_element_property p ON p.VALUE = CAST(f.ID AS CHAR) WHERE p.ID IS NULL AND f.MODULE_ID = 'iblock' AND f.DATE_CREATE < NOW() - INTERVAL '7 days'; 

Files from the result can be safely deleted via \CFile::Delete($fileId). Such cleanup can free 10 to 50 GB of disk space on large catalogs.

What's included in mass deletion setup

• Audit of the current catalog: identification of duplicates, seasonal items, dependencies with orders.
• Development of a batch deletion script tailored to your stack (PHP 8.1+, Bitrix 20+).
• Setup of an agent for large volumes (10k+ products).
• Preparation of SQL queries for integrity checks before deletion.
• Cleanup of file garbage after the operation.
• Documentation for usage and recovery.

Estimated setup time: from 1 to 5 days depending on catalog size. Cost is calculated individually — contact us for a project evaluation. Average time savings when using an agent instead of manual deletion — up to 90%.

Typical mistakes when self-deleting

Common mistakes include: using CIBlockElement::Delete in a loop without pauses, leading to timeout; deleting products with active orders, breaking data integrity; ignoring trade offers, leaving orphan records; deleting without prior backup; failing to account for events that break CRM or search. All these problems can be avoided with proper configuration.

Work process

1. Analytics — collect catalog data, identify problematic products.
2. Design — choose a strategy (deletion/deactivation), determine batch sizes.
3. Implementation — write and test code on a database copy.
4. Testing — verify on a test environment, simulate deletion.
5. Deploy — execute the operation on the production server during a night window.

Contact us for a catalog audit — we guarantee data integrity and provide post-deployment support. Over 10 years of experience and more than 500 successful Bitrix catalog optimization projects. CIBlockElement::Delete documentation

If you need mass product deletion, get a consultation — we will select an effective strategy for your catalog.