Пошук по сайту не працює? Як навчити його розуміти людей і не платити за ШІ

Відвідувач вводить слово в рядок пошуку, бачить «нічого не знайдено» і вирішує, що у вас цього немає, хоча воно є. Більшість таких збоїв виправляється без ШІ й без платних сервісів. Розбираємо, що люди вводять насправді, що і в якому порядку будувати, як ми зробили власний пошук на звичайному MySQL трьома мовами, які помилки знайшли в ньому наші перевірки і коли правильний вибір це Algolia, Elasticsearch, Meilisearch або векторний пошук.

КОРОТКО

Що вміє хороший пошук по сайту

Хороший пошук пробачає інші форми слова, синоніми, друкарські помилки й не ту мову, ставить першою сторінку, яка відповідає на запитання, ніколи не закінчується порожнім екраном і записує, чого не зміг знайти. На сайті до десятків тисяч сторінок (наша оцінка) більшу частину цього роблять ваша база даних і кілька сотень рядків коду. Платний рушій або векторний пошук окупаються на великих каталогах із фільтрами або там, де люди описують потребу словами, яких немає на ваших сторінках.

Проблема трапляється навіть там, де бюджети великі. У бенчмарку Baymard Institute за 2026 рік, понад 170 інтернет-магазинів і застосунків, пошук оцінено як «посередній або гірше» на 46% сайтів для комп’ютера, 58% мобільних сайтів і 64% застосунків (Baymard, оновлено у квітні 2026). Це магазини, за якими стоять команди, а в сервісного сайту часто є лише рядок, що прийшов разом із CMS.

У жовтні 2026 року ми переробили пошук на власному сайті за одним правилом: без ШІ й без платних сервісів. У цій статті те, чого ми навчилися, зокрема помилки, які знайшли лише під час перевірки для цього тексту.

ЩО ВВОДЯТЬ ЛЮДИ

Що відвідувачі вводять у рядок

Люди шукають своїми словами, а набирати текст довго й легко помилитися (Nielsen Norman Group, 2014). Сторінки написані вашими словами. Майже кожен збій пошуку це розрив між двома словниками, і різновидів у нього небагато.

П’ятий рядок власники недооцінюють найчастіше. За даними Baymard за 2026 рік, запити не про товари, наприклад про умови повернення, спричиняли проблеми на 66% досліджених сайтів, більше за всі інші типи запитів у тій статті, проти 20% у простих запитів за типом товару. Людина, яка шукає на вашому сайті телефон, уже вирішила з вами поговорити, а пошук відповідає їй статтею з блогу.

Кожен порожній пошук це відвідувач, який своїми словами сказав, чого хотів.

ЧОМУ СТАНДАРТНИЙ ПОМИЛЯЄТЬСЯ

Чому стандартний пошук не знаходить

Стандартний пошук розрахований на блог. Найнаочніший приклад WordPress, бо його код відкритий: кожне слово шукається через LIKE '%слово%' у трьох колонках (заголовок, уривок, вміст), і мають знайтися всі слова (довідник розробника WordPress, листопад 2026). Звідси й симптоми, на які скаржаться власники:

• Лише точні літери: друкарська помилка чи синонім не знаходять нічого.
• Шматки слів: %сад% знаходить і «посада», і «засади», тому короткий запит видає довгий і дивний список.
• Одна мова: запит іншою мовою шукає літери, яких немає в поточній версії сторінки.
• Лише ці колонки: характеристики товарів, додаткові поля й текст сторінок із шаблонів, часто це ваші ціни та послуги, лишаються поза досяжністю.
• Глухий кут: приблизно 50% інтернет-магазинів влаштовані так, що сторінка «нічого не знайдено» дратує людей і може відвести їх до зовнішнього пошуковика (Baymard, оновлено в лютому 2025).

Інші платформи починають із кращої позиції. Shopify повідомляє, що пошук у його магазинах за замовчуванням враховує друкарські помилки й використовує пов’язані слова та поняття (Shopify Help Center, листопад 2026), тому магазину на Shopify варто спершу подивитися на дані про товари, а купувати щось потім. Якщо платформа вже переросла свої плагіни, пошук зазвичай один симптом із кількох, про це ми писали в статті Коли бізнес переростає WordPress?

Старий короткий шлях, рядок на рушії Google, теж звузився. Custom Search JSON API закритий для нових клієнтів, у чинних є час до 1 січня 2027 року, а як альтернативу Google називає Vertex AI Search (Google for Developers, листопад 2026).

ПОРЯДОК РОБІТ

Що будувати і в якому порядку

Першою йде найдешевша й найкорисніша робота. На закритій платформі цей самий список стає переліком налаштувань і застосунків.

1. Записуйте кожен пошук: запит, мову, кількість результатів, чим пошук допоміг. Це година-дві роботи (наша оцінка), і лог підкаже, що має бути в решті пунктів.
2. Охопіть усе, що люди читають: статті, послуги, проєкти, відповіді FAQ, авторів, вакансії та сторінки із шаблонів.
3. Шукайте за початком слова й вимагайте всі значущі слова: одне це прибирає багато сміття.
4. Спершу заголовок: сторінка з усім запитом у заголовку має обходити сторінку, де ці слова трапляються в сороковому абзаці. Вирішіть, який тип сторінки виграє за рівності.
5. Додайте групи синонімів із логу: почніть із 10 чи 20 груп, які в ньому вже видно, усіма вашими мовами.
6. Додайте картки найкращої відповіді: ціни, контакти, вакансії, кожна галузь, з якою ви працюєте.
7. Замініть порожню сторінку: інша розкладка, найближче слово, інша мова й рядок про те, що було зроблено.
8. Додайте результати під час введення, в останню чергу, бо це множить усі проблеми вище.

Якщо код поки змінювати не можна, перший крок можна почати сьогодні в Google Analytics 4. Розширена статистика надсилає подію view_search_results із пошуковим запитом, коли в адресі сторінки є параметр q, s, search, query або keyword (Довідка Google Analytics, листопад 2026). Кількості результатів у цій події немає, тож запити без результатів потребують окремого налаштування. Люди ще й вставляють у рядок пошуку адреси пошти, а Google забороняє передавати в Analytics персональні дані, зокрема в параметрах адреси (Довідка Google Analytics, листопад 2026), тому увімкніть редагування даних.

Заведіть файл із 30 чи 50 реальних запитів зі сторінкою, яку ви очікуєте для кожного, кожною мовою, і запускайте його після кожної зміни. Це частина регресійної роботи, описаної у статті Скільки тестування потрібно сайту або застосунку перед запуском?

НАШ ВИПАДОК

Як влаштований наш власний пошук

Наш сайт працює на Laravel і MySQL, а весь пошук це один контролер приблизно на 600 рядків PHP і невеликий скрипт для списку підказок, англійською, російською та українською. Жодні зовнішні сервіси не викликаються.

Збіги. Статті, проєкти й послуги мають індекси InnoDB FULLTEXT, запити до них ідуть у логічному режимі. Кожне слово запиту перетворюється на обов’язкову групу з нього самого та його синонімів, кожен із зірочкою в кінці, тож запит «сайт ціна» виглядає приблизно як +(сайт* вебсайт* website* web*) +(ціна* вартіст* cost* ...). Плюс означає, що група обов’язкова, зірочка означає, що слово може так починатися (посібник MySQL 8.4). Усе, крім літер і цифр, спершу прибирається, бо випадковий символ може спрацювати як оператор. Слова коротші за три літери відкидаються, якщо лишається щось іще, бо мінімальний розмір токена в MySQL за замовчуванням дорівнює 3 (посібник MySQL 8.4).

Охоплення. Галузі, вакансії та автори шукаються через LIKE. Сторінки «Про нас», «Партнери», «Інвестори» та «Ціни» тримають текст у шаблонах, тому база про них нічого не знає. Пошук раз на день кожною мовою читає ці живі сторінки й кешує заголовок, мета-опис та основний текст, тож він шукає саме те, що читає відвідувач.

Синоніми. 27 груп, написаних вручну трьома мовами, наприклад група зі слів сайт, website, web і веб. Більшість записів це основи слів, так один рядок покриває більшість відмінків. Короткі терміни до трьох літер збігаються лише як цілі слова: 2 листопада 2026 року в англійській версії сайту запит car вивів картку автомобільної галузі, а careers вивів вакансії.

Ранжування. Бали настільки прості, що їх можна прочитати вголос:

Ці числа і є діловими рішеннями, записаними кодом: за однакових слів послуга відповідає краще за статтю, а вакансія майже ніколи не має обходити ні те, ні те. У магазині була б інша таблиця, з наявністю та маржею, тому пошук не можна просто встановити. У клієнтських проєктах ця логіка будується разом із продуктом, а код, правила ранжування й списки синонімів передаються вам за договором разом з усією системою. На дилерській платформі FIAT Kharkiv, наприклад, клієнти знаходять оригінальні запчастини за VIN свого авто: пошук, побудований навколо того, що продає цей бізнес.

НІЧОГО НЕ ЗНАЙДЕНО

Коли результатів немає

Порожній результат запускає драбину кроків, і сторінка повідомляє, що було зроблено.

Інша розкладка. Людина друкує українською, а клавіатура лишилася на англійській, і виходить абракадабра: ctj замість «сео». Таблиця відповідностей переводить запит в іншу розкладку й пробує знову, навіть якщо зверху є друкарська помилка. Таблиць у нас дві, англійська на російську й англійська на українську, бо літери і, ї, є стоять на своїх клавішах.

Найближче слово. Кожне слово від чотирьох літер із наших заголовків потрапляє до словника, який кешується на годину. Слово запиту, якого там немає, порівнюється зі словником за відстанню Левенштейна, тобто кількістю замін однієї літери між двома словами: одна заміна для слів до п’яти літер, дві для довших, за рівності виграє частіше слово. Функція levenshtein() у PHP, судячи із заміток користувачів у посібнику, працює з байтами й може порахувати одну кириличну літеру за дві заміни, тому відстань ми рахуємо за літерами самі. 2 листопада 2026 року запит development із двома переставленими літерами в англійській версії повернув «Did you mean» і послуги з розробки.

Інші мови. Кожна сторінка нашого сайту є трьома мовами, тому якщо слова збіглися з англійською версією сторінки, відвідувач української версії отримує українську сторінку й пояснення. Що ще змінюється між мовними версіями, розібрано у статті Дизайн багатомовного сайту: що змінюється, крім перекладу.

Картки найкращої відповіді стоять над результатами, навіть якщо більше нічого не знайшлося. Слова «ціна», «вартість» чи «бюджет» ставлять нагору картку сторінки з цінами, будь-якою з трьох мов. Таких намірів вісім, серед них контакти й вакансії, і ще вісім галузей.

Дрібниці української теж важать. Апостроф приходить трьома різними символами залежно від клавіатури, тому ми зводимо їх до одного, і запит «інтер’єр» із типографським апострофом під час перевірки дійшов до картки «Архітектура».

ЛОГ ПОШУКУ

Лог порожніх запитів це безплатний звіт для бізнесу

Кожен повний пошук на нашому сайті додає рядок до файлу місяця: час, мова, запит, кількість результатів, чим пошук допоміг, яку картку показав. У цьому файлі немає IP-адреси та cookie. Усе, що схоже на адресу пошти чи номер телефону, маскується до запису, запит обрізається на 120 символах, а рахується лише перша сторінка результатів.

Коротка команда виводить за будь-який місяць три списки: топ запитів, запити без результатів і запити, яким пошук допоміг. Свої цифри ми не публікуємо, але читати їх можна однаково в будь-якому бізнесі.

У магазині той самий лог показує відсутні товари й характеристики, яких немає в каталозі, про це стаття Intelligent Product Discovery: пошук, фільтри та конфігуратори для складних каталогів. Читання логу входить і до нашого юзабіліті аудиту, від $1 500.

«Нічого не знайдено» це єдиний звіт, який клієнти пишуть безплатно.

Більшості сайтів має вистачати пів години на місяць (наша оцінка): виправте три рядки, а за місяць подивіться, чи зрушили ці запити.

ДЕ ЛАМАЄТЬСЯ

Що знайшли наші перевірки

Для цієї статті ми перевірили власний пошук 2 листопада 2026 року через його публічну адресу підказок, яка не пише в лог. Знайшлися помилки, з якими може зіткнутися кожен, хто будує пошук на повнотекстовому MySQL.

Пастка стоп-слів. В англійській версії нашого сайту запит "how much does a custom website cost" не повернув у перших рядках нашу ж статтю з цим заголовком (українською вона називається Скільки коштує кастомний сайт у 2026 році?). Без слова how стаття одразу вийшла першою, просто під карткою цін. Посібник MySQL, як ми його розуміємо, пояснює чому: how входить до стандартного списку стоп-слів InnoDB, тому його немає в індексі, але слово з оператором усічення лишається в логічному запиті, навіть якщо це стоп-слово. Виходить, +(how*) вимагає слово, що починається на how, самого how в індексі немає, і проходить щось на кшталт however. У тому самому списку what, when, where, who і прийменники на кшталт for та with (посібник MySQL 8.4). Це слова, з яких починаються запитання. Ми виправили це того ж дня: стоп-слова прибрано з обов’язкової частини запиту, вони лишилися тільки для порівняння із заголовками, тож стаття тепер іде одразу під карткою цін. Наші перевірочні запитання українською та російською пройшли нормально, бо стандартний список переважно англійський. Якщо ваш сайт має англійську версію для експорту, перевірте її окремо.

Драбина починалася лише з нуля. Запит ctj перестав давати нуль результатів, бо наша стаття про product discovery наводить саме цей приклад, а тепер і ця. Запит знаходив ці статті, і виправлення розкладки не запускалося. Так само могло повестися російське слово в англійській версії сайту: одна випадкова стаття, де воно є, і жодного переходу до інших мов. Умову ми змінили того ж дня: якщо запиту немає в жодному заголовку, виправлення розкладки та інші мови теж запускаються і беруть гору, лише коли в їхніх результатах запит стоїть у заголовку. Запит ctj знову веде до «сео».

Пошук за початком слова має ціну. Правило цілих слів для коротких термінів керує картками й синонімами. Результати все одно збігаються з будь-яким словом, що починається так само, тому під карткою автомобільної галузі з’являється термін глосарія Cart abandonment.

Чого він не вміє зовсім. Він не розуміє сенсу: слова, яких немає на жодній сторінці й для яких не написано синонім, не знаходять нічого. Основи слів підтримуються вручну. Ранжування йде в PHP після завантаження всіх збігів, що зручно для тисяч документів і неправильно для сотень тисяч (наша оцінка).

ВИБІР РУШІЯ

MySQL, Algolia, Elasticsearch, Meilisearch чи вектори

У документації Laravel про вбудований пошуковий рушій на базі даних сказано, що для більшості застосунків цього досить, а до окремих рушіїв вона відправляє по терпимість до друкарських помилок, фасети, векторний пошук і геопошук у великому масштабі (документація Laravel 13, листопад 2026). Ціни нижче перевірено в листопаді 2026 року, вони змінюватимуться.

Порахуйте для свого трафіку. Algolia бере плату за пошуковий запит, а її бібліотека InstantSearch за замовчуванням надсилає запит на кожне натискання клавіші; вона радить затримку приблизно 200 мс (документація Algolia, листопад 2026). Припустімо, один пошук коштує п’ять запитів з урахуванням затримки, це наше припущення. За 20 000 пошуків на місяць виходить 100 000 запитів, близько $45 на Grow або $158 на Grow Plus. За 200 000 пошуків це мільйон запитів, близько $495 або $1 733. Сама Algolia називає свої оцінки орієнтовними. Для багатьох середніх компаній важливіше інше питання: копія каталогу на чужому сервісі і те, що буде, коли зміниться договір.

Перевірте мови до підписання. Для української це суттєво. В Elasticsearch є вбудований аналізатор для російської, а для української потрібен плагін, який виділяє основу через проєкт Morfologik (документація Elastic, листопад 2026). Meilisearch для кирилиці описує лише стандартне сегментування, декомпозицію й нижній регістр (документація Meilisearch, листопад 2026), тож основи слів там доведеться перевіряти на власних запитах.

Векторний пошук дешево індексувати й легко переоцінити. По $0,02 за мільйон токенів ембедінги тисячі сторінок приблизно по 1 500 токенів обійдуться приблизно у три центи (наш розрахунок). Справжні витрати це ще один сервіс і виклик моделі на кожен запит. До того ж він промахується там, де люди вводять найточніше: артикули, жаргон, дати й імена краще працюють із пошуком за словами, а гібридний пошук Microsoft запускає обидва паралельно (Microsoft Learn, оновлено у вересні 2026). У Laravel семантичний пошук на рушії бази даних потребує PostgreSQL із pgvector, а в розділі про типи даних MySQL 8.4 векторного типу немає. Наше правило: спершу подивіться лог порожніх запитів. Якщо в ньому описи, а не назви, пошук за сенсом може окупитися. Якщо в ньому друкарські помилки й інші слова для того самого, не окупиться. Коли відвідувачу потрібна розмова, а не список, це робота для ШІ-асистента на сайті.

Окремої ціни на пошук у нашому прайсі немає. Ми вбудовуємо його у вебзастосунок, від $25 000, або в інтернет-магазин, від $25 000, де в нього спільна модель даних із фільтрами та фасетною навігацією, а на готовому сайті починаємо з читання логу. Усі наші ціни на сторінці цін.

Спершу прочитайте лог: найчастіше він сам обирає рушій.

FAQ

Джерела

• Baymard Institute: E-commerce search query types, бенчмарк 2026 року
• Baymard Institute: сторінки "No Results"
• Посібник MySQL 8.4: логічний повнотекстовий пошук
• Документація Meilisearch: налаштування терпимості до помилок
• Algolia: ціни