Поиск Magento не находит по артикулу: как исправить

Что болит

Типичная ситуация для интернет-магазина на Magento 2.4.x с каталогом на 1–5 тысяч позиций: поиск Magento не находит товар по артикулу и срабатывает, только когда покупатель ввёл название символ в символ. «Гель лак 05» не совпадает с «Гель-лак Pastel Line 05» — для человека это тот же товар, для системы полное несовпадение. Артикул в карточке заполнен, но в поиск не попадает: запрос «pl05» или просто «05» даёт пустую выдачу. То же с цветом, линейкой, слитным и раздельным написанием, латиницей и кириллицей, не той раскладкой.

Человек, который вводит артикул, пришёл из прайса или Instagram с готовым намерением купить — и видит «ничего не найдено». Он не пишет в чат, а закрывает вкладку, и магазин этого даже не видит: неудачные запросы нигде не фиксируются. Первый шаг — включить в GA4 отчёт по внутреннему поиску (событие view_search_results, параметр search_term) и увидеть, сколько запросов заканчивается пустой выдачей.

Что мешает сделать просто

Штатный поиск Magento 2.4.x сравнивает запрос с названием и описанием и почти не умеет работать с частичными совпадениями и атрибутами. Включить атрибуту «Use in Search» недостаточно: без отдельного веса совпадение по артикулу проигрывает случайному совпадению в описании, и нужная позиция оказывается на десятом месте. Нужно менять состав поискового индекса, веса полей и разбор запроса — через собственный модуль или готовый (Mirasvit Search, Smile ElasticSuite), если его лицензия вас устраивает. Важна и версия движка: до Magento 2.4.3 это Elasticsearch 7.x, начиная с 2.4.4 поддерживается OpenSearch, а в 2.4.6+ он идёт как движок по умолчанию — от этого зависит синтаксис маппинга и анализаторов.

Второе ограничение — чужой подрядчик: сайт обычно сопровождает другая команда, работы идут в её тестовой среде и репозитории, и срок считается со дня получения доступов. Третье — данные: переработка работает, только если артикул, цвет и линейка заполнены отдельными атрибутами. Если они лежат текстом в описании или не синхронизированы с учётной системой (ERP, CRM — KeyCRM, SalesDrive, Odoo, BAS), сначала нужна нормализация каталога — отдельный объём работ.

Как решаем

Решение — перестроить поиск интернет-магазина на уровне индекса и разбора запроса. Работа идёт в пять шагов:

1. 1. Индексация атрибутов с весами. Артикул, цвет, линейка и название латиницей становятся отдельными полями индекса OpenSearch/Elasticsearch, совпадение по артикулу весит больше совпадения в описании. Частичное совпадение делается edge n-gram анализатором (минимум 2–3 символа) плюс fuzziness: AUTO для опечаток: «05» показывает все позиции с такой нумерацией, «pl05» — конкретную; порядок слов не важен. Реализуется либо собственным модулем с переопределением маппинга, либо на базе Smile ElasticSuite/Mirasvit — выбор фиксируем до старта.
2. 2. Нормализация запроса. Исправление раскладки («utkm» → «гель»), транслитерация латиница ⇄ кириллица («пастел лайн» → Pastel Line), слитное и раздельное написание, дефисы, типичные опечатки, плюс словарь синонимов цветов и линеек на трёх языках.
3. 3. Работа с пустой выдачей. Подсказки с третьего символа с фото и ценой, страница «ничего не найдено» с похожими позициями из той же категории, отчёт по запросам без результата — готовый список того, чего не хватает в каталоге или синонимах. Этот же отчёт полезен для SEO и для рекламы: видно, какими словами людям удобно искать.
4. 4. Синхронизация каталога и товарные фиды. Правила настраиваются на атрибуты, а не на список товаров: остатки и артикулы, приходящие из ERP или CRM, подхватываются индексом без ручной правки — это обычная автоматизация обмена данными между учётной системой и сайтом. Те же нормализованные атрибуты формируют XML-фиды для Rozetka и Prom.ua. Кейса по поиску в Magento в портфолио нет: переносим механизм работы с атрибутами, а не готовое решение для поиска — так мы разбирали справочники и мультикомпанию в коробочной ERP и связывали каталог интернет-магазина сумок с keyCRM.
5. 5. Запуск и проверка. Сборка тестируется на копии каталога по списку реальных запросов из отчёта, на живой сайт изменения выходят одним релизом с возможностью отката.

Из чего складывается стоимость и срок

Рыночная вилка для Magento 2.4.x с каталогом до 2–3 тысяч позиций: базовая переработка поиска (атрибуты, частичные совпадения, транслитерация, раскладка, синонимы, подсказки) — 8 000–14 000 ₴, 3–5 рабочих дней. С управлением выдачей (синонимы из админки, отчёт по запросам, ручное поднятие позиций, страница «ничего не найдено») — 12 000–20 000 ₴, 5–7 дней. Вместе с выгрузкой на маркетплейсы (фид, маппинг категорий, автообновление цен и остатков) — 20 000–30 000 ₴, 10–12 дней.

Главный фактор цены — не размер каталога, а состояние атрибутов. Если артикул, цвет и линейка уже в отдельных полях, работа по разработке сайта укладывается в нижнюю границу вилки; если разбросаны по описаниям — добавляется нормализация каталога, и бюджет растёт с количеством позиций. Второй фактор — скорость получения доступов от подрядчика, который сопровождает сайт. Оплата обычно 50% на старте и 50% после проверки на живом сайте, код остаётся в вашем репозитории.

Частые вопросы