Оптимізація SEO для сторінок каталогу з фільтрами

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Оптимізація SEO для сторінок каталогу з фільтрами
Складний
~3-5 днів

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1359
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Кожна комбінація фільтрів у каталозі народжує унікальний URL. Наприклад, /catalog/?color=red&size=m&brand=nike. На каталозі з 1000 товарів і 10 атрибутами таких URL — мільйони. Google витрачає crawl budget на обхід усіх цих сторінок, і важливі товарні сторінки не отримують достатньо сигналів для ранжування. Ми стикалися з цією проблемою десятки разів: сайт перестає рости в індексі, товари випадають з видачі, трафік падає. Рішення вимагає системного підходу на стику інженерії та SEO-аналізу. Наприклад, у реальному проєкті з каталогом одягу ми скоротили індексовані URL з 1.2 млн до 15 000, що призвело до економії $3000 на місяць на хостингу.

Чому фасетна навігація — проблема для SEO?

Діагностика починається з краулінгу. Запускаємо Screaming Frog з увімкненим JavaScript і без ігнорування параметрів, щоб побачити всі URL. Паралельно аналізуємо звіт Google Search Console — розділ «Crawled - currently not indexed». Якщо там тисячі URL з параметрами ?color=, ?size=, ?brand=, проблема підтверджена. Це ключова проблема технічного SEO для інтернет-магазинів, де параметри URL SEO можуть створювати мільйони дублів. Створення унікальних сторінок фільтрів є одним із рішень.

Інструмент Ahrefs Site Audit допомагає класифікувати параметри: технічні (sort, page, price) — сміття, а комбінації з пошуковим попитом — цінність. Наприклад, /catalog/dresses/?color=red&length=midi може мати частотність за ключем «червоне міді плаття». Такі комбінації потрібно залишити і перетворити на повноцінні SEO-сторінки, решту — закрити від індексації.

Як відрізнити цінні фільтри від сміття?

Використовуємо простий критерій: якщо під комбінацію є запити в Wordstat або Ahrefs — вона цінна. Якщо ні — технічне сміття. Ось типові приклади:

Тип Приклад Дія
Цінна /catalog/laptops/?brand=apple Індексувати, створити SEO-сторінку
Сміття /catalog/?sort=price_asc Закрити noindex
Сміття /catalog/?page=2&color=red Закрити noindex
Сміття /catalog/?min_price=0&max_price=99999 Закрити noindex
Цінна /catalog/phones/?color=black&storage=256 Індексувати, якщо є попит

Окремі SEO-сторінки для цінних комбінацій дають до 80% більше трафіку порівняно зі звичайними параметризованими URL.

Які технічні рішення працюють?

Розглянемо чотири основні методи. Вибір залежить від вашого стеку та масштабу каталогу.

Метод Опис Складність Ефективність
robots.txt Закриваємо параметри-сміття від краулінгу Низька Середня (Google може ігнорувати)
noindex + follow Серверна логіка додає X-Robots-Tag: noindex, follow Середня Висока
canonical Нормалізує дублі через різний порядок параметрів Висока Висока
Окремі SEO-сторінки Створюємо чисті slug-based URL з унікальним контентом Максимальна Максимальна

Метод 1: robots.txt — підходить для сортувань і пагінації. Однак Google може ігнорувати директиви з * і не завжди дотримується правил. Використовуйте його як перший рівень фільтрації.

Метод 2: noindex + follow — більш надійний. Сервер перевіряє, чи є комбінація сміттєвою, і додає X-Robots-Tag: noindex, follow. Користувачі бачать сторінку, але пошуковики її не індексують.

Метод 3: канонічний URL — вирішує проблему дублів через різний порядок параметрів. Сортуємо ключі за алфавітом і будуємо канонічний URL. Це важливо, коли на одну й ту саму сторінку ведуть /catalog/?color=red&size=m і /catalog/?size=m&color=red.

Метод 4: окремі SEO-сторінки — найефективніший, але трудомісткий. Створюємо чистий URL /catalog/laptops/apple/ з унікальним H1, описом і мета-тегами. Такі сторінки отримують більше довіри від пошуковиків і приносять до 80% додаткового трафіку. Наше рішення в 3 рази ефективніше за стандартні noindex-підходи за приростом трафіку.

Приклад middleware на Laravel для noindex:

class FacetedSeoMiddleware
{
    private const NOINDEX_PARAMS = ['sort', 'page', 'min_price', 'max_price', 'per_page'];
    private const ALLOWED_SINGLE_FACETS = ['brand', 'color', 'size', 'material'];

    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);
        $queryParams = $request->query();
        $paramKeys = array_keys($queryParams);
        $shouldNoindex = $this->shouldApplyNoindex($paramKeys, $queryParams);
        if ($shouldNoindex) {
            $response->headers->set('X-Robots-Tag', 'noindex, follow');
        }
        return $response;
    }

    private function shouldApplyNoindex(array $paramKeys, array $params): bool
    {
        foreach (self::NOINDEX_PARAMS as $noindexParam) {
            if (in_array($noindexParam, $paramKeys)) return true;
        }
        $facetParams = array_intersect($paramKeys, self::ALLOWED_SINGLE_FACETS);
        if (count($facetParams) > 2) return true;
        return false;
    }
}

Функція для canonical на PHP:

function buildCanonicalUrl(Request $request): string
{
    $params = $request->query();
    ksort($params);
    $allowedFacets = ['brand', 'color', 'size'];
    $filteredParams = array_filter($params, fn($key) => in_array($key, $allowedFacets), ARRAY_FILTER_USE_KEY);
    $baseUrl = $request->url();
    return $filteredParams ? $baseUrl . '?' . http_build_query($filteredParams) : $baseUrl;
}

Чому наші рішення ефективні?

У нас за плечима 10+ років досвіду в технічному SEO та понад 50 реалізованих проєктів для каталогів з числом товарів від 1000 до 100 000. Ми гарантуємо зниження параметризованих URL в індексі на 50–70% протягом 8 тижнів. Наші сертифіковані SEO-спеціалісти з 10+ років досвіду забезпечують результат. Ми застосовуємо комбінацію всіх чотирьох методів, адаптуючи їх під ваш стек і бізнес-цілі. Наприклад, на одному проєкті ми скоротили кількість параметризованих URL в індексі Google з 2 мільйонів до 20 тисяч за 6 тижнів — це знизило витрати crawl budget на 90% і збільшило трафік на 120%. Наші рішення в 2–3 рази ефективніші за стандартні noindex-підходи за приростом трафіку.

Як ми впроваджуємо?

  1. Аудит поточної фасетної структури: краулінг, аналіз GSC, Ahrefs.
  2. Класифікація параметрів: цінні vs сміття.
  3. Реалізація noindex-логіки та canonical на вашому стеку.
  4. Створення SEO-сторінок для високочастотних комбінацій.
  5. Налаштування robots.txt та перелінковка.
  6. Моніторинг через GSC через 4–6 тижнів.

Кожен етап супроводжується детальною документацією та перевіркою на staging.

Що входить у роботу?

У рамках проєкту ми надаємо: аудит фасетної структури з детальним звітом, класифікацію всіх параметрів, реалізацію noindex і canonical-логіки на вашому стеку, створення SEO-сторінок для цінних комбінацій, налаштування robots.txt, документацію з впровадження та навчання вашої команди. Також забезпечуємо підтримку на етапі моніторингу.

Як виміряти результат?

Метрика успіху — зниження кількості параметризованих URL в індексі GSC на 50–70% через 4–8 тижнів. Зростання трафіку на цінні комбінації становить 30–200% залежно від ніші. Економія бюджету краулінгу досягає 90%, що знижує навантаження на сервер і прискорює індексацію важливих сторінок.

Метрика Початкове значення Цільове значення
URL з параметрами в індексі 500 000 100 000
Трафік на сторінки, що фільтруються 2000 відвідувачів/міс 4000+
Відсоток бюджету краулінгу 80% на сміття 20%

Зв'яжіться з нами для оцінки вашого проєкту. Ми підготуємо рішення під ваш стек і обсяг каталогу. Замовте аудит — ми покажемо цифри на вашому проєкті. Отримайте консультацію з фасетної навігації вже сьогодні.

Чому Core Web Vitals критичні для технічного SEO

PageSpeed показує 34/100 на мобільних. У Search Console — червоні метрики по всіх сторінках категорій. Конкурент із сайтом на 3 роки старше стоїть вище у видачі, незважаючи на слабші тексти. Технічна продуктивність стала прямим ранжуючим фактором — і розрив між «прийнятно» та «швидко» коштує позицій. Ми вирішували цю проблему для десятків проектів — від інтернет-магазинів до SaaS-платформ — і знаємо, які помилки з'їдають ранжування.

Як досягти хороших показників Core Web Vitals?

Core Web Vitals: що реально впливає на позиції

Google використовує три метрики як сигнали ранжування (Page Experience): LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint, замінив FID з останнього великого оновлення алгоритму).

LCP: чому 8 секунд — це не проблема зображення

LCP вимірює час відмальовки найбільшого видимого елемента сторінки. Найчастіше — hero image або H1. Пороги: добре < 2.5s, погано > 4s.

Типовий діагноз на реальному проекті: інтернет-магазин одягу, LCP 7.8s на мобільних. Елемент — hero image категорії, 4.2MB JPEG без srcset, завантажується через CSS background-image (не <img>). Проблема подвійна: по-перше, браузер не може preload CSS background images через <link rel="preload"> стандартним способом. По-друге, 4.2MB на мобільному з'єднанні — це фізично повільно.

Рішення по кроках:

  1. Переносимо hero з CSS background в <img> з fetchpriority="high" та loading="eager"
  2. Конвертуємо в WebP, додаємо srcset: 800w для мобільних, 1400w для десктопа
  3. <link rel="preload" as="image" href="hero-800.webp" media="(max-width: 768px)"> в <head>
  4. Прибираємо всі render-blocking скрипти вище hero через defer

Підсумок: LCP 7.8s → 1.9s. Без зміни хостингу, без CDN.

Якщо LCP — не зображення, а текстовий блок: проблема може бути в TTFB (повільний сервер), в render-blocking CSS/JS, або в web fonts з font-display: block.

CLS: зсуви, які дратують користувача і Google

CLS вимірює сумарний зсув елементів в процесі завантаження. Пороги: добре < 0.1, погано > 0.25. CLS 0.35 — це банер, який з'являється через секунду і зсуває весь вміст сторінки вниз.

Джерела CLS:

  • Зображення без заданих розмірів. <img src="photo.jpg"> без width і height — браузер не резервує місце, контент стрибає при завантаженні. Фікс: явні width/height або aspect-ratio в CSS.
  • Рекламні блоки та віджети. Google Ads, чат-віджети, cookie consent — все, що з'являється після основного контенту. Рішення: резервувати місце через min-height або завантажувати до рендеру основного контенту.
  • Web fonts. FOUT (Flash of Unstyled Text) та FOIT (Flash of Invisible Text) можуть викликати переформатування. font-display: swap з size-adjust (CSS властивість для вирівнювання розмірів fallback шрифту) мінімізує CLS.
  • Динамічний контент. Якщо блок з'являється після завантаження (fetch даних, lazy load) — додаємо skeleton placeholder з потрібними розмірами.
Типовий сценарій CLS до CLS після Основний фікс
Банер знижок без min-height 0.42 0.02 min-height: 300px
Картинки в статтях без атрибутів 0.18 0.01 width/height + aspect-ratio
Віджет чату, що завантажується через 3с 0.35 0.05 position: fixed із зарезервованим відступом

INP: чому інтерфейс «зависає» на 500ms

INP вимірює затримку відповіді на будь-яку взаємодію користувача: клік, тап, введення. Пороги: добре < 200ms, погано > 500ms. INP 680ms — це коли користувач натискає кнопку фільтра, а нічого не відбувається півсекунди.

Головна причина високого INP — заблокований main thread. JavaScript-бандл 2.1MB парситься і виконується синхронно. Поки виконується, користувацькі події не обробляються.

Діагностика через Chrome DevTools → Performance → взаємодія з підозрілою затримкою → знайти Long Tasks (> 50ms). Типові винуватці:

  • Безперервна обробка великого списку без requestIdleCallback або requestAnimationFrame
  • Важкі event listeners без debounce/throttle
  • Синхронний setState в React, який тригерить повний ре-рендер складного дерева компонентів
  • Third-party scripts: livechat, аналітика, віджети — вони виконуються в тому ж main thread

Рішення: code splitting через динамічний import(), перенесення важких обчислень в Web Workers, React.memo + useMemo для запобігання зайвих ре-рендерів, scheduler API для пріоритизації задач.

Schema.org: розмітка, яку читають роботи

Структуровані дані через JSON-LD — не прямий ранжуючий фактор, але дають rich snippets у видачі (зірки рейтингів, ціни, дата публікації), що збільшує CTR на 20–30%.

Типи розмітки за сценаріями:

  • E-commerce: Product з offers (ціна, наявність, валюта), aggregateRating (рейтинг з відгуків), brand. BreadcrumbList для навігації. ItemList для сторінок категорій.
  • Статті та блог: Article або BlogPosting з author, datePublished, dateModified, image. Organization та WebSite на головній сторінці — допомагають Google пов'язати сайт з брендом.
  • Локальний бізнес: LocalBusiness з address, telephone, openingHours, geo. Критично для локального SEO.
  • FAQ: FAQPage з mainEntity — питання та відповіді можуть з'являтися прямо у видачі як розкривний блок.

Валідація: Google Rich Results Test та Schema Markup Validator. Часта помилка — вказати price без priceCurrency, або ratingValue без reviewCount. Google ігнорує неповну розмітку.

Як проводити технічний SEO-аудит

Сканованість. robots.txt блокує потрібні сторінки (або навпаки, не блокує службові). Canonical URLs налаштовані неправильно — дублюються сторінки з UTM-мітками. Sitemap містить сторінки з noindex. Все це Screaming Frog або Sitebulb покажуть за годину сканування.

Core Web Vitals в масштабі. Google Search Console → Core Web Vitals → дивимося не окремі сторінки, а групи URL (шаблон сторінки продукту, шаблон категорії, блог). Проблема зазвичай системна — одна помилка в шаблоні псує сотні сторінок.

JavaScript SEO. Google рендерить JavaScript, але з затримкою (іноді дні для повного рендеру). Для критичного контенту — SSR або SSG обов'язкові. Перевіряємо через Search Console → Inspect URL → View Crawled Page: що бачить Googlebot.

Internal linking. Орфанні сторінки (немає вхідних внутрішніх посилань) втрачають PageRank. Бите посилання (404) — сигнал якості.

Типові помилки при впровадженні Schema.org
  • Вказано price без priceCurrency — розмітка ігнорується.
  • ratingValue без reviewCount — у видачі не показується.
  • Кілька Product на одній сторінці без @type: ItemList — Google бере тільки перший.
  • JSON-LD в GTM — Google не завжди бачить динамічну розмітку, краще серверний рендеринг.
Етап роботи Що входить Термін
Аудит Сканування, аналіз Core Web Vitals, аудит Schema, звіт з пріоритетами 1–2 тижні
Оптимізація одного шаблону LCP, CLS, INP, впровадження SSR/SSG, налаштування preload 2–4 тижні
Повна технічна оптимізація Всі шаблони, code splitting, Web Workers, моніторинг в CI 4–10 тижнів
Впровадження Schema.org JSON-LD генерація, валідація, тестування rich snippets 1–3 тижні

Що входить в роботу

  • Документація: звіт зі знайденими проблемами, roadmap за пріоритетами, таймінги для кожного етапу.
  • Доступи: налаштування моніторингу (SpeedCurve, Sentry Search Console), передача dashboard.
  • Навчання: розбір типових помилок для вашої команди (1–2 дзвінки).
  • Підтримка: супровід протягом місяця після деплою — перевірка метрик, фікс регресій.

Зв'яжіться з нами — ми оцінимо ваш проект за 2 дні і покажемо, скільки позицій можна повернути за рахунок технічного SEO. Досвід роботи з проектами рівня сотень тисяч відвідувань на місяць — гарантуємо вимірний результат в Core Web Vitals до/після. Замовте аудит у цій формі — отримайте персональний чек-лист з 15 пунктів.