SEO w Magento

TL;DR — SEO w Magento polega na pomaganiu sklepowi Magento w rankingu w wyszukiwarkach. Po pierwsze, poznaj swoją wersję: Magento 1 jest martwe (brak aktualizacji od czerwca 2020), a Magento 2 występuje w wersji płatnej (Adobe Commerce) i darmowej (Magento Open Source). Rzeczą, która najbardziej psuje SEO w Magento, jest jego system filtrów — „nawigacja warstwowa” — który może tworzyć tysiące zduplikowanych adresów stron. Większość Twojej pracy polega na utrzymaniu ich pod kontrolą.

Czym jest Magento (i którą wersję masz)

Magento to platforma do budowania sklepów internetowych. W przeciwieństwie do Shopify, gdzie firma hostuje wszystko za Ciebie, Magento to coś, co Ty (lub Twoi programiści) instalujesz i uruchamiasz samodzielnie. To daje Ci dużą kontrolę — i dużo odpowiedzialności.

Zanim cokolwiek zrobisz, ustal, na której wersji Magento pracujesz:

• Magento 1 — stara wersja. Osiągnęła koniec wsparcia w czerwcu 2020 i nie otrzymuje już aktualizacji zabezpieczeń. Jeśli tu jesteś, Twój prawdziwy projekt SEO to migracja do Magento 2 (zrób to ostrożnie, z przekierowaniami).
• Magento 2 — aktualna wersja. Występuje jako Adobe Commerce (płatna, korporacyjna edycja) oraz Magento Open Source (darmowa, społecznościowa edycja). Dzielą ten sam rdzeń kodu, więc porady SEO są takie same.
• Adobe Commerce as a Cloud Service (ACCS) — nowszy, oddzielny produkt SaaS (uruchomiony w czerwcu 2025), który działa na innej infrastrukturze i nie obsługuje klasycznego motywu Luma w ogóle. Jeśli Twój sklep jest na ACCS, traktuj porady dotyczące motywu/schematu napisane dla „zwykłego” Magento jako punkt wyjścia, a nie bezpośrednie dopasowanie.

Nie myl tych wersji. Wiele starych poradników „SEO w Magento” online jest napisanych dla Magento 1, a menu i ustawienia po prostu już nie pasują.

Jeden wielki problem: filtry

Gdy kupujący trafia na stronę kategorii — na przykład „Buty do biegania” — Magento pokazuje filtry z boku: rozmiar, kolor, marka, cena. Ta funkcja nazywa się nawigacją warstwową i jest świetna dla kupujących.

Problem SEO polega na tym, że każdy filtr, który ktoś kliknie, zwykle tworzy nowy adres strony, na przykład /running-shoes?color=blue&size=10. Pomnóż kolory × rozmiary × marki × przedziały cenowe, a pojedyncza kategoria może wygenerować tysiące nieco różniących się stron — wszystkie pokazujące zasadniczo te same produkty. Wyszukiwarki widzą bałagan prawie zduplikowanych stron, nie wiedzą, którą pokazać, i marnują czas na indeksowanie śmieci zamiast Twoich prawdziwych produktów.

Rozwiązaniem jest powiedzenie wyszukiwarkom: „te przefiltrowane strony nie są ważne — czysta strona kategorii jest”. Robisz to za pomocą kanonicznego tagu (wskaźnika do głównej wersji) oraz oznaczając strony filtrów o niskiej wartości jako noindex (nie umieszczaj tego w wynikach wyszukiwania). Magento ma ustawienia do tego, a rozszerzenia SEO ułatwiają to.

Inne rzeczy do skonfigurowania

• Przyjazne adresy URL. Magento może generować czyste adresy, takie jak /running-shoes/nike-pegasus/ zamiast długiego kodu. Upewnij się, że ustawienie „przyjazne dla wyszukiwarek adresy URL” jest włączone.
• Tytuły i opisy. Każdy produkt i kategoria ma pola na tytuł strony i meta opis — wypełnij je zamiast zostawiać domyślne wartości Magento.
• Dane strukturalne (schema). To kod, który zasila ceny i oceny gwiazdkowe widoczne w wynikach Google. Magento nie dodaje tego automatycznie, więc będziesz potrzebować rozszerzenia lub programisty, aby to dodać.
• Warianty produktów. Jeśli produkt występuje w wielu rozmiarach lub kolorach, Magento zwykle przechowuje każdą kombinację jako osobny „produkt prosty” powiązany z rodzicem. Pozostawione same sobie mogą być indeksowane jako osobne prawie zduplikowane strony — wskaż je z powrotem do produktu nadrzędnego za pomocą kanonicznego tagu.

Chcesz szczegółową, techniczną wersję — dokładne ustawienia, tabelę przepisywania adresów URL i jak obsługiwać filtry na dużą skalę? Przełącz się na zakładkę Zaawansowane.

TL;DR — SEO w Magento zdominowane jest przez dwa generatory zduplikowanych treści: nawigacja warstwowa generująca adresy URL z parametrami oraz warianty produktów konfigurowalnych/prostych generujące prawie identyczne strony SKU. Dla obu zastosuj kanoniczne adresy URL wskazujące na czystą wersję nadrzędną (kategorię lub produkt konfigurowalny) i dodaj noindex do kombinacji o niskiej wartości; zarezerwuj strony indeksowalne dla filtrów lub wariantów z realnym popytem w wyszukiwarkach. Najpierw rozstrzygnij kwestię wersji — Magento 1 osiągnęło koniec wsparcia (czerwiec 2020); Magento 2 dostępne jest jako Adobe Commerce (płatne, hostowane samodzielnie), Magento Open Source (darmowe) lub Adobe Commerce as a Cloud Service (ACCS — osobny produkt SaaS od czerwca 2025, który całkowicie rezygnuje z Luma). Adresy URL przyjazne SEO działają przez tabelę url_rewrite — odrębną od przekierowań HTTP, które Magento może automatycznie tworzyć jako 301. Dane strukturalne różnią się w zależności od motywu sklepu i rozszerzeń, więc przed planowaniem niestandardowych prac sprawdź wyrenderowane strony.

Krok zerowy: ustal wersję

Połowa złych porad dotyczących SEO w Magento w internecie jest zła, ponieważ jest skierowana do niewłaściwej wersji. Ustal to przed czymkolwiek innym:

• Magento 1 osiągnęło koniec wsparcia 30 czerwca 2020 roku. Brak poprawek bezpieczeństwa, brak aktualizacji. Jeśli klient nadal na nim pracuje, praca SEO to migracja do Magento 2 — z pełną mapą przekierowań i kontrolą jakości opartą na crawl, traktowana jak każda migracja platformy, w której na szali leży autorytet rankingowy.
• Magento 2 to aktywna baza kodu. Występuje w dwóch edycjach: Adobe Commerce (płatna; funkcje B2B, page builder, opcja hostowanego PaaS) oraz Magento Open Source (darmowa; edycja społecznościowa). Ten sam rdzeń, ta sama powierzchnia SEO. Zmiana brandingu Adobe oznacza, że „Magento”, „Adobe Commerce” i „Magento Open Source” pojawiają się dla tej samej platformy — nie daj się zwieść nazewnictwu, myśląc, że model SEO się różni.
• Adobe Commerce as a Cloud Service (ACCS) to trzeci, osobny produkt — wdrożenie SaaS uruchomione w czerwcu 2025 ze sklepem opartym na Edge Delivery Services, a nie na tradycyjnym stosie Commerce/Luma. Luma nie jest w ogóle wspierane w ACCS, więc jeśli sklep na nim działa, poniższe uwagi dotyczące motywu Luma i schematów nie mają zastosowania — przebudowujesz tę warstwę od zera, a nie ją dostosowujesz.

Wszystko poniżej zakłada samodzielnie hostowane Magento 2 (Adobe Commerce lub Magento Open Source, na Luma lub Hyvä), chyba że ACCS jest wyraźnie wskazane.

Nawigacja warstwowa to cała gra

Jeśli naprawisz tylko jedną rzecz w sklepie Magento, napraw nawigację warstwową. To termin Magento na filtrowanie fasetowe na stronach kategorii, a domyślnie każdy wybór filtra dodaje parametr zapytania:

/running-shoes
/running-shoes?color=159
/running-shoes?color=159&size=42
/running-shoes?color=159&size=42&price=50-100
/running-shoes?size=42&color=159        ← same filters, different order = new URL

Jedno wyjaśnienie, zanim skopiujesz jakąkolwiek strategię crawl/indeksowania na sklep: Adobe dokumentuje standardową nawigację warstwową i Live Search (płatną, opartą na AI funkcję faset Adobe Commerce) jako odrębne implementacje o różnym zachowaniu filtrów/adresów URL. Poniższe wskazówki dotyczące kanonicznych adresów URL i noindex są napisane dla standardowej nawigacji warstwowej — jeśli sklep korzysta z Live Search, potwierdź rzeczywiste wzorce adresów URL, które generuje, zanim założysz, że te same zasady mają zastosowanie.

Eksplozja kombinatoryczna to problem. Katalog kilku tysięcy SKU może generować dziesiątki tysięcy możliwych do przeszukania, prawie zduplikowanych adresów URL. To kanoniczny wzorzec awarii nawigacji fasetowej, a Gary Illyes podał liczby dotyczące tego, jak wiele problemów sprawia to Google — nawigacja fasetowa to największe pojedyncze źródło skarg dotyczących marnowania zasobów crawl, jakie otrzymują (patrz zakładka Cytaty). Szkody po Twojej stronie: zduplikowane/prawie zduplikowane treści, rozdęty indeks, zasoby crawl marnowane na śmieci i wewnętrzny PageRank rozproszony na setki linków filtrów na każdej stronie kategorii.

Decyzja jest binarna, dla każdego wzorca adresu URL: czy ta przefiltrowana strona zasługuje na miejsce w indeksie, czy nie?

Dla ~99%, które nie zasługują (większość kombinacji kolor/rozmiar/cena/sortowanie nie ma popytu w wyszukiwarkach):

• Kanoniczny przefiltrowany URL do czystego URL kategorii. Ustawienie Magento 2 „Use Canonical Link Meta Tag for Categories” (Stores → Configuration → Catalog → Catalog → Search Engine Optimization) pomaga, ale samo w sobie wskazuje kategorię na nią samą, a nie warianty przefiltrowane na rodzica — więc dla URL z parametrami zwykle polegasz na rozszerzeniu SEO lub logice szablonu, aby wygenerować właściwy kanoniczny.
• noindex dla kombinacji filtrów o niskiej wartości, aby wypadły z indeksu. Pamiętaj o zasadzie Google: noindex wymaga, aby strona była indeksowalna — nigdy nie łącz noindex z robots.txt Disallow na tym samym URL, bo Googlebot nie będzie mógł odczytać tagu.
• Rozważ robots.txt disallow dla czysto kombinatorycznych przestrzeni parametrów, jeśli budżet indeksowania jest ostrym problemem — ale pamiętaj, że kontroluje to indeksowanie, a nie indeksację, i nie usunie już zaindeksowanych URL.

Dla mniejszości, KTÓRE MAJĄ popyt (np. strona typu “/running-shoes/nike/” gdzie filtr marki jest prawdziwym zapytaniem): promuj je do indeksowalnych stron lądowania z czystymi URL — unikalny tekst wprowadzający, samoodnoszący się kanoniczny, linki wewnętrzne, uwzględnienie w mapie witryny. To tam fasetowana nawigacja Magento zmienia się z obciążenia w atut długiego ogona. (Pełne omówienie w hubie faceted navigation, kanonicznym miejscu dla tego tematu po stronie Ecommerce; mechanika po stronie indeksowania znajduje się w URL parameters i crawl budget.)

Przepisywania URL i przyjazne SEO URL

Magento generuje czyste URL poprzez przepisywania URL, przechowywane w tabeli bazy danych url_rewrite i zarządzane w Adminie pod Marketing → SEO & Search → URL Rewrites. Dokumentacja Adobe wyraźnie rozróżnia dwa terminy, które są używane luźno: przepisanie to mapowanie po stronie serwera, które zmienia to, co się ładuje, bez dotykania paska adresu przeglądarki, podczas gdy przekierowanie wysyła przeglądarce odpowiedź HTTP informującą ją o nawigacji do innego URL — pasek adresu się aktualizuje. Automatyczne 301 przy zmianie klucza URL w Magento to przekierowanie; tabela url_rewrite przechowuje także wewnętrzne przepisania, które nigdy nie są widoczne dla odwiedzającego. Dwa ustawienia robią większość ciężkiej pracy:

• „Use Web Server Rewrites” (Stores → Configuration → General → Web → Search Engine Optimization) usuwa index.php z URL.
• Sufiksy URL / ścieżka kategorii w URL. Magento może zawierać ścieżkę kategorii w URL produktu (/men/shoes/nike-pegasus). Bądź świadomy: zawarcie ścieżki kategorii oznacza, że produkt w wielu kategoriach może być dostępny pod wieloma URL, odtwarzając duplikację — co jest dokładnie powodem, dla którego Magento dodaje opcje kanoniczne również dla produktów („Use Canonical Link Meta Tag for Products”). Wielu specjalistów SEO Magento ustawia URL produktów bez ścieżki kategorii, aby całkowicie tego uniknąć.

Gdy zmienisz klucz URL produktu lub kategorii, Magento może automatycznie utworzyć 301 w tabeli url_rewrite („Create Permanent Redirect for old URL”). Potwierdź, że ten przełącznik jest włączony przed jakimikolwiek masowymi edycjami URL, w przeciwnym razie pozostawisz zaindeksowane URL na 404. Przed zmianą ustawień ścieżki kategorii lub sufiksu na działającym sklepie, zinwentaryzuj wzorce URL dotknięte per widok sklepu i przygotuj plan przekierowań/kanonicznych, zamiast przełączać przełącznik i mieć nadzieję — dokumentacja Adobe ostrzega, że ponowne generowanie przepisań dla kategorii z wieloma przypisanymi produktami może być realnym obciążeniem wydajnościowym, nie tylko SEO.

Produkty konfigurowalne i proste: drugi czynnik duplikacji treści

Nawigacja warstwowa to nie jedyny sposób, w jaki katalog Magento generuje prawie zduplikowane adresy URL. Produkty konfigurowalne (produkt nadrzędny — „But do biegania”) zbudowane z produktów prostych (rzeczywiste kombinacje rozmiarów i kolorów, które można kupić) tworzą ten sam problem na skalę katalogu. Paul Rogers z Vervaunt dobrze opisuje tę matematykę: sklep modowy z 3 000 produktów nadrzędnych, każdy w 8 rozmiarach i 6 kolorach, może wygenerować 144 000 kombinacji produktów prostych. W Magento te kombinacje są relacją katalogową, a nie decyzją indeksacyjną — bez jawnej polityki kanonicznej Googlebot może znaleźć je wszystkie jako osobne, indeksowalne adresy URL prowadzące do prawie identycznych treści.

Poradniki praktyków są zgodne: ustaw canonical każdego produktu prostego na jego produkt nadrzędny (konfigurowalny) i nie polegaj wyłącznie na ustawieniach widoczności w katalogu — produkt prosty ustawiony jako „Niewidoczny indywidualnie” jest nadal osiągalny przez bezpośredni URL, mapę witryny lub link wewnętrzny, więc Googlebot może go zaindeksować, nawet jeśli jest ukryty w nawigacji. Jawny tag canonical wskazujący na produkt nadrzędny to właściwe rozwiązanie, a ponieważ jest renderowany po stronie serwera, nie zależy od JavaScriptu.

Indeksuj wariant osobno tylko wtedy, gdy ma realny, niezależny popyt w wyszukiwarkach, który możesz wyróżnić unikalną treścią — konkretną kombinację koloru/rozmiaru, której ludzie szukają po nazwie, a nie każdy SKU domyślnie.

Sprawdź w Stores → Configuration → Catalog → Catalog → Search Engine Optimization, czy opcja „Use Canonical Link Meta Tag for Products” jest włączona, a następnie potwierdź — na faktycznie wyrenderowanej stronie, nie tylko w ustawieniu — że adresy URL produktów prostych zawierają canonical prowadzący do produktu nadrzędnego.

Luka w JSON-LD

To często zaskakuje, ponieważ zakłada się, że tak duża platforma radzi sobie ze schematem. Magento 2 nie generuje danych strukturalnych JSON-LD po wyjęciu z pudełka. Niektóre motywy emitują mikrodane na stronach produktów, ale:

• Google zaleca JSON-LD jako format implementacji zamiast mikrodanych/RDFa (zobacz zakładkę Official Docs).
• Aby kwalifikować się do rozszerzonych wyników produktów, potrzebujesz schematu Product z polami name, image, description, offers (cena, waluta, dostępność) oraz — dla ocen gwiazdkowych — aggregateRating/review, które muszą pochodzić z prawdziwych recenzji.

Uzyskanie rozszerzonych wyników w Magento to zatem zadanie dla rozszerzenia lub własnego rozwoju: dedykowane rozszerzenie danych strukturalnych, motyw obsługujący schemat lub praca nad szablonem, która generuje JSON-LD. Gdy je dodasz, sprawdź pod kątem zduplikowanego schematu — jeśli pozostałości mikrodanych z motywu i JSON-LD z rozszerzenia oba opisują produkt, możesz wysłać dwa sprzeczne bloki Product. Wybierz jedno źródło prawdy.

Reszta powierzchni technicznej

• Tagi kanoniczne. Poza kategoriami/produktami zwróć uwagę na stronę główną (/ vs ?___store= i podobne parametry widoku sklepu), paginację oraz parametry widoku sklepu/języka, które Magento dodaje. Zobacz kanonikalizacja oraz tag kanoniczny – szczegółowe omówienia.
• Paginacja. Magento paginuje kategorie za pomocą ?p=2. Nadaj każdej stronie unikalny, samoodnoszący się kanonik — nie kanonizuj strony 2+ z powrotem do strony 1, i nie stosuj noindex dla całej sekwencji (może to obciąć link equity do produktów wymienionych tylko głęboko na stronach). rel=prev/next jest martwe; nie polegaj na nim.
• Widoki sklepu (wielojęzyczne / wielostanowiskowe). Architektura widoków sklepu w Magento jest potężna w przypadku konfiguracji międzynarodowych, ale jest klasycznym źródłem zduplikowanych treści i brakujących/niedopasowanych hreflang. Jeśli prowadzisz wiele widoków sklepu na jednym katalogu, hreflang to ręczna praca, a częściowe wdrożenie jest gorsze niż żadne.
• Produkty niedostępne i wyłączone. Zdecyduj o polityce: utrzymuj rankingowe strony na żywo ze statusem dostępności lub 404/410 + przekierowanie trwale usuniętych SKU. Nie wyłączaj produktów po cichu i nie zostawiaj ich URL-i z 404 i linkami przychodzącymi.
• Core Web Vitals. Wydajność samo-hostowanego Magento zależy w całości od Twojej infrastruktury. Pełna pamięć podręczna stron (Varnish), CDN, optymalizacja obrazów (WebP) oraz zdyscyplinowana higiena rozszerzeń/JS to dźwignie. Dwie różne ścieżki headless są tu mylone, więc bądź precyzyjny, którą oceniasz: PWA Studio to starszy, oparty na React storefront Adobe, nałożony na istniejącą infrastrukturę Commerce, podczas gdy Adobe Commerce as a Cloud Service (ACCS) to oddzielny produkt SaaS na Edge Delivery Services, gdzie Luma nie jest w ogóle wspierana. Każda z nich może podnieść sufit CWV, ale obie dodają własne kwestie renderowania i indeksowania — potwierdź, którą (lub żadną) sklep faktycznie uruchamia, zanim zaplanujesz migrację headless dla CWV.

Co faktycznie priorytetyzować

W większości audytów Magento kolejność wpływu jest następująca:

1. Nawigacja warstwowa — strategia kanonik + noindex dla URL-i z parametrami. To największa część wartości technicznego SEO.
2. Kanonikalizacja produktów konfigurowalnych/prostych — kanonizuj proste SKU do ich nadrzędnego produktu konfigurowalnego; zweryfikuj to na wyrenderowanych stronach, nie tylko w ustawieniu administracyjnym.
3. Przepisywania URL-i i przekierowania — przyjazne URL-e włączone, przekierowanie przy zmianie włączone, bez osieroconych 404.
4. Schema — dodaj JSON-LD (brak natywnego wsparcia), unikaj zduplikowanych bloków.
5. Tytuły/meta + treść kategorii — wypełnij pola; kategorie są domyślnie puste.
6. Wydajność — pamięć podręczna, CDN, obrazy.

Wszystko inne to dopracowanie. Magento daje Ci pełną kontrolę, co oznacza, że prawie każdy problem SEO w sklepie Magento to wybór konfiguracji, który możesz naprawić — i prawie każdy zaczyna się od filtrów.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• SEO w Magento jest zdominowane przez dwa generatory zduplikowanych treści. Nawigacja warstwowa (filtrowanie fasetowe) dodaje parametry filtrów do adresów URL kategorii; warianty produktów konfigurowalnych/prostych generują prawie identyczne adresy URL SKU. Oba wymagają tego samego podejścia: kanoniczne do czystego rodzica (kategorii lub produktu konfigurowalnego) oraz noindex dla kombinacji o niskiej wartości; promuj tylko filtry/warianty z realnym popytem w wyszukiwarkach na stronach indeksowalnych.
• Wersja ma znaczenie: Magento 1 jest zakończone (czerwiec 2020) — migruj. Magento 2 jest dostępne jako Adobe Commerce (płatne, samodzielnie hostowane) i Magento Open Source (darmowe) z jednej bazy kodu, plus osobny produkt SaaS, Adobe Commerce as a Cloud Service (ACCS, od czerwca 2025), który całkowicie rezygnuje z motywu Luma.
• Nawigacja warstwowa vs. Live Search: Adobe dokumentuje standardową nawigację warstwową i płatne, oparte na AI fasetki Live Search jako odrębne implementacje z różnym zachowaniem adresów URL — potwierdź, którą faktycznie używa sklep, zanim zastosujesz reguły indeksowania/czołgania.
• Produkty konfigurowalne/proste: ustaw kanoniczne proste SKU na ich nadrzędny produkt konfigurowalny; same ustawienia widoczności w katalogu nie powstrzymują Google przed znalezieniem i indeksowaniem ich przez sitemap lub bezpośredni URL.
• Adresy URL: przyjazne SEO adresy URL działają przez tabelę url_rewrite (Admin → Marketing → SEO & Search → URL Rewrites) — odrębną od przekierowań HTTP, które Magento może automatycznie tworzyć jako 301. Włącz przepisywanie na serwerze WWW i przekierowanie przy zmianie URL; zinwentaryzuj dotknięte wzorce URL przed zmianą ustawień ścieżek kategorii lub sufiksów.
• Luka w schemacie: Magento 2 domyślnie nie emituje JSON-LD (mikrodane tylko w niektórych motywach). Google zaleca JSON-LD, więc schemat dla wyników rozszerzonych to zadanie rozszerzenia/własnego rozwoju — i uważaj na zduplikowane bloki Product.
• Zajmij się też: paginacją (unikalne, samoodnoszące się kanoniki, nigdy noindex dla serii), duplikacją widoków sklepu + hreflang dla sklepów wielojęzycznych, polityką braków magazynowych i Core Web Vitals — pamiętając, że PWA Studio i ACCS to dwie różne ścieżki headless, nie zamienne.
• Kolejność priorytetów: nawigacja warstwowa → kanonizacja produktów konfigurowalnych/prostych → przepisywanie/przekierowania URL → schemat → tytuły/meta/treść kategorii → wydajność.

Oficjalna dokumentacja

Dokumentacja ze źródeł pierwotnych. Własna dokumentacja Magento obejmuje ustawienia platformy; dokumentacja Google obejmuje zachowania SEO, które te ustawienia muszą spełniać.

Adobe / Magento

• Adobe Commerce / Magento Open Source — SEO best practices — oficjalny przewodnik konfiguracji SEO (URL-e, metadane, sitemapy, robots.txt).
• URL rewrites — jak działa system url_rewrite w Admin.
• Search Engine Optimization (config reference) — przepisywanie na serwerze WWW, sufiksy URL i ustawienia SEO w Stores → Configuration.
• Layered navigation — dokumentacja Adobe funkcji filtrowania, która jest sercem SEO w Magento.
• Software lifecycle / Magento 1 end-of-life — wsparcie wersji i koniec życia Magento 1 w czerwcu 2020.

Google — co Twoja konfiguracja Magento musi spełniać

• Wprowadzenie do danych strukturalnych produktu — wymagane/zalecane pola Product; zalecany JSON-LD.
• Dane strukturalne dla sklepów ecommerce — typy schematów ecommerce obsługiwane przez Google.
• Paginacja i stopniowe ładowanie stron — unikalne adresy URL, strony z własnym kanonicznym, noindex dla filtrów, nie dla paginacji.
• Zarządzanie indeksowaniem adresów URL nawigacji fasetowej — oficjalne wytyczne Google dotyczące problemu nawigacji warstwowej.
• Optymalizacja budżetu indeksowania — dlaczego rozrost parametrów ma znaczenie na dużą skalę.

Cytaty ze źródła

Wypowiedzi na temat części Magento SEO, które faktycznie mają znaczenie — nawigacja fasetowa, dane strukturalne i paginacja. Każdy link to link bezpośredni, który prowadzi do cytowanego fragmentu, jeśli źródło to umożliwia.

Google — dane strukturalne (schemat, którego Magento nie dodaje za Ciebie)

• “Merchant listings: For pages where customers can purchase products from you. This markup has more options for specifying detailed product information, like apparel sizing, shipping details, and return policy information.” (tłumaczenie) „Merchant listings: dla stron, na których klienci mogą kupić od Ciebie produkty. Ten znacznik ma więcej opcji określania szczegółowych informacji o produkcie, takich jak rozmiary odzieży, szczegóły wysyłki i informacje o polityce zwrotów.” — Google Search Central, Wprowadzenie do danych strukturalnych produktu. Przejdź do cytatu
• “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data.” (tłumaczenie) „Dostarczanie zarówno danych strukturalnych na stronach internetowych, jak i pliku danych w Merchant Center maksymalizuje Twoją kwalifikowalność do doświadczeń i pomaga Google poprawnie zrozumieć i zweryfikować Twoje dane.” Przejdź do cytatu

Google — paginacja (strony kategorii Magento z ?p=)

• “Give each page a unique URL” (tłumaczenie) „Nadaj każdej stronie unikalny adres URL” — i przypisz każdej stronie własny kanoniczny, zamiast wskazywać wszystkie na pierwszą stronę. — Google Search Central, Paginacja i stopniowe ładowanie stron. Przejdź do cytatu
• “Apply noindex meta tags to filter variations or alternative sort orders” (tłumaczenie) „Zastosuj meta tagi noindex do wariantów filtrów lub alternatywnych sortowań” — czyli do faset, nie do samej sekwencji paginacji. Przejdź do cytatu

Gary Illyes, Google — dlaczego nawigacja warstwowa jest głównym ryzykiem

• O fasetowych/przestrzeniach URL z parametrami: “Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.” (tłumaczenie) „Gdy odkryje zestaw adresów URL, nie może podjąć decyzji, czy ta przestrzeń URL jest dobra, czy nie, dopóki nie przeszuka dużej części tej przestrzeni URL.”

  Przekazane za pośrednictwem relacji Search Engine Land z raportu o indeksowaniu Search Off the Record za rok 2025; potwierdź w oryginalnym odcinku przed uznaniem za ostateczne. Według tej relacji nawigacja fasetowa jest pojedynczym największym źródłem zgłoszeń problemów z indeksowaniem, które otrzymuje Google (~50 %).

  Przeczytaj relację
• “Sometimes you might create these new fake URLs accidentally, exploding your URL space from a balmy 1000 URLs to a scorching 1 million, exciting crawlers that in turn hammer your servers unexpectedly.” (tłumaczenie) „Czasami możesz przypadkowo utworzyć te nowe fałszywe adresy URL, rozszerzając swoją przestrzeń URL z przyjemnych 1000 adresów URL do palącego 1 miliona, co ekscytuje roboty indeksujące, które z kolei niespodziewanie obciążają Twoje serwery.”

  Przekazane z posta Gary’ego Illyesa na LinkedIn (sierpień 2024) za pośrednictwem Search Engine Journal.

  Przeczytaj relację

Praktycy — kanonikalizacja produktów konfigurowalnych/prostych

• “Canonical to the parent configurable product.” — Dan Taylor, Search Engine Journal, The Technical Guide to Common Magento (Adobe Commerce) SEO Issues. Przejdź do cytatu
• “The canonical tag used on each of the simple products points back to the primary configurable version — to prevent duplicate variants of the product from being indexed by Google.” — Paul Rogers (Vervaunt). Przejdź do cytatu
• “…potentially generates 144,000 product combinations.” — Vervaunt, na temat hipotetycznego przykładu sklepu modowego (3000 produktów nadrzędnych × 8 rozmiarów × 6 kolorów), ilustrującego, dlaczego jawna polityka kanoniczna ma znaczenie na dużą skalę, a nie uniwersalny rozmiar katalogu. Przejdź do cytatu

Lista kontrolna SEO dla Magento

Uszeregowane w przybliżeniu według wpływu — najważniejsze pozycje decydują o sukcesie lub porażce sklepów Magento.

Wersja i fundamenty

• Potwierdź, że używasz Magento 2, a nie wycofanego Magento 1 (jeśli tak, przeprowadź migrację).
• Znaj swoją edycję (Adobe Commerce, Magento Open Source lub ACCS), aby określić zakres funkcji — ACCS całkowicie rezygnuje z motywu Luma.

Nawigacja warstwowa (najważniejsza)

• Potwierdź, czy sklep używa standardowej nawigacji warstwowej, czy płatnych faset Live Search — Adobe dokumentuje je jako odrębne implementacje.
• Przeanalizuj, ile adresów URL z parametrami generują filtry (przeskanuj witrynę; sprawdź liczbę site: oraz zindeksowane vs. odkryte w GSC).
• Ustaw kanoniczne adresy URL dla filtrowanych kategorii prowadzące do czystego adresu URL kategorii.
• Dodaj noindex do kombinacji filtrów o niskiej wartości (i pozostaw je przeszukiwalne, aby tag został odczytany — nigdy nie łącz noindex z Disallow w robots.txt).
• Zidentyfikuj filtry z realnym popytem w wyszukiwarkach i zbuduj je jako indeksowalne strony docelowe z czystymi adresami URL i unikalną treścią.

Produkty konfigurowalne i proste

• Włącz opcję „Use Canonical Link Meta Tag for Products” (Stores → Configuration → Catalog → Catalog → Search Engine Optimization).
• Potwierdź na wyrenderowanej stronie — nie tylko w ustawieniu — że adresy URL prostych produktów zawierają kanoniczny link do nadrzędnego produktu konfigurowalnego.
• Nie polegaj wyłącznie na opcji „Not Visible Individually”; nie blokuje ona indeksowania bezpośrednich adresów URL, mapy witryny ani linków wewnętrznych.

Adresy URL i przekierowania

• Włącz opcję „Use Web Server Rewrites” (bez index.php w adresach URL).
• Ustaw przyjazne SEO klucze URL dla produktów i kategorii.
• Włącz opcję „Create Permanent Redirect for old URL” przed jakimikolwiek zmianami kluczy URL.
• Zdecyduj o ścieżce kategorii w adresie URL produktu (wyłączenie zapobiega duplikacji wielu adresów URL).

Dane strukturalne

• Dodaj Product JSON-LD (Magento 2 nie zawiera żadnego) przez rozszerzenie lub kodowanie.
• Potwierdź brak zduplikowanego schematu (mikrodane motywu + JSON-LD z rozszerzenia).
• aggregateRating/review tylko z prawdziwych recenzji.

On-page i indeksowanie

• Unikalne tytuły i meta opisy dla produktów i kategorii.
• Uzupełnij treść opisu kategorii (domyślnie pusta).
• Paginacja: unikalne kanoniczne adresy URL wskazujące na siebie; serie nie z noindex.
• Ustal politykę dla produktów niedostępnych / wycofanych (nie pozostawiaj osieroconych błędów 404).

Międzynarodowość i wydajność

• Kontrola duplikacji widoków sklepu; hreflang kompletny i dwukierunkowy, jeśli wielojęzyczny.
• Pełna pamięć podręczna strony (Varnish), CDN i obrazy WebP dla Core Web Vitals.

Magento SEO ściągawka

Mapa wersji

Nawigacja warstwowa — co robić dla każdego typu URL

Kluczowe ustawienia Admina (Magento 2)

• Sklepy → Konfiguracja → Ogólne → Web → Optymalizacja dla wyszukiwarek: Użyj przepisywania serwera WWW = Tak.
• Sklepy → Konfiguracja → Katalog → Katalog → Optymalizacja dla wyszukiwarek: sufiks URL produktu/kategorii, Użyj kanonicznego tagu meta dla kategorii/ produktów = Tak.
• Marketing → SEO i wyszukiwanie → Przepisywania URL: menedżer url_rewrite.
• Edycja produktu/kategorii → Optymalizacja dla wyszukiwarek: klucz URL, tytuł meta, opis meta; włącz Utwórz trwałe przekierowanie dla starego URL.

Twarde fakty

• Magento 2 domyślnie nie emituje JSON-LD (mikrodane tylko w niektórych motywach).
• Google zaleca JSON-LD zamiast mikrodanych/RDFa.
• noindex wymaga indeksowalnej strony — nie łącz z robots.txt Disallow.
• Przyjazne URL-e znajdują się w tabeli url_rewrite.

Modele mentalne

1. Najpierw wersja. Przed jakąkolwiek taktyką odpowiedz: Magento 1 czy 2? Jeśli 1, projekt to migracja, kropka. Jeśli 2, edycja (Adobe Commerce vs Open Source) zmienia funkcje, nie podstawy SEO.

2. Nawigacja warstwowa = binarna decyzja per URL. Każdy przefiltrowany URL jest albo aktywem (realny popyt w wyszukiwarce → zrób z niego indeksowalną stronę docelową), albo zobowiązaniem (brak popytu → kanonicznie go usuń i/lub noindex). Nie traktuj wszystkich faset tak samo; posortuj je według popytu, a następnie zastosuj właściwy sygnał.

3. Trzy zasady “nie łącz”.

• noindex + robots.txt Disallow na tym samym URL → tag nigdy nie odczytany.
• noindex + kanoniczny na tym samym URL → sprzeczne sygnały.
• kanoniczny sam dla budżetu indeksowania → strony źródłowe nadal są indeksowane.

4. Kontroluj przestrzeń URL, a następnie indeks. System url_rewrite Magento oraz reguły przepisywania serwera WWW zarządzają jakie URL-e istnieją i dokąd przekierowują. Kanoniczne/noindex zarządzają co jest w indeksie. Najpierw napraw generowanie URL-i (nie twórz duplikatów), a następnie zarządzaj indeksacją.

5. Schema jest tutaj opcjonalna. Na większości platform schema to drobna poprawka; w Magento to budowa. Zaplanuj JSON-LD jako element dostarczany, a następnie zabezpiecz się przed wysłaniem dwóch bloków Product.

Narzędzia do SEO w Magento

• Magento Admin — URL Rewrites (Marketing → SEO & Search) — natywny menedżer tabeli url_rewrite; Twoje źródło prawdy dla przyjaznych URL-i i przekierowań.
• Crawlery / audyty stron — Screaming Frog SEO Spider lub Ahrefs Site Audit, aby zmierzyć, ile URL-i z parametrami faktycznie generuje nawigacja warstwowa, wykryć zduplikowane tytuły/kanoniczne i znaleźć łańcuchy przekierowań. W ten sposób określisz skalę problemu nawigacji fasetowej.
• Google Search Console — raport Page indexing (Odkryto/Zindeksowano — często nieindeksowane rośnie przy rozroście parametrów) oraz Crawl stats, aby zobaczyć budżet crawlowania zużywany na URL-e filtrów.
• Rich Results Test / Schema Markup Validator — potwierdź, że dodany JSON-LD jest poprawny i że nie masz konkurencyjnego bloku microdata.
• Rozszerzenia SEO dla Magento — Mageworx, Mirasvit, Amasty i podobne dodają JSON-LD, dokładniejszą kontrolę kanoniczną oraz reguły indeksacji nawigacji warstwowej, które Magento core pozostawia Tobie. (Oceń pod kątem zachowania zduplikowanego schema.)
• Analiza plików logów — dla dużych katalogów logi serwera pokazują dokładnie, ile crawlowania jest marnowane na URL-e filtrów.

Jak mierzyć kondycję SEO w Magento

To są stałe KPI dla sklepu Magento, a nie jednorazowe kontrole — śledź je cyklicznie, aby nawigacja warstwowa, indeksowanie i schema nie dryfowały cicho z powrotem do bałaganu.

Wskaźnik zindeksowanych do odkrytych URL-i

Co Ci to mówi: Jak bardzo nawigacja warstwowa zawyża widok Google na stronę. Kategoria z kilkuset produktami nie powinna mieć dziesiątek tysięcy odkrytych URL-i.

Jak to pobrać: Search Console → raport Page indexing, konkretnie kategorie “Discovered — currently not indexed” i “Crawled — currently not indexed”. Segmentuj według wzorca URL (filtruj ciągi zapytań) za pomocą próbki inspekcji URL z raportu lub eksportu crawl.

Benchmark / realistyczny zakres: Nie ma uniwersalnej liczby — zależy od rozmiaru katalogu i liczby filtrów. Sygnał, który się liczy, to trend: wskaźnik rosnący z miesiąca na miesiąc oznacza, że strategia kanoniczna/noindex dla nawigacji warstwowej nie działa.

Częstotliwość: Miesięcznie lub po każdej zmianie konfiguracji nawigacji warstwowej.

Budżet crawlowania wydany na URL-e filtrów

Co Ci to mówi: Czy Googlebot marnuje zdolność crawlowania na prawie zduplikowane kombinacje parametrów zamiast na Twoje prawdziwe strony produktów i kategorii.

Jak to pobrać: Search Console → raport Crawl stats (według odpowiedzi i według celu), skrzyżowany z plikami logów serwera/CDN przefiltrowanymi do żądań z ? parametrami. Mój Faceted Navigation Auditor może sklasyfikować dostarczoną listę URL-i z parametrami, aby pomóc określić, które kombinacje są faktycznie generowane.

Benchmark / realistyczny zakres: Zależy od rozmiaru katalogu i częstotliwości crawlowania — nie ma stałego “dobrego” procentu. Traktuj rosnący udział trafień crawl na URL-e z parametrami w stosunku do kanonicznych URL-i produktów/kategorii jako sygnał ostrzegawczy.

Częstotliwość: Miesięcznie dla ustalonych sklepów; co tydzień podczas i po zmianie konfiguracji nawigacji warstwowej.

Spójność sygnałów kanonicznych

Co Ci to mówi: Czy przefiltrowane i stronicowane URL-e faktycznie rozwiązują się do zamierzonego kanonicznego, a nie cicho wracają do samoodnoszących się lub brakujących tagów po aktualizacji motywu/rozszerzenia.

Jak to pobrać: Sprawdź punktowo URL-e filtrów i paginacji za pomocą mojego Canonicalization Checker — audytuje on sygnały kanoniczne HTML i HTTP oraz flaguje konflikty.

Benchmark / realistic range: Should be 100% — every filtered URL you intend to suppress should carry a canonical pointing to the clean category page, every paginated page a self-referencing canonical. Any exception is a bug, not a range.

Cadence: After every theme, extension, or layered-navigation setting change; spot-check quarterly otherwise.

Product rich-result eligibility

What it tells you: Whether the JSON-LD you added (Magento ships none by default) is actually valid and complete enough to earn price/rating rich results, and whether a leftover theme microdata block is conflicting with it.

How to pull it: Search Console → Enhancements report for Product snippets, or spot-check individual URLs with Google’s Rich Results Test. For a raw-HTML audit of the schema itself — including duplicate-block detection — use my PDP SEO Checker.

Benchmark / realistic range: Depends on catalog size and review coverage — not every SKU will have aggregateRating data. Track the trend in valid vs. error/ warning items, not an absolute target.

Cadence: Monthly, and immediately after any schema extension update or theme change.

Validation tests: proving a Magento SEO fix took effect

Pass/fail checks for the specific changes covered in this article — run each one right after you make the change, then again on the monitoring cadence noted.

Canonical added to a filtered category URL

Test to run: Load a filtered URL (e.g. /running-shoes?color=blue) in my Canonicalization Checker.

Expected result: The tool reports a rel=canonical on the filtered URL pointing to the clean category URL (/running-shoes), with no conflicting HTTP header canonical.

Failure interpretation: No canonical, a self-referencing canonical, or a canonical pointing somewhere else means the “Use Canonical Link Meta Tag for Categories” setting or your template/extension logic isn’t emitting it for this URL pattern.

Monitoring window: Immediate for the tag itself; 2–4 weeks in Search Console’s Page indexing report to see Google pick up the consolidated signal.

Rollback trigger: If indexed-URL counts for the filter pattern keep climbing after 4 weeks with the canonical confirmed present, the signal isn’t being respected — check for a conflicting noindex or robots.txt block on the same URL.

noindex applied to a low-value filter combination

Test to run: Fetch the filtered URL’s rendered HTML <head> (view-source or curl) and check for <meta name="robots" content="noindex,follow">. Then check robots.txt for that URL pattern with my Google Index Checker.

Expected result: The noindex tag is present AND the URL is not disallowed in robots.txt — Google can only read the tag on a crawlable page.

Failure interpretation: If robots.txt also disallows the pattern, Googlebot never fetches the page to see the noindex tag, and the URL can stay indexed indefinitely from historical signals alone.

Monitoring window: Days for the crawl to pick up the tag; 2–8 weeks for the URL to actually drop out of the index (longer for previously well-linked filter pages).

Rollback trigger: URL still indexed after 8 weeks with noindex confirmed crawlable — check for a canonical fighting the noindex on the same URL (they’re contradictory signals; Google may ignore one).

Simple product canonical points to its configurable parent

Test to run: Load a simple-product variant URL (a specific size/color combination) in my Canonicalization Checker.

Expected result: The tool reports a rel=canonical on the simple product URL pointing to the parent configurable product’s URL, with no conflicting HTTP header canonical.

Interpretacja błędu: Samoodnoszący się lub brakujący canonical oznacza, że opcja „Use Canonical Link Meta Tag for Products” nie jest włączona albo wariant jest traktowany jako widoczny/indeksowany niezależnie od relacji z produktem nadrzędnym.

Okno monitorowania: Natychmiastowe dla samego tagu; 2–4 tygodnie w raporcie Page indexing w Search Console, aby potwierdzić, że adresy URL wariantów konsolidują się pod produktem nadrzędnym, a nie kumulują jako osobne zindeksowane strony.

Wyzwalacz wycofania: Jeśli liczba zindeksowanych adresów URL prostych produktów nadal rośnie po 4 tygodniach, mimo potwierdzonej obecności kanonika, sprawdź, czy zamiast tagu canonical nie polega się na opcji „Not Visible Individually” — widoczność w katalogu nie blokuje indeksowania bezpośrednich adresów URL, mapy witryny ani linków wewnętrznych.

Przekierowanie przy zmianie adresu URL chroni stare adresy URL

Test do wykonania: Po zmianie klucza adresu URL produktu lub kategorii wyślij bezpośrednie żądanie do starego adresu URL: curl -I https://yourstore.com/old-url-key.

Oczekiwany wynik: Pojedyncze 301 do nowego adresu URL (bez łańcuchów przekierowań).

Interpretacja błędu: Kod 404 oznacza, że opcja „Create Permanent Redirect for old URL” była wyłączona w momencie zmiany klucza albo wpis url_rewrite nie został wygenerowany — stary adres URL oraz wszelkie linki przychodzące i rankingi, które posiadał, są teraz porzucone.

Okno monitorowania: Natychmiastowe — to sprawdzenie kodu statusu, nie wymaga czekania.

Wyzwalacz wycofania: Jakikolwiek kod 404 lub łańcuch przekierowań na adresie URL, który wcześniej miał ranking — przywróć wpis url_rewrite lub dodaj ręczne przekierowanie, zanim adres wypadnie z indeksu.

Schemat JSON-LD produktu jest prawidłowy i niezduplikowany

Test do wykonania: Przepuść stronę produktu przez mój PDP SEO Checker, aby sprawdzić surowy JSON-LD pod kątem wymaganych pól i zduplikowanych bloków, a następnie potwierdź kwalifikację do rozszerzonych wyników za pomocą Google Rich Results Test.

Oczekiwany wynik: Jeden prawidłowy blok Product z polami name, image, description, offers (price, priceCurrency, availability) oraz — jeśli deklarujesz oceny gwiazdkowe — aggregateRating/review pochodzące z prawdziwych recenzji. Żadnego drugiego, sprzecznego bloku z pozostałości mikrodanych motywu.

Interpretacja błędu: Dwa bloki Product (mikrodane motywu + JSON-LD rozszerzenia) zwykle oznaczają, że Google wybiera jeden arbitralnie lub odrzuca oba jako niespójne; brakujące pola offers oznaczają, że strona nie zakwalifikuje się do fragmentów z ceną.

Okno monitorowania: Natychmiastowe dla poprawności; 2–4 tygodnie w raporcie Enhancements w Search Console, aby potwierdzić, że rozszerzone wyniki faktycznie zaczynają się pojawiać.

Wyzwalacz wycofania: Raport Enhancements pokazuje rosnącą liczbę „Invalid items” po aktualizacji motywu lub rozszerzenia — wyłącz nowsze źródło, dopóki duplikat nie zostanie rozwiązany.

Zasoby warte Twojego czasu

Na tematy dominujące w SEO Magento (na tej stronie)

• Faceted navigation — główne źródło informacji o problemie nawigacji warstwowej i ramach decyzyjnych indeksuj-lub-ukryj.
• Canonicalization oraz tag canonical — podstawowe rozwiązanie problemu duplikacji parametrów w Magento.
• Duplicate content — dlaczego adresy URL filtrów i widoków sklepu dzielą sygnały.
• URL parameters oraz crawl budget — mechanika indeksowania w kontekście rozrostu parametrów.

Moje powiązane artykuły (Ahrefs)

• The Beginner’s Guide to Technical SEO — gdzie te mechanizmy wpisują się w szerszy obraz.
• Faceted Navigation: Definition, Examples & SEO Best Practices — pełne ramy decyzyjne (jestem recenzentem tego artykułu).
• URL Parameters: A Complete Guide for SEOs.

Oficjalne

• Adobe Commerce SEO best practices — oficjalne wytyczne platformy.
• Zarządzanie indeksowaniem adresów URL nawigacji fasetowej — dokumentacja Google.

Od innych

• r/TechSEO i Magento Stack Exchange — gdzie debuguje się specyficzne dla Magento problemy z indeksowaniem i crawl.
• The Technical Guide to Common Magento SEO Issues (Search Engine Journal, Dan Taylor) — obszerny praktyczny przewodnik obejmujący przepisywania URL, kanonikalizację produktów konfigurowalnych/prostych oraz kontrolę nawigacji fasetowej.
• The Ultimate Guide to Duplicate Content in Magento (Vervaunt, Paul Rogers) — najczęściej cytowane źródło pełnej mapy źródeł zduplikowanych treści oraz strategii kanonicznej dla produktów konfigurowalnych/prostych.
• SEO Considerations for Configurable and Simple Products in Magento (Paul Rogers) — dogłębna analiza kanonikalizacji prostych SKU do ich konfigurowalnych rodziców na dużą skalę.
• Layered Navigation Causing Problems? Deal With It (Scandiweb) — aktualne, zgodne z Google wytyczne dotyczące disallow w robots.txt jako podstawowej kontroli crawl nawigacji fasetowej.
• Magento 2 Layered Navigation SEO: The Ultimate Guide (Mageworx) — szczegółowy przewodnik po proliferacji adresów URL z parametrami, z konkretnymi przykładami URL.
• Product Schema for Adobe Commerce (Lumio) — wyjaśnia, dlaczego Luma dostarcza prawie żadnego JSON-LD, i przeprowadza przez budowę niestandardowego modułu JSON-LD w oparciu o model EAV.

Dziennik zmian