На прошлой неделе мне написал владелец интернет-магазина автозапчастей. У него 14 тысяч позиций в каталоге, WooCommerce, хостинг за три тысячи рублей в месяц, и одна очень конкретная боль — поиск. Человек говорит: «Клиент вводит артикул детали, жмёт Enter, ждёт шесть секунд, получает пустой результат, и уходит к конкуренту. Я теряю деньги каждый день, и не могу понять, что с этим делать». Я спросил, что он уже пробовал. Выяснилось — ставил три разных поисковых плагина, один платный за 79 долларов в год, и ни один толком не решил проблему. Поиск по-прежнему тормозил, опечатки не прощал, а русскую морфологию не понимал вообще. Слово «подшипник» находило, а «подшипники» — уже нет.

Эта история — не исключение. Я слышу подобное практически каждую неделю от разных людей, с разными магазинами, но с одной и той же проблемой. И знаете что меня поражает больше всего? Не то, что встроенный поиск WordPress плохой — это давно известно. А то, что огромное количество владельцев магазинов даже не подозревают, насколько он плохой и сколько денег они теряют из-за этого каждый месяц. Они списывают низкую конверсию на конкуренцию, на сезонность, на рекламу — на что угодно, кроме того маленького окошка поиска в шапке сайта, через которое проходит от 30 до 60 процентов всех покупателей.

Давайте разберёмся, почему так происходит, что с этим можно сделать, и почему мы в итоге построили собственный поисковый модуль на Typesense прямо внутри нашего плагина COS WP Woo. Я расскажу без прикрас — с реальными цифрами, с граблями, на которые мы наступали, и с результатами, которые получили на боевом магазине с почти семнадцатью тысячами товаров.

Почему встроенный поиск WordPress — это приговор для интернет-магазина

Чтобы понять масштаб проблемы, нужно на секунду заглянуть под капот. Когда покупатель вводит запрос в стандартную строку поиска WordPress и нажимает Enter, происходит следующее: WordPress берёт этот запрос и формирует SQL-запрос к базе данных MySQL. Причём делает это самым примитивным способом из возможных — через оператор LIKE с процентами по обеим сторонам. Если перевести на человеческий язык, это звучит примерно так: «Дорогая база данных, пожалуйста, пройдись по каждой строке таблицы wp_posts и проверь, содержит ли поле post_title или post_content где-нибудь внутри себя эту последовательность символов». Нет индекса, нет оптимизации, нет ничего — просто полный перебор, строка за строкой.

На блоге с пятьюдесятью статьями это работает нормально. На магазине с тысячей товаров — терпимо. Но когда у вас десять, пятнадцать, двадцать тысяч позиций, причём каждый товар имеет мета-поля, атрибуты, описания, вариации — это превращается в катастрофу. MySQL начинает задыхаться. Запрос, который должен выполняться мгновенно, занимает от полутора до трёх секунд. А если сервер в этот момент нагружен другими задачами — легко и пять-шесть секунд.

Но медлительность — это ещё полбеды. Настоящая проблема в том, что этот поиск тупой. Он не понимает морфологию — если товар называется «Масло моторное синтетическое», а покупатель ищет «моторные масла», стандартный поиск его не найдёт. Потому что «моторное» и «моторные» — это для LIKE-оператора разные строки. Он не прощает опечатки — набрал «масло Шелл» вместо «масло Shell», и всё, результатов ноль. Он не умеет в релевантность — если запросу соответствуют триста товаров, они выстраиваются не по важности, а по дате публикации. Промышленный кабель за двести рублей окажется выше генератора за миллион просто потому, что был добавлен в каталог позже.

Я долго думал, почему WordPress за двадцать лет существования так и не обзавёлся нормальным поиском. И пришёл к выводу, что дело не в лени разработчиков, а в архитектуре. WordPress проектировался как движок для блогов, и поиск по блогу — это совершенно другая задача, чем поиск по товарному каталогу. Для блога достаточно найти статью по ключевым словам. Для магазина нужно находить товар по артикулу, по бренду, по характеристике, по синониму, по части названия, с учётом опечатки — и делать это за доли секунды, с мгновенным предпросмотром и фильтрацией. WordPress для этого просто не создан, и никакие плагины, которые пытаются «допилить» стандартный WP_Query, принципиально эту проблему не решат. Нельзя починить то, что сломано by design.

Вот в чём штука: большинство «поисковых плагинов» для WooCommerce делают именно это — пытаются улучшить стандартный запрос. Добавляют поиск по мета-полям, по SKU, подкручивают релевантность через дополнительные JOIN-ы к таблицам. И это даёт эффект — процентов на двадцать, может тридцать. Но фундаментальная проблема остаётся: поиск всё равно идёт через MySQL, всё равно через полный перебор, всё равно без морфологии и без нормальной обработки опечаток. Это как пытаться выиграть гонку Формулы-1 на «Жигулях», просто покрасив их в красный цвет и наклеив спойлер.

Typesense — когда я впервые увидел разницу

Мы пришли к Typesense не сразу. Сначала смотрели на Elasticsearch — признанный стандарт полнотекстового поиска, который используют Amazon, eBay и половина крупных e-commerce площадок мира. Технически Elasticsearch великолепен. Но для небольшого и среднего интернет-магазина это как покупать карьерный самосвал, чтобы возить продукты из «Пятёрочки». Elasticsearch требует минимум два гигабайта оперативной памяти просто чтобы запуститься. На практике для комфортной работы нужно четыре-восемь гигабайт. Это отдельный сервер или мощный VPS. Плюс Java-стек, плюс сложная конфигурация, плюс необходимость мониторинга и обслуживания. Для магазина на десять-пятнадцать тысяч товаров это как стрелять из пушки по воробьям, причём пушка ещё и дорогая в обслуживании.

Потом коллега порекомендовал Typesense. Честно говоря, я отнёсся скептически — open-source проект, не так широко известен, как Elasticsearch или Algolia. Но решил попробовать, и первый же тест меня буквально поразил. Мы загрузили в Typesense индекс из пятнадцати тысяч товаров, и поисковый запрос стал выполняться за пять-двенадцать миллисекунд. Не секунд — миллисекунд. Для сравнения, тот же запрос через стандартный WooCommerce-поиск на этом же каталоге занимал от восьмисот до полутора тысяч миллисекунд. Разница не в разы — в десятки раз.

Но скорость — это только одна сторона медали. Typesense из коробки умеет то, чего MySQL не будет уметь никогда: поиск с учётом опечаток, так называемый typo tolerance. Покупатель набирает «Кастрол» вместо «Castrol» — и всё равно находит нужные масла. Пишет «гидравлическоен масло» — Typesense понимает, что это опечатка, и выдаёт правильные результаты. Для русскоязычного магазина это критически важно, потому что русская раскладка клавиатуры и латинские названия брендов — это бесконечный источник опечаток. Люди переключают раскладку не в тот момент, пишут транслитом, путают «и» и «й», «е» и «ё» — и Typesense всё это корректно обрабатывает.

Отдельно стоит сказать про морфологию. Для английского языка это не так критично — там морфология относительно простая. Но русский язык — это другая история. У нас одно существительное может иметь двенадцать форм, а глагол — и того больше. «Масло», «масла», «маслу», «маслом», «масле», «масел» — всё это один и тот же товар, и поисковый движок обязан это понимать. Typesense поддерживает русскую морфологию, и это работает не идеально — бывают edge cases, — но на порядок лучше, чем тупое сравнение строк в MySQL.

А ещё Typesense потребляет смехотворно мало ресурсов по сравнению с Elasticsearch. Для индекса из двадцати тысяч товаров хватает ста-двухсот мегабайт оперативной памяти. Он написан на C++, работает как один бинарный файл, не требует Java, не требует сложной инфраструктуры. Можно поставить прямо на тот же сервер, где крутится WordPress, и он будет мирно сосуществовать, потребляя минимум ресурсов. Или использовать облачный Typesense Cloud — там есть бесплатный тариф для небольших проектов и вполне доступные платные планы.

Когда я увидел всё это в действии, стало очевидно: встроенный поиск WordPress должен быть заменён полностью, а не «улучшен». И мы начали строить интеграцию Typesense прямо внутри нашего плагина, чтобы владелец магазина мог получить поиск уровня Algolia, но без ежемесячных платежей в сотни долларов и без необходимости разбираться в настройке поисковых серверов.

Как мы это построили — и на какие грабли наступили

Идея звучит просто: берём данные из WooCommerce, загружаем в Typesense, показываем результаты через AJAX-виджет. На практике, конечно, всё оказалось сложнее. Первый вопрос, который встал — что именно индексировать. Название товара — очевидно. Описание — тоже. А дальше начинаются нюансы. SKU (артикул) — обязательно, потому что многие B2B-покупатели ищут именно по артикулу. Атрибуты товара — да, потому что человек может искать «масло 5W-30» и ожидать, что поиск найдёт товары с атрибутом вязкости 5W-30. Цена — нужна для фасетной фильтрации, чтобы можно было отфильтровать результаты по диапазону цен. Категории — для тех же фасет. Бренд — аналогично. Наличие на складе — потому что нет ничего хуже, чем найти идеальный товар и обнаружить, что его нет в наличии.

Мы пошли ещё дальше и добавили индексирование по содержимому PDF-файлов, прикреплённых к товарам. Это звучит как экзотика, но для промышленных магазинов, где к каждому товару прилагается техническая документация, паспорта безопасности, сертификаты — это меняет правила игры. Менеджер по закупкам может ввести номер ГОСТ или название конкретного допуска, и поиск найдёт товары, в чьей документации этот ГОСТ упоминается. Раньше для этого приходилось открывать каждый PDF вручную.

Следующая задача — синхронизация. Индекс Typesense должен быть актуальным. Когда менеджер добавляет новый товар, меняет цену, обновляет описание — эти изменения должны отразиться в поиске. Мы реализовали это через Action Scheduler — встроенный планировщик задач WooCommerce. При каждом сохранении товара срабатывает хук, который ставит задачу обновления индекса в очередь. SearchIndexerJob подхватывает эту задачу и обновляет соответствующий документ в Typesense. Это происходит асинхронно, в фоне — менеджер не ждёт, пока индекс обновится, он просто сохраняет товар и идёт дальше.

Честно говоря, именно с синхронизацией мы намучились больше всего. Первая версия обновляла индекс синхронно, прямо в хуке save_post — и при массовом импорте товаров из 1С это убивало сервер. Представьте: приходит пакет из трёхсот товаров, и на каждый — HTTP-запрос к Typesense. Триста запросов за минуту — это ещё терпимо, но если импорт идёт чанками и товаров пятнадцать тысяч, сервер начинает задыхаться. Перешли на очередь через Action Scheduler — и проблема ушла. Теперь при массовом импорте задачи на обновление индекса ставятся в очередь и обрабатываются пачками, не нагружая ни WordPress, ни Typesense.

Ещё одна неочевидная проблема — первоначальная индексация. Когда магазин только подключает модуль поиска, нужно проиндексировать весь каталог. Для магазина на тысячу товаров это занимает минуту-две. Для нашего боевого магазина с 16 844 товарами первоначальная индексация заняла около двадцати минут. Мы оптимизировали процесс, разбив его на батчи по 250 товаров, с паузами между батчами, чтобы не перегружать сервер. В админке отображается прогресс-бар — владелец видит, сколько процентов проиндексировано, и может спокойно заниматься другими делами.

Была и история с кодировками. Typesense прекрасно работает с UTF-8, но некоторые магазины на WordPress имеют товары с хитрыми символами — неразрывными пробелами, специальными тире, символами торговых марок. Один магазин масел хранил знак «™» в названиях товаров, и это ломало JSON-сериализацию при отправке в Typesense. Пришлось добавить нормализацию текста перед индексацией — очистку от невидимых управляющих символов, замену «умных» кавычек на обычные, и прочие радости работы с реальными данными.

Отдельная глава — фасетная фильтрация. Когда покупатель ищет «моторное масло», он получает, допустим, четыреста результатов. Без фильтрации это бесполезно — никто не будет листать четыреста карточек. Нужны фасеты: отфильтровать по бренду (Shell, Castrol, Лукойл), по вязкости (5W-30, 10W-40), по типу (синтетическое, полусинтетическое), по цене (от 500 до 2000 рублей). Typesense поддерживает фасетную фильтрацию нативно — мы просто указываем, какие поля являются фасетными, и движок автоматически считает количество товаров в каждой категории. Пользователь видит не просто список фильтров, а фильтры с количеством — «Shell (47)», «Castrol (32)» — и может быстро сузить выдачу до нужных товаров.

Синонимы, курирование и аналитика — три кита умного поиска

Есть три вещи, которые отличают по-настоящему умный поиск от просто быстрого. Первая — синонимы. В каждой нише есть свой жаргон, свои сокращения, свои альтернативные названия. В магазине масел «трансмиссионка» = «трансмиссионное масло» = «масло для КПП» = «gear oil». В магазине электроники «мобильник» = «смартфон» = «телефон» = «сотовый». В магазине стройматериалов «гипсокартон» = «ГКЛ» = «сухая штукатурка». Если поисковый движок не знает этих синонимов, он теряет покупателей.

Мы сделали управление синонимами максимально простым. В админке WordPress, в разделе поиска, есть вкладка «Синонимы». Добавляете группу синонимов — например, «трансмиссионное масло», «трансмиссионка», «масло КПП», «gear oil» — и Typesense начинает считать все эти термины эквивалентными. Покупатель вводит любой из вариантов и получает одинаковый набор результатов. Настройка занимает пять минут, а эффект — десятки спасённых поисковых сессий в день.

Есть ещё один тип синонимов — однонаправленные. Это когда «Мобил» должен находить товары бренда «Mobil», но не наоборот. Или когда «жидкость ГУР» должна находить «масло для гидроусилителя руля», но запрос «масло для гидроусилителя руля» не обязательно должен включать всё, что помечено как «жидкость ГУР». Такие тонкости особенно важны в технических нишах, где терминология может быть неоднозначной.

Вторая важная вещь — курирование результатов. Бывают запросы, которые стратегически важны для бизнеса. Например, вы знаете, что по запросу «моторное масло 5W-30» к вам приходит больше всего покупателей из поиска. И вы хотите, чтобы первыми в выдаче стояли не какие попало масла 5W-30, а конкретные позиции — может, с самой высокой маржой, может, от партнёрского бренда, может, те, что сейчас на акции. Курирование позволяет зафиксировать позиции конкретных товаров в выдаче по конкретным запросам. Вы говорите: «По запросу "масло 5W-30" первым всегда показывай Shell Helix Ultra, вторым — Castrol Edge, а товар X вообще скрой из выдачи». И это работает.

Я знаю, что у некоторых людей сама идея «ручной подкрутки» результатов поиска вызывает отторжение. Мол, поиск должен быть объективным, алгоритм должен решать. И в теории это верно. Но на практике бизнес — это не академическое упражнение. У вас есть товары, которые нужно продвигать. Есть товары, которые нужно распродать. Есть партнёрские обязательства. И умный мерчандайзинг в поиске — это такой же законный инструмент, как мерчандайзинг в физическом магазине, где конфеты всегда стоят на кассе, а молоко — в самом дальнем углу.

Третья и, возможно, самая недооценённая функция — аналитика поиска. Мы записываем каждый поисковый запрос: что искали, нашли ли что-то, кликнули ли на результат. Из этих данных складывается картина, которую невозможно получить никаким другим способом. Вы видите, что за последний месяц двести человек искали «антифриз красный G12», и ни один не нашёл результатов — потому что в вашем каталоге этот товар называется «охлаждающая жидкость G12+ красная». Добавляете синоним — и двести потерянных поисковых сессий в месяц превращаются в двести найденных товаров и потенциальных продаж.

Или другой пример. Вы видите, что сотня людей в месяц ищет конкретный артикул — допустим, «550046983». Это артикул масла Shell, которого у вас нет в каталоге. Но у вас есть аналог от другого производителя. Без аналитики поиска вы бы никогда не узнали, что эти сто человек приходят, не находят товар и уходят. А теперь вы видите этот запрос в топе «поисков без результатов» и можете принять решение: либо добавить этот товар в каталог, либо настроить синоним, который перенаправит этот запрос на аналог, либо хотя бы показать баннер «Не нашли этот артикул? Попробуйте наш аналог...».

Аналитика поиска — это, по сути, прямая линия связи с потребностями ваших покупателей. Они сами говорят вам, чего хотят, через поисковую строку. Остаётся только слушать.

Мы показываем аналитику в удобном виде: топ запросов, запросы без результатов, запросы с низким CTR (когда люди находят результаты, но не кликают — значит, результаты нерелевантные), тренды по дням и неделям. Менеджер магазина может зайти в раздел аналитики раз в неделю, потратить пятнадцать минут, и получить больше полезной информации о спросе, чем из любого маркетингового исследования.

Виджет поиска — как это выглядит для покупателя

Всё, о чём я говорил до этого — это бэкенд. Индексация, синонимы, аналитика — покупатель ничего этого не видит. Он видит поисковую строку, и его опыт взаимодействия с ней определяет, купит он что-то или уйдёт. Поэтому фронтенд поиска мы делали с особой тщательностью.

Виджет поиска работает так. Покупатель начинает вводить текст — и уже после второго-третьего символа под строкой поиска появляется выпадающее окно с результатами. Не просто текстовые ссылки, а полноценные карточки товаров: миниатюра изображения, название, цена, наличие на складе. Покупатель видит результаты ещё до того, как дописал запрос и нажал Enter. Это называется search-as-you-type, и это стандарт, к которому люди привыкли благодаря Google, Amazon и другим крупным платформам. Когда ваш магазин тоже так умеет — это не просто удобство, это сигнал: «Мы серьёзный магазин, здесь всё работает как надо».

Запрос к Typesense уходит при каждом нажатии клавиши, но с дебаунсом в 200 миллисекунд — чтобы не засыпать сервер запросами, пока покупатель быстро печатает. Ответ приходит за 5-50 миллисекунд, и результаты обновляются мгновенно. Ощущение — как будто результаты уже готовы и просто ждут, когда их покажут.

Виджет вставляется на любую страницу через шорткод. Можно поставить в шапку сайта вместо стандартного поиска WordPress — для этого в большинстве тем достаточно добавить шорткод в нужный виджет-блок. Можно разместить на отдельной странице результатов поиска. Можно использовать как элемент лендинга: «Найдите нужное масло за 3 секунды» — и тут же поисковая строка, которая моментально показывает результаты. Это работает как мощный элемент доверия, потому что демонстрирует покупателю, что каталог реально большой и навигация по нему удобная.

Если покупатель нажимает Enter или кликает «Показать все результаты», он попадает на страницу результатов поиска. И здесь в игру вступает фасетная фильтрация, о которой я говорил раньше. Слева — панель фильтров с категориями, брендами, ценовым диапазоном и атрибутами. Справа — карточки товаров с пагинацией. Фильтры работают мгновенно — без перезагрузки страницы, через AJAX. Кликнул на «Shell» — список обновился за доли секунды, показывая только товары Shell. Убрал фильтр — снова весь список. Это тот уровень UX, к которому покупатели привыкли на маркетплейсах, и который резко выделяет ваш магазин на фоне конкурентов, где поиск выдаёт все результаты одной бесконечной простынёй без возможности фильтрации.

Отдельно расскажу про подсветку совпадений. Когда покупатель ищет «гидравлическое масло HLP 46», в результатах найденные слова подсвечиваются — жирным шрифтом или цветом. Покупатель мгновенно видит, почему именно этот товар оказался в выдаче, и может быстро оценить его релевантность. Мелочь, но она значительно улучшает опыт и сокращает время от запроса до клика.

И ещё один момент, который часто упускают из виду — адаптивность. Виджет поиска корректно работает на мобильных устройствах. А мобильный трафик сейчас — это 60-70 процентов для большинства интернет-магазинов. На телефоне выпадающее окно с результатами занимает всю ширину экрана, карточки товаров адаптируются под узкий экран, фильтры на странице результатов сворачиваются в выезжающую панель. Ничего не ломается, ничего не налезает друг на друга. Казалось бы, очевидное требование — но вы удивитесь, сколько поисковых плагинов до сих пор криво работают на мобильных.

16 844 товара — как это работает в бою

Теория — это хорошо, но давайте поговорим о реальном опыте. У нас есть магазин смазочных материалов — 16 844 товара, WooCommerce, кастомная тема на базе Porto, и наш плагин COS WP Woo с модулем поиска на Typesense. Этот магазин — наш боевой полигон, где мы обкатываем все функции на реальных данных и реальных покупателях.

До внедрения Typesense поиск на этом магазине работал через стандартный WooCommerce с несколькими улучшениями — поиск по SKU и по атрибутам через дополнительный плагин. Среднее время ответа на поисковый запрос составляло от 800 до 2000 миллисекунд, в зависимости от нагрузки на сервер. На мобильных устройствах, где каждая секунда на счету, это было катастрофически медленно. Аналитику поисковых запросов мы не собирали вообще — не было инструмента.

После запуска модуля поиска на Typesense мы провели полную индексацию каталога. Шестнадцать с лишним тысяч товаров — индексация заняла около двадцати минут в фоновом режиме, через Action Scheduler. Размер индекса в Typesense — порядка ста пятидесяти мегабайт. Потребление оперативной памяти самим Typesense — около двухсот мегабайт. Для сервера с восемью гигабайтами RAM это незаметно.

Среднее время ответа на поисковый запрос после перехода на Typesense — 8-15 миллисекунд. Это с учётом сетевой задержки между WordPress и Typesense, который стоит на том же сервере. Для покупателя это выглядит как мгновенный отклик — он начинает печатать, и результаты появляются ещё до того, как он успевает убрать палец с клавиши.

Мы начали собирать аналитику поиска с первого дня, и она быстро показала интересные вещи. Оказалось, что значительная часть покупателей ищет товары по артикулу — не по названию, а именно по буквенно-цифровому коду. Это типично для B2B-сегмента: менеджер по закупкам имеет спецификацию с артикулами и просто вбивает их один за другим. Для такого сценария мгновенный поиск с автодополнением — это колоссальная экономия времени. Вместо того чтобы каждый раз ждать по три-пять секунд, пока загрузится страница результатов, менеджер получает ответ мгновенно и может обработать заказ в разы быстрее.

Другое открытие из аналитики — количество запросов с нулевым результатом. В первую неделю их было около 15 процентов от общего числа. То есть каждый шестой-седьмой покупатель не находил то, что искал. Мы проанализировали эти запросы и обнаружили несколько закономерностей. Часть запросов — опечатки и альтернативные написания, которые решились настройкой синонимов. Часть — запросы на товары, которых действительно не было в каталоге, но которые имело смысл добавить. Часть — запросы на товары, которые были в каталоге, но под другим названием. Через месяц работы с аналитикой и синонимами мы снизили долю запросов с нулевым результатом до 4-5 процентов. Это значит, что около десяти процентов покупателей, которые раньше уходили с пустыми руками, теперь находят то, что ищут.

Вот конкретный пример. Покупатели часто искали «ВМГЗ» — это марка гидравлического масла, хорошо знакомая в промышленности. Но в каталоге товар назывался «Масло гидравлическое ВМГЗ-45», и стандартный поиск находил его только по полному вхождению. Если покупатель вводил просто «ВМГЗ» без «-45» — результат был, но если вводил «масло ВМГЗ» — поиск уже терялся, потому что слова шли в другом порядке. После перехода на Typesense эта проблема исчезла — Typesense ищет по всем полям, учитывает порядок слов, находит частичные совпадения. Плюс мы добавили синонимы: «ВМГЗ» = «гидравлическое масло ВМГЗ» = «масло ВМГЗ-45» — и теперь любой из этих запросов ведёт к правильным товарам.

Если говорить о влиянии на бизнес-метрики — и тут нужно быть честным, чистый A/B-тест мы не проводили, поэтому я не могу сказать с научной точностью, что конверсия выросла на X процентов именно из-за поиска. Но мы видим корреляцию: после внедрения нового поиска процент поисковых сессий, которые завершаются добавлением товара в корзину, вырос. Покупатели стали чаще пользоваться поиском вместо навигации по каталогу — что логично, потому что поиск теперь работает быстрее и надёжнее, чем перебор категорий. И количество обращений в поддержку с формулировкой «не могу найти товар» практически сошло на нет.

Я не буду называть конкретные цифры роста конверсии, потому что считаю это нечестным — на конверсию влияет слишком много факторов, и выделить вклад одного из них без контролируемого эксперимента невозможно. Но я могу сказать с уверенностью: быстрый умный поиск убирает одно из самых раздражающих препятствий между покупателем и покупкой. А устранение препятствий — это и есть суть оптимизации конверсии.

Есть ещё один аспект, который редко обсуждают — нагрузка на сервер. Стандартный WooCommerce-поиск — это тяжёлый SQL-запрос, который нагружает базу данных MySQL. Каждый поисковый запрос — это JOIN нескольких таблиц, полнотабличный скан, потребление CPU и дискового I/O. Когда на сайте одновременно ищут десять человек — десять тяжёлых запросов одновременно. На хостинге с ограниченными ресурсами это может замедлить не только поиск, но и весь сайт — страницы каталога, корзина, чекаут. С Typesense поисковая нагрузка полностью снимается с MySQL. База данных занимается тем, чем должна — обработкой заказов, обновлением остатков, работой с корзиной. А поиск обрабатывается отдельным, оптимизированным для этого движком. Это особенно критично во время пиковых нагрузок — распродаж, акций, когда трафик возрастает в разы.

Мы на нашем магазине заметили, что после переноса поиска на Typesense средняя загрузка MySQL снизилась процентов на пятнадцать-двадцать. Это не звучит как много, но на практике это разница между «сайт работает стабильно» и «сайт периодически подтормаживает в часы пик». А для магазина, который получает заказы на десятки и сотни тысяч рублей, каждая секунда задержки на чекауте — это потенциально потерянный заказ.

И нельзя не сказать о поиске по документам. Это функция, которую мало кто реализует, но которая бесценна для промышленных и B2B-магазинов. Наш модуль может индексировать содержимое PDF-файлов, прикреплённых к товарам. Технические паспорта, сертификаты соответствия, паспорта безопасности, инструкции по применению — всё это текст, и всё это становится доступным через поиск. Инженер вводит номер ТУ или ГОСТ, и поиск находит товары, в чьей технической документации этот стандарт упомянут. Для компании, которая закупает промышленные смазочные материалы, и где выбор масла определяется не ценой, а соответствием конкретному стандарту — это принципиально меняет опыт работы с каталогом. Они больше не звонят менеджеру и не просят «найти масло, которое соответствует ГОСТ 17479.4-87» — они находят его сами, за три секунды, через поиск.

Отдельная гордость — скорость переиндексации. Когда мы подключили синхронизацию с 1С через наш же модуль интеграции, и каждую ночь в магазин приходит обновление цен и остатков по всем шестнадцати тысячам товаров, нам было важно, чтобы поисковый индекс обновлялся так же быстро. Typesense обрабатывает обновление одного документа за 1-2 миллисекунды. Шестнадцать тысяч обновлений — это около тридцати секунд суммарно. Для сравнения, переиндексация Elasticsearch для такого объёма заняла бы минуты, если не десятки минут, в зависимости от конфигурации.

Расскажу ещё про одну ситуацию, которая хорошо иллюстрирует разницу между «поиск работает» и «поиск работает правильно». У нас в каталоге есть масла разных фасовок — одно и то же масло может продаваться в канистре 1 литр, 4 литра, 20 литров и в бочке 208 литров. Это четыре разных товара с разными ценами, разными артикулами, но по сути — один и тот же продукт. Когда покупатель ищет «Shell Helix HX8 5W-30», он ожидает увидеть все фасовки рядом, чтобы выбрать нужную. Стандартный поиск WordPress выдавал их вперемешку с другими маслами Shell, потому что релевантность определялась порядком слов в заголовке и датой публикации. Typesense же ранжирует по степени совпадения — точное совпадение названия всегда выше частичного, и все четыре фасовки оказываются на первых позициях, сгруппированные естественным образом. Покупатель сразу видит все варианты и может выбрать, не пролистывая три страницы результатов.

Ещё один момент, который я считаю принципиально важным — безопасность и изоляция данных. Typesense индексирует только те данные, которые вы явно решили проиндексировать. Он не имеет доступа к базе данных WordPress, не знает паролей пользователей, не видит заказов, не хранит персональные данные покупателей. В индексе — только товарная информация: название, описание, цена, атрибуты, изображения. Для магазинов, которые работают с корпоративными клиентами и должны соблюдать требования к обработке персональных данных, это существенный плюс. Поисковый движок физически не может «утечь» ничего кроме публичной каталожной информации, потому что ничего другого в нём нет.

И ещё я хочу поговорить о стоимости владения, потому что это вопрос, который задают чаще всего. Algolia — самый известный конкурент Typesense в мире облачного поиска — стоит от 1 доллара за тысячу поисковых операций. Звучит дёшево, пока не посчитаешь. Если у вас тысяча посетителей в день, и каждый делает в среднем три поисковых запроса (один основной и два уточняющих с автодополнением), это 90 тысяч операций в месяц. Плюс индексирование — каждое обновление товара тоже считается операцией. Для магазина с шестнадцатью тысячами товаров и активной торговлей счёт от Algolia легко может составить 50-100 долларов в месяц. И это при том, что Algolia — отличный сервис, я ничего плохого о нём не скажу.

Typesense Cloud стоит значительно дешевле — от 29,99 долларов в месяц за выделенный инстанс, который обрабатывает неограниченное количество запросов. Без оплаты за операцию, без счётчиков, без сюрпризов в конце месяца. А если вы готовы поставить Typesense на свой сервер — это вообще бесплатно, потому что Typesense полностью open-source. Мы для нашего боевого магазина выбрали именно self-hosted вариант — Typesense стоит на том же сервере, что и WordPress, потребляет двести мегабайт памяти и не стоит ни копейки. Единственная «стоимость» — время на первоначальную установку, которая занимает минут тридцать-сорок для человека, знакомого с Linux, или несколько кликов, если использовать Docker.

Когда я сравниваю стоимость Typesense с тем, сколько магазин теряет из-за плохого поиска — разница настолько очевидна, что сам вопрос кажется риторическим. Один потерянный заказ в день — допустим, средний чек три тысячи рублей — это девяносто тысяч рублей в месяц. Один. А сколько заказов теряется, когда 15 процентов поисковых запросов заканчиваются нулевым результатом? Когда поиск не понимает опечатки? Когда покупатель ждёт три секунды и уходит к конкуренту, у которого результаты появляются мгновенно? Я не хочу спекулировать на конкретных цифрах, но масштаб потерь явно превышает стоимость решения — на порядки.

Вот что я понял за время работы с поиском: правильный поиск — это не feature, это infrastructure. Это такая же критическая часть интернет-магазина, как корзина или чекаут. Можно иметь идеальный каталог, красивый дизайн, быструю доставку — но если покупатель не может найти нужный товар, всё остальное не имеет значения. И при этом поиск — одна из самых недоинвестированных частей большинства WooCommerce-магазинов. Люди тратят тысячи долларов на рекламу, привлекают трафик, а потом теряют покупателей на самом простом — «я не нашёл то, что искал».

А что если посмотреть на это с другой стороны? Каждый рубль, вложенный в улучшение поиска, работает не на привлечение нового трафика, а на конвертацию существующего. Вы не платите за клик, не платите за показ — вы просто перестаёте терять тех, кто уже пришёл. И в этом смысле ROI от хорошего поиска может быть значительно выше, чем ROI от очередной рекламной кампании.

Я много думал о том, почему сообщество WordPress так долго мирилось с плохим поиском. И мне кажется, дело в том, что большинство владельцев магазинов просто не знают, как может быть по-другому. Они привыкли к тому, что поиск — это медленная штука, которая не всегда находит то, что нужно. Они не видели, как работает поиск на Amazon или Ozon, не задумывались о том, что та же технология доступна и для магазина на WooCommerce. И когда показываешь им разницу — буквально открываешь два окна браузера, в одном стандартный поиск, в другом Typesense, и вводишь один и тот же запрос — у людей буквально отвисает челюсть. «А что, так можно было?» — самая частая реакция.

Да, так можно. И нужно. И мы сделали это максимально доступным — встроили прямо в плагин, с пошаговой настройкой, с понятной админкой, с автоматической синхронизацией. Никаких танцев с бубном, никакого программирования, никаких отдельных серверов — хотя такая возможность тоже есть, для тех, кому нужна масштабируемость. Подключил Typesense Cloud или поставил на свой сервер, указал API-ключ в настройках, нажал «Индексировать» — и через двадцать минут у тебя поиск, который работает в пятьдесят раз быстрее, понимает опечатки, русскую морфологию и артикулы. Это не маркетинговое преувеличение, это буквально то, что происходит.

И последнее, что хочу сказать. Мы не остановились на том, что есть сейчас. Поиск — это живая система, которая должна развиваться вместе с магазином и с ожиданиями покупателей. В ближайших планах — персонализация результатов поиска на основе истории покупок и просмотров, интеграция с рекомендательным движком, голосовой поиск для мобильных устройств. Мир e-commerce движется в сторону всё более интеллектуального взаимодействия с покупателем, и поиск — это передний край этого движения.

А пока — если у вас WooCommerce-магазин с более чем тысячей товаров и стандартный поиск WordPress — попробуйте набрать какой-нибудь запрос с опечаткой и посмотрите на результат. Если результат вас расстроит — значит, пришло время что-то менять. И я знаю, с чего начать.

Попробуйте COS WP Woo — 14 дней бесплатно. Установите плагин, подключите модуль умного поиска на Typesense и посмотрите, как изменится опыт ваших покупателей. Без ограничений функциональности, без привязки карты. Просто быстрый, умный поиск, который находит то, что ищут ваши клиенты — за миллисекунды, а не за секунды.