Custom React Search Development for 1C-Bitrix

We often encounter a situation where the built-in Bitrix search can no longer handle the load of an e-commerce store. The standard search module with morphological indexing in b_search_content and b_search_stem tables responds in 800–1200 ms and does not support instant search. This is critical for catalogs with 50,000+ SKUs: customers leave without waiting for results. We develop custom React search for catalogs from 10,000 to 500,000 SKUs. Our experience — over 10 years in Bitrix development, dozens of implementations, including integration with 1C via CommerceML and trade catalogs of any complexity. For catalogs with 10,000 SKUs, infrastructure costs are minimal, and the conversion uplift from fast search reaches 15–20%.

Choosing a search engine

Elasticsearch / OpenSearch — justified for volumes >100,000 documents, full-text search with morphology, boost ranking, synonyms. Requires a separate server. Typesense — a simpler alternative with good performance, easier to administer. Suitable for medium catalog. Meilisearch — fast start, fuzzy search out of the box, good documentation. For catalogs up to 500,000 items. Custom SQL (Bitrix) — FULLTEXT INDEX in MySQL or tsvector in PostgreSQL. Works without additional infrastructure, sufficient for catalogs up to 50,000 SKUs.

Engine comparison:

Meilisearch processes queries 10x faster than the native Bitrix search — confirmed by our tests for catalogs up to 500,000 items.

How to choose an engine for your catalog?

For most mid-range e-commerce stores (up to 100,000 SKUs), we recommend Meilisearch or custom PostgreSQL full-text. Elasticsearch only if you already have the infrastructure or require advanced search analytics.

Bitrix product indexing

Regardless of the chosen engine, data synchronization between Bitrix and the search index is needed. We use the OnProductUpdate event (1C-Bitrix product change event) to add a task to the background queue.

// Обработчик события изменения товара
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'catalog', 'OnProductUpdate',
    function(\Bitrix\Main\Event $event) {
        $productId = $event->getParameter('id');
        \Local\Search\IndexQueue::add($producs ProductIndexer
{
    public function indexProduct(int $productId): void
    {
        $product = \CIBlockElement::GetById($productId)->GetNext();
        $prices  = \CCatalogProduct::GetOptimalPrice($productId, 1, [], 'N', [], SITE_ID);
        $props   = $this->getProductProperties($productId);

        $document = [
            'id'          => $productId,
            'name'        => $product['NAME'],
            'description' => strip_tags($product['DETAIL_TEXT']),
            'brand'       => $props['BRAND']['VALUE'],
            'price'       => $prices['RESULT_PRICE']['DISCOUNT_PRICE'],
            'in_stock'    => $props['QUANTITY']['VALUE'] > 0,
            'category'    => $this->getCategoryPath($product['IBLOCK_SECTION_ID']),
        ];

        $this->searchEngine->upsertDocument($document);
    }
}

Synchronization via queue (\Bitrix\Main\Application::getInstance()->addBackgroundJob()) — changes are processed asynchronously, without slowing down the main thread.

React search component

Instant search with debounce is fundamental for UX. Minimum delay for a live feel: 200–300 ms.

function SearchBox() {
  const [query, setQuery] = useState('');
  const debouncedQuery = useDebounce(query, 250);

  const { data, isLoading } = useQuery({
    queryKey: ['search', debouncedQuery],
    queryFn:  () => searchProducts(debouncedQuery),
    enabled:  debouncedQuery.length >= 2,
    staleTime: 10_000,
  });

  return (
    <div className="search-wrapper">
      <input
        value={query}
        onChange={e => setQuery(e.target.value)}
        placeholder="Поиск товаров..."
      />
      {debouncedQuery.length >= 2 && (
        <SearchDropdown results={data} isLoading={isLoading} />
      )}
    </div>
  );
}

The search dropdown is split by categories: 'Products', 'Categories', 'Brands', 'Articles'. Categorization is done server-side or on the front end from a unified response.

Why implement search analytics?

Search analytics is an underrated tool. Zero-result queries directly indicate missing products that customers are looking for. Low CTR queries reveal mismatched expectations. We set up click tracking in GA4 and a custom local_search_analytics table, allowing targeted ranking adjustments.

Case study: a construction hypermarket

A building materials store, 85,000 SKUs, 12,000 unique search queries per day. Problem: built-in Bitrix search couldn't find products with typos (e.g., 'шпатлёфка' vs 'шпатлёвка'), didn't support SKU search, and had 800–1200 ms response time.

We chose Meilisearch (single server, sync via Bitrix queue).

Implementation: Index includes: name, description, brand, SKU, synonyms (a separate table in Bitrix with 'query → correct term' pairs). Fuzzy search with typoTolerance — Meilisearch handles typos automatically. React dropdown — 4 sections: top 4 products, categories (if query matches a category name), brands, 'View all results'. Fixed dropdown height (max 480 px), scrollable list.

Full results page

For the full results page (/search/?q=шпатлёвка) — a React application with a side filter (same components as the catalog), sorting, pagination. URL syncs with all parameters. Highlighting — matches are highlighted in search results. Meilisearch returns a _formatted field with <em> tags, styled in React.

How does React search development proceed?

1. Catalog analysis: volume, infoblock structure, typical queries.
2. Engine selection and index configuration with synonyms and stop words.
3. Synchronization: writing the indexer, setting up queues.
4. Development of React components: instant search, dropdown, results page.
5. Analytics integration: click tracking, zero-results monitoring.
6. Testing and optimization: A/B speed tests, ranking adjustments.

What's included

• Selection of the search engine based on volume and budget
• Index setup and synchronization with the Bitrix catalog
• React development: instant search, dropdown, full results page
• Configuration of synonyms, stop words, and boost ranking
• Analytics: click tracking, zero-results monitoring
• Documentation, access handover, team training
• Post-project support: 3-month warranty

Timeline and cost

Cost is calculated individually after a catalog audit. Instant search with a dropdown — from 2 weeks. Full results page plus analytics — from an additional 2 weeks. Contact us — we'll assess your project for free.

We guarantee: 10+ years of Bitrix experience, certified specialists, 15+ successful custom search implementations. Get a consultation — write to us.

What Does React Development for 1C-Bitrix Provide and When Is It Needed?

A catalog with 30,000 SKUs and a faceted filter — the standard Bitrix template loads the page in 3 seconds. A B2B cabinet with personalized discounts — price recalculation with every filter change. The bottleneck is not the data but the monolithic architecture: each block calls REST separately, 6–8 sequential requests of 200–500 ms result in a total delay of 2–3 seconds. React solves this radically: component model, virtual DOM, and library ecosystem turn a slow interface into a responsive application. We are a certified 1C-Bitrix partner with 10+ years of experience and over 500 completed projects. Order an audit — we will evaluate your project in 1–2 days and show cases similar to yours.

Architectural Approaches

SPA on React + REST API Bitrix (BX.rest)

The React application lives separately, accessing /rest/ or custom endpoints via CRestServer. Maximum control, but also maximum work.

• Client-side routing with React Router — transitions without reload, but on F5 you need a catch-all on Nginx: try_files $uri /index.html
• Optimistic updates: cart updates instantly, sale.basket.update flies in the background. On error, roll back state and show a toast
• Frontend deploys to CDN independent of Bitrix — updated a button without touching the backend

SSR with Hydration — When Yandex Doesn't See SPA

Yandex has learned to render JS, but not perfectly; Googlebot is better, but still not 100%. Server-side rendering of React components via Node.js solves the problem radically: the bot receives ready HTML, the user gets an interactive application after hydration. FCP drops below one second on normal hosting, og:title and og:image work for social networks. The complexity is needing a Node.js process alongside Apache/Nginx serving Bitrix: two runtimes, two deploys, two log sets. Bitrix cache (CPHPCache, Composite) can be used to warm data that later goes to SSR.

Headless Bitrix — Admin Panel for Content Managers, React for Visitors

Content manager logs into /bitrix/admin/, edits infoblocks. The visitor sees a React application that retrieves data via API. One backend serves the site, mobile app, and Telegram bot. Scaling: React bundle on CloudFront/CDN, Bitrix on a single server. With 50,000 unique visitors, the frontend does not directly load the backend. Pitfall: the standard Bitrix visual editor (BXEditor) stops working for visitors — content managers will have to work only through the admin panel.

Stack and Component Architecture

Stack We Actually Use

How We Build Components and Type Data

Every project starts with a design system — otherwise, by the third month, three developers will write three different button components. Typography, colors, spacing — via CSS variables and Tailwind config. Forms: inputs with masks (phone, INN), searchable selects, file upload with preview and MIME validation. Product card is a separate story: price with discounts from CCatalogProduct::GetOptimalPrice(), labels "Hit"/"New" from infoblock properties, "Add to cart" button with loading/success/error states. Tables with virtualization (react-window) for price lists of 5000+ rows.

We type everything that comes from Bitrix. The REST API returns string where you'd expect number, "Y"/"N" instead of boolean, and null instead of empty array. A Zod schema on input parses and transforms — components get proper types.

// Real type of CIBlockElement via REST — surprises everywhere
interface BitrixProduct {
  ID: string;          // yes, string, not number
  ACTIVE: "Y" | "N";  // not boolean
  PRICE: string;       // also string
  QUANTITY: string;    // and this is string
}

Performance and API Integration

Aggregating endpoints are key. One ajax.php or custom controller on \Bitrix\Main\Engine\Controller gathers catalog data, filters, cart, and user in a single request. React Query caches the response, and a second visit returns from cache with staleTime — load time reduces by 60% already on the second load.

How Does React Improve Core Web Vitals?

• LCP < 2.5 s — lazy loading images via loading="lazy", inline critical CSS, preload LCP image via <link rel="preload">
• INP (replaces FID) < 200 ms — useTransition for heavy filtering, useDeferredValue for search input
• CLS < 0.1 — fixed sizes for skeletons and images. Skeleton placeholders instead of spinners

Virtualization is not optional, but necessary. A catalog with faceted filter may return 500 products per page. React-window or react-virtuoso render only the visible 20–30 cards — DOM does not bloat, scrolling is smooth.

REST and Custom Controllers

Out of the box via /rest/: infoblocks (iblock.element.get), cart (sale.basket.*), orders (sale.order.*), users (user.*). For a simple catalog, that's enough. But 70% of tasks require custom endpoints. \Bitrix\Main\Engine\Controller is the standard way to create your own endpoints in D7. Write a controller, register via registerAction, get endpoint with CSRF protection and authorization out of the box.

• Aggregation: one request = catalog data + filters + cart + user
• WebSocket via Bitrix Push & Pull (CPullStack::AddByTag) — order status updates in real time, no polling
• GraphQL middleware (webonyx/graphql-php) on top of D7 ORM — frontend requests exactly the fields it needs. Mobile traffic savings up to 40%

Projects, Timelines, and What's Included

Typical Projects We Have Already Done

• Online store with 30,000 SKUs and faceted filter via \Bitrix\Iblock\PropertyIndex\Facet — SPA, React Query, catalog virtualization
• B2B cabinet: personalized prices from CCatalogGroup, reconciliation statements from 1C via \Bitrix\Sale\Compatible\OrderCompatibility, order history with filtering
• Corporate portal: dashboards on Recharts, real-time via Push & Pull, integration with internal APIs through middleware
• Marketplace: two React applications (buyer + seller), common backend, data separation via CUser::GetUserGroup()

Timelines and What's Included

• Audit of current Bitrix code and architecture
• Design of API layer (REST / custom controllers / GraphQL)
• Development of design system and components
• CI/CD setup (deploy React bundle independently of Bitrix)
• Documentation of endpoints and types (Swagger / TypeScript types)
• Transfer of access to server, admin panel, repository
• Training content managers to work through the admin panel
• Warranty support for 2 months after delivery

Exact numbers after scope analysis. Assessment is phased, with a fixed budget for each sprint.

How We Implement React in a Project

1. Audit existing code — find bottlenecks: redundant requests, outdated templates, suboptimal caches.
2. Design API layer — determine which endpoints are needed, design aggregators or GraphQL.
3. Develop design system — create components (buttons, forms, cards) based on mockups or UX recommendations.
4. Integrate with Bitrix via chosen approach (SPA, SSR, or Headless) — set up rendering and routing.
5. Test and deploy — launch a pilot section (e.g., catalog), measure Core Web Vitals, upon approval expand.

Why React, Not Vue or Bitrix Templates

• Ecosystem. For any UI task, there is a ready library: tables, charts, drag-and-drop, virtualization. For Vue, the choice is narrower; for Bitrix templates, almost absent.
• Talent pool. Finding a React developer is three times easier than a Bitrix templater who knows D7 and template.php.
• React Native. Components are reused in mobile app — not one-to-one, but business logic and types are shared.
• Gradual adoption. Start with one section (/catalog/) on React, keep the rest on Bitrix templates. component_epilog.php loads the React bundle, data is passed via window.__INITIAL_DATA__.

1C-Bitrix + React is not a theoretical architecture but a working combination that already serves catalogs with tens of thousands of SKUs and B2B cabinets with heavy business logic. Learn more about React and 1C-Bitrix. Get a consultation — we will send you cases similar to your project. Contact us to discuss details. We implement turnkey with a guarantee of results.