Audyt SEO sklepu internetowego — co sprawdzić i w jakiej kolejności

Audyt SEO sklepu internetowego rzadko wymaga płatnych narzędzi. Wymaga właściwej kolejności. Większość tego, co trzeba sprawdzić, Google udostępnia bezpłatnie w Search Console i Merchant Center, więc problemem nie jest dostęp do danych, tylko to, w jakim porządku je czytasz. Audyt zaczęty od treści produktowej niewiele da, jeśli duża część katalogu nie jest zindeksowana. Audyt zaczęty od Core Web Vitals nie ma sensu, jeśli roboty Google nie docierają do stron produktów przez źle skonfigurowaną nawigację fasetową.

Poniżej opisujemy audyt SEO sklepu jako siedem kroków, w kolejności, w jakiej mają znaczenie: od indeksowania, przez wydajność i wyniki rozszerzone, po treść i dane w Merchant Center. Ogólny audyt dowolnej strony internetowej opisujemy w tekście o audycie strony internetowej. Tu skupiamy się na tym, co w sklepie jest inne: tysiącach adresów URL, filtrach, wariantach i wymaganiach Merchant Center, których strona firmowa ani blog nie mają.

Audyt SEO sklepu internetowego: dlaczego kolejność kroków ma znaczenie

Każdy z siedmiu kroków opiera się na poprzednim. Wyższy krok sprawdza coś, co ma sens dopiero wtedy, gdy niższy jest w porządku. Audyt SEO sklepu rozpoczęty od środka, np. od treści produktowej albo od wyglądu strony w wynikach wyszukiwania, kończy się często poprawkami, które niewiele zmieniają, bo przyczyna leży piętro niżej: w indeksowaniu albo w strukturze adresów URL.

Krok 1: raport Indeksowanie stron

Pierwsze pytanie nie dotyczy pozycji w wynikach, tylko tego, czy strona produktu w ogóle ma szansę się w nich pojawić. Raport Indeksowanie stron w Search Console „zawiera informacje o stanie zindeksowania przez Google wszystkich adresów URL, o których Google wie, że znajdują się w Twojej usłudze” i pokazuje, „ile adresów URL w Twojej witrynie zostało zeskanowanych i zindeksowanych przez Google” (Search Console, raport Indeksowanie stron, odczyt 2026-10-05).

Dwa główne statusy, „Zindeksowano” i „Nie zindeksowano”, to dopiero początek. Przy niezindeksowanych adresach raport podaje konkretny powód: błąd serwera, blokadę w robots.txt, znacznik noindex, błąd 404 albo inny. W sklepie z dużym katalogiem bardziej niż pojedynczy adres liczy się wzorzec. Jeśli dziesiątki stron produktów mają ten sam powód niezaindeksowania, np. ten sam parametr URL zablokowany w robots.txt, problem jest strukturalny, a nie przypadkowy.

Przy dużym katalogu warto też wiedzieć, czego raport nie obiecuje. Google pisze wprost, że nie należy oczekiwać „zindeksowania 100% witryny”, tylko stron kanonicznych, a o stronach oznaczonych jako duplikaty lub wersje alternatywne pisze, że „zwykle jest to dobry znak”: Google znalazł wersję kanoniczną i ją zindeksował. Lista przykładowych adresów przy każdym statusie obejmuje najwyżej 1 000 pozycji, więc w sklepie z kilkudziesięcioma tysiącami produktów nie zobaczysz w niej wszystkich problematycznych stron. Wzorzec odczytasz z próbki, ale skalę sprawdzisz w liczbach na wykresie.

Dwa statusy wyglądają podobnie, a znaczą co innego. „Strona wykryta – obecnie niezindeksowana” oznacza, że Google zna adres, ale go jeszcze nie pobrał; najczęstszą przyczyną według pomocy jest to, że próba pobrania mogła przeciążyć witrynę, więc Google przełożył ją na później. „Strona zeskanowana, ale jeszcze niezindeksowana” oznacza, że Google stronę pobrał, ale jej nie zindeksował; może to zrobić w przyszłości. Skoro Google podaje przeciążenie jako najczęstszą przyczynę pierwszego statusu, tysiące wykrytych, a niepobranych kart produktu to sygnał, żeby sprawdzić, ile adresów generują filtry i jak szybko odpowiada serwer. Przy drugim statusie pomoc dodaje, że nie ma potrzeby ponownego przesyłania adresu do zeskanowania. Pełny opis statusów i tego, co z nimi robić, jest w artykule o Google Search Console.

Osobna, mniej pilna część raportu to tabela „Popraw wygląd i działanie stron”. Zebrane w niej problemy „nie uniemożliwiają indeksowania strony, ale ograniczają możliwości Google do zrozumienia i zindeksowania Twoich stron”. Sprawdź ją po głównych statusach, nie przed nimi.

Jeśli ten krok pokaże, że istotna część katalogu nie jest zindeksowana z powodu filtrów i parametrów, przejdź od razu do kroku 4, w którym opisujemy, jak Google radzi ograniczać indeksowanie filtrów.

Krok 2: raport Core Web Vitals — kiedy sięgać głębiej

Drugi raport mierzy wydajność, ale tylko na danych od prawdziwych użytkowników. Raport Core Web Vitals w Search Console „zawiera informacje o skuteczności Twoich stron na podstawie rzeczywistych danych o korzystaniu”. Grupuje adresy URL według stanu („Słabej jakości”, „Wymagana poprawa”, „Dobrej jakości”), według wskaźnika (LCP, INP, CLS) i według grupy podobnych stron, np. wszystkich kart produktu w jednym szablonie. Stan jest ustawiany na „najwolniejszy stan przypisany do niego dla danego typu urządzenia”, czyli decyduje najgorszy wskaźnik. Przykład Google: adres, który na telefonach ma CLS „Słabej jakości”, a LCP „Wymagana poprawa”, dostaje dla telefonów stan „Słabej jakości” (Search Console, raport Core Web Vitals, odczyt 2026-10-05).

Dane w tym raporcie pochodzą z „raportu na temat użytkowania Chrome” (CrUX), czyli od realnych użytkowników, a nie z testu w laboratorium. To odróżnia raport od jednorazowego testu Lighthouse, który mierzy stronę w kontrolowanych warunkach. PageSpeed Insights pokazuje jedno i drugie: na górze dane z CrUX, na dole wynik testu Lighthouse; jak czytać obie części, opisujemy w artykule o PageSpeed Insights. Jeśli raport w Search Console pokazuje problem dla konkretnej grupy stron, np. wszystkich kart produktu, dopiero wtedy sprawdź pojedynczą stronę w PageSpeed Insights, żeby zobaczyć, co ją obciąża.

Taką kolejność zaleca sam Google. Dane terenowe powstają z monitorowania wszystkich użytkowników, którzy odwiedzają stronę, a dane laboratoryjne z wczytania strony w kontrolowanym środowisku, przy z góry ustalonych warunkach sieci i urządzenia. Jeśli masz jedne i drugie, „dane terenowe są tym, czym należy się kierować przy ustalaniu priorytetów”, bo to najdokładniejszy sposób, by zrozumieć, z czym naprawdę mają problem Twoi użytkownicy (web.dev, różnice między danymi laboratoryjnymi a terenowymi, tłumaczenie własne, odczyt 2026-10-05). W audycie oznacza to: nie zaczynaj od testu losowej podstrony w Lighthouse. Zacznij od raportu w Search Console, który pokazuje, które grupy stron mają problem u Twoich klientów, a test laboratoryjny wykorzystaj do znalezienia przyczyny w kodzie.

Mechanizmy, które psują te metryki w sklepie, plan naprawy i porównanie platform sklepowych według HTTP Archive Web Almanac opisujemy w tekście Core Web Vitals w sklepie internetowym. Jednorazowy test konkretnej strony zrobisz w naszym teście szybkości strony.

Krok 3: wyniki rozszerzone — product snippet i merchant listing

Trzeci krok sprawdza, czy Google ma dość danych, żeby pokazać stronę produktu z czymś więcej niż tytułem i opisem. Google rozróżnia dwa powiązane typy wyników rozszerzonych (Search Central, uporządkowane dane Product, odczyt 2026-10-05):

• Krótki opis produktu (product snippet) — „w przypadku stron produktów, na których użytkownicy nie mogą bezpośrednio kupić produktu”. Daje więcej miejsca na opinie i szczegóły; wymaga danych strukturalnych z name i co najmniej jedną z właściwości review, aggregateRating albo offers.
• Merchant listing (informacje o produkcie umieszczone przez sprzedawcę) — „w przypadku stron, na których klienci mogą kupować produkty od Ciebie”. Pokazuje rozmiar, dostawę, zasady zwrotów i zawsze zawiera cenę; wymaga name, image i offers z ceną wyższą od zera oraz walutą. Merchant listing wymaga typu Offer, a krótki opis produktu przyjmuje też AggregateOffer (Search Central, merchant listing, odczyt 2026-10-05).

Oba typy „w pewnym stopniu się pokrywają”: dodanie właściwości wymaganych dla merchant listing sprawia zwykle, że strona kwalifikuje się też do krótkiego opisu produktu (Search Central, uporządkowane dane Product, odczyt 2026-10-05).

Pomoc Search Console opisuje ogólne narzędzia do wyników rozszerzonych: raport przeglądu, raport danych strukturalnych, których nie da się przeanalizować, i test wyników z elementami rozszerzonymi. Jej sekcja o zakupach wymienia też osobny raport „Możliwości dla sprzedawców” z rekomendacjami poprawy widoczności sklepu oraz ustawienie „Dostawa i zwroty” (Ustawienia > Zakupy). To ustawienie zobaczysz tylko wtedy, gdy konto Merchant Center jest powiązane z usługą w Search Console (Search Console, raporty dotyczące zakupów, odczyt 2026-10-05). To kolejny powód, żeby oba konta były połączone, a nie prowadzone osobno.

Brak wymaganej właściwości, np. priceCurrency w offers, oznacza, że strona nie spełnia wymagań danego wyniku rozszerzonego. To inna sprawa niż stan w raporcie Indeksowanie stron. Takie braki przejdź razem z osobą techniczną, bo dane strukturalne generuje zwykle szablon karty produktu: jedna poprawka w szablonie obejmuje wszystkie strony, które z niego korzystają.

Krok 4: filtry, duplikaty i adresy kanoniczne — checklista

Tu sklep wytwarza najwięcej adresów URL, a razem z nimi wiele problemów z indeksowaniem z kroku 1. Sprawdź po kolei:

• Nawigacja fasetowa. Najczęstsze wdrożenie, oparte na parametrach URL, „może generować nieskończone przestrzenie adresów URL”. Skutki są dwa: zbyt częste indeksowanie, bo adresy z filtrami „wydają się nowe”, i wolniejsze indeksowanie nowych, przydatnych stron, bo roboty tracą czas na bezużyteczne kombinacje. Google zaleca: „zezwól na indeksowanie tylko stron poszczególnych produktów oraz strony z listą produktów bez filtrów”, a kombinacjom filtrów bez wyników zwracaj kod 404. Atrybuty rel="canonical" i rel="nofollow" na linkach do filtrów są „na dłuższą metę mniej skuteczne” niż reguły w robots.txt i fragmenty adresu URL (#) (Search Central, nawigacja fasetowa, odczyt 2026-10-05).
• Paginacja. Każda strona listy produktów powinna mieć unikalny adres URL, np. z parametrem ?page=n. Pierwszej strony sekwencji nie ustawiaj jako kanonicznej dla pozostałych: każda dostaje własny adres kanoniczny. Tagów rel="next" i rel="prev" Google „obecnie już ich nie używa, ale takich linków nadal mogą używać inne wyszukiwarki” (Search Central, podział na strony, odczyt 2026-10-05). Jeśli zostały w kodzie z poprzednich lat, nie szkodzą, ale na indeksowanie w Google nie wpływają.
• Warianty produktu (kolor, rozmiar). Google prosi, by każdy wariant „mógł być identyfikowany za pomocą osobnego adresu URL”, jako segment ścieżki albo parametr (Search Central, struktura adresów URL w e-commerce, odczyt 2026-10-05). Nie publikuje natomiast reguły „zawsze kanonikalizuj warianty do jednego adresu bazowego”. To decyzja biznesowa: zależy od tego, czy chcesz, żeby każdy kolor był osobno widoczny w wyszukiwarce.
• Duplikaty i adres kanoniczny. Wybór strony kanonicznej to „proces wyboru reprezentatywnego – kanonicznego – adresu URL fragmentu treści”, a „wyniki sortowania i filtrowania strony kategorii” Google wymienia wprost jako źródło duplikatów. Ważne zastrzeżenie: „określenie preferowanego adresu kanonicznego to wskazówka, a nie reguła”. Google bierze pod uwagę także m.in. HTTP czy HTTPS, przekierowania i obecność adresu w mapie witryny (Search Central, wybór strony kanonicznej, odczyt 2026-10-05).
• Mit „kary za duplicate content”. Aktualna dokumentacja Google mówi łagodnie: „Witryna będzie prawdopodobnie działać dobrze, nawet jeśli nie określisz kanonicznego ustawienia” (Search Central, konsolidacja zduplikowanych adresów URL, odczyt 2026-10-05). rel="canonical" daje kontrolę i oszczędza czas robotów, ale nie chroni przed karą. Mocniejsze, często powtarzane zdanie, że kary za duplicate content nie ma, chyba że duplikacja ma oszukać i manipulować wynikami, pochodzi z wpisu na blogu Google Search Central z września 2008 roku i nie jest częścią aktualnej dokumentacji. Traktuj je jako kontekst historyczny, nie dzisiejsze stanowisko.

Strukturę URL, paginację, nawigację fasetową i duplikaty w sklepie, z przykładami wdrożenia na konkretnych platformach, omawiamy w tekście o pozycjonowaniu sklepu internetowego.

Krok 5: treść produktowa i kategorii

Treść poprawiaj dopiero wtedy, gdy kroki 1–4 pokazują zaindeksowane, technicznie poprawne strony. Inaczej zmiany w opisach niewiele dadzą w wynikach wyszukiwania. Sprawdź, czy opisy produktów i kategorii to treści, które „zostały utworzone głównie z myślą o użytkownikach i nie mają na celu manipulowania rankingiem w wyszukiwarce” (Search Central, tworzenie przydatnych treści, odczyt 2026-10-05). Jeśli duża część opisów jest generowana automatycznie, na masową skalę i bez dodatkowej wartości, to już nie kwestia stylu, tylko ryzyko naruszenia zasady dotyczącej „nadużyć na dużą skalę dotyczących treści”, (Search Central, zasady dotyczące spamu, odczyt 2026-10-05). Google wprowadził ją 5 marca 2024 roku razem z marcową aktualizacją podstawową.

Pełną checklistę strony produktu, czyli limity znaków w Merchant Center, wymagania dotyczące zdjęć, to, kiedy opisy kategorii pomagają, a kiedy szkodzą, i jak traktować treści generowane przez AI, opisujemy w tekście o opisach produktów pod SEO.

Krok 6: diagnostyka w Merchant Center

Jeśli sklep korzysta z Google Merchant Center, audyt musi objąć też to konto, bo jego błędów nie widać w raporcie indeksowania. Dotyczy to feedu produktowego, bezpłatnych informacji o produktach i reklam. Sprawdź:

• statusy produktów i powody odrzucenia. Wymagania dotyczące strony docelowej mówią, że cena ma być „dobrze widoczna i zgodna z ceną podaną w danych produktów”, a kluczowe elementy, w tym cena, waluta i dostępność, mają się zgadzać z przesłanymi danymi (Merchant Center, wymagania dotyczące strony docelowej, odczyt 2026-10-05);
• ostrzeżenia w powiadomieniach konta. Przy części zasad, np. dotyczących treści nieakceptowanych w Zakupach Google, Google zapowiada, że ich naruszenie „nie spowoduje natychmiastowego zawieszenia konta bez wcześniejszego ostrzeżenia”, a ostrzeżenie „zostanie wysłane co najmniej 7 dni przed zawieszeniem konta” (Merchant Center, treści nieakceptowane w Zakupach Google, odczyt 2026-10-05). Z tego czasu skorzystasz tylko wtedy, gdy regularnie zaglądasz do powiadomień;
• zgodność strony docelowej z wymaganiami: widoczną cenę zgodną z danymi, link do konkretnego produktu, brak elementów zasłaniających informacje;
• połączenie z Search Console. Bez niego nie zobaczysz ustawienia „Dostawa i zwroty” (Ustawienia > Zakupy).

Jak skonfigurować konto Merchant Center od zera, zweryfikować witrynę i czym różni się plik danych od danych strukturalnych, opisujemy w osobnym tekście o Google Merchant Center.

Krok 7: zrobić samodzielnie czy zlecić audyt

Publicznej, rzetelnie policzonej średniej ceny audytu SEO sklepu w Polsce nie ma, więc żadnej kwoty tu nie podajemy. Raporty rynkowe, które sprawdziliśmy, mierzą coś innego (zarobki specjalistów SEO, widoczność sklepów w indeksie konkretnego narzędzia) albo są materiałami agencji z widełkami dobranymi pod pozyskanie klienta, a nie danymi z próby. Kroki 1–4 możesz przejść samodzielnie z naszą checklistą samodzielnego audytu, bo wymagają głównie czytania bezpłatnych raportów Google, nie specjalistycznych narzędzi.

Zlecenie audytu wykonawcy ma tym więcej sensu, im bardziej splątany jest problem. Dotyczy to sytuacji, gdy katalog liczy tysiące adresów URL, a problem z indeksowaniem ma kilka nakładających się przyczyn (filtry, warianty, migracja platformy). Także wtedy, gdy trzeba ustalić, która z kilku równoczesnych przyczyn odpowiada za spadek widoczności, albo gdy raporty wskazują problem, ale nie wiesz, który element szablonu lub wtyczki go wywołuje. To praca, która wymaga czasu człowieka, a nie tylko odczytania raportu.

Różnica między checklistą a zleconym audytem leży właśnie w interpretacji. Checklista mówi: „sprawdź raport Indeksowanie stron i zobacz, czy są błędy”, i to wystarczy, żeby zauważyć problem. Nie mówi, co dalej, gdy błędów jest kilkaset i mają kilka przyczyn naraz: część stron blokuje robots.txt dodany przy poprzedniej migracji, część ma noindex pozostały po etapie testowym wdrożenia, a do części nie prowadzi żaden link z reszty witryny. Rozdzielenie tych przyczyn, ustalenie, którą naprawić najpierw, i sprawdzenie, czy poprawka w szablonie nie zepsuje czegoś na pozostałych stronach tego typu, wykonawca zrobi szybciej niż ktoś, kto widzi te raporty pierwszy raz.