Filtry w sklepie internetowym to jedno z niewielu miejsc, gdzie jedna decyzja techniczna potrafi zmienić rozmiar witryny z tysiąca adresów na kilkaset tysięcy. Każdy dodany facet mnoży liczbę możliwych kombinacji, a Googlebot traktuje większość z nich jak osobne strony. Efekt: budżet indeksowania idzie na warianty, których nikt nie szuka, a kategorie z realnym popytem czekają w kolejce tygodniami.
Poniżej opisujemy model decyzyjny, który stosujemy w audytach: najpierw ustalamy, które kombinacje filtrów mają popyt, potem dobieramy do nich technikę (indeksacja, blokada, konsolidacja), a na końcu pilnujemy spójności linkowania wewnętrznego. Ta sama logika porządkowania adresów decyduje dziś także o tym, czy model językowy znajdzie w sklepie stronę, którą da się zacytować, co opisujemy w przewodniku o tym, jak firma trafia do wyników AI w 2026 roku.
Jak powstaje index bloat na filtrach
Mechanika jest kombinatoryczna. Kategoria z pięcioma facetami po sześć wartości generuje teoretycznie ponad siedem tysięcy kombinacji. Dodajmy do tego sortowanie (cena rosnąco, malejąco, popularność), paginację i parametry sesyjne, a liczba adresów rośnie wykładniczo. Sklep, który w panelu ma 800 produktów, może wystawić crawlerowi 300 000 URL-i.
Problem nie polega na tym, że Google tych adresów nie rozumie, tylko na tym, że musi je pobrać, żeby stwierdzić, że są bezwartościowe. Typowe objawy w Search Console:
- raport indeksowania pokazuje kilkadziesiąt tysięcy stron w stanie „Wykryta, obecnie niezaindeksowana”, prawie wyłącznie z parametrami w adresie,
- statystyki indeksowania pokazują, że 60 procent lub więcej żądań dotyczy adresów z pytajnikiem,
- nowe produkty i nowe kategorie czekają na pierwsze pobranie dwa tygodnie i dłużej,
- w wynikach pojawiają się warianty filtrowe zamiast kategorii nadrzędnej, często z gorszym tytułem i słabszym opisem.
Ostatni punkt jest najbardziej kosztowny: ruch, który powinien trafić na dopracowaną kategorię, rozsypuje się po przypadkowych kombinacjach filtrów.
Które kombinacje filtrów mają realny popyt
Zasada jest prosta: indeksujemy wyłącznie te strony filtrowe, które odpowiadają na zapytanie faktycznie wpisywane przez ludzi, z potwierdzonym wolumenem.
W praktyce popyt mają prawie zawsze pojedyncze facety, nie ich kombinacje. Ludzie szukają „buty trekkingowe damskie”, znacznie rzadziej „buty trekkingowe damskie wodoodporne rozmiar 38 kolor szary do 400 zł”. Z tego wynika reguła, od której zaczynamy każdy projekt:
| Typ strony filtrowej | Decyzja domyślna | Warunek odstępstwa |
|---|---|---|
| Jeden facet, wartość o potwierdzonym wolumenie (marka, płeć, typ, parametr techniczny) | Indeksować, własny tytuł i opis | Mniej niż 5 produktów w wyniku |
| Dwa facety, kombinacja z własnym zapytaniem (np. marka plus typ) | Indeksować wybiórczo, z listy ręcznej | Brak wolumenu w danych o zapytaniach |
| Trzy facety i więcej | Nie indeksować | Praktycznie nigdy |
| Cena, rozmiar, dostępność, kolor jako jedyny filtr | Nie indeksować | Kolor przy modzie, jeśli dane pokazują popyt |
| Sortowanie, widok listy, liczba produktów na stronie | Nigdy nie indeksować | Brak |
Listę kandydatów budujemy z czterech źródeł: raportu zapytań z Search Console (filtr po adresie kategorii), wyszukiwarki wewnętrznej sklepu, planera słów kluczowych oraz zapytań, na które już płacimy w kampaniach produktowych. To ostatnie źródło jest najbardziej niedoceniane, bo pokazuje zapytania z potwierdzoną intencją zakupową. Jeśli pracujecie z danymi kampanijnymi, warto przy okazji sprawdzić, czy sygnał konwersji w ogóle dociera do systemów reklamowych, o czym piszemy w tekście o utracie sygnału w Meta Ads i konfiguracji Conversions API.
Wynikiem tego etapu jest zamknięta lista: zwykle od 20 do 150 adresów filtrowych na sklep. Wszystko poza nią jest domyślnie zamknięte.
Parametry w adresie kontra ścieżki statyczne
Strony filtrowe, które chcemy indeksować, powinny mieć czysty, statyczny adres: /buty-trekkingowe/damskie/, nie /buty-trekkingowe/?plec=damskie&sort=cena. Adres statyczny łatwiej opisać, łatwiej do niego linkować i łatwiej odróżnić od szumu, bo cały ruch parametryczny można wtedy traktować jako jedną klasę do zablokowania.
Ścieżki statyczne mają haczyk: kolejność segmentów. Jeśli szablon dopuszcza zarówno /damskie/wodoodporne/, jak i /wodoodporne/damskie/, powstaje duplikat. Kolejność trzeba wymusić w kodzie, a wariant odwrotny przekierować kodem 301.
Pozostałe filtry, te nieindeksowane, najlepiej obsłużyć parametrami zapytania w jednej, przewidywalnej konwencji (jeden prefiks, na przykład ?f_), albo w ogóle poza adresem, czyli po stronie klienta bez zmiany URL-a. Drugie rozwiązanie jest najczystsze z punktu widzenia crawlu, ale trzeba pamiętać, że użytkownik traci wtedy możliwość udostępnienia wyniku filtrowania linkiem.
Robots.txt, noindex i canonical: co czym załatwić
To miejsce, w którym popełnia się najwięcej błędów, bo trzy mechanizmy wyglądają na wymienne, a rozwiązują różne problemy:
- Robots.txt blokuje pobranie. Googlebot nie wejdzie na adres, więc oszczędzamy budżet indeksowania. Nie zobaczy jednak znacznika noindex ani canonicala, bo nie przeczyta kodu strony. Dokumentacja Google opisuje to w wprowadzeniu do pliku robots.txt.
- Meta noindex pozwala pobrać stronę, ale usuwa ją z indeksu. Kosztuje crawl, za to działa pewnie i obsługuje przypadki, których nie da się opisać wzorcem w robots.txt.
- Canonical to tylko sugestia konsolidacji. Google traktuje go jako jeden z wielu sygnałów i regularnie ignoruje, zwłaszcza gdy treść strony filtrowej wyraźnie różni się od wskazanego celu.
Z tego wynika podział pracy, który sprawdza się w praktyce. Sortowanie, paginację parametryczną, parametry sesyjne i filtry techniczne blokujemy w robots.txt, bo to czysty, masowy szum opisany prostym wzorcem. Kombinacje facetów, które są potencjalnie sensowne, ale nie trafiły na naszą listę, dostają meta noindex razem z atrybutem follow, żeby linki do produktów nadal przenosiły sygnał. Strony z listy zostają w pełni otwarte i mają canonical wskazujący na siebie. Canonicala używamy do konsolidacji wyłącznie tam, gdzie treść jest praktycznie identyczna, na przykład przy wariancie adresu z odwróconą kolejnością segmentów, co Google opisuje w materiale o konsolidacji zduplikowanych adresów.
Jedna pułapka jest wyjątkowo częsta: blokada w robots.txt na adresach już zaindeksowanych. Taki adres zostanie w indeksie, często z opisem „Brak informacji o tej stronie”, bo Google nie może pobrać strony i odczytać noindexa. Kolejność jest więc istotna: najpierw noindex i odczekanie, aż adresy wypadną z indeksu, potem blokada pobierania.
Linkowanie do wybranych stron filtrowych
Decyzja o indeksacji bez zmiany linkowania zwykle nie działa: jeśli strona filtrowa ma rankować, musi być osiągalna zwykłym linkiem, a nie tylko przez interfejs filtra wymagający JavaScriptu. Praktyka, która daje najszybszy efekt: w każdej kategorii nadrzędnej umieszczamy blok z 5 do 12 linkami do wybranych podstron filtrowych, z naturalnym tekstem zakotwiczenia odpowiadającym zapytaniu („damskie buty trekkingowe”, „laptopy z 32 GB RAM”). Blok jest w treści, w HTML, nie w rozwijanym menu. Dodatkowo takie strony wchodzą do mapy witryny, a warianty nieindeksowane z niej wypadają.
Odwrotnie też warto być konsekwentnym: linki do kombinacji nieindeksowanych nie powinny być zwykłymi odnośnikami w kodzie. Jeśli facet obsługuje przycisk zmieniający widok bez przeładowania, crawler nie ma czego zbierać, a to najskuteczniejsza forma ograniczenia bloatu.
Treść na stronie filtra: ile wystarczy
Strona filtrowa nie potrzebuje artykułu. Potrzebuje czterech rzeczy: unikalnego tytułu i opisu meta, krótkiego akapitu wprowadzającego (60 do 120 słów) odpowiadającego na zapytanie, sensownego nagłówka H1 innego niż na kategorii nadrzędnej oraz listy produktów, która faktycznie coś zawiera.
Ten ostatni warunek jest twardy. Strona filtrowa z dwoma produktami to kandydat na „thin content” niezależnie od tego, jak dobry jest opis. Progiem, który stosujemy, jest minimum 5 produktów, a dla konkurencyjnych zapytań raczej 10 i więcej. Jeśli stan magazynowy spada poniżej progu, strona powinna automatycznie dostać noindexa, a nie zostać usunięta, bo asortyment zwykle wraca.
Dopisywanie bloków tekstu pod listingiem na zapas rzadko pomaga, a prawie zawsze pogarsza czas wczytywania. Strony filtrowe są na to wrażliwe, bo łączą zapytania bazodanowe z dużą liczbą obrazków. Jeśli listing ładuje się wolno na telefonie, warto zacząć od wydajności, a nie od treści: typowe przyczyny zebraliśmy w analizie dziewięciu powodów LCP powyżej 4 sekund na mobile.
Kontrola w logach i w raporcie indeksowania
Po wdrożeniu mierzymy trzy liczby, najlepiej w cyklu tygodniowym.
Udział żądań parametrycznych w logach serwera. To najszybszy wskaźnik. Liczymy, jaki procent żądań Googlebota trafia na adresy z pytajnikiem albo ze wzorcem zablokowanym w robots.txt. Przed porządkami bywa to 50 do 70 procent, po poprawnym wdrożeniu powinno zjechać poniżej 10 procent w ciągu dwóch do czterech tygodni.
Liczba adresów w stanach „Wykryta, obecnie niezaindeksowana” i „Zduplikowana, Google wybrał inny kanoniczny”. Oba powinny spadać. Jeśli pierwszy stan rośnie dalej, to znaczy, że gdzieś w szablonie został niezablokowany generator kombinacji, zwykle sortowanie albo paginacja wewnątrz filtra.
Czas do pierwszego pobrania nowego produktu. Najbardziej wymierna korzyść biznesowa. W sklepach, które porządkowały facety, widzieliśmy skrócenie tego czasu z 10–14 dni do 2–4 dni, bez żadnych zmian w linkach zewnętrznych.
Warto też pilnować, czy w wynikach nadal pojawiają się przypadkowe warianty filtrowe na zapytania brandowe i kategoryjne. Kanibalizację najłatwiej wyłapać, porównując, który adres Google wybiera dla tego samego zapytania w kolejnych tygodniach. Przy sklepach z lokalnymi punktami odbioru dochodzi warstwa sygnałów zewnętrznych, którą opisujemy w tekście o tym, ile ocen i jakiej treści potrzebuje lokalna firma.
Uwaga porządkowa na koniec: wszystkie te decyzje powinny być zapisane w jednym dokumencie, facet po facecie, z datą i uzasadnieniem. Po pół roku nikt nie pamięta, dlaczego filtr „kolor” jest zamknięty, a „marka” otwarty, i przy następnym wdrożeniu ktoś cofa cały układ jednym commitem. Rekomendacje Google zebrane są w dokumentacji Search Central o nawigacji fasetowej.
FAQ
Czy strony filtrowe mogą rankować lepiej niż kategoria nadrzędna?
Tak i jest to zjawisko pożądane, jeśli zapytanie jest węższe niż kategoria. Strona „damskie buty trekkingowe” powinna rankować na to zapytanie lepiej niż ogólna kategoria „buty trekkingowe”. Problem pojawia się tylko wtedy, gdy wariant filtrowy wypiera kategorię na zapytanie ogólne, co zwykle oznacza błąd w linkowaniu wewnętrznym albo brak dopracowanej treści na kategorii.
Czy blokada filtrów w robots.txt zaszkodzi rankingom kategorii?
Nie, o ile znacznik noindex nie jest jedynym mechanizmem wykluczenia na już zaindeksowanych adresach. Ryzyko polega na czymś innym: zbyt szerokim wzorcem można przypadkowo zablokować paginację kategorii albo zasoby CSS i JS. Każdą regułę trzeba przetestować w narzędziu do sprawdzania robots.txt na kilkunastu przykładowych adresach, w tym na tych, które mają zostać otwarte.
Ile stron filtrowych warto indeksować w średnim sklepie?
W sklepie z 500 do 5000 produktów zwykle od 20 do 150. Liczba wynika z danych o zapytaniach, nie z liczby możliwych kombinacji. Jeśli wychodzi kilka tysięcy, to znaczy, że na listę trafiły kombinacje bez potwierdzonego wolumenu.
Co zrobić z filtrem ceny?
Zostawić całkowicie poza indeksem i najlepiej poza adresem URL. Zapytania typu „laptopy do 3000 zł” istnieją, ale lepiej obsłużyć je dedykowaną stroną z własną treścią niż dynamicznym zakresem cenowym, który zmienia zawartość przy każdej aktualizacji cennika i szybko staje się nieaktualny.
Czy canonical ze strony filtrowej na kategorię rozwiązuje problem duplikacji?
Częściowo i niepewnie. Canonical jest sugestią, a nie dyrektywą, więc Google może go zignorować, jeśli uzna, że treść strony filtrowej jest inna. Dodatkowo nie oszczędza budżetu indeksowania, bo strona nadal musi zostać pobrana. Do masowego szumu właściwym narzędziem jest robots.txt, a do pojedynczych przypadków meta noindex.
Jak szybko widać efekt porządkowania facetów?
Spadek żądań parametrycznych w logach jest widoczny w ciągu 2–4 tygodni. Wypadanie starych adresów z indeksu trwa od 4 do 12 tygodni, zależnie od ich liczby. Poprawa czasu pierwszego pobrania nowych produktów pojawia się zwykle najszybciej, bo budżet uwalnia się niemal od razu po wdrożeniu blokad.