Filtry, tagi i parametry: Zwalczanie kanibalizacji w dużych sklepach e-commerce

Duży sklep rzadko przegrywa SEO jednym błędem. Częściej przegrywa tysiącami małych adresów, które wyglądają niewinnie: filtr koloru, rozmiar, sortowanie po cenie, widok siatki, parametr kampanii, wariant produktu. Z perspektywy użytkownika to wygoda. Z perspektywy Google — potencjalnie osobne URL-e, osobne sygnały, osobne decyzje o crawlowaniu i indeksowaniu.

Najgorszy scenariusz wygląda tak: główna kategoria „buty trekkingowe” ma 60 marek, 12 rozmiarów, 8 kolorów, 5 zakresów cen, 4 sposoby sortowania i kilka tagów sezonowych. Matematycznie robi się z tego tysiące kombinacji. Większość nie ma własnego popytu, własnej treści ani sensu biznesowego. Google w dokumentacji o faceted navigation ostrzega wprost, że takie mechanizmy mogą tworzyć bardzo dużą liczbę adresów, powodować nadmierne crawlowanie i spowalniać odkrywanie nowych, ważnych URL-i.

Dlatego pytanie nie brzmi: „czy filtry są dobre dla SEO?”. Są dobre dla klienta. Pytanie brzmi: które filtry powinny dostać prawo do życia w indeksie, a które mają zostać tylko narzędziem zawężania listy produktów.

Filtry w indeksie: kiedy faceted search pomaga, a kiedy robi śmietnik w Google

Nawigacja fasetowa powinna działać według jednej zasady: indeksujemy tylko te kombinacje, które mają samodzielny sens wyszukiwarkowy, handlowy i treściowy. Reszta ma służyć użytkownikowi, ale nie powinna walczyć o miejsce w Google.

W praktyce osobny, indeksowalny URL warto rozważyć dla filtra, który spełnia kilka warunków naraz:

• ma wyraźny popyt, np. „czarne sneakersy damskie”, „śruby M8 nierdzewne”, „laptop 17 cali i7”;
• pokazuje stabilną ofertę, a nie chwilową kombinację 2 produktów;
• można go opisać inaczej niż kategorię nadrzędną;
• ma logiczne miejsce w strukturze sklepu;
• nie konkuruje z mocniejszą kategorią albo tagiem o tę samą frazę;
• da się go linkować czystym, przewidywalnym adresem, np. /buty-damskie/czarne/, a nie chaosem typu ?color=black&size=39&sort=price_asc.

Roboczo, przy audycie dużego sklepu, nie traktowałbym jako landing page’a SEO filtra, który ma mniej niż 5–10 aktywnych produktów, chyba że mówimy o produkcie bardzo wysokomarżowym albo B2B, gdzie nawet jedna pozycja potrafi mieć konkretny popyt. To nie jest oficjalny limit Google. To praktyczna granica bezpieczeństwa: poniżej niej łatwo stworzyć stronę cienką, pustą po sezonie albo zbyt podobną do innych.

Filtry, które najczęściej zasługują na indeksację:

• marka + kategoria, np. /opony/michelin/;
• materiał + kategoria, np. /blaty-kuchenne/drewniane/;
• zastosowanie + kategoria, np. /farby/do-lazienki/;
• ważny parametr techniczny, np. /sruby/m8/, /laptopy/17-cali/;
• kolor, ale tylko tam, gdzie realnie występuje intencja zakupowa, np. moda, wyposażenie wnętrz, obuwie.

Filtry, które zwykle powinny być ukryte przed Google:

• sortowanie: cena rosnąco, cena malejąco, popularność, najnowsze;
• liczba produktów na stronie: ?limit=24, ?per_page=96;
• widok listy/siatki: ?view=grid;
• zakres ceny, jeśli jest generowany automatycznie i ma setki kombinacji;
• filtry dostępności, np. tylko produkty dostępne dziś;
• parametry sesyjne, trackingowe i kampanijne, np. utm_source, sessionid;
• kombinacje wielokrotne, np. kolor + rozmiar + marka + cena + sortowanie;
• puste lub absurdalne kombinacje, np. „zielone ryby w rozmiarze tiny”, jeśli taka oferta nie istnieje — Google zaleca zwracanie 404 dla kombinacji filtrów bez wyników lub nielogicznych układów.

Największy błąd? Indeksowanie wszystkiego „na zapas”. To wygląda ambitnie tylko w arkuszu. W indeksie kończy się zwykle setkami adresów o prawie tym samym tytule, tym samym H1 i tą samą liście produktów w innej kolejności. W Search Console pojawiają się potem komunikaty w stylu „Duplikat, Google wybrał inną stronę kanoniczną niż użytkownik”, a właściciel sklepu zastanawia się, dlaczego nowa kategoria nie chce wejść do indeksu.

Dobra architektura filtrów zaczyna się od mapy decyzji. Dla każdego filtra trzeba przypisać jedną z trzech ról:

1. SEO landing page — filtr ma czysty URL, unikalny title, H1, opis, self-canonical, linki wewnętrzne i może trafić do sitemap.xml.
2. Filtr użytkowy — działa dla klienta, ale nie jest linkowany jako adres indeksowalny; może działać przez AJAX, fragment URL albo parametr wykluczony z crawlowania.
3. Kombinacja techniczna — nie powinna być indeksowana, linkowana ani umieszczana w mapie strony.

Dla przykładu: w sklepie z odzieżą „sukienki czerwone” mogą mieć sens jako osobna strona, bo użytkownik często szuka koloru jako głównej cechy. Ale „sukienki czerwone, rozmiar 38, cena 100–150 zł, sortowanie od najtańszych” to już nie landing page. To stan interfejsu. Różnica jest fundamentalna.

Google dopuszcza blokowanie crawlowania adresów fasetowych przez robots.txt, jeśli nie chcemy, żeby takie URL-e pojawiały się w Google i zależy nam na oszczędzaniu zasobów serwera. Jednocześnie dokumentacja wskazuje, że często nie ma powodu, aby pozwalać crawlerom chodzić po filtrowanych listach, jeśli wystarczą strony produktów i główne listy kategorii.

Trzeba jednak uważać na kolejność działań. robots.txt blokuje crawlowanie, nie jest narzędziem do pewnego usuwania adresów z indeksu. Google może nadal znać zablokowany URL, jeśli znajdzie do niego linki z innych miejsc. Jeśli adresy filtrów są już w indeksie i trzeba je usunąć, bezpieczniejszą ścieżką jest najpierw dopuścić Googlebota do strony z dyrektywą noindex, a dopiero po wyczyszczeniu indeksu rozważyć blokadę crawlowania. Google zaznacza, że noindex nie zadziała, jeśli strona jest zablokowana w robots.txt, bo crawler nie zobaczy tej dyrektywy.

Parametry, sortowanie i duplikaty: techniczny porządek w adresach URL

Parametry w URL są potrzebne. Problem zaczyna się wtedy, gdy sklep pozwala im rozmnażać się bez kontroli.

Adres:

/buty-trekkingowe?brand=salomon&color=black&sort=price_asc

i adres:

/buty-trekkingowe?sort=price_asc&color=black&brand=salomon

dla człowieka znaczą to samo. Dla crawlera mogą być dwoma różnymi URL-ami, które trzeba pobrać, porównać i dopiero potem uznać za duplikaty. Google w dokumentacji e-commerce pisze wprost, że różne adresy zwracające tę samą treść mogą zwiększać liczbę niepotrzebnych żądań, a ciągle zmieniające się wartości parametrów mogą sprawiać wrażenie nieskończonej liczby stron.

W 2026 roku nie można już liczyć na stare narzędzie URL Parameters w Google Search Console. Google ogłosiło jego wycofanie w 2022 roku, wskazując, że roboty uczą się obsługi parametrów automatycznie, a większą kontrolę można uzyskać m.in. przez robots.txt. To oznacza jedno: porządek musi być zrobiony w sklepie, nie w panelu Google.

Najważniejsze zasady dla parametrów:

• ustal jedną kolejność parametrów, np. brand, color, size, price, sort;
• nie pozwalaj na duplikaty typu ?color=black&color=black;
• wymuszaj małe litery w adresach;
• usuwaj parametry puste, np. ?color=;
• nie linkuj wewnętrznie do wersji z UTM;
• nie dodawaj do sitemap.xml adresów sortowania, filtrowania technicznego ani trackingowych;
• dla adresów indeksowalnych stosuj self-canonical;
• dla duplikatów stosuj canonical do wersji głównej, ale nie traktuj canonicala jak magicznego odkurzacza.

Canonical pomaga konsolidować sygnały dla podobnych lub zduplikowanych stron, a Google zaleca spójne linkowanie wewnętrzne do adresu kanonicznego. Nie jest to jednak rozkaz bezwarunkowy. Jeśli strona filtrowana ma inną treść, inne linki, inny title i inne sygnały, Google może wybrać inną wersję niż wskazana.

Dla sortowania najlepszy wariant jest prosty: sortowanie nie tworzy strony SEO. To funkcja listy produktów.

Przykład wdrożenia:

/laptopy/ — URL kanoniczny, indeksowalny
/laptopy/?sort=price_asc — dostępny dla użytkownika, canonical do /laptopy/, poza sitemapą
/laptopy/?sort=price_desc — dostępny dla użytkownika, canonical do /laptopy/, poza sitemapą
/laptopy/?view=grid — najlepiej bez osobnego indeksowalnego adresu
/laptopy/?limit=96 — nieindeksowalny stan interfejsu

Przykładowy canonical dla sortowania:

<link rel="canonical" href="https://www.sklep.pl/laptopy/" />

Jeśli Googlebot masowo crawluje sortowania mimo canonicali, trzeba iść krok dalej: ograniczyć linkowanie do takich adresów, użyć przycisków zamiast standardowych linków tam, gdzie to uzasadnione UX-owo, zastosować AJAX albo zablokować określone wzorce w robots.txt. Google w dokumentacji crawl budget wskazuje, że inaczej sortowane wersje tej samej strony mogą być przykładami URL-i, które warto blokować, jeśli nie da się ich skonsolidować.

Przykładowy, ostrożny zapis dla robots.txt może wyglądać tak:

User-agent: Googlebot
Disallow: /*?*sort=
Disallow: /*&sort=
Disallow: /*?*view=
Disallow: /*&view=
Disallow: /*?*limit=
Disallow: /*&limit=

To nie jest wzór do wklejenia w ciemno. Przed wdrożeniem trzeba sprawdzić, czy sklep nie używa tych samych parametrów dla ważnych, indeksowalnych stron. Błąd w robots.txt potrafi odciąć Google od dużej części katalogu. Przy dużym e-commerce testuje się to najpierw na crawlu stagingowym, potem na małej sekcji, a dopiero później globalnie.

Warto też rozdzielić trzy narzędzia, bo są często mylone:

canonical — mówi, która wersja ma być preferowana przy duplikatach; dobry do konsolidacji sygnałów;
noindex — usuwa stronę z indeksu, ale crawler musi ją zobaczyć;
robots.txt — ogranicza crawlowanie, ale sam w sobie nie gwarantuje usunięcia URL-a z wyników.

Kolejność działań przy sprzątaniu parametrów powinna wyglądać tak:

1. Wyciągnij z logów serwera i GSC listę najczęściej crawlowanych parametrów.
2. Oznacz parametry jako: SEO, UX, techniczne, trackingowe.
3. Dla parametrów SEO zostaw indeksację tylko tam, gdzie istnieje popyt i unikalna treść.
4. Dla parametrów UX ustaw canonical do czystej kategorii i usuń je z linkowania indeksowalnego.
5. Dla trackingowych i sesyjnych wymuś brak linkowania wewnętrznego i czyszczenie URL-i.
6. Dla sortowania rozważ blokadę crawlowania, ale dopiero po sprawdzeniu skutków.
7. W sitemap.xml zostaw wyłącznie adresy kanoniczne, indeksowalne, zwracające 200.

To jest nudna praca, ale właśnie tu zwykle odzyskuje się kontrolę. Nie przez dopisanie kolejnych opisów kategorii, tylko przez odcięcie setek lub tysięcy adresów, które nigdy nie powinny były konkurować z głównymi stronami.

Warianty produktów i mega-menu: jak nie rozbić autorytetu strony na dziesiątki kopii

Kanibalizacja między produktami jest bardziej zdradliwa niż kanibalizacja między kategoriami. Przy kategoriach łatwo zobaczyć konflikt: dwie strony celują w tę samą frazę. Przy produktach problem wygląda normalnie, bo każdy SKU „musi mieć przecież swój URL”. Nie zawsze musi.

Weźmy przykład: sklep ma 10 śrub tego samego typu, różniących się tylko średnicą: M3, M4, M5, M6, M8, M10, M12. Decyzja nie jest automatyczna. Trzeba odpowiedzieć na pytanie: czy średnica zmienia intencję wyszukiwania i decyzję zakupową, czy jest tylko wariantem wyboru?

Jeden produkt z wariantami wybieram wtedy, gdy:

• użytkownik najpierw wybiera typ produktu, a dopiero potem parametr;
• opis, zdjęcia, zastosowanie i producent są prawie identyczne;
• różni się głównie średnica, długość, kolor, rozmiar lub opakowanie;
• warianty mają wspólną historię opinii i wspólną kartę produktu;
• osobne URL-e byłyby niemal kopiami;
• sklep ma problem z indeksacją i crawl budgetem.

Wtedy karta może wyglądać tak:

/sruba-imbusowa-din-912-nierdzewna/

Na stronie użytkownik wybiera średnicę, długość i liczbę sztuk. Warianty mają własne SKU, ceny, dostępność i dane w feedzie produktowym, ale SEO skupia się na jednej mocnej karcie. Dla Google można wdrożyć dane strukturalne ProductGroup, Product, variesBy, hasVariant i productGroupID, bo Google oficjalnie obsługuje oznaczanie wariantów produktów różniących się m.in. rozmiarem, kolorem, materiałem czy wzorem.

Osobne URL-e dla wariantów zostawiam wtedy, gdy:

• każdy wariant ma własny popyt, np. „śruba M8 nierdzewna” i „śruba M12 nierdzewna”;
• parametry techniczne istotnie zmieniają zastosowanie produktu;
• wariant ma inną cenę, zdjęcia, opis techniczny, normę, kompatybilność lub grupę klientów;
• użytkownik trafiający z Google na konkretny wariant nie powinien wybierać go od nowa;
• sklep prowadzi kampanie produktowe na konkretne SKU;
• warianty mogą mieć pełną, samodzielną treść.

W takim modelu każdy wariant powinien mieć własny, konkretny URL, np.:

/sruba-imbusowa-m6-din-912-nierdzewna/
/sruba-imbusowa-m8-din-912-nierdzewna/
/sruba-imbusowa-m10-din-912-nierdzewna/

Ale to wymaga dyscypliny. Nie wystarczy podmienić „M6” na „M8” w tytule. Każda strona musi mieć dane techniczne, kompatybilność, zastosowanie, tabelę wymiarów, dostępność, cenę i sensowny opis. Inaczej sklep sam produkuje konkurentów dla własnej kategorii.

Google rozróżnia dwa podejścia do wariantów: single-page, gdzie warianty wybiera się na jednej stronie, oraz multi-page, gdzie warianty są dostępne na różnych stronach. W dokumentacji Google zaznacza, że przy wariancie single-page zwykle istnieje jeden kanoniczny URL dla całej grupy, a przy multi-page strony wariantów mogą być rozłożone na równorzędne adresy, które muszą mieć samodzielne oznaczenia.

W Google Merchant Center dochodzi jeszcze item_group_id. Google zaleca używanie go do grupowania wariantów tego samego produktu, ale ostrzega, aby nie używać go dla produktów tylko podobnych, które nie są faktycznymi wariantami. To ważny niuans. Zestaw łazienkowy i pojedynczy dozownik nie są wariantami. Śruba M6 i M8 mogą być wariantami, ale tylko wtedy, gdy sklep i użytkownik faktycznie traktują je jako wersje tego samego produktu.

Druga część problemu to mega-menu. W dużym sklepie potrafi ono zrobić więcej szkody niż niejeden błąd w canonicalach. Google analizuje relacje między stronami na podstawie linków, a nawigacja i linki wewnętrzne wpływają na rozumienie struktury serwisu. Google podaje też, że im więcej linków wewnętrznych prowadzi do strony, tym większe może być jej względne znaczenie w obrębie witryny.

Mega-menu nie powinno być katalogiem wszystkiego. Jeśli z każdej podstrony linkujesz do 500 kategorii, 80 marek, 40 tagów i 20 promocji, to wysyłasz sygnał: „wszystko jest ważne”. A jeśli wszystko jest ważne, nic nie jest naprawdę priorytetowe.

Praktyczna zasada: w menu głównym trzymaj strony, które mają największą wartość dla biznesu i SEO:

• główne kategorie;
• najważniejsze podkategorie;
• sezonowe landing page’e, ale tylko w sezonie;
• marki, jeśli mają popyt i ofertę;
• poradniki zakupowe tylko wtedy, gdy wspierają decyzję i sprzedaż.

Nie wrzucaj do mega-menu:

• wszystkich tagów blogowych;
• filtrów typu kolor + rozmiar;
• sortowań;
• parametrów cenowych;
• stron z małą liczbą produktów;
• stron tymczasowych bez planu wycofania;
• kilku linków z tym samym anchorem do różnych URL-i.

Ten ostatni punkt jest szczególnie ważny. Jeśli anchor „buty trekkingowe” prowadzi raz do /buty-trekkingowe/, raz do /trekking/, a raz do /outdoor/buty/, sklep sam rozmywa sygnał. Google zaleca, aby anchor text był opisowy, zwięzły i adekwatny do strony docelowej; linki typu „kliknij tutaj” albo niejednoznaczne anchory są słabszym sygnałem.

Dobre mega-menu nie musi być małe. Musi być hierarchiczne. Najpierw kategorie główne, potem logiczne podkategorie, potem ewentualnie najważniejsze filtry SEO. Jeżeli kategoria ma 200 podkategorii, do menu głównego powinno trafić 20–40 najważniejszych, a reszta powinna być dostępna przez stronę kategorii, linkowanie kontekstowe, breadcrumbs i moduły „popularne podkategorie”.

Najpierw naprawia się linkowanie do stron, które już mają potencjał. Dopiero potem tworzy nowe landing page’e filtrowe. Odwrotna kolejność kończy się tym, że sklep produkuje 300 nowych URL-i, których nikt nie linkuje, Google ich nie priorytetyzuje, a raport indeksowania puchnie bez ruchu.

FAQ: najczęstsze pytania o filtry, parametry i kanibalizację w e-commerce

Czy każdy filtr w sklepie powinien mieć osobny adres URL?
Nie. Osobny URL powinny mieć tylko filtry z realnym popytem, stabilną ofertą i możliwością przygotowania unikalnej treści. Sortowanie, widok listy, zakres ceny i przypadkowe kombinacje filtrów powinny zostać poza indeksem.

Czy canonical wystarczy do rozwiązania problemu duplikacji?
Nie zawsze. Canonical pomaga wskazać preferowaną wersję, ale nie zastępuje porządku w linkowaniu, sitemapie i architekturze. Jeżeli sklep nadal masowo linkuje do duplikatów, Google musi je crawlowac i oceniać.

Co zrobić z sortowaniem po cenie?
Traktować je jako funkcję UX, nie jako stronę SEO. Adresy typu ?sort=price_asc powinny zwykle wskazywać canonical do głównej kategorii, nie trafiać do sitemap.xml i nie być wzmacniane linkowaniem wewnętrznym.

Kiedy użyć noindex, a kiedy robots.txt?
Noindex stosuj, gdy chcesz usunąć stronę z indeksu i możesz pozwolić Googlebotowi ją odczytać. robots.txt stosuj, gdy chcesz ograniczyć crawlowanie adresów, które nie powinny zużywać zasobów. Nie blokuj w robots.txt strony, na której liczysz na zadziałanie noindex.

Czy rozmiar produktu powinien być indeksowany jako filtr?
Zależy od branży. W modzie rozmiar często jest tylko filtrem użytkowym. W technicznych produktach B2B, np. śruby M8, rury 50 mm, łożyska 6204, parametr może być główną intencją wyszukiwania i wtedy warto rozważyć osobny URL.

Co zrobić z 10 prawie identycznymi produktami różniącymi się średnicą?
Jeżeli różnica jest tylko wariantem wyboru, połącz je w jeden produkt z wariantami. Jeżeli średnica zmienia intencję, zastosowanie, dane techniczne i zapytania użytkowników, zostaw osobne URL-e, ale przygotuj dla nich samodzielne treści i dane strukturalne.

Czy mega-menu powinno linkować do wszystkich kategorii?
Nie. Mega-menu powinno promować najważniejsze kategorie, podkategorie i wybrane landing page’e SEO. Linkowanie do wszystkiego osłabia priorytety i utrudnia Google rozpoznanie, które strony naprawdę mają znaczenie.

Od czego zacząć porządki w dużym sklepie?
Najpierw sprawdź w logach i Google Search Console, jakie parametry Googlebot crawluje najczęściej. Potem usuń z sitemap.xml wszystkie niekanoniczne adresy, uporządkuj canonicale, ogranicz linkowanie do sortowań i dopiero na końcu decyduj, które filtry zasługują na własne landing page’e.