SEO dla Magento: crawl budget i indeksacja przy 100K+ produktów | Critical - Strategiczny Partner Marketingu Cyfrowego

Dlaczego duży katalog w Magento to wyzwanie dla SEO

50 000 produktów. 500 000 URL-i w indeksie. Dziesięć razy więcej stron, niż masz produktów. Brzmi jak błąd? Nie. Brzmi jak typowy sklep na Magento, który nikt nie skonfigurował pod kątem SEO.

Magento (Adobe Commerce) jest platformą, którą wybierają sklepy z rozbudowanym asortymentem. To naturalne środowisko dla tej platformy i jeden z powodów, dla których Magento w ogóle istnieje. Problem pojawia się wtedy, gdy nawigacja warstwowa, warianty konfigurowalnych produktów, paginacja, parametry sortowania i widoki multi-store generują adresów URL więcej niż Google jest w stanie sensownie przetworzyć.

Googlebot ma ograniczony crawl budget na każdą domenę. Jeśli marnuje go na setki tysięcy bezwartościowych stron filtrów, to Twoje kluczowe strony produktowe i kategorie mogą tygodniami czekać na ponowne zaindeksowanie. W tym artykule przechodzę przez konkretne mechanizmy Magento, które generują ten problem, i pokazuję, jak je opanować.

Skąd bierze się eksplozja URL-i w Magento

Zanim przejdziemy do rozwiązań, warto zrozumieć skalę problemu. W typowym sklepie Magento nadmiarowe URL-e powstają z kilku źródeł jednocześnie.

Nawigacja fasetowa to najczęstszy winowajca. Magento domyślnie tworzy osobny URL dla każdej kombinacji filtrów. Jeśli masz kategorię z 8 atrybutami, a każdy ma kilka wartości, liczba możliwych kombinacji rośnie wykładniczo.

Przykład: kategoria “buty damskie” z filtrami marka (20 wartości), rozmiar (15), kolor (10), materiał (5), sezon (4), cena (6 zakresów), styl (8) i obcas (4). 20 x 15 x 10 x 5 x 4 x 6 x 8 x 4 = 5 760 000 kombinacji. Prawie sześć milionów URL-i z jednej kategorii. Wszystkie dostępne dla Googlebota, wszystkie z niemal identyczną lub pustą treścią.

Warianty produktów konfigurowalnych

Magento rozróżnia produkty proste (simple) i konfigurowalne (configurable). Produkt konfigurowalny - na przykład koszulka dostępna w 5 kolorach i 4 rozmiarach - składa się z 20 produktów prostych. Domyślnie każdy z tych wariantów może mieć własny URL, co oznacza 21 adresów zamiast jednego.

Paginacja

Kategoria z 2000 produktów przy 24 produktach na stronę to 84 strony paginacji. Sam w sobie to nie jest tragiczny problem, ale w połączeniu z nawigacją warstwową każda strona paginacji istnieje dla każdej kombinacji filtrów.

Multi-store i wielojęzyczność

Magento obsługuje wiele sklepów (store views) w ramach jednej instalacji. Sklep działający w Polsce i Niemczech, z trzema wersjami językowymi, generuje trzy kopie każdego URL-a. Bez prawidłowej konfiguracji hreflang i kanonicznych adresów to prosta droga do masowych duplikatów.

Parametry sortowania i widoku

Sortowanie po cenie, nazwie, popularności, a do tego zmiana liczby produktów na stronie - każda taka opcja tworzy nowy parametr w URL-u. To kolejne mnożniki, które powiększają indeks o tysiące bezwartościowych stron.

Zarządzanie crawl budgetem - fundament technicznego SEO w Magento

Crawl budget to ilość zasobów, które Googlebot przeznacza na crawlowanie Twojej domeny. W małym sklepie z 500 produktami nie jest to temat, którym trzeba się zajmować. Przy 100 000+ produktów i nawigacji warstwowej staje się krytyczny.

robots.txt - pierwsza linia obrony

Plik robots.txt powinien blokować crawlowanie ścieżek, które nigdy nie powinny trafić do indeksu. W Magento 2 typowa konfiguracja obejmuje:

blokowanie parametrów sortowania i widoku (?product_list_order=, ?product_list_dir=, ?product_list_mode=)
blokowanie ścieżek wewnętrznych (/checkout/, /customer/, /catalogsearch/result/)
blokowanie stron porównania i listy życzeń (/catalog/product_compare/, /wishlist/)

Uwaga: robots.txt blokuje crawlowanie, ale nie gwarantuje usunięcia z indeksu. Jeśli strona jest linkowana z zewnątrz, Google może ją zaindeksować nawet bez crawlowania treści - pojawi się w wynikach z niepełnym opisem. Dlatego robots.txt to narzędzie uzupełniające, a nie jedyne rozwiązanie.

Meta robots noindex - kontrola indeksacji

Dyrektywa noindex mówi Googlebotowi wprost: “zaindeksuj tę stronę, ale nie pokazuj jej w wynikach wyszukiwania”. W kontekście Magento noindex powinien trafiać na:

strony filtrów nawigacji warstwowej (z wyjątkami, o których niżej)
strony wyników wyszukiwania wewnętrznego
strony porównania produktów
strony paginacji powyżej drugiej (opcjonalnie - Google radzi sobie z paginacją, ale przy 80+ stronach warto rozważyć)
strony z parametrami sortowania

Kluczowe: nie blokuj jednocześnie crawlowania (robots.txt) i nie ustawiaj noindex. Wybierz jedno lub drugie. Jeśli zablokujesz crawlowanie, Googlebot nie zobaczy dyrektywy noindex i strona może pozostać w indeksie.

Tagi canonical - wskazanie wersji głównej

Tagi canonical to jeden z najważniejszych elementów SEO w Magento przy dużym katalogu. Każda strona filtrów, sortowania czy wariantu powinna wskazywać kanoniczną wersję - czyli stronę, którą Google powinien traktować jako główną.

W Magento 2 canonical działa natywnie, ale wymaga prawidłowej konfiguracji w Stores > Configuration > Catalog > Search Engine Optimization. Upewnij się, że:

canonical dla kategorii wskazuje na URL bez parametrów filtrów i sortowania
canonical dla produktów wskazuje na URL bez parametru kategorii (Magento potrafi generować URL-e produktów z pełną ścieżką kategorii)
strony paginacji mają canonical wskazujący na pierwszą stronę (lub na siebie - zależy od strategii)

Mapa strony XML - kierowanie crawlerów

Sitemap XML w dużym sklepie Magento to nie jeden plik - to sitemap index z wieloma plikami podrzędnymi. Magento 2 generuje sitemapy automatycznie (Marketing > SEO & Search > Site Map), ale domyślna konfiguracja rzadko jest optymalna.

Więcej o strategii sitemapów w dalszej części artykułu.

Nawigacja warstwowa w Magento - co indeksować, a co blokować

To najważniejsza decyzja SEO w dużym sklepie na Magento. Domyślna nawigacja warstwowa generuje ogromną liczbę URL-i, ale nie wszystkie są bezwartościowe. Niektóre kombinacje filtrów odpowiadają na realne zapytania użytkowników i mogą generować ruch organiczny.

Które kombinacje filtrów indeksować

Zasada jest prosta: indeksuj te kombinacje, na które ludzie szukają w Google. Konkretnie:

marka + kategoria - tak. “Buty Nike damskie” to realne zapytanie z wolumenem wyszukiwań. Strona filtrów buty-damskie?marka=nike (lub lepiej - dedykowany URL buty-damskie/nike) powinna być widoczna dla Google.
typ produktu + materiał - sytuacyjnie. “Kurtki skórzane” ma wolumen, “skarpetki bawełniane” raczej nie.
kolor + rozmiar - nie. Nikt nie szuka “niebieskie buty rozmiar 42” w Google. Te strony filtrów powinny mieć noindex.
zakres cenowy - nie. Strony filtrów cenowych nie mają wartości SEO.
kombinacje trzech i więcej filtrów - prawie nigdy. Im więcej filtrów, tym mniejsza szansa, że ktoś tak szuka.

Jak to wdrożyć w Magento

Natywne Magento nie daje wystarczającej kontroli nad indeksacją nawigacji warstwowej. Potrzebny jest moduł zewnętrzny (np. Amasty Improved Layered Navigation, Mageworx SEO Suite) albo niestandardowe rozwiązanie, które pozwala:

generować przyjazne URL-e dla wybranych kombinacji filtrów (zamiast parametrów GET)
ustawiać noindex/nofollow dla pozostałych kombinacji
dodawać unikalne meta tagi i treści H1 dla indeksowanych stron filtrów
kontrolować canonical osobno dla każdego atrybutu

Bez takiego modułu zostajesz z dwoma opcjami: albo blokujesz całą nawigację warstwową (tracisz potencjalny ruch z fraz typu “marka + kategoria”), albo zostawiasz wszystko otwarte (marnujesz crawl budget na setki tysięcy pustych stron). Oba warianty są złe. Tyle że ten drugi jest gorszy, bo wygląda, jakby wszystko było w porządku.

Produkty konfigurowalne vs proste - obsługa SEO

Magento traktuje produkty konfigurowalne i proste jako osobne encje z osobnymi URL-ami. Z perspektywy SEO to problem, bo Google widzi dziesiątki stron z niemal identyczną treścią, różniących się tylko rozmiarem czy kolorem.

Canonical na produkt nadrzędny

Standardowe podejście: wszystkie warianty (produkty proste) powinny mieć canonical wskazujący na produkt konfigurowalny (nadrzędny). To komunikuje Google, że wersja główna to strona z selektorem wariantów, a poszczególne rozmiary czy kolory to nie osobne produkty.

W Magento 2: Stores > Configuration > Catalog > Search Engine Optimization > Use Canonical Link Meta Tag for Products. Ta opcja ustawia canonical, ale nie rozwiązuje problemu widoczności wariantów w nawigacji i linkach wewnętrznych.

Widoczność wariantów w katalogu

Najczystsze rozwiązanie to ustawienie widoczności produktów prostych na “Not Visible Individually” w panelu administracyjnym. Wtedy warianty nie pojawiają się w wynikach wyszukiwania wewnętrznego ani w listach kategorii - użytkownik trafia na stronę produktu konfigurowalnego i tam wybiera rozmiar/kolor.

Wyjątek: jeśli warianty różnią się na tyle, że zasługują na osobne pozycjonowanie (np. wersja produktu w zupełnie innym kolorze z osobną nazwą handlową), wtedy warto rozważyć osobne strony z unikalnymi treściami.

Dane strukturalne dla wariantów

Nawet jeśli warianty nie mają osobnych stron, ich dane powinny być widoczne w danych strukturalnych (Schema.org) na stronie produktu konfigurowalnego. Oznacz poszczególne warianty jako ProductModel lub offers z różnymi atrybutami - Google wykorzysta te dane do wyświetlania bogatych fragmentów w wynikach wyszukiwania.

Multi-store SEO - hreflang, canonical i duplikaty

Magento w konfiguracji multi-store to potężne narzędzie, ale z perspektywy SEO wymaga szczególnej uwagi. Dwa lub trzy store views mogą podwoić lub potroić liczbę URL-i, a bez odpowiednich sygnałów Google nie wie, która wersja jest dla którego rynku.

Implementacja hreflang

Hreflang informuje Google, że strona istnieje w wielu wersjach językowych lub regionalnych. W Magento wdrożenie hreflang obejmuje:

dodanie tagów hreflang w sekcji <head> każdej strony, wskazujących na odpowiedniki we wszystkich store views
uwzględnienie tagu x-default dla wersji domyślnej
zapewnienie dwustronności - jeśli strona PL wskazuje na DE, to strona DE musi wskazywać na PL
uwzględnienie hreflang w sitemapie XML (alternatywna metoda implementacji)

Magento natywnie nie generuje hreflang. Potrzebny jest moduł (np. Amasty Hreflang, Mageworx Cross-Linking) lub niestandardowe rozwiązanie w szablonie.

Canonical w kontekście multi-store

Kluczowe pytanie: czy canonical powinien wskazywać na wersję w tym samym store view, czy na jedną “główną” wersję? Odpowiedź: canonical powinien wskazywać na siebie w ramach danego store view. Każda wersja językowa/regionalna jest wersją kanoniczną sama dla siebie. To hreflang komunikuje relacje między wersjami, a canonical rozwiązuje duplikaty wewnątrz jednego store view (parametry, filtry, sortowanie).

Błąd, który widuję regularnie: ustawienie canonical ze wszystkich wersji językowych na wersję polską. Efekt: Google ignoruje wersje obcojęzyczne, bo canonical mówi mu, że to duplikaty strony polskiej. Robiłem audyt sklepu, który przez rok prowadził wersję niemiecką. Zero ruchu z google.de. Canonical wskazywał na polskie URL-e. Rok pracy w plecy, bo nikt nie sprawdził jednego tagu w nagłówku strony.

Treści unikalne vs wspólne

Każdy store view powinien mieć unikalne treści - przynajmniej meta title, meta description i opisy kategorii. Proste tłumaczenie maszynowe jest lepsze niż nic, ale Google coraz lepiej rozpoznaje treści niskiej jakości. Jeśli operujesz na rynku niemieckim czy czeskim, inwestycja w natywne treści się zwraca.

Elementy wspólne - zdjęcia, specyfikacje techniczne, numery katalogowe - mogą być takie same. To nie generuje problemów z duplikacją, bo hreflang jasno komunikuje, że to wersje tej samej strony dla różnych rynków.

Strategia sitemap XML dla dużych katalogów

Przy 100 000+ produktów sitemap XML to narzędzie, które aktywnie kieruje Googlebota na wartościowe strony. Źle skonfigurowany sitemap to zmarnowana szansa.

Sitemap index i podział

Magento 2 generuje sitemap index automatycznie, dzieląc produkty, kategorie i strony CMS na osobne pliki. Limit jednego pliku sitemap to 50 000 URL-i lub 50 MB (nowy limit Google to 50 MB). Przy dużym katalogu upewnij się, że:

każdy plik sitemap nie przekracza limitu
sitemap index jest dostępny i poprawnie linkuje do wszystkich plików podrzędnych
sitemap jest zgłoszony w Google Search Console i odświeżany automatycznie (cron job w Magento)

Co umieszczać w sitemapie

W sitemapie powinny znaleźć się wyłącznie strony, które chcesz mieć w indeksie Google. To oznacza:

strony produktów (widoczne, z canonical na siebie)
strony kategorii (główne, bez parametrów filtrów)
wybrane strony filtrów (te, które celowo indeksujesz - marka + kategoria)
strony CMS (o nas, kontakt, regulamin, blog)

Nie umieszczaj w sitemapie:

stron z noindex
stron wariantów produktów ustawionych na “Not Visible Individually”
stron paginacji (Google i tak je znajdzie przez linkowanie)
stron z parametrami sortowania i widoku

Priority i changefreq

Google oficjalnie mówi, że ignoruje te atrybuty. W praktyce nie warto poświęcać czasu na ich optymalizację. Jeśli je ustawiasz, zachowaj spójność: strona główna i kluczowe kategorie mogą mieć wyższy priorytet, ale nie dawaj priority 1.0 wszystkim produktom - to nic nie zmienia, a jedynie zaburza sygnał.

Analiza logów serwera - co naprawdę crawluje Googlebot

Wszystkie powyższe działania to teoria. Jedynym sposobem weryfikacji, czy crawl budget jest wykorzystywany efektywnie, jest analiza logów serwera.

Czego szukać w logach

Filtruj logi po user-agent Googlebota i analizuj:

rozkład crawlowania - ile procent requestów trafia na strony produktów, ile na filtry, ile na strony techniczne. Jeśli 60% crawlowania to strony nawigacji warstwowej, masz problem. Spoiler: w większości sklepów Magento, które audytuję, ten odsetek jest bliżej 70%.
częstotliwość crawlowania kluczowych stron - jak często Googlebot odwiedza Twoje najważniejsze kategorie i strony produktowe. Jeśli rzadziej niż raz w tygodniu, crawl budget jest marnowany na inne zasoby.
kody odpowiedzi - ile requestów zwraca 200 (OK), ile 301/302 (przekierowania), ile 404 (nie znaleziono), ile 500 (błąd serwera). Duży odsetek 404 i 301 to sygnał, że Googlebot crawluje nieistniejące strony.
czas odpowiedzi serwera - jeśli strony ładują się powyżej 2 sekund, Googlebot zmniejszy częstotliwość crawlowania.

Narzędzia do analizy logów

Do analizy logów dużego sklepu Magento sprawdzają się:

Screaming Frog Log File Analyser - dedykowane narzędzie do analizy logów SEO, filtruje po botach, pokazuje rozkład crawlowania
GoAccess - lekkie narzędzie open source do szybkiej analizy logów z poziomu terminala
ELK Stack (Elasticsearch, Logstash, Kibana) - dla dużych wolumenów danych, gdy potrzebujesz zaawansowanych wizualizacji i alertów

Rekomendacja: analizuj logi co najmniej raz w miesiącu. Po każdej większej zmianie (nowa kategoria, zmiana struktury URL, wdrożenie modułu SEO) rób analizę natychmiast, żeby wychwycić problemy zanim wpłyną na indeksację.

Narzędzia i moduły do SEO w Magento

Natywne Magento daje podstawy SEO, ale do zarządzania dużym katalogiem potrzebne są dodatkowe narzędzia.

Moduły Magento

Amasty SEO Toolkit - zestaw modułów obejmujący obsługę hreflang, rich snippets, przyjaznych URL-i, cross-linking i HTML/XML sitemap. Popularny wybór dla Magento 2.
Mageworx SEO Suite Ultimate - konkurencyjne rozwiązanie z kontrolą canonical, zarządzaniem przekierowaniami i obsługą nawigacji warstwowej. Oferuje zaawansowaną kontrolę indeksacji filtrów.
Mageplaza SEO Extension - bezpłatna wersja bazowa z rozszerzeniami premium. Dobre rozwiązanie na start.

Narzędzia do crawlowania i audytów

Screaming Frog SEO Spider - przy dużych katalogach wymaga odpowiedniej konfiguracji (tryb database, zarządzanie pamięcią). Pozwala na crawlowanie setek tysięcy URL-i i identyfikację problemów z canonical, noindex, duplikatami.
Sitebulb - alternatywa z lepszą wizualizacją i automatycznymi rekomendacjami. Łatwiejszy w obsłudze niż Screaming Frog, ale wolniejszy na dużych zbiorach.
Google Search Console - podstawowe, bezpłatne narzędzie. Raport “Strony” pokazuje, ile stron jest zaindeksowanych, a ile wykluczonych i dlaczego. Raport “Statystyki crawlowania” daje wgląd w aktywność Googlebota.

Workflow audytu technicznego

Przy sklepach Magento z ponad 100 000 produktów rekomendowany workflow wygląda tak:

crawl domeny Screaming Frogiem (lub Sitebulb) z limitem głębokości crawla
analiza logów serwera - porównanie tego, co crawluje Googlebot z tym, co chcesz indeksować
sprawdzenie raportów indeksacji w Google Search Console
identyfikacja rozbieżności i wdrożenie poprawek
monitoring przez 2-4 tygodnie i ponowna analiza

Jeśli szukasz wsparcia w optymalizacji SEO dla dużego sklepu na Magento, na stronie SEO dla Magento opisujemy nasz zakres pracy i podejście do platform e-commerce.

FAQ

Czy Magento 2 ma lepsze SEO niż Magento 1?

Tak, ale nie rewolucyjnie. Magento 2 poprawia kilka rzeczy natywnie - generuje sitemap XML, obsługuje canonical (choć wymaga konfiguracji), lepiej radzi sobie z przyjaznym URL-ami. Fundamentalne problemy - nawigacja warstwowa, warianty, multi-store - wymagają modułów zewnętrznych w obu wersjach. Jeśli nadal jesteś na Magento 1, to brak wsparcia bezpieczeństwa jest ważniejszym argumentem za migracją niż samo SEO.

Ile URL-i powinien mieć sklep Magento z 50 000 produktów w indeksie Google?

Nie ma jednej prawidłowej liczby, ale stosunek URL-i w indeksie do liczby realnych produktów i kategorii powinien być rozsądny. Jeśli masz 50 000 produktów i 200 kategorii, to indeks w okolicach 55 000-65 000 stron jest zdrowy (produkty + kategorie + CMS + wybrane filtry). Jeśli w indeksie jest 300 000 stron, to sygnał, że coś jest nie tak.

Czy powinienem blokować całą nawigację warstwową w robots.txt?

Nie polecam. Blokowanie w robots.txt nie usuwa stron z indeksu - jeśli Google już je zaindeksował, mogą tam pozostać. Lepsze podejście to selektywne noindex (blokujesz bezwartościowe kombinacje filtrów) przy jednoczesnym indeksowaniu wartościowych kombinacji (marka + kategoria). Robots.txt rezerwuj dla ścieżek, które Googlebot nie powinien w ogóle crawlować - checkout, konto klienta, porównanie produktów.

Jak często Googlebot crawluje duży sklep Magento?

Zależy od autorytetu domeny, szybkości serwera i ilości nowych treści. Duże, aktywne sklepy mogą mieć 50 000-200 000 requestów Googlebota dziennie. Małe sklepy na współdzielonym hostingu - kilkaset. Dane znajdziesz w Google Search Console w raporcie “Statystyki crawlowania”. Jeśli widzisz spadek crawlowania, sprawdź czas odpowiedzi serwera i liczbę błędów 5xx.

Czy warto przenosić duży sklep z Magento na inną platformę ze względu na SEO?

Samo SEO rzadko jest wystarczającym powodem do migracji platformy. Problemy z crawl budgetem i indeksacją w Magento da się rozwiązać odpowiednimi modułami i konfiguracją. Migracja dużego sklepu to projekt ryzykowny - utrata widoczności przy zmianie struktury URL-i, przekierowania, zmiana danych strukturalnych. Jeśli rozważasz migrację z innych powodów (koszty utrzymania, wydajność, rozwój), to SEO powinno być częścią planowania, ale nie głównym motorem decyzji.