Клієнт
GKit - це український інтернет-магазин, що спеціалізується на продажі брендового одягу, взуття та аксесуарів. Проєкт заснований з метою створення прозорого сервісу для купівлі оригінальних речей. Компанія наголошує, що працює виключно з перевіреними постачальниками та принципово не продає репліки чи копії.
Магазин пропонує продукцію для чоловіків, жінок та дітей:
- Взуття: кросівки, кеди, черевики, сандалі, тапочки (популярні серії: Air Jordan, Nike Dunk, New Balance 9060 та ін.).
- Одяг: футболки, худі, світшоти, штани, шорти, куртки, жилетки.
- Аксесуари: сумки, рюкзаки, шапки, кепки, шкарпетки, м'ячі.
Сервіс та умови
- Доставка: здійснюється по всій Україні.
- Оплата: готівкою або карткою (підтримка Privat24, Monopay, Visa, Mastercard).
- Гарантії: можливість обміну та повернення протягом 14 днів.
- Допомога: консультації щодо підбору розміру та можливість пошуку товару під замовлення.
Роботи з розробки сайту
Сайт реалізовувався на базі OpenCart. Як тільки проєкт зайшов на розробку, наш програміст провів аналіз наявного макету та видав правки, які спростили технічну архітектуру та забезпечили коректне відображення сайту на всіх типах пристроїв.
Відсутні елементи (UI Gaps)
- Перемикач мов: у дизайні був відсутній зовнішній вигляд випадаючого списку (dropdown), слід було промалювати стан при натисканні.
- Індикатори в шапці: на іконках Кошика та Обраного не відображалась кількість товарів (лічильник у вигляді цифр). Потрібно було додати ці елементи, щоб користувач бачив наповненість без переходу на сторінку.
- Картка товару: була відсутня форма додавання відгуку, в той час як користувач мусив мати можливість залишити фідбек безпосередньо на сторінці товару.
Пропозиції щодо логіки (UX Optimizations)
Сторінка Відгуки:
- Зміна структури (сітка): ми запропонували розмістити відгуки у форматі 3 одиниці в один ряд (у 3 колонки), що забезпечило б симетрію інтерфейсу та зручність сканування тексту оком.
- Оптимізація контенту: у загальному списку відгуків слід було додати зображення товару та пряме посилання на нього. Це допомогло б користувачам швидше ідентифікувати товар і перейти до покупки.
- Управління кнопками: ми запропонували прибрати кнопку Додати відгук з цієї сторінки, оскільки основним місцем для написання відгуків мали стати картки товарів.
Сформований пакет пропозицій ми надали клієнту для розгляду та впровадження. Далі нас чекав проміжковий аудит оновленого макета.
Поточний стан сайту на момент проведення аудиту
- Категоризація: в системі було створено 3 базові категорії: Аксесуари, Одяг та Взуття.
- Картка товару: вся наявна інформація про товар була обмежена.
- Дублювання позицій: однакові товари різних розмірів внесені до бази як окремі товарні одиниці, а не як варіації однієї моделі.
Пропозиції щодо оптимізації
Ми надали пропозицію об'єднати різні розміри та характеристики одного артикула в одну картку товару через функціонал модифікацій. Переваги такого підходу:
- Чистота бази: уникнення створення величезної кількості дублів однакових товарів.
- Зручність обліку: простіше відстежувати залишки конкретної моделі в розрізі розмірів/кольорів.
- Користувацький досвід: у картці товару (якщо це синхронізовано з сайтом) клієнту буде зручніше обирати потрібний розмір, не переходячи на інші сторінки.
Таке рішення скоротить кількість зайвих товарів та в подальшому зробить імпорт коректним.
Оскільки наповнення сайту планувалося через CRM-систему (клієнт обрав KeepinCRM), ми зосередились на побудові архітектури даних - розробили логіку автоматизації товарних опцій та визначили джерела вхідних даних. Сформоване бачення передали клієнту для узгодження технічного стеку інтеграції.
1. Автоматизація опцій (розмір та колір)
Слід було підтвердити, чи створюємо ми опції товарів автоматично (Розмір, Колір) двома мовами. Якщо так, то в кожній картці товару в CRM обов'язково мали бути заповнені відповідні поля. Саме на їхній основі далі мали бути сформовані модифікації при імпорті.
2. Відповідність обов'язкових полів
Клієнту необхідно було вказати, з яких саме полів у CRM (або файлі вивантаження) слід забирати дані для наступних параметрів:

Фільтри на кшталт (Розмір, Колір - будуть створені на підставі опцій). Для всіх інших фільтрів також слід було створити поля в CRM: Доставка, Тип, Колекція, Сезон, Призначення. Ми рекомендували використовувати список зі значеннями в CRM, а не поле для введення, це стандартизувало б вибір варіантів і прискорило би заповнення товарів.
Основний принцип системи: CRM є головним вузлом для обліку залишків та керування даними про товари. Ми запропонували наступну логіку.
1. Оновлення товарів (CRM - Сайт). Весь облік складських залишків ведеться виключно в CRM. Процес оновлення виглядає так:
- Маркер синхронізації: у картці товару в CRM створюється спеціальний елемент керування (випадаючий список або чекбокс).
- Включено: при збереженні змін у CRM дані автоматично передаються на сайт.
- Виключено: зміни в CRM залишаються лише всередині системи, синхронізація з сайтом не відбувається.
- Пріоритет даних: CRM має вищий пріоритет. Якщо адміністратор змінить дані про товар безпосередньо в адмінпанелі сайту, виникне розбіжність. Однак, при наступному оновленні цього ж товару з боку CRM, дані на сайті будуть перезаписані актуальною інформацією з CRM.
2. Створення замовлень (Сайт - CRM). Процес обробки замовлень працює у зворотному напрямку для забезпечення операційного обліку:
- Автоматичне створення: щойно клієнт оформлює замовлення на сайті, система автоматично генерує нове замовлення в CRM.
- Передача даних: у CRM передається повний пакет інформації:
- Перелік замовлених товарів;
- Кількість та ціна;
- Контактні дані покупця;
- Методи доставки та оплати.
Далі ми розробили технічний план оптимізації даних у CRM для синхронізації з сайтом.
1. Реструктуризація товарної сітки (усунення дублювання)
Основна проблема - створення окремих карток для кожного розміру, що захаращувало базу та ускладнювало фільтрацію на сайті.
- Перехід до моделі «Товар + Варіації»: замість 5 окремих товарів (наприклад, кросівки розмірів 40, 41, 42, 43, 44) створюється одна батьківська картка моделі. Розміри та кольори виносяться у модифікації (SKU) всередині цієї картки.
- Логіка об'єднання: об'єднати дублікати за ознакою "Модель + Бренд". Це дозволило би клієнту на сайті бачити одну картку з випадаючим списком розмірів, що значно покращило б UX (користувацький досвід).
2. Впровадження обов'язкових полів (мультимовність)
Для коректного відображення товарів на сайті, у CRM необхідно було налаштувати наступні поля:
Ідентифікація та логістика:
- Артикул (SKU): унікальний ідентифікатор (обов'язково для синхронізації залишків).
- Модель: групуюча назва для об'єднання модифікацій.
- Кількість: актуальний залишок на складі.
- Ціна / Ціна 2 / Ціна 3: (наприклад: роздрібна, оптова, акційна).
| Поле | UA (Українська) | RU (Російська) | Примітка |
| Назва товару | Обов'язково | Обов'язково | Чітка назва (напр. "Кросівки бігові") |
| Опис | Обов'язково | Обов'язково | Детальний текст про товар |
| Характеристики | Обов'язково | Обов'язково | Склад, матеріал, сезонність тощо |
| Бренд | Обов'язково | Обов'язково | Для роботи фільтрів на сайті |
Наявних 3х категорій (Аксесуари, Одяг, Взуття) недостатньо для якісного SEO та навігації. Ми рекомендували створити підкатегорії (наприклад: Одяг - Худі / Футболки / Штани), що дозволило би автоматично розподіляти товари по відповідних розділах сайту під час імпорту.
4. Кроки по реалізації:
- Налаштування в CRM логіки зв'язку "Батьківський товар - Модифікації" (мав втілити розробник).
- Аудит бази, злиття дублікатів в одну модель та дозаповнення відсутніх мовних версій (особливо назв та описів) - завдання контент-менеджера.
- Визначення, чи всі три типи цін (Ціна 1, 2, 3) мали вивантажуватися на сайт, чи деякі призначені лише для внутрішнього використання в CRM (звітна особа - замовник).
Технічні вимоги до полів Опцій та Фільтрів у CRM
1. Логіка формування Опцій. Для того, щоб на сайті замість дублікатів з'явилася одна картка з вибором параметрів, необхідно було впровадити автоматизацію на основі конкретних полів у CRM.
- Автоматичне створення: ми рекомендували формувати опції автоматично при імпорті.
- Необхідні поля в CRM:
- Розмір: числове або буквене значення (напр. 42, XL, 38).
- Колір (UA/RU): текстове поле або довідник (напр. Чорний / Черный).
- Результат: система групує товари за Артикулом/Моделлю, а значення з цих полів перетворює на кнопки вибору у картці товару на сайті.
2. Структура полів для фільтрації. Для коректної роботи фільтрів на сайті, кожна характеристика в CRM мусить мати двомовне значення. Ми рекомендували використовувати тип поля "Випадаючий список" (Dropdown) або "Мультиселект", адже це виключає помилки (наприклад, "Lviv", "lviv" та "Львів" система сприйме як різні значення, якщо вводити їх вручну).
| Характеристика | Тип поля в CRM | UA (Українська) | RU (Російська) |
| Доставка | Випадаючий список | Напр. "В наявності" | Напр. "В наличии" |
| Тип | Випадаючий список | Напр. "Кросівки" | Напр. "Кроссовки" |
| Колекція | Випадаючий список | Напр. "Весна 2026" | Напр. "Весна 2026" |
| Сезон | Випадаючий список | Напр. "Демісезон" | Напр. "Демисезон" |
| Призначення | Мультиселект | Напр. "Для спорту" | Напр. "Для спорта" |
3. Переваги уніфікації через списки
- Чистота даних: на сайті відсутні сміттєві фільтри через друкарські помилки в CRM.
- Швидкість контент-менеджменту: співробітнику простіше обрати варіант зі списку, ніж щоразу вводити текст на двох мовах.
- SEO-оптимізація: фільтри з чіткими назвами краще індексуються пошуковими системами.
Також на сайті у CRM потрібно було створити чекбокс або випадаючий список: “Оновлювати товар на сайті?”. Він дозволив би керувати тим, чи мав товар синхронізуватися під час збереження.
Під час налаштування СРМ системи зʼявились питання на майбутнє, на які ми надали рекомендації.
1. Де зберігати дані (оригінали). Завантажувати фото безпосередньо в CRM - не найкраща ідея для високонавантажених проєктів, оскільки бази даних CRM не оптимізовані для зберігання та швидкої роздачі великих медіафайлів.
Рекомендація:
- CRM виступає як «мозок»: у картці товару зберігаються лише текстові посилання (URL) на фото.
- Хмарне сховище (наприклад, S3 або bunny.net) виступає як «склад»: там лежать оригінали високої якості.
2. Як це працює в ланцюжку: CRM - Сайт - Клієнт. Логіка наступна:
- Менеджер завантажує фото. Скрипт автоматично кладе його в сховище, а в CRM записує лише лінк: https://cdn.yourdomain.com/products/image_123.jpg.
- Сайт через API забирає з CRM дані про товар (назву, ціну) разом із цим лінком.
- Коли покупець відкриває сторінку, його браузер запитує фото не у вашого сервера/сайту, а безпосередньо у CDN.
3. Переваги використання CDN (на прикладі bunny.net). Клієнт вніс пропозицію використовувати «нарізку» (Image Optimizer), адже це критично для SEO та швидкості:
- Адаптивність: завантажується одне велике фото, а CDN віддає смартфону картинку розміром 400px, а монітору - 1200px.
- Формати: автоматична конвертація в WebP або AVIF, що зменшує вагу файлу на 30-50% без втрати якості.
- Швидкість: завдяки мережі дата-центрів по всьому світу (PoP), клієнт у Києві отримає фото з сервера в Східній Європі, а не з США.
4. Ризики та нюанси. Щоб система працювала стабільно, слід врахувати наступне:
- Синхронізація назв: файли в сховищі мусять мати зрозумілу структуру або ID, що відповідає ID товару в CRM, щоб уникнути плутанини.
- Вартість оптимізації: сервіси на кшталт Bunny Optimizer або Cloudflare Images зазвичай платні (наприклад, $1/міс за зону + оплата за трафік). Але це дешевше, ніж втрачати клієнтів через повільний сайт.
- Відмовостійкість: якщо CDN впаде (що буває рідко), сайт залишиться без картинок. Тому важливо налаштувати коректне кешування на стороні браузера.

Надані рекомендації були погоджені із замовником, проте не впроваджені через зміну бізнес-логіки проєкту на стороні замовника.
Далі слід було створити та заповнити обов’язкові поля в CRM - цією роботою займалася команда замовника.
Наступний етап - специфікація обов’язкових полів товарної картки в CRM.
Для стабільного імпорту та коректного відображення товарів на сайті (в обох мовних версіях), необхідно було впровадити наступну структуру:
1. Ідентифікація та склад (системні поля). Ці поля є критичними для синхронізації залишків та замовлень.
- Артикул (SKU): обов’язково, це унікальний ідентифікатор товару. Без нього автоматичне оновлення ціни/кількості неможливе.
- Модель: обов’язково, адже використовується для групування варіацій (наприклад, різні кольори однієї моделі).
- Кількість: обов’язково, адже слід знати поточний залишок на складі.
2. Ціноутворення.
- Ціна (Роздрібна): обов’язково (основна ціна на сайті).
- Ціна 2 / Ціна 3: опціонально (можуть використовуватись для акційних цін, оптових прайсів або різних програм лояльності).
3. Контент (локалізація: UA / RU). Щоб сайт не мав пустих сторінок, ці поля мали бути заповнені в обох мовних версіях.
- Назва товару: обов’язково.
- Опис: обов’язково (для SEO та інформування клієнта).
- Характеристики: обов’язково (матеріал, розмір, склад тощо).
- Бренд: обов’язково (для фільтрації на сайті).
Також на рівні CRM ми рекомендували встановити заборону на збереження картки, якщо не заповнені: Артикул, Ціна, Кількість та Назва (UA). Це б вберегло клієнта від ситуації, коли на сайт вивантажується битий товар без назви або з нульовою ціною.
*відображення додаткових рівнів цін (Ціна 2 та Ціна 3) не було реалізоване через перегляд комерційної логіки проєкту.
Поля для опцій
Необхідно було визначити: чи створюються опції (розмір, колір) автоматично. Якщо так, у CRM потрібно було додати:
- Розмір
- Колір (укр / рос)
На основі цих полів формуються опції товарів на сайті.
Поля для фільтрів
Щоб фільтри на сайті працювали коректно, у CRM мали бути поля:
- Доставка
- Тип
- Колекція
- Сезон
- Призначення
Усі значення мали бути вказані двома мовами. Важливо: ми рекомендували використовувати випадаючі списки, а не вільний ввід тексту - так дані уніфікуються, що пришвидшує роботу.
Логіка даних при створенні товару на сайті:
- Якщо не заповнено поле Бренд (рос), береться значення з поля Бренд.
- Якщо не заповнено поле Модель, береться значення з поля Артикул.
- Якщо не заповнено поле Назва товару (рос), береться значення з поля Назва товару.
- Якщо не заповнено поле Опис (рос), береться значення з поля Опис (укр).
- Характеристики товару заповнюються на основі таких полів: Тип, Колір, Колекція, Сезон, Призначення.
- На основі характеристик та опцій автоматично створюються фільтри.
Додатково ми створили модуль, в якому можна вказувати ключ API та інші параметри.
Після того, як клієнт вніс товари в CRM, ми завершили технічну інтеграцію сайту з CRM, що дозволило повністю автоматизувати імпорт товарної номенклатури та атрибутів (фільтрів). Для подальших робіт ми надіслалаи запит на інформацію:
1. SEO-дані для фільтрів (ЧПУ)
Для кожної сторінки фільтрації необхідно було підготувати:
- Заголовок H1 та URL-адресу.
- Мета-теги: Title та Description.
- Контент: текстовий опис категорії.
- Технічне: перелік активованих фільтрів для коректної логіки меню.
2. Контактна інформація та сервісні сторінки
- Контакти: номери телефонів, e-mail, посилання на соцмережі.
- FAQ: підготовка відповідей на типові запитання клієнтів.
- Сайт: текст Про нас.
- Юридичне: тексти Правил використання сертифікатів, Політики конфіденційності, Публічної оферти.
3. Контент-маркетинг та соціальний доказ
- Блог: написання статей (тексти + візуальне оформлення).
- Відгуки: наповнення загальними відгуками про магазин та окремими - про конкретні товари.
Після реалізації наданих даних клієнт провів підсумковий аудит ресурсу та надав перелік фінальних правок. Ми їх опративно реалізували.
В кінці лютого відбувся реліз проєкта. Далі клієнт перейшов на послугу SEO-оптимізація сайту, де ми сфокусувалися на безпечному переході до релізу. Наша команда провела передрелізну та післярелізну перевірки, за результатами яких було виконано необхідні технічні вдосконалення.
SEO-просування проєкту
Як тільки проєкт зайшов на розробку та просування, ми провели перевірку обраного клієнтом домену (gkit.com.ua) за наступними напрямками:
- Статус реєстрації: перевірка через сервіси imena.ua та whois.domaintools.com підтвердила, що домен вільний і доступний для викупу.
- Історія домену: аналіз через Wayback Machine показав відсутність будь-яких збережених копій сайту в минулому, що свідчить про те, що домен не мав попередніх власників і має чисту історію.
- Юридична перевірка (ТМ): пошук у базі даних sis.nipo.gov.ua не виявив зареєстрованих торговельних марок з назвою "gkit", що мінімізувало юридичні ризики при використанні бренду.
- Безпека: проведено аналіз на наявність вірусів та шкідливого ПЗ, який підтвердив безпечність домену.
- Санкції та блокування: перевірка в реєстрах заборонених ресурсів показала, що домен не перебуває під санкціями та не заблокований провайдерами.
Висновок: домен був повністю придатний для реєстрації та подальшого використання.
Також після перегляду поточного макету ми надали рекомендації щодо вдосконалення дизайну та функціоналу сайту.
1. Сторінка брендів: структура та навігація. Для підвищення зручності пошуку та візуальної привабливості ми запропонували оновити сторінку брендів, орієнтуючись на кращі практики ринку (зокрема досвід найближчого конкурента):
- Візуальна ієрархія: у верхній частині сторінки розмістити плитку з логотипами найпопулярніших брендів. Для інтерактивності додати легкий hover-ефект при наведенні.
- Алфавітний покажчик: нижче реалізувати блоки брендів, відсортовані за алфавітом. Для швидкого переходу між секціями впровадити алфавітну навігацію (якірні посилання).
- Контентний блок: додати лаконічний вступний текст над сіткою брендів (наприклад: «GKit співпрацює виключно з перевіреними світовими виробниками одягу та взуття»). Це корисно як для користувача, так і для SEO-індексації сторінки.
2. Сторінка статті: робота з типографікою та акцентами. Поточний макет потребував корекції для покращення читабельності та залучення аудиторії:
- Оптимізація верстки: вирівняти ширину текстового блоку відносно банера, щоб позбутися ефекту стиснутого тексту та збалансувати композицію сторінки.
- Структурування контенту: на початку кожної статті додати блок Змісту (Table of Contents) з клікабельними пунктами для швидкої навігації.
- Візуальні акценти: переробити блок цитат. Замість суто декоративного елемента створити контрастний блок із чітким маркуванням: Думка експерта або Коментар стиліста.
- Робота з заголовками: назва статті обов’язково має дублюватися текстом перед основним зображенням, навіть якщо вона є частиною графічного банера.
- Блок Схожі новини: візуально відокремити цю секцію від основного контенту (використати інший фон або змінити формат карток на більш компактний), щоб уникнути одноманітності.
- Соціальні функції та перелінковка:
- Додати іконки Поділитися у соціальних мережах.
- Реалізувати блок внутрішньої перелінковки з іншими актуальними матеріалами.
- Розглянути можливість додавання форми коментарів (за умови наявності ресурсу на модерацію).
3. Сторінка Блогу: експертність та утримання уваги
- Авторство: біля кожної публікації, окрім дати, зазначати ім'я автора, адже це підвищує рівень довіри (E-E-A-T фактори) та персоналізує бренд.
- Рециркуляція трафіку: під основним списком статей додати динамічний блок Популярне або Останні новини, щоб стимулювати користувача залишатися на сайті довше.
Усі пропозиції щодо оптимізації ми передали на погодження команді замовника. Далі ми здійснили комплексний ресерч ніші та детальний аудит найближчих конкурентів. Аналіз охоплював їхні профілі посилань, контентні стратегії та технічні рішення. Проведені роботи допомогли нам визначити вектори розвитку проєкту та запропонувати рішення, що зроблять проєкт помітним для цільової аудиторії з перших днів.
Аналіз ніші
1. Ключові гравці ринку. Основними прямими конкурентами в ТОП-видачі за комерційними запитами (брендовий одяг, брендове взуття) визначено:
- yesoriginal.com.ua - стабільне зростання органічного трафіку, фокусується на категоріях чоловічих кросівок та конкретних колекціях (наприклад, Nike P6000).
- allstars.ua - сильні позиції за брендами Nike та Jordan, проте спостерігалась тенденція до зменшення кількості сторінок в органіці.
- answear.ua - великий гравець із високим рівнем довіри (DR 59), найбільша кількість трафіку на головну сторінку та бренд Birkenstock.
- prm.com - фокусується на преміум-сегменті та колекціях Adidas (Samba, Campus), має високий авторитет домену (DR 58).
2. Джерела та структура трафіку
- Пріоритетні товари: основний трафік конкуренти отримують на сторінки кросівок, особливо брендів Nike та Adidas.
- Типи запитів: найбільшу частку відвідувань приносять брендові запити (назва магазину) та комерційні ключі кластера Кросівки.
- Мовні версії: головні сторінки конкурентів часто оптимізовані під назву бренду, при цьому українські версії сайтів стають основними для отримання трафіку.
3. Технічні та SEO особливості
- Робота з фільтрами: найбільш грамотний підхід у Yes, Original - вони використовують ЛЗУ (людинозрозумілі URL) для фільтрів, які відкриті для індексації та мають оптимізовані метадані, тоді як не потрібні фільтри закриті від роботів.
- Контент: більшість конкурентів не мають розгорнутих SEO-текстів на сторінках категорій, обмежуючись оптимізованими метатегами та блоками з цінами.
- Структура меню: у деяких конкурентів (наприклад, Yes, Original) основні розділи Чоловіче, Жіноче не є клікабельними, а трафік спрямовується відразу на конкретні підкатегорії взуття.
4. Посилальні стратегії
- Answear.ua є прикладом для наслідування: регулярна закупівля якісних посилань (DR 30+) з доменної зони .ua та .com.
- Негативні приклади: деякі конкуренти (yesoriginal, allstars) використовують агресивну стратегію з великою часткою (понад 80%) низькоякісних донорів та майже 100% dofollow-посилань, що дає короткостроковий ефект, але підвищує ризик санкцій від Google.
Основні надані рекомендації на основі аналізу:
- Оптимізувати обидві мовні версії під назву сайту та ключі "брендовий одяг/взуття".
- Зробити акцент на просуванні сторінок кросівок Nike та Adidas.
- Використовувати підхід Yes, Original до індексації фільтрів: відкривати лише цільові та закривати технічні.
- Формувати посилальний профіль за рахунок трастових українських ресурсів (блоги, медіа), уникаючи масової закупівлі сміттєвих лінків.
Структура сайту
Спираючись на досвід просування аналогічних проєктів та детальний ресерч конкурентів, ми провели аудит макета на етапі прототипування. Наші спеціалісти сформували перелік рекомендацій, що базуються на доцільності кожного елемента для SEO та зручності користувача (UX), щоб мінімізувати шлях клієнта до покупки.
Запропоновані прототипи сторінок:
Додаткові рекомендації
У футер можна додати сторінки із цього списку:
- Доставка і оплата
- Політика конфіденційності
- Повернення і обмін
- Договір публічної оферти
- Програма лояльності
- Про компанію
- Відгуки
- Подарункові сертифікати
- FAQ
- Правила використання сертифіката
Ми розробили логіку навігації, базуючись на пріоритетних категоріях клієнта: Одяг, Взуття та Аксесуари. У футері сайту наявний статичний блок Каталог, який слугує відправною точкою для навігації - ці 3 ключові розділи стали фундаментом для побудови ЧПУ-фільтрів (SEO-friendly URLs), що дозволило автоматизувати створення оптимізованих сторінок для всього асортименту. Паралельно ми структурували блок сервісної інформації (контакти, графік роботи, email), забезпечивши швидкий доступ до зв'язку з магазином та підвищивши рівень довіри користувачів.
Ключові тригери продажів доцільніше винести в зону першого екрана, щоб забезпечити максимальне охоплення з перших секунд:
- Інтерактивна карусель брендів: акцент на світових іменах, що є фундаментом стратегії просування та головним маркером довіри.
- Блок Хіти продажу: розміщення бестселерів у першому скролі для стимулювання миттєвих переходів та підвищення CTR товарних карток.
Далі настав етап аудиту розробки, після якого ми надали рекомендації щодо оптимізації коду й структури для максимальної відповідності вимогам пошукових систем.
Техаудит
1. Термінові завдання до виконання (пункти критично впливали на безпеку та коректне сприйняття сайту пошуковими системами).
- SSL-сертифікат та протокол HTTPS: сайт обов’язково має працювати на захищеному протоколі.
- Редирект з HTTP на HTTPS: необхідно було налаштувати 301-редирект для всіх сторінок сайту, щоб уникнути дублювання контенту та забезпечити безпеку користувачів.
2. Важливі рекомендації, які впливали на ранжування
- Налаштування hreflang: для кожної сторінки потрібно було вказати мовні версії та версію за умовчанням (x-default), щоб Google не сприймав перекладений контент як дублікати.
- Правила формування URL:
- Використання дефісів (-) замість нижніх підкреслень (_).
- Уникання кирилиці, пробілів та спеціальних символів (%, &, +).
- Всі URL мусили мати однаковий формат із замикаючим слешем (наприклад, /choloviche-vzuttya/).
- Оптимізація зображень:
- Використання формату WebP.
- Обов'язкове заповнення атрибутів ALT та title за шаблоном "Назва товару".
- Впровадження "лінивого завантаження" (loading="lazy").
- Мікророзмітка (Schema.org): рекомендовано впровадити типи Product (для товарів), BreadcrumbList (для хлібних крихт) та Organization.
- Усунення дублів головної сторінки: головна мала бути доступна тільки за однією адресою. Варіанти типу /index.php мусили мати 301-редирект на основний домен.
- Канонічні посилання (rel="canonical"): для сторінок із фільтрами потрібно було вказувати канонічну адресу основної категорії, щоб прибрати параметри з індексу.
3. Рекомендації щодо індексації та структури
- Обмеження індексації: сторінки кошика, оформлення замовлення, особистого кабінету та результатів пошуку мали бути закриті тегом noindex, follow.
- Пагінація:
- Сторінки пагінації (напр. /page-2/) мусили бути відкриті для індексації.
- Кожна така сторінка мусила мати rel="canonical" на саму себе.
- Атрибут lang: для української версії в коді <html> мало бути вказано саме lang="uk". Використання ua було помилкою.
4. Функціональні та SEO-фішки
- Сортування товарів: у категоріях товари, що є в наявності, мають відображатися першими.
- Динамічна зміна ціни: рекомендовано впровадити логіку зміни ціни в залежності від залишків (основна ціна при >2 шт, підвищена при залишку 1-2 шт), щоб уникнути створення дублів карток товарів для різних розмірів.
- Sitemap.xml: після впровадження всіх правок слід згенерувати актуальну карту сайту та налаштувати файл robots.txt з відповідними заборонами (Disallow).
Для відстеження ефективності проєкту та збору маркетингових даних, ми ініціювали встановлення базового стеку інструментів Google - підготували клієнту технічні завдання та детальні інструкції щодо інтеграції наступних сервісів:
1. Google Search Console (GSC). Інструмент для контролю індексації та технічного стану сайту в пошуковій видачі.
- Метод впровадження: верифікація ресурсу шляхом завантаження HTML-файлу в корінь сайту (директорії /public_html/ або /www/).
- Статус: клієнту був переданий файл підтвердження та офіційну інструкцію від Google для коректної активації панелі вебмайстра.
2. Google Analytics 4 (GA4). Налаштування сучасної системи аналітики для відстеження поведінки користувачів та конверсій.
- Метод впровадження: інтеграція ідентифікатора потоку даних безпосередньо в код сайту.
- Супровід: ми підготовили та передали клієнту текстовий файл із кодом відстеження та візуальні інструкції (скріншоти) для безпомилкового розміщення скрипта в структурі сторінок.
3. Google Tag Manager (GTM). Впровадження диспетчера тегів для гнучкого керування маркетинговими скриптами без залучення розробників у майбутньому.
- Статус: ми сформували ТЗ на встановлення контейнера GTM. Після підтвердження коректності встановлення на пошту клієнта будуть делеговані повні права доступу до всіх налаштованих ресурсів.
Ми повністю налаштували модуль Ecommerce, перші дані про тестові транзакції вже почали фіксуватися в GA4. Контейнер GTM оптимізовано під електронну комерцію, а права власності в GSC успішно підтверджено.
Семантика
Аналіз видачі та стратегій конкурентів чітко показав: у цій ніші Головна сторінка - це найпотужніший інструмент для ранжування. Саме тому ми вирішили зосередити на ній найбільш вагомі та частотні кластери (брендові речі та брендовий одяг). Оскільки Головна має найбільшу вагу в очах пошуковиків, такий підхід давав нам реальний шанс зачепитися за ТОП у боротьбі з сильними гравцями ринку. Водночас ми не забували про внутрішню структуру: для розділу «Одяг» ми підготували окремий набір метаданих, щоб чітко розмежувати запити й уникнути канібалізації ключів. Щоб закріпити результат і дати пошуковим роботам правильні сигнали, розробили детальні ТЗ для копірайтерів - кожна категорія мала отримати якісний контент, який працював би і на SEO, і на лояльність покупця.
Метадані
Розробили та впровадили оптимізовані шаблони метаданих для забезпечення коректного відображення всіх сторінок у пошуковій видачі.
Одразу після релізу ми здійснили повний технічний аудит, підтвердивши стабільність усіх налаштувань. Зараз проєкт перебуває на стадії активного заповнення каталогу з боку клієнта. Однак ми вже спостерігаємо перші результати в органічній видачі.
Органічний трафік
Завдяки комплексному підходу (SEO та технічна розробка на нашій стороні) ми отримали ресурс, який почав залучати цільовий трафік з першого дня після запуску. У результаті за перший місяць після релізу сайт продемонстрував такі показники відвідуваності:
Ключові показники Organic Search:
- Сеанси: 85.
- Залучені сеанси: 50 (рівень залученості - 58,82%, що є непоганим показником для органіки для нового сайту).
- Середній час взаємодії: 1 хвилина.
- Ключові події (вони ж конверсії): 2.
Графік свідчить про поступове зростання активності у другій половині березня. Пік залученості припав на період 23-25 березня.
- Усього кліків: 42.
- Усього показів: 2,6 тисячі.
- Середній CTR (клікабельність): 1,6%.
- Середня позиція: 24,3.
Графік показів (фіолетова лінія) демонструє стійку тенденцію до зростання, починаючи з 18 березня. Це свідчить про те, що пошукові системи активніше індексують сайт і виводять його за більшою кількістю запитів. Сплеск показів супроводжується зростанням кліків (синя лінія) наприкінці місяця, що підтверджує, що контент потрапляє в цільову аудиторію. Новий сайт в середньому ранжується на 3-й сторінці видачі. Багато запитів уже знаходяться поблизу ТОП-10. CTR 1,6% - для позиції на 3й сторінці це нормальний показник, але він вказує на потенціал росту. Як тільки ключові сторінки піднімуться в ТОП-10, кількість кліків зросте.
Як бачимо зі скріншотів, розроблений сайт демонструє чудові показники клікабельності вже на етапі запуску. Високий рівень взаємодії з пошуковою видачею свідчить про те, що обрана стратегія формування сніпетів (Title/Description) працює ефективно та залучає цільову аудиторію. Подальший супровід та розвиток ресурсу ми передали внутрішній команді замовника.