Designing a Product Filtering System for 1C-Bitrix

Designing a product filtering system for 1C-Bitrix is a task where every millisecond counts. In our practice, a filter on 180,000 SKUs executed in 0.2 seconds, while the standard component returned runtime errors. A slow filter is almost always caused by incorrect property types or a missing faceted index. A filter showing products without stock tracking—a confusion between product and SKU properties. A filter returning zero results when combining criteria—a logic problem of AND vs. OR. We solve these tasks with your infrastructure in mind, saving up to 40% of development time. Contact us to design your filter and avoid common pitfalls, getting a fast, precise tool for your catalog.

Speeding up Filtering with the Faceted Index

The faceted index is the primary tool for speed. It is 15 times faster than regular queries to b_iblock_element_property. Faceted navigation (https://ru.wikipedia.org/wiki/Фасетная_навигация) allows instant counting of elements for each value. However, the index only works with 'List' and 'Reference' property types. Numeric fields require range filtering—also supported by the standard component.

The bitrix:catalog.smart.filter Component: Capabilities and Limitations

The standard smart filter component supports:

• Filtering by 'List' and 'Reference' (HL-block) properties using the faceted index
• Range filtering for numeric properties (price, size)
• Filtering by SKU properties (OFFER_IBLOCK_ID)
• Generating SEO-friendly URLs for selected filters (SEF_FOLDER)
• AJAX updating of product list without page reload

Limitations:

• Does not support filtering from multiple information blocks simultaneously
• Does not build smart combinations (showing available values accounting for already selected)
• Does not support geofiltering out of the box

When the Standard Component Isn't Enough—We Build a Custom Filter

Sometimes standard capabilities fall short: combining attributes from different categories, complex AND logic, geo-filtering, or high-load performance requirements. Then we write a custom filter with proprietary SQL queries to faceted tables or using ElasticSearch. The cost is calculated individually based on complexity, but a typical budget saving on refinements is up to 30%.

Why Standard Filter Doesn't Work for Complex Attributes

Filter logic: AND within property vs. AND between properties is a design decision often overlooked. Example: a product has a 'Color' property with multiple values ('red', 'blue'). User selects both colors.

• OR logic: show all products that have red OR blue. Most filters work this way.
• AND logic: show only products that have BOTH red AND blue. Makes sense for tags.

The standard component uses OR within one property and AND between different ones. Without modification, this cannot be changed.

Stock Availability in the Filter

A common case: the filter shows property values for which all products are out of stock. User selects 'red' and gets 0 results. Solution at the faceted index level: when rebuilding the index (\Bitrix\Iblock\PropertyIndex\Manager::runIndex()), Bitrix automatically excludes elements with ACTIVE = N. But stock is not automatically accounted for—a custom mechanism is needed:

• Event handler for stock changes in b_catalog_store_amount
• Updating the IN_STOCK flag property on the parent product
• Elements with IN_STOCK = N are marked inactive or filtered in the component

Configuring SEO-Friendly URLs for the Filter

Bitrix automatically generates SEO URLs for the filter when the catalog.smart.filter component is configured with SEF. Format: /catalog/smartfon/filter/brand-is-samsung/. This works only with correct SEF_FOLDER and urlrewrite rules. A design decision: which combinations get SEO pages with meta tags, which do not. For large catalogs, generating all combinations in a sitemap is impractical—a prioritization strategy is needed (e.g., only single-factor filters).

From Our Practice: Filtering System for a Clothing Marketplace

Platform with multiple sellers, 180,000 SKUs, 8 clothing categories with different attributes. Requirement: a unified filter accounting for stock. Attributes vary by category: in 'Shoes'—size (35–46), in 'Outerwear'—size (XS–4XL) and length. Building a single faceted index with 60 properties would show 'Shoe size' in the 'Jackets' section.

Solution:

• Single information block, but filter with a dynamic set of properties depending on the section
• Additional table category_filter_props (custom via DataManager): category → list of properties to display
• Faceted index on the offer information block with a stock flag
• Agent recalculating stock every 30 minutes

Result: filter by size + color + availability—0.2 seconds on 180,000 SKUs. Payback for this solution was under two quarters due to increased conversion.

Step-by-Step Filter Design Plan

1. Collect attributes and filtering requirements (properties, stock tracking, SEO).
2. Choose property types considering faceted index (list, reference, numeric range).
3. Design logic (AND/OR, stock tracking, geofiltering).
4. Configure bitrix:catalog.smart.filter or custom solution with SQL/ElasticSearch.
5. Design SEO URLs: indexable combinations, sitemap configuration.
6. Strategy for updating faceted index and stock (agents, events).
7. Test scenarios: correctness under different combinations, performance under load, edge cases.

Comparison: Standard vs Custom Filter

Typical Mistakes in Filter Design

• Inappropriate property types (string instead of list)—breaks the faceted index.
• Ignoring stock tracking—zero results after selection.
• Lack of SEO URL strategy—page duplication or traffic loss.
• Filtering by all properties from a single information block—unnecessary attributes in the filter.

What's Included in the Design Work

• Analysis of attributes and property types
• Architecture selection (standard or custom filter)
• Logic design with stock tracking, multiple values, and category intersection
• Faceted index and agent update configuration
• Documentation and testing recommendations
• Performance evaluation on test data

Our team: over 10 years of experience in 1C-Bitrix development and 500+ completed projects. We guarantee stable filter operation under any load. To get a precise cost and timeline estimate for your catalog, contact us. Write to us—we'll evaluate your project in one business day.

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.