Пошук Magento не знаходить за артикулом: як виправити

Що болить

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

Людина, яка вводить артикул, прийшла з прайсу чи Instagram з готовим наміром купити — і бачить «нічого не знайдено». Вона не пише в чат, а закриває вкладку, і магазин цього навіть не бачить: невдалі запити ніде не фіксуються. Частку сесій з внутрішнім пошуком варто подивитися у звіті site_search у GA4 до початку робіт — це і буде база для порівняння після переробки.

Що заважає зробити просто

Штатний пошук Magento 2.4.x порівнює запит із назвою та описом і майже не вміє працювати з частковими збігами й атрибутами. Увімкнути атрибуту «Use in Search» недостатньо: без окремої ваги збіг по артикулу програє випадковому збігу в описі, і потрібна позиція опиняється на десятому місці. Треба змінювати склад пошукового індексу, ваги полів, аналізатори та розбір запиту — це повноцінна розробка сайту, а не галочка в адмінці. Важливо врахувати й рушій: до Magento 2.4.3 включно стандартом був Elasticsearch 7.x, з 2.4.4 офіційно підтримується OpenSearch, а в 2.4.6+ він стоїть за замовчуванням — від цього залежить синтаксис аналізаторів і сумісність модулів.

Друге обмеження — чужий підрядник: сайт зазвичай супроводжує інша команда, роботи йдуть у її тестовому середовищі й репозиторії, і строк рахується з дня отримання доступів. Третє — дані: переробка працює, лише якщо артикул, колір і лінійка заповнені окремими атрибутами. Якщо вони лежать текстом в описі або не синхронізовані з обліковою системою (CRM чи ERP на кшталт KeyCRM, SalesDrive, Odoo), спершу потрібна нормалізація каталогу — окремий обсяг робіт.

Як вирішуємо

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

1. 1. Індексація атрибутів з вагами. Артикул, колір, лінійка й назва латиницею стають окремими полями індексу OpenSearch з boost'ом: збіг по артикулу важить більше за збіг в описі. Частковий збіг реалізується edge n-gram аналізатором (мінімум 2–3 символи) плюс fuzziness: AUTO на текстових полях — «05» показує всі позиції з такою нумерацією, «pl05» — конкретну; порядок слів не має значення. Для Magento 2.4.x це робиться або власним модулем поверх Magento\Elasticsearch, або на базі Smile ElasticSuite (безкоштовний, дає керування вагами й аналізаторами), або Mirasvit Advanced Search — вибір залежить від того, що вже стоїть у проєкті й чи готовий підрядник підтримувати сторонній модуль.
2. 2. Нормалізація запиту. Виправлення розкладки («utkm» → «гель»), транслітерація латиниця ⇄ кирилиця («пастел лайн» → Pastel Line), склеєне й роздільне написання, дефіси, типові помилки, плюс словник синонімів кольорів і лінійок трьома мовами.
3. 3. Робота з порожньою видачею. Підказки з третього символу з фото й ціною, сторінка «нічого не знайдено» зі схожими позиціями з тієї ж категорії, звіт за запитами без результату — готовий список того, чого бракує в каталозі чи синонімах. Ці ж запити корисні для SEO й для реклами: за ними видно, що люди реально шукають.
4. 4. Вивантаження на маркетплейси (опційно). Ті самі нормалізовані атрибути формують фід для Rozetka і Prom.ua: мапінг категорій, артикул як ідентифікатор позиції, автооновлення цін і залишків за розкладом — каталог на сайті й на майданчиках перестає розходитися.
5. 5. Синхронізація й запуск. Правила налаштовуються на атрибути, а не на список товарів, а залишки й артикули підтягуються з ERP чи CRM за розкладом — це звичайна автоматизація обміну даними. Прямого аналога «пошук у Magento» в наших кейсах немає: спільний механізм тут — синхронізація атрибутів і довідників, як у магазині з інтеграцією keyCRM або в проєкті, де налаштовані довідники і мультикомпанія в коробковій ERP. На живий сайт зміни виходять одним кроком після перевірки за списком реальних запитів і контролю, що SEO-URL фільтрів і layered navigation лишилися без змін.

З чого складається вартість і строк

Ринкова вилка для 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% після перевірки на живому сайті, код лишається у вашому репозиторії.

Питання, які ставлять найчастіше