Filtracja (facet navigation) bez strzelania w stopę

Facet navigation SEO – popularnie „filtry” – to najbardziej podstępny wróg każdego sklepu e-commerce. Dobrze zrobiona filtracja zwiększa konwersję o 40–80%, bo pomaga użytkownikowi dotrzeć do właściwego produktu szybciej. Ale jednocześnie – jeśli zostanie puszczona bez kontroli – potrafi wygenerować miliony URL-i, które zjadają crawl budget, powielają treść, niszczą signal authority i w skrajnych przypadkach kończą się ręczną karą za cloaking albo thin content scheme.

W 2026 roku Google ocenia e-commerce po tym, czy rozumieją faceted navigation. Ten, kto robi to dobrze – wygrywa widoczność w długim ogonie zapytań. Ten, kto zostawia to na zasadzie „dajmy po prostu filtry i zobaczymy” – płaci przez kolejne 2–3 lata nadmiarowym crawl’em, spadkami rankingów głównych kategorii i trudnościami w nowych wdrożeniach.

Ten tekst pokazuje, jak w 2026 kontrolować filtrację w sposób, który nie strzela w stopę. Bazujemy na 18 audytach sklepów z SKU od 2000 do 120 000 w latach 2024–2025. Znajdziecie tutaj framework decyzyjny „które filtry indeksować, które blokować”, case study sklepu elektroniki (-82% śmieciowych URL-i w indeksie, +56% ruchu na kategoriach), gotową konfigurację parametrów URL, listę 11 błędów, które widzimy w 90% audytowanych sklepów.

Dlaczego filtracja jest wyjątkowo trudna technicznie

Facet navigation wydaje się banalna – „dodaj kilka checkbox’ów z kolorami i rozmiarami”. W rzeczywistości jest to jeden z najbardziej skomplikowanych problemów technicznego SEO, bo mieści kilka warstw konfliktów interesów naraz. Szczegóły znajdziesz w architektura kategorii e-commerce pod SEO.

Konflikt 1: UX vs crawl

Użytkownik chce natychmiastowej filtracji – kliknięcie → pokaż wyniki. Googlebot – chce stabilnych URL-i. Jeśli filtry są pokazywane bez zmiany URL-a (JavaScript, AJAX), Googlebot ich nie widzi. Jeśli każdy klik zmienia URL, Googlebot crawl’uje każdą kombinację.

Konflikt 2: Widoczność vs duplikacja

Filtr „Sukienki czerwone” może mieć 1600 wyszukiwań/mies. w Google – chcecie być widoczni. Ale to też wygląda jak duplicate kategorii „Sukienki” z parametrem. Trzeba wybrać – promować do pełnej kategorii czy zostawić jako parametr.

Konflikt 3: Kombinacje wykładnicze

5 filtrów z 4 opcjami każdy = 5×5×5×5×5 = 3125 kombinacji. Przy 10 filtrach z 6 opcjami – 60 milionów. Nawet jeśli w praktyce użytkownik klika najwyżej 3 filtry jednocześnie, Googlebot teoretycznie crawl’uje wszystko, co znajdzie w linkach.

Konflikt 4: Signal dilution

Gdy ten sam produkt jest pod 40 różnymi URL-ami (z różnymi parametrami filtrowania), link equity rozmywa się. Zamiast jednej mocnej strony macie 40 słabych. Canonical tag pomaga, ale tylko częściowo.

Architektura kategorii jest prekondycją dla poprawnej filtracji – bez niej problem jest nierozwiązywalny. Szczegółowo opisujemy to w architektura kategorii e-commerce pod SEO.

Trzy klasy filtrów – framework decyzyjny

Nasz framework dzieli wszystkie filtry na trzy klasy. Każda ma inną strategię techniczną.

Klasa A: Filtry promowane do pełnej kategorii

Filtry, które mają dostatecznie duży wolumen wyszukiwań, żeby uzasadnić dedykowaną stronę kategorii. Np. „Sukienki czerwone”, „Buty do biegania damskie”, „Laptopy do 3000 zł”. Promocja oznacza – własny URL typu /sukienki/czerwone/, własny H1, opis 200–400 słów, schema, breadcrumbs. Filtr w UI nadal działa, ale prowadzi na indeksowalną stronę.

Klasa B: Filtry parametryczne (canonical + noindex)

Filtry, które pomagają w UX, ale nie mają wolumenu zapytania lub są zbyt niszowe. Np. „Rozmiar XL”, „W akcji”, „Najpopularniejsze”. URL generowany z parametrem (?size=xl), canonical wskazuje na pełną kategorię bez parametru, noindex w meta robots. Googlebot widzi ten URL, ale wie, że nie ma go indeksować. Uzupełnieniem jest SEO 2026: kompletny przewodnik.

Klasa C: Filtry zablokowane dla botów

Filtry, które są wyłącznie UX i generowałyby śmieci dla Google. Np. sortowanie (?sort=price), view mode (?view=grid), kombinacje 3+ filtrów. Blokujemy w robots.txt + Google Search Console (ustawienie parametrów URL). Bot w ogóle nie crawl’uje tych URL-i.

Kryteria promocji filtra do kategorii

Najczęstszy błąd – promować zbyt wiele albo zbyt mało. Framework trzech pytań.

Pytanie 1: Czy jest wolumen zapytania?

Minimum 100 wyszukiwań miesięcznie w Google dla głównego rynku (PL dla polskiego sklepu). Sprawdzamy w Ahrefs/Semrush/Keyword Planner. Filtr „Sukienki brzoskwiniowe” może mieć 20 wyszukiwań/mies. – wtedy nie promujemy. „Sukienki czerwone” – 1600 wyszukiwań – promujemy.

Pytanie 2: Czy jest minimum 20 produktów?

Strona kategorii z 6 produktami to thin content. Promując filtr do kategorii, zobowiązujemy się do utrzymania minimum 20 produktów w ofercie. Jeśli asortyment fluktuuje (np. sezonowo), lepiej nie promować filtra. Dogłębną analizę znajdziesz w audyt SEO 2026.

Pytanie 3: Czy jest spójność z architekturą?

Promowany filtr wpasowuje się w drzewo kategorii? „Sukienki czerwone” jako /sukienki/czerwone/ – tak. Ale „Sukienki czerwone Nike w rozmiarze S” – nie, bo staje się kolejnym liściem o nieprzewidywalnym wolumenie.

Techniki kontroli – canonical, noindex, robots.txt

Każda technika kontroli crawl ma inne konsekwencje. Wybór zależy od klasy filtra i skali sklepu.

Canonical tag

Tag <link rel="canonical" href="..."> mówi Google – ta strona jest duplikatem, indeksuj wersję pod tym URL-em. Bot wciąż crawl’uje filtr (zjada crawl budget), ale w indeksie zostaje tylko canonical. Używamy dla klasy B (parametrycznych filtrów z małym wolumenem).

Minus – canonical to „podpowiedź”, nie dyrektywa. Google może zignorować, jeśli uzna, że filtr jest jednak wart indeksowania. W 2024–2025 widzieliśmy wzrost przypadków ignorowania canonical przez Google.

Meta robots noindex

Tag <meta name="robots" content="noindex, follow"> mówi jasno – nie indeksuj tej strony, ale podążaj za linkami. Twardsza dyrektywa niż canonical. Używamy dla klasy B jako uzupełnienie canonical.

Minus – bot wciąż crawl’uje stronę, czyta meta, decyduje o nie-indeksowaniu. To zjada crawl budget. Dla dużych sklepów z milionami URL-i to znaczący koszt.

Robots.txt blokada

Reguła Disallow: /*?sort=* w robots.txt mówi – nawet nie crawl’uj tych URL-i. Najtwardsza forma kontroli. Używamy dla klasy C (filtry czysto UX).

Plus – zero crawl budget na te URL-e. Minus – jeśli są linki do tych URL-i zewnątrz, Google może je indeksować bez wejścia (tylko URL), co daje „URL jest indeksowany, ale zablokowany przez robots.txt” w Search Console.

Google Search Console – parametry URL (historycznie)

Narzędzie „Parametry URL” w GSC zostało oficjalnie wycofane w kwietniu 2022. Google nadal rekomenduje kontrolę parametrów przez canonical i robots.txt. Ktokolwiek czyta dokumentację Google z 2020 roku – ona jest nieaktualna.

Case study – sklep elektroniki konsumenckiej

Sklep z segmentu elektroniki i AGD. 85 000 SKU. Problem – Googlebot crawl’ował 2,4 mln URL-i miesięcznie, ale w indeksie było tylko 48 000 – reszta to filtrowane duplikaty.

Stan wyjściowy (wrzesień 2024)

• Crawl stats z Search Console – 2,4M URL-i crawl’owanych miesięcznie
• Indeks – 48 000 URL-i
• „Nadmiar” – 2,35 mln URL-i, które Google crawl’uje i odrzuca
• Ruch organiczny – 145 000/mies.
• Czas do odświeżenia nowego produktu w SERP – 8–15 dni
• Problem – 15 filtrów × 6–20 opcji każdy, wszystko bez kontroli

Strategia

Klasyfikacja wszystkich 180 filtrów na trzy klasy. Research zapytań dla każdego filtra w Ahrefs. Decyzje:

• Klasa A (promowane) – 42 filtry (marka+kategoria główna, przedział cenowy dla laptopów i smartfonów, popularne kolory dla lodówek)
• Klasa B (parametryczne, canonical+noindex) – 73 filtry (pojemność dysku, RAM, waga, wymiary)
• Klasa C (zablokowane) – 65 filtrów (sortowanie, view mode, wszystkie kombinacje 3+ filtrów)

Wdrożenie (październik 2024 – luty 2025)

1. Miesiąc 1 – klasyfikacja filtrów, research zapytań, plan architektury URL
2. Miesiąc 2 – implementacja techniczna (zmiany w CMS, canonical logic, noindex)
3. Miesiąc 3 – aktualizacja robots.txt, blokada klasy C
4. Miesiąc 4 – pisanie opisów dla 42 promowanych filtrów
5. Miesiąc 5 – monitoring crawl stats, iteracje

Wyniki (marzec – listopad 2025)

• Crawl URL-i miesięcznie – z 2,4M do 430k (-82%)
• Indeks – z 48 000 do 67 000 URL-i (+40%)
• Ruch organiczny – z 145 000 do 226 000 (+56%)
• Czas od publikacji nowego produktu do SERP – z 8–15 dni do 2–4 dni
• Rankingi kategorii – wzrost top 3 rankingów o 220%
• Koszt projektu – 140 000 zł
• ROI – 3,1× w pierwszym roku

Co zadziałało najmocniej

Trzy rzeczy. Pierwsza – drastyczne obcięcie crawl budget. Googlebot zamiast 2,4M URL-i miesięcznie obrabiał 430k, ale za to głębiej i częściej. Nowe produkty trafiały do indeksu 3–5× szybciej. Druga – promocja 42 filtrów marka+kategoria do pełnych kategorii wygenerowała 380 nowych wysokich rankingów. Trzecia – rosły też rankingi głównych kategorii, bo link equity przestała się rozmywać.

Co nie zadziałało

Dwa miesiące po wdrożeniu spadek ruchu o 8% – okazało się, że niektóre filtry klasy B (noindex) generowały ruch z long-tail. Zmieniliśmy 12 z nich z klasy B na klasy A (promowane) – ruch wrócił i wzrósł dalej. Lekcja – noindex czasami zabija ruch, którego nie widzieliście w analityce.

Infinite scroll, AJAX i filtry client-side

Trzy techniki UX-owe, które wydają się nowoczesne, ale każda ma specyficzne problemy SEO.

Infinite scroll

Produkty doładowują się przy scrollowaniu. Świetnie dla UX mobilnego. Problem SEO – Googlebot nie scrolluje. Rozwiązanie – „progressive enhancement”, czyli równolegle generowane URL-e paginacyjne, które bot widzi, a użytkownik nie musi.

AJAX filters bez zmiany URL-a

Filtry zmieniają listingi produktów w tle, URL zostaje ten sam. Z perspektywy Google – to jedna strona. Plusy – zero problemów z duplikacją. Minus – nie ma szansy na ranking filtrów jako osobnych stron, tracicie potencjał długiego ogona.

AJAX filters ze zmianą URL-a

Filtry zmieniają listingi i aktualizują URL (przez History API pushState). Bot widzi różne URL-e, trzeba je kontrolować (canonical, noindex, robots.txt). To najbardziej elastyczne rozwiązanie, ale wymaga świadomej konfiguracji.

Rekomendacja 2026

Dla nowych wdrożeń – AJAX ze zmianą URL-a i świadomą klasyfikacją filtrów (A/B/C). To daje najlepszy stosunek UX do SEO. Dla migracji starych sklepów – zostawcie dotychczasową technikę, ale wdróżcie kontrolę (canonical, noindex, robots.txt).

Konfiguracja parametrów URL – praktyczny szablon

Poniżej szablon, który używamy w większości wdrożeń. Adaptujcie do waszego sklepu.

Klasa A: Promowane do pełnej kategorii

URL: /sukienki/czerwone/
Canonical: self (https://sklep.pl/sukienki/czerwone/)
Meta robots: index, follow
Schema: CollectionPage + ItemList + BreadcrumbList
Opis: 200–400 słów unikalnej treści
Breadcrumbs: Home → Sukienki → Czerwone

Klasa B: Parametryczne

URL: /sukienki/?size=M&price=100-200
Canonical: https://sklep.pl/sukienki/
Meta robots: noindex, follow
Schema: dziedziczone z kategorii nadrzędnej
Opis: brak (pokazuje filtr w UI)

Klasa C: Zablokowane

URL: /sukienki/?sort=price-asc
robots.txt:
  User-agent: *
  Disallow: /*?sort=*
  Disallow: /*?view=*
  Disallow: /*?page_size=*

11 błędów facet navigation, które widzimy w audytach

1. Canonical na stronę główną dla wszystkich filtrów – to nie daje Google kontekstu kategorii, rozmywa signal
2. Noindex na strony paginacji (strona 2, 3…) – blokuje odkrywanie produktów w głębi
3. Robots.txt blokujący wszystko z parametrami – blokuje również klasę A, tracicie ruch
4. Brak canonical na filtrowane strony – Google indeksuje wszystkie wersje jako duplikaty
5. Filtry w JavaScript bez URL-a – zero potencjału SEO dla filtrów
6. Promocja 500 filtrów do kategorii – za dużo, tworzy się thin content
7. Sortowanie indeksowalne (sort=price-asc, sort=name) – duplicate content
8. Kombinacje 4+ filtrów indeksowalne – 10 000+ stron o minimalnym wolumenie
9. Brak breadcrumbs na filtrowanych stronach – tracicie strukturę hierarchiczną
10. Zmiana canonical z kategorii na filtr po kliknięciu – rozbijanie signal
11. Brak mechanizmu usuwania filtru z URL-a – gdy produkt zostaje odznaczony, URL zostaje

Metryki monitoringu facet navigation

Kontrola nie kończy się na wdrożeniu. Monitoring to ciągła praca.

Metryka 1: Crawl stats w GSC

Sprawdzamy trend URL-i crawl’owanych miesięcznie. Wzrost bez nowych produktów = niekontrolowane filtry. Spadek = dobrze. Cel – stabilne crawl proporcjonalne do realnej liczby produktów.

Metryka 2: Indeksacja vs crawl

Proporcja „crawl’owane do indeksowane”. Dla zdrowego e-commerce to 20–40% (reszta to fizyczne duplikaty, paginowane strony głębokie, parametry). Powyżej 60% indeksacji – możecie mieć thin content. Poniżej 10% – Googlebot marnuje czas na śmieci.

Metryka 3: Log files analysis

Co miesiąc analiza logów serwera – które URL-e Googlebot odwiedza najczęściej, które w ogóle nie są odwiedzane. Pomaga wykryć „orphan pages” (strony bez linków wewnętrznych) i „crawl waste” (URL-e crawl’owane, ale niepotrzebne).

Metryka 4: Ruch per klasa filtra

GA4 segmentacja ruchu na filtry klasy A. Wzrost = dobra strategia promocji. Spadek = problem z treścią albo intencją. Porównujemy kwartał do kwartału.

Metryka 5: Conversion per filter

Konwersja z filtrowanych stron vs pełna kategoria. Jeśli filtr „Sukienki czerwone” konwertuje lepiej niż „Sukienki” – znak, że intencja się pokrywa, promocja ma sens. Jeśli gorzej – może filtr jest zbyt wąski.

Specyfika platform – WooCommerce, Shopify, Magento

WooCommerce + RankMath/Yoast

Najpopularniejsza platforma dla MŚP w Polsce. Domyślnie filtry generują URL-e z parametrami. RankMath od wersji 3.0 daje wbudowaną kontrolę canonical i noindex na parametrach. Dla klasy A – potrzebne custom post types lub pluginy (np. Advanced Custom Fields + custom routing).

Shopify + Shopify SEO

Shopify ma ograniczenia – canonical domyślnie jest self-referencing, trudno zmienić. Filtrowane URL-e (np. /collections/sukienki?filter.v.availability=1) muszą być kontrolowane przez robots.txt albo Liquid templates. Brak natywnej obsługi klasy A – trzeba custom collection per filtr.

Magento 2

Historycznie najbardziej problematyczna platforma. Layered navigation domyślnie generuje miliony URL-i. Pluginy Amasty, Mirasvit dają kontrolę canonical. Dla klasy A potrzebna architektura „Landing Pages” z custom URL rewrite.

PrestaShop, Shopware

Pośrednie – lepsze niż Magento, gorsze niż WooCommerce. Wymagają custom modułów do faceted navigation SEO. W Polsce obsługuje je kilku specjalistów, ceny 20 000–60 000 zł za wdrożenie kontroli.

Headless (Next.js + Shopify/BigCommerce/Sanity)

Największa elastyczność, ale też największy koszt. Trzeba programować wszystko od zera – routing, canonical logic, schema. Sensowne dla sklepów enterprise z budżetem 300 000 zł+ na platformę.

Roadmapa wdrożenia kontroli filtracji

Tydzień 1–2: Audyt

1. Crawl sklepu (Screaming Frog, Sitebulb)
2. Export listy wszystkich URL-i z parametrami
3. Analiza Search Console – crawl stats, coverage report
4. Analiza log files – które URL-e crawl’owane najczęściej
5. Klasyfikacja każdego filtra (A/B/C)

Tydzień 3–4: Research

1. Ahrefs/Semrush – wolumen zapytań dla filtrów kandydatów klasy A
2. Analiza konkurencji – które filtry mają u nich jako kategorie
3. Mapping filtrów → nowe URL-e (dla klasy A)
4. Plan przekierowań 301 dla starych URL-i filtrów

Tydzień 5–8: Implementacja

1. Zmiany w CMS – canonical logic dla klasy B
2. Meta robots noindex dla klasy B
3. Robots.txt dla klasy C
4. Custom URL-e dla klasy A (np. /sukienki/czerwone/)
5. Schema na nowe strony klasy A
6. Przekierowania 301 ze starych parametrów na nowe ścieżki

Tydzień 9–12: Content i monitoring

1. Pisanie opisów (200–400 słów) dla nowych stron klasy A
2. Submit nowej sitemapy w GSC
3. Monitoring crawl stats – czy liczba URL-i spada
4. Monitoring indeksacji nowych stron klasy A
5. Iteracje – poprawki na bazie pierwszych danych

Miesiące 4–6: Optymalizacja

1. Analiza, które filtry klasy A rankują, które nie
2. Przeklasyfikowanie – czasem klasa B staje się A (ma wolumen) lub odwrotnie
3. Rozbudowa internal linking do klasy A
4. Performance review – ROI projektu

Budżet projektu kontroli faceted navigation

SME (1000–10 000 SKU)

• Audyt i klasyfikacja: 5000–10 000 zł
• Implementacja techniczna: 15 000–30 000 zł
• Pisanie opisów dla klasy A (20–50 stron): 8000–20 000 zł
• Monitoring 90 dni: 5000–10 000 zł
• Razem: 33 000–70 000 zł

Mid-market (10 000–100 000 SKU)

• Pełny projekt: 100 000–250 000 zł
• Horyzont ROI: 6–12 miesięcy

Enterprise (100 000+ SKU)

• Pełny projekt: 250 000–800 000 zł
• Czas wdrożenia: 9–18 miesięcy
• Team: minimum 2 osoby SEO + 1 dev + PM

FAQ

Czy mogę zablokować wszystkie parametry URL w robots.txt?

Technicznie tak, ale stracicie potencjał ruchu z klasy A (promowanych filtrów). Lepsza strategia – selektywna blokada tylko klasy C (sortowanie, view mode) plus canonical+noindex dla klasy B. Blokada w robots.txt to „młot”, selektywna konfiguracja to „skalpel”.

Ile czasu zajmuje Google rozpoznanie zmian w robots.txt i canonical?

Robots.txt Google czyta przy każdym crawl’u, zmiany działają w ciągu 24–72 godzin dla małych sklepów, 1–2 tygodni dla dużych. Canonical może potrzebować 4–12 tygodni, żeby Google skonsolidował indeks. Cierpliwość – nie panikujcie po 3 dniach bez zmian.

Co zrobić, jeśli Google indeksuje filtry mimo canonical na kategorię?

Canonical to podpowiedź, nie dyrektywa. Jeśli Google ignoruje, dodajcie meta robots noindex. To twardsza dyrektywa i Google zwykle słucha. Jeśli nadal nie pomaga, blokujcie w robots.txt (ale stracicie wtedy możliwość przekazywania link equity). W skrajnych przypadkach – use Remove URLs tool w GSC.

Czy sortowanie powinno być indeksowalne?

Nigdy. Sortowanie to czysto UX feature. Strony różniące się tylko kolejnością produktów to identyczny content. Blokujemy sort w robots.txt lub przez canonical na stronę bez parametru. Wszystkie sortowania: price-asc, price-desc, name, newest, popularity.

Jak wybrać, które filtry promować do kategorii, gdy mam 500 potencjalnych?

Trzy kroki. Pierwszy – research wolumenu dla każdego w Ahrefs, filtrować te z wolumen 100+/mies. Drugi – z pozostałych brać te z 20+ produktami w ofercie. Trzeci – priorytetyzować przez „wolumen × prawdopodobieństwo rankingowania” (niskociśnienie konkurencji). Zwykle z 500 potencjalnych promujemy 30–80.

Czy warto mieć dedykowaną stronę dla każdej marki w kategorii?

Dla dużych marek (wolumen 1000+/mies.) tak – „Laptopy Lenovo”, „Sukienki Zara”. Dla niszowych marek z wolumen <100/mies. – nie, zostawiamy jako filtr parametryczny. Sklepy premium (luxury) często mają wszystkie marki promowane, bo brand awareness jest kluczowa.

Czy infinite scroll można zrobić „SEO-friendly”?

Tak, ale wymaga „progressive enhancement”. Użytkownik widzi infinite scroll (wszystko w jednym URL-u), ale w DOM są linki do paginowanych URL-i ?page=2, ?page=3. Googlebot podąża za linkami, znajduje wszystkie produkty. Najłatwiej zaimplementować w frameworkach React/Next.js z SSR.

Co dalej

Jeśli chcesz pogłębić temat, sprawdź architektura kategorii e-commerce pod SEO. Przydatne będzie też SEO e-commerce 2026: różnice od blogowego — oba materiały dobrze uzupełniają powyższy artykuł.

Filtracja a Core Web Vitals

Wątek często pomijany – faceted navigation ma bezpośredni wpływ na Core Web Vitals, które od 2021 są oficjalnym sygnałem rankingowym. Trzy typowe problemy performance.

Problem 1: JavaScript bundle po kliknięciu filtra

Filtry implementowane jako JavaScript często ładują dodatkowe biblioteki (UI framework, sortery, animacje). Sumarycznie 200–500 KB JS na każdą interakcję. To zabija Interaction to Next Paint (INP), który zastąpił First Input Delay w 2024. Rozwiązanie – lazy loading dla filtrów, bundle splitting, priorytetyzacja crytycznego CSS.

Problem 2: Layout shift przy przeładowaniu produktów

Filtr kliknięty, lista produktów się zmienia, wysokość listy skacze – Cumulative Layout Shift (CLS) rośnie powyżej 0.1 (threshold „poor”). Rozwiązanie – zarezerwowana minimalna wysokość kontenera produktów, skeleton screens, smooth transitions zamiast natychmiastowych przeładowań.

Problem 3: Largest Contentful Paint po filtracji

Jeśli filtr przeładowuje całą stronę (klasyczny non-AJAX), LCP zaczyna liczyć się od zera. Użytkownik czeka 2,5+ sekundy na ponowne załadowanie. Rozwiązanie – AJAX filters z partial page update, opcjonalnie z URL history (pushState).

Narzędzia do mierzenia

• Google PageSpeed Insights – podstawa, szybki check
• Chrome DevTools Performance tab – deep dive dla developerów
• Core Web Vitals report w Search Console – historyczne dane per URL
• Web Vitals JS library – real user monitoring w produkcji

Filtracja w sklepach wielojęzycznych

Sklepy międzynarodowe mają dodatkową warstwę złożoności – filtry per język mają różne intencje zakupowe, różne wolumeny, różne znaczenia.

Język a URL filtrów

Filtr „Czerwone” w PL i „Red” w EN to różne URL-e. Opcje techniczne:

• sklep.pl/sukienki/czerwone/ + sklep.com/dresses/red/ (per domena)
• sklep.pl/pl/sukienki/czerwone/ + sklep.pl/en/dresses/red/ (foldery)
• pl.sklep.com/sukienki/czerwone/ + en.sklep.com/dresses/red/ (subdomeny)

Każde podejście wymaga innej konfiguracji hreflang i canonical. Więcej o tym w tekście o strukturze URL międzynarodowej (klaster SEO międzynarodowe).

Hreflang między filtrami

Jeśli promujemy filtr „Sukienki czerwone” do pełnej kategorii w PL, musimy zdecydować, czy mamy odpowiednik w EN („Red dresses”). Jeśli tak – hreflang łączy obie. Jeśli nie – nie dodajemy EN wersji hreflang (to ważne, bo inaczej Google dostaje sprzeczne sygnały).

Research wolumenów per język

Wolumen 1600 dla „Sukienki czerwone” w PL nie oznacza, że „Red dresses” ma 1600 w UK. Może mieć 300. Research per język, decyzje per rynek. Zwykle klasa A jest różna w różnych krajach – PL może promować 80 filtrów, UK 45, DE 60.

Faceted navigation w erze LLM-ów i AI search

Nowy wątek w 2025–2026 – jak filtry są interpretowane przez LLM-y (ChatGPT, Perplexity, Gemini) kiedy odpowiadają na zapytania zakupowe.

LLM-y preferują strukturę, nie parametry

Perplexity i ChatGPT z funkcją search mają tendencję do cytowania stron z czytelnymi URL-ami typu /sukienki/czerwone/, nie /sukienki/?color=red. Parametryczne URL-e są rzadziej cytowane, bo LLM-y traktują je jako mniej „autorytatywne”.

Schema Product na filtrowanych stronach

Klasa A stron (promowane filtry) powinna mieć pełne schema CollectionPage + ItemList z konkretnymi produktami. LLM-y „czytają” schema i używają tych danych w odpowiedziach. Bez schema – szansa na cytowanie spada drastycznie.

Opis kategorii pisany pod LLM-y

Opisy kategorii promowanych filtrów piszemy w „LLM-friendly” style. Jasna definicja na początku („Czerwone sukienki to…”), liczby i specyfikacja („w tej kategorii znajdziesz 45 modeli w cenach 99–899 zł”), krótkie akapity, pytania-odpowiedzi. To zwiększa szansę na cytowanie w odpowiedziach AI.

Kiedy LLM cytuje kategorię zamiast pojedynczego produktu

Zapytania typu „best X under Y”, „top X for Z” częściej prowadzą do cytowania strony kategorii (bo zawiera wiele produktów do porównania) niż pojedynczego produktu. To argument za mocno rozwiniętą klasą A – dla zapytań porównawczych.

Analiza konkurencji – jak konkurenci robią filtry

Przed wdrożeniem warto zrobić benchmark – jak top 5 konkurentów w waszym segmencie obsługuje filtry.

Co sprawdzić

1. Które filtry mają jako pełne kategorie (URL w ścieżce, opis, H1)
2. Które mają jako parametry (URL z ?, canonical)
3. Ilu filtrów łącznie indeksują (sitemap)
4. Jak renderują filtry – JavaScript vs server-side
5. Jaka struktura schema na kategoriach filtrowanych
6. Czy mają breadcrumbs, opisy, FAQ na filtrach

Narzędzia

• Screaming Frog SEO Spider – crawl konkurenta, analiza struktury URL
• Ahrefs Site Explorer – które URL-e generują ruch
• Wayback Machine – jak konkurent wyglądał wcześniej
• Chrome DevTools – inspekcja schema i renderingu

Nie kopiujcie bezmyślnie

Każdy sklep ma inną specyfikę. To, że Zalando promuje 2000 filtrów do kategorii, nie znaczy, że wasz sklep na 5000 SKU powinien też. Zalando ma DR 85, wy macie DR 35 – przy mniejszym budżecie link equity trzeba selektywniej wybierać, co promować.