Фільтри заважали індексації товарів: SEO-кейс інтернет-магазину

SEO-кейс: як фільтри заважали інтернет-магазину запчастин для кавомашин отримувати трафік
Тип кейсу: технічне SEO, індексація, структура каталогу, внутрішня перелінковка
Ніша: запчастини для кавомашин
Термін: 4 місяці
Уявімо інтернет-магазин, який продає помпи, ущільнювачі, заварювальні блоки, клапани та інші запчастини для кавомашин. Асортимент великий, товарні сторінки є, попит на конкретні деталі теж є. Але органічний трафік майже не зростає. Власник вважає, що потрібні нові SEO-тексти й посилання. Під час аудиту виявляється інше: каталог генерує тисячі технічних URL, а важливі сторінки товарів залишаються погано пов'язаними з основною структурою сайту.
У цьому кейсі розберемо, як відокремити симптоми від причини, чому перша спроба оптимізації не дала помітного ефекту та як організувати роботу без ризикованого масового закриття сторінок.
Вихідна ситуація: товари є, зростання немає
Модельний магазин працює по всій Україні та має:
1 850 активних карток товарів;
42 основні категорії та підкатегорії;
фільтри за брендом, типом деталі, сумісністю, наявністю й ціною;
сортування за вартістю та популярністю;
Google Search Console і GA4 з налаштованими покупками.
За попередні 28 днів пошук Google приніс 3 120 кліків. Значна частина комерційного попиту припадала на запити на кшталт «ущільнювач для кавомашини Delonghi» або «помпа для кавомашини Saeco». Проте деякі відповідні товари не отримували переходів узагалі.
Команда помітила ще один сигнал: у звітах індексації Google Search Console індексованих товарних URL було суттєво менше, ніж активних товарів. Сам по собі цей факт не означає помилку — Google не зобов'язаний індексувати всі сторінки. Але разом із слабкою видимістю пріоритетних позицій він став причиною для перевірки.
Перша спроба: переписали Title — результату майже не було
Спочатку SEO-фахівець пішов очевидним шляхом: оновив шаблони Title та meta description для основних категорій, додав назви брендів і комерційні формулювання. На частині сторінок уточнив H1.
Через два тижні переконливого приросту кліків не було. Це не доводить, що робота з метаданими марна: двох тижнів часто недостатньо, а пошукова видимість залежить від багатьох чинників. Однак перші зміни не усунули головну технічну проблему.
Помилка була в пріоритетах. Команда оптимізувала зовнішній вигляд сторінок у пошуку, не перевіривши, які саме URL скануються, які Google обирає канонічними і наскільки легко робот знаходить товарні картки.
Що показав технічний аудит
1. Фільтри створювали величезну кількість адрес
Наприклад, одна категорія могла мати такі варіанти:
/zapchastyny/pompy/
/zapchastyny/pompy/?brand=saeco
/zapchastyny/pompy/?brand=saeco&available=1
/zapchastyny/pompy/?brand=saeco&available=1&sort=price_asc
Покупцю фільтри потрібні — вони допомагають знайти відповідну деталь. Але для пошукового робота кожна комбінація параметрів потенційно є окремою адресою.
У змодельованому аудиті краулер знайшов близько 6 800 адрес із параметрами фільтрів і сортування. Частина сторінок відрізнялася лише порядком товарів, частина була майже порожньою, інші дублювали комбінації, доступні за кількома URL.
Головне не абсолютна кількість адрес, а те, що значна частина з них не мала самостійної цінності для органічного пошуку.
2. Внутрішні посилання вели на випадкові комбінації
Навігація створювала звичайні HTML-посилання на багато варіацій фільтрів. Водночас важливі підкатегорії та товарні картки отримували мало контекстних посилань із базових категорій.
Наприклад, користувач міг знайти ущільнювачі для Delonghi лише через кілька кліків у фільтрах, хоча на такі товари існує окремий пошуковий попит.
3. Сигнали канонічності були непослідовними
Для деяких URL сортування був вказаний canonical на базову категорію. Для інших — самоканонічний URL із параметрами. У sitemap потрапляли адреси, які сайт одночасно пропонував Google не вважати основними.
Це створювало суперечливі сигнали. Важливо пам'ятати: rel="canonical" — сильна підказка, але не безумовна команда пошуковій системі.
4. Частина товарних сторінок була занадто схожою
Картки містили лише назву деталі, артикул і короткий універсальний опис. При цьому користувачу насамперед потрібна відповідь: із якими моделями кавомашин сумісна запчастина.
Тут проблема була не в кількості символів. Сторінці бракувало інформації, необхідної для рішення про покупку.
План виправлення: не закрити все, а розділити URL за роллю
Команда поділила адреси на три групи.
Група | Приклад | Рішення |
|---|---|---|
Основні категорії та товарні картки | /zapchastyny/pompy/ | Залишити доступними для сканування й індексації, поліпшити зміст і перелінковку |
Цінні посадкові сторінки під окремий попит | /zapchastyny/delonghi/ushchilniuvachi/ | Створювати або зберігати лише за наявності попиту, достатнього асортименту й унікальної користі |
Технічні комбінації фільтрів і сортування | ?available=1&sort=price_asc | Не просувати як окремі SEO-сторінки; обмежити непотрібне сканування після перевірки поточного стану |
Ключовий принцип: далеко не кожен фільтр потрібно індексувати. Але й автоматично забороняти всі фільтри небезпечно: частина таких адрес може відповідати реальному попиту.
Крок 1. Відібрали комбінації, для яких потрібні окремі сторінки
Перевірили частотність і намір запитів, асортимент, конкуренцію та можливість зробити корисну сторінку. Для першої хвилі обрали 12 підкатегорій за типом запчастини й брендом.
Для кожної підготували:
логічну статичну адресу без випадкових параметрів;
конкретний H1 і Title без переліку зайвих ключових слів;
перелік релевантних товарів із можливістю переходу до карток;
коротке пояснення сумісності та підбору;
посилання з батьківської категорії й навігаційні «хлібні крихти».
Сторінку створювали лише тоді, коли вона реально вирішувала окреме завдання користувача. Порожні посадкові сторінки під кожну марку й кожну деталь не генерували.
Крок 2. Привели до ладу фільтри та canonical
Спочатку перевірили зразки URL через URL Inspection і звіти індексації. Особливо уважно поставилися до адрес, які вже мали покази та кліки: їх не можна механічно виключати з пошуку без аналізу.
Для сторінок, що відрізнялися тільки сортуванням одного й того самого набору товарів, уніфікували канонічні сигнали на базову адресу. Для непотрібних комбінацій, які не мали пошукової цінності, спланували обмеження сканування відповідних параметрів через robots.txt і скорочення кількості внутрішніх посилань, що їх породжували.
При цьому не поєднували механічно Disallow та noindex. Якщо потрібно, щоб Google побачив noindex на вже відомій сторінці, бот спочатку повинен мати змогу її просканувати. Після перевірки вилучення з індексу для певних шаблонів можна окремо вирішувати питання довгострокового обмеження сканування. robots.txt не гарантує деіндексацію URL, а canonical не є способом керувати скануванням із гарантованим результатом.
Сторінки фільтрів із порожньою або безглуздою комбінацією, для яких не передбачено корисного результату, налаштували на коректний HTTP 404, зберігши зрозумілий інтерфейс для користувача. Правила не поширювали на тимчасово відсутні товари без окремого рішення.
Крок 3. Очистили sitemap і посилили перелінковку
З XML sitemap прибрали технічні дублікати та неканонічні URL. У файлі залишили адреси, які сайт справді хоче бачити в індексі.
На сторінках категорій додали зрозумілі посилання на пріоритетні підкатегорії. На сторінках брендів — посилання на відповідні типи деталей. Картки товарів отримали переходи на суміжні позиції там, де це допомагало вибору.
Перевірили, що посилання ведуть безпосередньо на потрібні канонічні URL, а не через зайві ланцюжки редиректів.
Крок 4. Покращили картки товарів, не створюючи «SEO-текст заради SEO-тексту»
Для 120 пріоритетних товарів додали перевірені дані:
точний артикул і назву виробника;
сумісні моделі кавомашин;
технічні характеристики й фото;
пояснення, як перевірити сумісність перед замовленням;
інформацію про наявність, доставку та повернення.
Ці дані мали братися з документації виробників і каталогу магазину, а не генеруватися навмання. Помилкова сумісність у такій ніші шкодить не лише SEO, а й покупцям.
Як вимірювали результат
Команда розділила оцінювання на технічну та бізнесову частини. Порівняла два 28-денні періоди: один до початку робіт, інший — після того, як основні зміни вже мали час бути просканованими й обробленими. У моделі це приблизно четвертий місяць проєкту.
Показник | До змін | Після змін | Різниця |
|---|---|---|---|
Кліки з Google Search, 28 днів | 3 120 | 3 950 | +26,6% |
Покази в Google Search, 28 днів | 145 000 | 182 000 | +25,5% |
Покупки з органічного трафіку в GA4, 28 днів | 61 | 76 | +24,6% |
Індексовані товарні URL у вибраному наборі | 1 240 | 1 510 | +270 |
Усі числа в таблиці змодельовані. Це приклад того, як може виглядати звіт, а не обіцянка подібного результату. До того ж кількість проіндексованих сторінок не є самостійною ціллю: важливі їхня корисність, видимість і продажі.
Для реального проєкту варто додатково перевірити сезонність, зміни асортименту й цін, рекламну активність, оновлення пошуку та коректність аналітики. Порівняння «до/після» не доводить, що весь приріст спричинений саме SEO-роботами. За можливості слід аналізувати окремо змінені та незмінені групи сторінок і порівнювати ті самі сезонні періоди.
Що спрацювало, а що — ні
Не дало переконливого швидкого ефекту: масове редагування Title без виправлення структури. Метадані залишаються важливими, але вони не замінюють технічний аудит.
Виявилося корисним у межах сценарію: чітке розділення технічних фільтрів і посадкових сторінок, послідовні сигнали канонічності, нормальні внутрішні посилання та зміст карток, який допомагає підібрати запчастину.
Чого свідомо не робили: не ставили noindex на всі сторінки з параметрами; не закривали весь каталог у robots.txt; не створювали сотні порожніх SEO-категорій; не перетворювали фільтри на масові редиректи на головну сторінку.
Як повторити логіку на власному сайті: чекліст
Вивантажте важливі URL із sitemap, каталогу й Search Console. Зіставте їх із реально доступними для сканування адресами.
Знайдіть шаблони параметрів: бренд, ціна, наявність, сортування, кілька фільтрів одночасно.
Для кожного шаблону визначте, чи є попит і чи має сторінка самостійну цінність у пошуку.
Перевірте canonical, HTTP-статус, директиви індексації, внутрішні посилання й наявність URL у sitemap.
Спочатку виправляйте невелику контрольну групу. Відстежуйте індексацію та кліки, перш ніж масштабувати рішення.
Додайте корисні посадкові сторінки лише для справді важливих комбінацій і зробіть їх доступними через навігацію.
У звітах розділяйте технічні зміни, зростання пошукової видимості та реальні конверсії. Не приписуйте весь приріст одному фактору.
Поширені запитання
Чи потрібно закривати всі URL фільтрів від індексації?
Ні. Деякі фільтри відповідають окремим комерційним запитам. Рішення залежить від попиту, асортименту, корисності сторінки та того, чи зможете ви підтримувати її актуальність.
Чи достатньо поставити canonical на основну категорію?
Ні. Це сигнал про бажану основну адресу для однакових або дуже схожих сторінок, а не універсальний спосіб зупинити сканування. Google може вибрати іншу канонічну адресу.
Чи допоможе один лише robots.txt?
Він може обмежити сканування непотрібних варіантів URL, але сам по собі не гарантує, що вже відома адреса зникне з результатів Google. Перед змінами потрібно оцінити статус URL, які вже можуть індексуватися.
Висновок
Коли інтернет-магазин не зростає в органіці, проблема не завжди в браку статей чи зовнішніх посилань. Іноді пошуковому роботу доводиться обходити тисячі технічних варіацій замість того, щоб швидко знаходити корисні сторінки товарів і категорій.
Головний урок цього кейсу — спочатку визначити, які сторінки мають приносити пошуковий трафік, і лише потім керувати індексацією та перелінковкою. Універсального правила для всіх магазинів немає: рішення повинно випливати з аудиту, пошукового попиту й цілей бізнесу.
Офіційні джерела для перевірки технічних рішень
Google: керування скануванням URL фасетної навігації
Обговорення та запитання (0)
Поки що тут немає запитань або коментарів. Будьте першим, хто розпочне обговорення.