Чому сайт не приносить клієнтів: що показали 220 ручних перевірок
Коли сайт дає мало звернень, найпростіше пояснення звучить так: «потрібно більше трафіку», «потрібен редизайн» або «треба покращити SEO».
На практиці проблема часто знаходиться в іншому місці.
Ми систематизували 220 ручних розборів комерційних сайтів і подивилися не на кількість формальних зауважень, а на те, які труднощі реально повторювалися у сценаріях користувачів.
У робочій вибірці:
- у 45 розборах була прямо зафіксована проблема мобільного сценарію;
- у 26 — роботи або портфоліо були, але від них було складно перейти до предметного запиту чи прорахунку;
- у 25 — губився наступний крок: запис, прорахунок, звернення або інша основна дія;
- у 24 — сайт уже помітно відставав від реального рівня бізнесу;
- у 17 — була явна технічна поломка: не працював сайт, кнопка, форма, калькулятор або важлива сторінка.
Категорії перетинаються: один сайт міг мати кілька різних проблем. Це також не репрезентативна статистика всього ринку, а робоча вибірка Vectora Systems. Детальніше методологію ми описали у Vectora Research.
Але саме ця вибірка змінила наш підхід до аналізу.
Головний висновок: сигнал ще не означає проблему
Знайти на сайті щось незвичне легко.
Немає форми на сторінці. Мало кнопок. Довгий текст. Сайт виглядає старим. PageSpeed показує рекомендації.
Кожен із цих пунктів може бути приводом перевірити сайт уважніше. Але сам по собі він ще не доводить, що користувачеві щось заважає.
Наприклад, на сторінці послуги немає окремої форми. За чек-листом це легко записати як недолік.
Але під першим екраном є помітна кнопка «Записатися». Вона відкриває просту форму. Форма нормально заповнюється, показує підтвердження, а звернення фактично надходить бізнесу.
У такій ситуації відсутність ще однієї форми на самій сторінці — сигнал для перевірки, але не підтверджена проблема.
Тому ми все частіше використовуємо послідовність:
сигнал → перевірка сценарію → контекст → висновок → масштаб рішення.
1. Сайт адаптивний, але мобільний сценарій незручний
Більшість сучасних сайтів уже вміє перебудовуватися під смартфон. Колонки стають одна під одною, меню ховається, зображення зменшуються.
Але технічна адаптивність не гарантує, що людині зручно виконати основну задачу.
На телефоні часто проявлялися інші проблеми:
- CTA губиться серед довгого контенту;
- каталог перетворюється на десятки карток поспіль;
- до запису або прорахунку потрібно довго прокручувати;
- важлива інформація конкурує з банерами;
- після того, як людина вже зацікавилася, наступну дію доводиться шукати заново.
Тому mobile ми перевіряємо не питанням «чи влазить сторінка в екран», а сценарієм:
зайшов → зрозумів → знайшов потрібне → вирішив звернутися → зміг це зробити.
2. Портфоліо є, але воно не продовжує шлях до замовлення
Це особливо часто проявлялося на сайтах меблів, вікон, ремонту, будівництва та інших послуг, де результат добре показувати візуально.
Компанія має десятки фотографій реальних робіт. Людина знаходить приклад, який їй подобається. А далі — тиша.
Щоб отримати прорахунок, потрібно повернутися в меню, знайти контакти, відкрити окрему форму і ще раз пояснити, що саме зацікавило.
Тут проблема не в портфоліо. Воно виконує свою функцію — показує досвід. Слабке місце знаходиться між інтересом і наступною дією.
У деяких випадках достатньо зв’язати конкретну роботу з логічним кроком:
- «Хочу схожий проєкт»;
- «Надіслати розміри»;
- «Отримати попередній прорахунок».
Новий сайт для цього не потрібен.
3. Контакти є, але незрозуміло, що робити далі
Ще один повторюваний патерн — сайт формально має все необхідне: телефон, форму, месенджер, сторінку контактів, кілька CTA.
Але відвідувачеві доводиться самому вирішувати, який шлях правильний.
Кількість кнопок тут не допомагає. Часто сильніша проста логіка:
обрати послугу → зрозуміти умови → записатися
або
подивитися роботи → передати параметри → отримати наступний крок.
Саме тому ми не оцінюємо CTA лише за кількістю. Важливіше, чи є зрозумілий вихід із читання в дію.
4. Бізнес виріс, а сайт залишився в минулому
Сайт може бути технічно справним і навіть виглядати нормально, але вже не показувати реальний рівень компанії.
За кілька років бізнес міг розширити послуги, накопичити сильне портфоліо, отримати нове обладнання, сформувати команду або змінити географію.
А сайт усе ще показує стару структуру і старі аргументи.
Це важливо відрізняти від простого «застарілого дизайну».
Іноді кольори та шрифти можна взагалі не чіпати. Потрібно оновити структуру, докази, сторінки послуг і зв’язки між ними.
Саме для таких випадків ми окремо описуємо доопрацювання існуючого сайту — без автоматичного продажу нового проєкту.
5. Іноді головна проблема дуже проста: щось реально не працює
Серед ручних перевірок були ситуації, де довго сперечатися про UX не потрібно:
- CTA веде на 404;
- калькулятор закінчується помилкою;
- форма не відправляється;
- сайт стабільно недоступний;
- кнопка виглядає активною, але не виконує очікувану дію.
У такому випадку питання кольору кнопки, SEO-тексту або анімації тимчасово стають другорядними.
Людина вже намагається виконати цільову дію — і не може.
Тому одна з найкорисніших перевірок сайту займає кілька хвилин: натисніть усі ключові кнопки й пройдіть сценарій до кінця.
Не просто відкрийте форму — відправте її. Не просто побачте калькулятор — отримайте результат. Не просто перевірте номер — натисніть його з телефона.
6. PageSpeed може знайти рекомендації навіть там, де швидкість не є головною проблемою
Технічні інструменти потрібні. Але вони не знають контексту бізнесу.
В одному з реальних проєктів Core Web Vitals показували:
- LCP — 1,8 с;
- INP — 180 мс;
- CLS — 0,006.
У цій ситуації не було підстав робити «термінове прискорення» головним комерційним завданням.
Знайти ще технічні покращення можна майже завжди. Питання інше: чи є це зараз найважливішим обмеженням сайту?
Якщо одночасно не працює форма або CTA веде на 404, пріоритет очевидний.
7. Аналітика не повинна перетворювати припущення на факт
Припустімо, в Clarity ми побачили користувача, який кілька разів натиснув на неклікабельне зображення.
Це корисне спостереження. Але воно ще не доводить, що «користувачі не розуміють цей блок».
Потрібно перевірити, чи повторюється поведінка, на яких пристроях вона виникає і чи заважає основному сценарію.
Так само два місяці аналітики нового сайту вже дають багато корисної інформації, але ще не дозволяють впевнено говорити про річну сезонність або довгострокову конверсію.
«Недостатньо даних» — нормальний професійний висновок.
Як ми тепер класифікуємо знайдене
Замість «хороший сайт / поганий сайт» корисніше використовувати кілька рівнів.
Не проблема
Рішення незвичне, але сценарій працює.
Можливість покращення
Можна зробити зручніше, але критичного бар’єра немає.
Реальне тертя
Людині помітно складніше виконати важливу дію.
Системна проблема
Та сама складність повторюється на групі сторінок.
Критична проблема
Основна функція не працює.
Архітектурне обмеження
Існуюча структура вже не дозволяє нормально розвивати сайт.
Ця шкала корисніша за абстрактний «бал сайту зі 100», тому що одразу підводить до наступного питання: наскільки великим має бути рішення?
Масштаб рішення має відповідати масштабу проблеми
Якщо зламана кнопка — спочатку ремонтуємо кнопку.
Якщо на телефоні губиться запис — працюємо з mobile-сценарієм.
Якщо слабка одна сторінка — не обов’язково перебудовувати весь сайт.
Якщо десятки сторінок більше не утворюють зрозумілої системи — тоді потрібна системна робота.
Новий сайт має бути наслідком діагнозу, а не стартовим припущенням.
Перед великим етапом варто відповісти на п’ять питань:
- Що саме людина намагається зробити?
- Де конкретно виникає трудноща?
- Чи повторюється проблема?
- Чи можемо ми її підтвердити технічно або даними?
- Яке найменше втручання вирішує її?
Іноді результатом стане великий проєкт. Іноді — одна сторінка. Іноді — одна кнопка.
А іноді правильний висновок звучить так:
цю частину сайту зараз не потрібно змінювати.
Саме тому хороший аналіз починається не з пошуку максимальної кількості недоліків, а з перевірки того, що реально заважає користувачеві або бізнесу — і що вже працює нормально.
Якщо після перевірки незрозуміло, чи достатньо точкових змін, використайте інтерактивну перевірку «доопрацьовувати чи переробляти». Окремі сценарії перевірки показані у Vectora Lab.
