Magento SEO: jak poprawić indeksowanie filtrów i nawigacji warstwowej

Sklep Magento może działać poprawnie, szybko generować strony kategorii i jednocześnie wysyłać do Google tysiące adresów, które nie powinny być traktowane jako osobne strony. Najczęściej odpowiada za to nawigacja warstwowa: filtry koloru, rozmiaru, marki, ceny, materiału, oceny oraz ich wzajemne kombinacje. Dla użytkownika taki mechanizm jest wygodny. Dla wyszukiwarki może oznaczać jednak setki wariantów tej samej kategorii, powielone tytuły, podobną treść i niepotrzebne wizyty robota na adresach sortowania, paginacji oraz parametrów. ^[2]

Problem nie polega na tym, że każdy filtrowany adres URL jest zły. Część kombinacji ma realny popyt wyszukiwawczy i może skutecznie pozyskiwać ruch, na przykład buty trekkingowe damskie czarne albo telewizory Samsung 55 cali. Kłopot zaczyna się wtedy, gdy Magento traktuje każdą możliwą kombinację jako równorzędny widok, mimo że większość z nich nie ma własnego potencjału SEO.

Skuteczna optymalizacja nie polega więc na mechanicznym zablokowaniu całej nawigacji warstwowej. Trzeba ustalić, które filtry są tylko narzędziem nawigacyjnym, które powinny być kanoniczne wobec kategorii, a które warto przekształcić w przyjazne, opisane i kontrolowane strony docelowe.

Niekontrolowana nawigacja warstwowa w Magento: realny problem z duplikacją i budżetem indeksowania

Objawy w Google Search Console: tysiące adresów poza mapą witryny

Pierwszym sygnałem problemu jest zwykle raport indeksowania w Google Search Console. Właściciel sklepu widzi tam adresy oznaczone jako „Zindeksowano, ale brak w mapie witryny”, „Duplikat, Google wybrał inną stronę kanoniczną” albo „Wykryto, obecnie niezindeksowane”. Same statusy nie zawsze oznaczają błąd. Ich duża skala może jednak wskazywać, że Google odkrywa znacznie więcej wariantów kategorii, niż sklep planował obsługiwać.

W adresach często pojawiają się parametry związane z filtrami, na przykład:

• /meble/krzesla.html?color=12,
• /meble/krzesla.html?color=12&material=8,
• /meble/krzesla.html?price=100-300,
• /meble/krzesla.html?brand=24&color=12&size=medium,
• /meble/krzesla.html?product_list_order=price,
• /meble/krzesla.html?p=3.

Nie każdy z tych adresów musi być dostępny w indeksie. W praktyce często są one odkrywane przez linki wewnętrzne, linki generowane po stronie klienta, mapy witryny, historię indeksowania albo zewnętrzne odnośniki. Jeśli odpowiedź serwera jest poprawna, strona zwraca produkty i nie ma jednoznacznej dyrektywy, robot może poświęcić zasoby na sprawdzanie kolejnych kombinacji.

Obawa przed utratą widoczności po zmianie filtrów

Naturalna obawa brzmi: „Jeżeli zablokuję filtry, stracę ruch z długiego ogona”. To ryzyko istnieje, ale dotyczy głównie tych kombinacji, które już generują wejścia, mają zapytania w Google lub są logicznie dopasowane do oferty. Zablokowanie przypadkowego adresu z parametrem sortowania nie odbiera sklepowi wartościowej widoczności. Przeciwnie, może ułatwić wyszukiwarce skupienie się na kategorii, produktach i wybranych landing page’ach. ^[3]

Bezpieczna ingerencja zaczyna się od rozdzielenia dwóch grup:

• adresy użytkowe – służące do zawężania wyników, sortowania i wygodnego przeglądania produktów;
• adresy SEO – mające własny popyt, unikalną intencję, wystarczającą liczbę produktów i możliwość przygotowania odrębnej treści.

Największym błędem jest wdrożenie jednej reguły dla wszystkich filtrów bez sprawdzenia danych. Równie ryzykowne bywa pozostawienie ustawień bez zmian tylko dlatego, że sklep dotychczas nie odnotował gwałtownego spadku ruchu. Problemy z indeksacją często narastają stopniowo: po dodaniu nowych atrybutów, uruchomieniu modułu layered navigation SEO, zmianie szablonu lub zwiększeniu liczby produktów.

Kanibalizacja kategorii i wariantów filtrów

Załóżmy, że sklep ma kategorię /buty-trekkingowe.html oraz dziesiątki wariantów:

• /buty-trekkingowe.html?color=black,
• /buty-trekkingowe.html?gender=women,
• /buty-trekkingowe.html?gender=women&color=black,
• /buty-trekkingowe.html?gender=women&color=black&size=39.

Jeżeli wszystkie widoki mają bardzo podobny tytuł, opis i listę produktów, Google może mieć trudność z ustaleniem, który adres najlepiej odpowiada zapytaniu. W efekcie strona głównej kategorii konkuruje z filtrowanym wariantem, a sygnały linków i treści rozpraszają się między adresami. Taka kanibalizacja nie zawsze objawia się spadkiem pozycji jednej konkretnej frazy. Częściej widać niestabilne adresy wyświetlane w wynikach, zmienny ruch i indeksowanie stron, których właściciel nie wybrał jako docelowych.

Sam tag kanoniczny może pomóc, lecz nie zastępuje decyzji strategicznej. Jeśli kombinacja „damskie czarne buty trekkingowe” ma być stroną docelową, wskazanie kanonicznej kategorii nadrzędnej odbierze tej kombinacji sygnał, że jest samodzielnym landing page’em. Z kolei pozostawienie samokanonicznego adresu bez unikalnej treści może spowodować, że Google uzna go za mało wartościowy duplikat.

Przeciążenie crawl budgetu w sklepie z dużą liczbą wariantów

Crawl budget, czyli budżet indeksowania, nie jest sztywną liczbą przydzielaną wszystkim sklepom. Google ocenia między innymi wielkość serwisu, częstotliwość zmian, wydajność serwera, jakość odpowiedzi i historię indeksowania. Duży sklep nie może jednak zakładać, że robot bez kosztu sprawdzi każdą kombinację filtrów.

Robot może odwiedzać najpierw:

• adresy z inną kolejnością parametrów, które pokazują ten sam zestaw produktów;
• widoki sortowania po cenie, nazwie lub dacie dodania;
• kolejne strony paginacji dla każdej kombinacji filtrów;
• przedziały cenowe, w których nie ma produktów albo jest ich bardzo mało;
• adresy z nieaktualnymi wartościami atrybutów;
• filtry wielokrotnego wyboru generujące ogromną liczbę permutacji.

W takiej sytuacji nowe karty produktów, aktualizacje stanów magazynowych i świeżo utworzone kategorie mogą być odkrywane wolniej. Nie oznacza to, że każdy adres z parametrem bezpośrednio „zabiera” indeksowanie konkretnej podstronie. Oznacza natomiast, że niekontrolowany zbiór URL-i zwiększa koszty techniczne i utrudnia wyszukiwarce ocenę struktury sklepu.

Anatomia problemu: dlaczego silnik Magento domyślnie tworzy pułapki indeksacji?

Mechanizm generowania dynamicznych adresów w layered navigation

Nawigacja warstwowa Magento działa na zasadzie filtrowania kolekcji produktów w obrębie kategorii. Atrybuty skonfigurowane jako dostępne w layered navigation tworzą odnośniki, które po kliknięciu zmieniają zakres wyników. W zależności od konfiguracji, wersji Magento, motywu oraz użytego rozszerzenia parametry mogą być przekazywane w adresie URL, kodowane w inny sposób albo obsługiwane częściowo przez AJAX. ^[1]

Dla użytkownika przejście z kategorii „Kurtki” do widoku „Kurtki + marka X + kolor granatowy” jest jedną czynnością. Dla wyszukiwarki może to być nowy URL z własnym kodem odpowiedzi, tytułem, zestawem linków i kolejną porcją odnośników do filtrów. Każdy następny wybór poszerza zbiór możliwych adresów.

Warto przeanalizować nie tylko linki widoczne w kodzie HTML, lecz także:

• adresy generowane przez JavaScript;
• linki w elementach formularzy i przyciskach filtrów;
• wartości przekazywane do endpointów AJAX;
• adresy zapisane w mapach XML;
• odnośniki umieszczone w danych strukturalnych lub elementach nawigacyjnych;
• wewnętrzne przekierowania po zmianie filtrów.

Sam fakt, że adres nie występuje jako klasyczny link tekstowy w źródle HTML, nie gwarantuje, że Google go nie odkryje. URL może zostać znaleziony w renderowanym DOM, skrypcie, zewnętrznym odnośniku lub historii crawlowania.

Filtry wielokrotnego wyboru a zwykłe atrybuty produktu

Nie wszystkie atrybuty generują takie samo ryzyko. Prosty filtr jednokrotnego wyboru, na przykład marka, może tworzyć ograniczoną liczbę sensownych wariantów. Filtr wielokrotnego wyboru, taki jak kolor, materiał lub cecha techniczna, pozwala łączyć wartości w różne zestawy. W zależności od implementacji adres dla „czarny + granatowy” może być różny od adresu „granatowy + czarny”, mimo że wynik jest identyczny.

To prowadzi do problemu równoważnych URL-i. Przykładowo poniższe adresy mogą zwracać tę samą listę produktów:

• ?color=black&brand=acme,
• ?brand=acme&color=black,
• ?color=black%2Cbrand=acme,
• ?color=black&color=black&brand=acme.

Dokładna składnia zależy od modułu i konfiguracji, dlatego audyt powinien opierać się na rzeczywistych adresach z serwera, raportów GSC i crawlera, a nie na założeniu, że każda instalacja Magento zachowuje się identycznie. W szczególności trzeba ustalić, czy moduł normalizuje kolejność parametrów, usuwa duplikaty oraz przekierowuje nieprawidłowe warianty do jednej wersji URL.

Nieskończona przestrzeń kombinacji

W sklepie z dziesięcioma wartościami koloru, pięcioma markami, kilkoma rozmiarami i wieloma przedziałami cenowymi liczba możliwych kombinacji rośnie szybciej, niż sugeruje liczba samych atrybutów. Dochodzą do tego parametry sortowania, widoku listy, liczby produktów na stronie, paginacji i czasem identyfikatory sesji.

Najbardziej problematyczny scenariusz wygląda tak:

1. kategoria zawiera kilka filtrów;
2. każdy filtr tworzy indeksowalny link;
3. po wybraniu jednego filtra nadal widoczne są pozostałe;
4. każda kombinacja ma własny zestaw linków;
5. paginacja powiela ten proces na kolejnych stronach wyników;
6. sortowanie tworzy kolejne warianty tej samej kombinacji.

Jeżeli do tego dochodzi automatyczne generowanie mapy witryny obejmującej filtrowane adresy, sklep sam wskazuje wyszukiwarce, że te URL-e są ważne. Mapa XML nie powinna zawierać przypadkowych parametrów tylko dlatego, że technicznie da się je wygenerować.

Przegląd technicznych metod blokowania i kontroli: robots.txt, noindex czy rel=”canonical”?

Po rozpoznaniu adresów trzeba dobrać metodę do celu. Inaczej postępuje się z URL-em, którego robot w ogóle nie powinien odwiedzać, inaczej z widokiem potrzebnym użytkownikom, ale nieprzeznaczonym do indeksowania, a jeszcze inaczej z wartościową stroną filtrowaną, która ma konkurować w wynikach wyszukiwania na własnych zasadach.

Najczęściej wykorzystywane są trzy mechanizmy:

• robots.txt ograniczający crawlowanie wskazanych wzorców adresów;
• dyrektywa noindex usuwająca stronę z indeksu, ale wymagająca możliwości jej odczytania przez robota;
• rel="canonical" wskazujący preferowany adres dla kilku podobnych lub równoważnych wersji.

Robots.txt: dobre narzędzie do ograniczania crawlowania

Reguła w pliku robots.txt może powstrzymać robota przed pobieraniem określonych adresów. Sprawdza się przede wszystkim przy parametrach, które nie niosą wartości dla wyszukiwarki, takich jak sortowanie, zmiana sposobu prezentacji listy czy techniczne warianty widoku.

User-agent: *
Disallow: /*?product_list_order=
Disallow: /*?product_list_dir=
Disallow: /*?p=

To tylko przykład składni. Konkretne wzorce trzeba dopasować do sposobu, w jaki Magento i rozszerzenia budują adresy. Zbyt szeroka reguła może zablokować także wartościowe landing page’e, a zbyt wąska pozostawi wiele niepotrzebnych wariantów.

robots.txt ma istotne ograniczenie: nie jest dyrektywą indeksowania strony. Jeżeli adres zostanie znaleziony z innego źródła, Google może znać jego istnienie, ale bez pobrania treści nie otrzyma tagu canonical, nagłówka noindex ani innych sygnałów znajdujących się w dokumencie. Zablokowany URL może więc nadal pojawiać się w raportach jako adres znany wyszukiwarce.

Nie należy także umieszczać w robots.txt blokady dla adresów, na których znajduje się noindex. Robot musi móc wejść na stronę, aby odczytać tę dyrektywę. W przeciwnym razie oba mechanizmy będą sobie przeczyć.

Noindex: gdy strona ma działać dla użytkownika, ale nie ma trafiać do indeksu

noindex jest właściwym wyborem, gdy filtrowany widok powinien pozostać dostępny dla klientów i robotów, lecz nie ma być samodzielnym wynikiem organicznym. Dotyczy to często kombinacji o niskiej wartości, stron z niewielką liczbą produktów oraz widoków technicznych, które są potrzebne w nawigacji sklepu.

Dyrektywę można przekazać w sekcji <head>:

<meta name="robots" content="noindex,follow">

albo w nagłówku HTTP:

X-Robots-Tag: noindex, follow

Wariant follow pozwala robotowi podążać za odnośnikami znajdującymi się na stronie, ale nie gwarantuje, że każda strona docelowa zostanie przez to szybko odkryta lub zindeksowana. Najważniejsza informacja brzmi: noindex nie zmniejsza automatycznie liczby wizyt robota. Adres nadal może być crawlowany, dlatego przy bardzo dużej skali nie powinien być jedynym sposobem ograniczania niepożądanych żądań.

W Magento dyrektywa może być uzależniona od:

• rodzaju kategorii;
• zestawu użytych atrybutów;
• liczby aktywnych filtrów;
• liczby produktów po zastosowaniu filtracji;
• obecności strony w zatwierdzonej liście landing page’ów SEO.

Takie warunki powinny być realizowane konsekwentnie. Jeśli moduł dodaje noindex tylko w kodzie renderowanym po stronie klienta, trzeba sprawdzić, czy dyrektywa jest obecna w finalnym dokumencie odczytywanym przez Google, a nie wyłącznie w początkowym HTML-u lub w stanie aplikacji JavaScript.

Canonical: konsolidacja podobnych adresów, a nie blokada indeksacji

Tag rel="canonical" wskazuje adres preferowany spośród kilku wersji opisujących podobną zawartość. Może być przydatny dla parametrów, które nie zmieniają istotnie intencji strony, lecz nie powinien służyć jako uniwersalny zamiennik blokowania filtrów.

Przykładowo widok kategorii posortowany według ceny może wskazywać wersję podstawową:

<link rel="canonical" href="https://sklep.pl/meble/krzesla.html">

Canonical jest sygnałem, nie bezwzględnym poleceniem. Google może wybrać inny adres, jeśli uzna go za bardziej reprezentatywny, jeśli strony znacząco się różnią albo jeśli sygnały wewnętrzne i zewnętrzne są niespójne.

Nie należy kanonikalizować wszystkich filtrowanych stron do kategorii nadrzędnej, gdy wybrane kombinacje mają być osobnymi stronami docelowymi. W takim przypadku samokanoniczny adres, unikalny tytuł, własny opis i logiczne linkowanie wewnętrzne wspierają decyzję o traktowaniu go jako samodzielnego zasobu.

Canonical nie powstrzymuje też przed crawlowaniem adresu. Robot musi pobrać stronę, aby odczytać wskazanie. Jeśli problemem jest przede wszystkim liczba żądań, potrzebne są dodatkowe działania: ograniczenie linkowania, wykluczenie parametrów technicznych, normalizacja adresów i odpowiednia konfiguracja robots.txt.

Jak łączyć te mechanizmy?

W praktyce skuteczna konfiguracja zwykle korzysta z kilku warstw:

Najgorszy scenariusz to jednoczesne blokowanie adresu w robots.txt, dodawanie na nim noindex oraz wskazywanie canonicala do innej strony. Taka konfiguracja utrudnia diagnozę, ponieważ robot nie może odczytać części sygnałów. Każda klasa URL-i powinna mieć jedną jasno określoną funkcję i odpowiadającą jej regułę.

Od filtrów do ruchu organicznego: selektywne indeksowanie wartościowych kombinacji

Kontrola layered navigation nie powinna kończyć się na blokowaniu. Celem jest wyłonienie tych kombinacji, które mogą odpowiadać na konkretne zapytania i jednocześnie tworzyć dobrą stronę docelową.

Kiedy filtr zasługuje na własny landing page?

Warto rozważyć indeksowanie kombinacji, jeśli spełnia większość poniższych warunków:

• odpowiada rozpoznawalnej intencji wyszukiwania;
• ma stabilny, możliwy do utrzymania adres;
• zwraca wystarczającą liczbę dostępnych produktów;
• nie jest wyłącznie wariantem sortowania lub paginacji;
• można przygotować odrębny tytuł, nagłówek i opis;
• ma miejsce w strukturze linkowania wewnętrznego;
• oferta na tej stronie nie znika po krótkiej zmianie sezonowej.

Przykładowo strona „telewizory Samsung 55 cali” może mieć wyraźną intencję zakupową, pod warunkiem że sklep rzeczywiście posiada odpowiedni asortyment, a tekst i struktura strony potwierdzają temat. Samo połączenie dwóch filtrów nie jest jednak wystarczającym powodem do indeksowania.

Landing page nie powinien być tylko kopią kategorii z innym zestawem produktów. Należy zadbać o elementy, które wyjaśniają wybór:

• unikalny tytuł i nagłówek H1;
• krótki opis nad listą produktów;
• treść pomocniczą dotyczącą cech filtrowanej grupy;
• odpowiednie breadcrumbs;
• linki do kategorii nadrzędnej i powiązanych stron;
• prawidłowe dane strukturalne, jeśli są uzasadnione.

Lista zatwierdzonych kombinacji zamiast automatycznego indeksowania

Bezpieczniejszy model polega na utworzeniu listy dozwolonych stron SEO. Zamiast indeksować każdy możliwy zestaw filtrów, sklep przechowuje określone kombinacje, dla których zdefiniowano adres, metadane, treść i status publikacji.

Takie rozwiązanie może działać jako:

• moduł SEO dla layered navigation;
• dedykowana encja landing page’ów;
• konfiguracja oparta na regułach atrybutów;
• ręcznie zarządzana mapa stron wspierana przez CMS.

Ważne, aby lista była źródłem decyzji także dla innych elementów systemu. Jeśli strona znajduje się na liście zatwierdzonych kombinacji, powinna otrzymać indeksowalny szablon, linkowanie i wpis w mapie XML. Jeśli jej nie ma, nie powinna przypadkowo trafiać do sitemap, menu ani modułu automatycznych linków SEO.

Warto również ustalić kryterium wycofania. Landing page z zerowym stanem magazynowym przez długi czas, bez ruchu i bez zapytań, może wymagać przekierowania, oznaczenia niedostępności albo usunięcia z listy stron indeksowalnych. Mechanizm nie powinien pozostawiać setek historycznych kombinacji tylko dlatego, że kiedyś miały produkty.

Zawiłości wdrożeniowe i pułapki techniczne przy modyfikacji layered navigation

Różnice między źródłem HTML, renderowanym DOM i odpowiedzią serwera

W sklepie korzystającym z AJAX filtr może zmieniać listę produktów bez pełnego przeładowania strony. Nie oznacza to jednak, że problem SEO znika. Trzeba sprawdzić, czy po zmianie filtrów:

• zmienia się adres w pasku przeglądarki;
• powstaje link możliwy do skopiowania i otwarcia w nowej sesji;
• serwer zwraca tę samą zawartość po bezpośrednim wejściu;
• renderowany DOM zawiera odnośniki do kolejnych wariantów;
• meta robots i canonical są aktualizowane dla każdej wersji.

Audyt należy wykonywać zarówno narzędziem crawlerowym, jak i testem bezpośrednich żądań HTTP. Widok poprawny w przeglądarce może po ponownym otwarciu adresu zwrócić kategorię bazową, błąd, pustą listę albo inny canonical.

Canonical zmieniany przez szablon lub rozszerzenie

Magento może generować canonical na poziomie kategorii, motywu lub modułu SEO. Konflikt pojawia się wtedy, gdy jeden komponent ustawia adres filtrowany, a inny zawsze wskazuje kategorię nadrzędną. Dodatkowo rozszerzenie może modyfikować canonical dopiero po załadowaniu konfiguracji sklepu lub zależnie od widoku store view. ^[4]

Weryfikacja powinna obejmować:

Najczęściej zadawane pytania (FAQ)

Czy każdy adres z filtrem w Magento powinien być blokowany?

Nie. Warto najpierw sprawdzić, czy dana kombinacja ma popyt wyszukiwawczy, unikalną intencję, wystarczającą liczbę produktów i możliwość przygotowania odrębnej treści.

Czy tag kanoniczny rozwiązuje problem filtrowanych adresów?

Nie zawsze. Kanoniczny adres może ograniczyć duplikację, ale nie zastępuje decyzji, które warianty powinny być stronami docelowymi SEO, a które wyłącznie widokami użytkowymi.

Jakie adresy filtrów najczęściej powodują problemy z indeksacją?

Najczęściej są to kombinacje wielu filtrów, adresy sortowania, paginacji, zmiany liczby produktów na stronie oraz warianty różniące się kolejnością parametrów.

Czy filtry wielokrotnego wyboru są bardziej ryzykowne?

Tak, ponieważ pozwalają tworzyć wiele kombinacji wartości. W niektórych implementacjach różne adresy mogą zwracać ten sam zestaw produktów.

Gdzie sprawdzić, jakie filtrowane adresy odkrywa Google?

Warto przeanalizować Google Search Console, logi serwera, crawlera, mapy XML oraz adresy generowane w kodzie strony, renderowanym DOM i przez JavaScript.

Źródła

• [1] Adobe Commerce – Layered navigation ↑
• [2] Google for Developers – Managing crawling of faceted navigation URLs ↑
• [3] Adobe Commerce – Meta data ↑
• [4] Search Engine Journal – The Technical Guide To Adobe Commerce (Magento) SEO Issues ↑