Розробка модуля пошуку для каталогу 1С-Бітрікс

Коли каталог перевищує 5 000 позицій, штатний пошук Бітрікс на основі b_search_content перестає справлятися: товари не знаходяться за помилками, транслітерацією, синонімами?

На одному проекті з 30 000 товарів частка нульових результатів становила 15% — після впровадження кастомного модуля на PostgreSQL FTS вона впала до 1.2%. Один із клієнтів втрачав понад 200 000 ₽ на місяць через те, що користувачі не знаходили потрібні товари; після впровадження модуля дохід зріс на 12%. Наша розробка модуля пошуку по каталогу 1С-Бітрікс включає нечіткий пошук, синоніми та транслітерацію — все, що потрібно для швидкого та релевантного пошуку. Наша компанія — 5+ років на ринку, 150+ проектів, сертифіковані спеціалісти 1С-Бітрікс. Гарантуємо стабільну роботу та підтримку після запуску. Зниження відмов на 15% економить клієнту до 300 000 ₽ на місяць на рекламі. Замовте консультацію — ми проаналізуємо ваш каталог та запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб отримати безкоштовний аудит поточного пошуку.

Чому штатний пошук не підходить для каталогу?

Штатний пошук (search.php та модуль search) будує повнотекстовий індекс b_search_content. Він працює для контентних сайтів, але не справляється з каталогом: не підтримує транслітерацію («iphone 12» → «айфон 12»), синоніми, числові діапазони («навушники до 3000 гривень»). Як тільки каталог перевищує 10 000 позицій, пошук стає повільним і нерелевантним. Додаткова проблема — відсутність нормалізації запитів: користувачі вводять «айфон» і не знаходять iPhone.

Як розробити модуль пошуку по каталогу 1С-Бітрікс?

Варіанти реалізації

Перш ніж писати власний індекс, варто чесно розглянути готові рішення:

Ми проектуємо модуль з абстрактним шаром пошукового двигуна, щоб перемикати бекенд без переробки логіки Бітрікс.

Архітектура модуля

Індексатор. Агент раз на годину перевіряє зміни в b_iblock_element (по полю TIMESTAMP_X) та оновлює пошуковий індекс. При збереженні товару через події OnAfterIBlockElementUpdate індекс оновлюється негайно для цього елемента. Індекс містить поля: назва, опис, характеристики (значення властивостей), артикул, бренд, категорія, ціна (для фільтрації за діапазоном), наявність. Числові поля зберігаються окремо для range-запитів.

class SearchIndexer { public function indexElement(int $elementId): void { $element = $this->loadElementWithProps($elementId); $document = [ 'id' => $elementId, 'title' => $element['NAME'], 'description' => strip_tags($element['DETAIL_TEXT']), 'sku' => $element['PROPERTY_ARTICLE_VALUE'], 'price' => $this->getMinPrice($elementId), 'in_stock' => $this->isInStock($elementId), 'brand' => $element['PROPERTY_BRAND_VALUE'], 'tsvector' => null, ]; SearchIndexTable::merge($document); } } 

Пошуковий запит. Користувацький рядок нормалізується: транслітерація (iphone → айфон та зворотна), виправлення розкладки клавіатури (руьщт → iphone), видалення стоп-слів. Після нормалізації — запит до індексу з ранжуванням за ts_rank. Словник синонімів зберігається в таблиці myvendor_search_synonyms, перед пошуком запит перевіряється на збіг.

Як працює нечіткий пошук?

Найчастіша причина нульових результатів — помилки. Рішення — відстань Дамерау-Левенштейна для коротких запитів та pg_trgm для PostgreSQL (детальніше про full-text search).

-- Індекс триграм для нечіткого пошуку CREATE INDEX idx_search_title_trgm ON myvendor_search_index USING gin(title gin_trgm_ops); -- Нечіткий пошук з порогом схожості SELECT id, title, similarity(title, 'айфно') AS sim FROM myvendor_search_index WHERE title % 'айфно' ORDER BY sim DESC LIMIT 20; 

Розширення pg_trgm дозволяє шукати за схожістю з порогом (0.3), що ефективніше за попередньо обчислені виправлення. В одному з проектів з каталогом 40 000 товарів впровадження нечіткого пошуку знизило частку нульових результатів з 12% до 0.8%, а середня позиція знайденого товару перемістилася з 5-ї на 2-у.

Що входить у розробку модуля пошуку?

Саджест (автодоповнення)

AJAX-ендпоінт повертає підказки за першими 2+ символами запиту. Підказки беруться з попередньо розрахованої таблиці популярних запитів (myvendor_search_popular, оновлюється з лога запитів раз на добу) та з індексу за LIKE 'запит%' з лімітом 5. Відповідь кешується в Memcached/Redis з TTL 1 година.

Як проходить розробка модуля пошуку?

1. Аудит поточного пошуку та збір лога запитів.
2. Вибір пошукового бекенду (PostgreSQL, Elasticsearch або Sphinx).
3. Розробка індексатора та двигуна пошуку.
4. Інтеграція з сайтом (компонент, AJAX-роутинг).
5. Налаштування сервера та створення індексів.
6. Тестування та навчання співробітників.
7. Документація та передача вихідного коду.
8. Підтримка протягом 1 місяця після релізу.

Що входить у роботу

• Документація — технічне завдання, опис архітектури, інструкції з розгортання та оновлення.
• Вихідний код — повний код модуля з коментарями, без обфускації, розміщується в репозиторії.
• Навчання — 2-годинна онлайн-сесія для адміністраторів та розробників замовника.
• Деплой — налаштування пошукового бекенду та перенесення файлів на бойовий сервер, налаштування агентів кешування.
• Підтримка — 1 місяць безкоштовного супроводу після запуску (виправлення критичних помилок).

Терміни розробки

Завдяки багаторічному досвіду ми робимо розробку ефективно та без зриву термінів. Зв'яжіться з нами — ми запропонуємо рішення, яке окупиться за рахунок зростання конверсії. Гарантуємо якість та підтримку.

Детальну інформацію про пошукові механізми можна знайти в офіційній документації 1С-Бітрікс.