Wyszukiwarka Magento 2 nie znajduje po SKU: rozwiązanie

Na czym polega problem

Typowa sytuacja w sklepie internetowym na Magento 2.4.x z katalogiem 1–5 tysięcy pozycji: wyszukiwarka Magento 2 działa tylko wtedy, gdy klient wpisze nazwę znak w znak, a wyszukiwanie po SKU nie działa wcale. „Lakier hybrydowy 05” nie pasuje do „Lakier-hybrydowy Pastel Line 05” – dla człowieka to ten sam produkt, dla systemu brak dopasowania. SKU jest uzupełnione w karcie, ale nie jest wyszukiwane: zapytanie „pl05” albo samo „05” daje pustą stronę. Tak samo z kolorem, linią produktów, pisownią łączną i rozdzielną, polskimi znakami i złym układem klawiatury.

Skutek jest mierzalny. Ktoś, kto wpisuje SKU, przyszedł z cennika lub Instagrama z konkretnym zamiarem zakupu – i widzi „brak wyników”. Zwykle nie pisze na czacie, tylko zamyka kartę, a sklep tego nie rejestruje, bo nieudane wyszukiwania nie są zapisywane. Udział sesji z wyszukiwarką odczytujemy przed przebudową w GA4: raport zdarzeń view_search_results oraz wbudowany raport site_search. Po włączeniu logowania pustych wyników zwykle okazuje się, że 5–15% zapytań kończy się zerem rezultatów.

Dlaczego nie da się tego zrobić prosto

Standardowa wyszukiwarka Magento 2.4.x porównuje zapytanie z nazwą i opisem i słabo radzi sobie z dopasowaniem częściowym i atrybutami. Samo włączenie „Use in Search” nie wystarczy: bez osobnej wagi trafienie po SKU przegrywa z przypadkowym trafieniem w opisie, a właściwy produkt ląduje na dziesiątym miejscu. Trzeba zmienić mapping indeksu, wagi pól i analizę zapytania – to prace programistyczne na stronie sklepu, a nie przełączniki w panelu. Istotny jest też silnik: do Magento 2.4.3 standardem był Elasticsearch 7.x, od 2.4.4 wspierany jest OpenSearch, a w 2.4.6+ to domyślny silnik – mapping i analizatory piszemy pod wersję zainstalowaną na sklepie. Część zakresu zamykają gotowe moduły (Smile ElasticSuite, Mirasvit Search); decyzję podejmujemy po audycie, bo ElasticSuite nadpisuje własną logikę istotności i wymaga ponownego przetestowania sortowania i filtrów.

Drugie ograniczenie to inny wykonawca: sklep zwykle utrzymuje inny zespół, prace idą w jego środowisku testowym i repozytorium, a termin liczy się od dnia otrzymania dostępów. Trzecie to dane: przebudowa działa tylko wtedy, gdy SKU, kolor i linia są osobnymi atrybutami. Jeśli leżą tekstem w opisie albo nie są zsynchronizowane z systemem magazynowym, CRM lub ERP, najpierw potrzebne jest uporządkowanie katalogu – jako osobny zakres. Uczciwie zaznaczamy: w naszym portfolio nie ma sklepu na Magento ani projektu stricte wyszukiwarkowego; przeniesiony mechanizm to synchronizacja i porządkowanie atrybutów katalogu, a nie samo wyszukiwanie.

Jak to rozwiązujemy

Rozwiązanie to przebudowa wyszukiwarki sklepu internetowego na poziomie indeksu i analizy zapytania. Praca idzie w pięciu krokach:

1. 1. Indeksowanie atrybutów z wagami. SKU, kolor, linia produktów i nazwa łacińska stają się polami wyszukiwania w mappingu OpenSearch, a trafienie po SKU dostaje wyższy boost niż opis. Dopasowanie częściowe realizuje analizator edge n-gram na polu SKU (minimum 2–3 znaki), literówki – kontrolowane fuzziness na nazwie, nie na numerach. Efekt: „05” pokazuje wszystkie pozycje z tym numerem, „pl05” – konkretną; kolejność słów nie ma znaczenia.
2. 2. Normalizacja zapytania. Poprawa układu klawiatury, obsługa polskich znaków i transliteracji, pisownia łączna i rozdzielna, myślniki, typowe literówki oraz słownik synonimów kolorów i linii w trzech językach.
3. 3. Obsługa pustych wyników. Podpowiedzi od trzeciego znaku ze zdjęciem i ceną, strona „brak wyników” z podobnymi pozycjami z tej samej kategorii i raport zapytań bez wyników – gotowa lista tego, czego brakuje w katalogu lub synonimach. Ten raport jest też materiałem dla SEO i reklamy: pokazuje realne frazy klientów.
4. 4. Feedy na marketplace. Z tych samych uporządkowanych atrybutów generujemy plik XML dla Allegro i Ceneo: mapowanie kategorii i parametrów, SKU jako identyfikator oferty, automatyczna aktualizacja cen i stanów według harmonogramu.
5. 5. Synchronizacja i start. Reguły dotyczą atrybutów, a nie listy produktów, więc stany i SKU spływające z ERP lub CRM aktualizują indeks według harmonogramu – to zwykła automatyzacja wymiany danych, bez ręcznego uzupełniania. Zmiany wchodzą na produkcję jednym krokiem po sprawdzeniu na liście prawdziwych zapytań, z pełną reindeksacją poza godzinami szczytu.

Od czego zależą koszt i termin

Widełki rynkowe dla Magento 2.4.x z katalogiem do 2–3 tysięcy pozycji: podstawowa przebudowa wyszukiwania (atrybuty, dopasowanie częściowe, polskie znaki, układ klawiatury, synonimy, podpowiedzi) – 1 000–1 800 zł netto i 3–5 dni roboczych. Z zarządzaniem wynikami (synonimy z panelu, raport zapytań, ręczne podbijanie pozycji, strona „brak wyników”) – 1 500–2 500 zł netto i 5–7 dni. Razem z eksportem na marketplace i automatyczną aktualizacją cen i stanów – 2 500–3 800 zł netto i 10–12 dni.

Głównym czynnikiem ceny nie jest wielkość katalogu, lecz stan atrybutów. Jeśli SKU, kolor i linia są już w osobnych polach, praca mieści się w dolnej granicy widełek; jeśli są rozrzucone po opisach, dochodzi porządkowanie katalogu, a budżet rośnie z liczbą pozycji. Drugi czynnik to tempo przekazania dostępów przez wykonawcę utrzymującego sklep oraz licencja płatnego modułu, jeśli zdecydujemy się na Mirasvit. Płatność zwykle 50% na starcie i 50% po sprawdzeniu na produkcji; kod zostaje w Państwa repozytorium.

Częste pytania