Catalog and Filtering on 1C-Bitrix

Why an Infoblock-Based Catalog Is Both a Blessing and a Headache

Infoblocks in Bitrix store products in b_iblock_element and b_iblock_element_property tables. When the catalog has 5,000 SKUs — everything flies. When it has 80,000 — bitrix:catalog.smart.filter starts generating JOINs across 6-8 property tables, and MySQL goes into full scan. We design catalogs that handle half a million items without degradation — through faceted indexes, proper property architecture, and hybrid storage.

Smart Filter: The Standard Component and Its Limits

bitrix:catalog.smart.filter builds a filter form automatically from infoblock properties. Out of the box you get checkboxes, radio buttons, sliders (range), dropdowns, color circles, and image buttons.

But here's what needs to be customized on almost every project:

• Product count next to each value — without it, shoppers click into the void
• Hiding empty values — a "graveyard" of zero-count checkboxes kills UX
• AJAX application without a "Show" button — users expect instant response
• Resetting individual parameters instead of the entire filter at once
• Collapsible groups with state remembered in localStorage

Horizontal placement above the catalog saves space on mobile — but requires template rework, the default layout is on the side.

Faceted Index — The Most Important Thing to Know

This is where the real performance gains are buried. Without a faceted index, every filter click triggers an SQL query with JOINs across b_iblock_element, b_iblock_element_property, b_catalog_price, and a couple more tables. On 100,000 products, that query takes 2-4 seconds. With a faceted index — 30-80 ms.

How it works: Bitrix creates a b_catalog_smart_filter table (the faceted index) where it stores precalculated combinations of "section + property + value + product count." During filtering, the engine queries this flat table instead of assembling data from the normalized infoblock structure.

Pitfalls everyone steps on:

• The index must be created for each catalog section separately — through the admin panel "Products → Faceted Index → Create"
• During bulk imports (1C sync, CSV upload), the index gets invalidated. If you don't set up reindexing via the CIBlockCatalog::ReindexFacet agent or a cron job — the filter starts showing incorrect counts
• Not all properties need to be in the facet. An "Internal SKU" property that nobody filters by just bloats the index
• On catalogs with 300,000+ items, the facet table weighs gigabytes — monitor its size via SHOW TABLE STATUS LIKE 'b_catalog_smart_filter'

SEO Filters

The standard filter generates ?filter[brand]=apple&filter[color]=black — search engines either don't index these URLs or treat them as duplicates. But the query "apple laptops black" is the most conversion-rich long-tail traffic.

We create clean URLs: /catalog/laptops/brand-apple/color-black/ with unique title, description, and H1. Not templated "Buy {brand} in Minsk" but meaningful — tailored to the specific combination.

Important details:

• Canonical URLs — so /brand-apple/color-black/ and /color-black/brand-apple/ don't duplicate each other
• Controlling the number of indexed combinations — 10 properties with 20 values each produce millions of pages, Yandex penalizes for that
• Automatic sitemap for SEO filter pages
• Admin interface for the manager — they decide which intersections to index

Infoblocks vs Highload Blocks

In practice, the best architecture is hybrid. Products and sections live in infoblocks — that's where SEO, the visual editor, and standard catalog components are. But reference properties (brands, cities, size charts) with thousands of values are moved to Highload blocks. HLBs work with separate tables directly, without the b_iblock_element_property overhead.

When it's definitely time for HLBs: the "Cities" directory exceeded 5,000 values, and the dropdown in the product card takes 8 seconds to load. Or the "Size" property for a shoe catalog — 200 values that get pulled on every page.

User data (favorites, viewed items, comparison) also goes into Highload blocks. It grows fast, and infoblocks aren't built for that.

Multi-Categories

A product in Bitrix can belong to multiple sections simultaneously. A backpack — both in "Camping Gear" and "Gifts for Men." Linked via additional sections without physically duplicating the element. The key is to set up canonical URLs so the search engine doesn't treat one product in three sections as three duplicates.

Quick View and Sorting

Quick view — an AJAX modal with photos, price, availability, and an "Add to Cart" button. Preloading on cursor hover gives the feeling of instant response. On mobile — a bottom sheet instead of a popup.

Out-of-the-box sorting: price, popularity, rating, newness, name, availability. For promotional sections, we add sorting by discount size; for B2B catalogs — a table view with technical parameters. Preferences are saved in cookies between sessions.

Performance

• Selecting only needed fields via arSelect — no SELECT * on infoblocks
• Managed cache with tags: added a product — cache is automatically rebuilt
• Composite cache for anonymous users — TTFB < 100 ms, HTML is served without launching PHP
• Indexes on properties used in filtering — without them, MySQL scans the entire b_iblock_element_property
• TTFB monitoring: if the catalog responds slower than 500 ms — we dig into the slow query log

Implementation Timelines

A catalog pays for itself through conversion growth and SEO traffic from long-tail queries. But most importantly — the buyer finds the product in two clicks instead of leaving after the first tap on the filter.