Audyt SEO sklepu internetowego: checklista, koszty i retest

W sklepie internetowym liczba dostępnych adresów może szybko rosnąć przez filtry, sortowanie i warianty produktów. Nawet jedna kategoria potrafi wygenerować tysiące kombinacji URL-i, z których wiele pokazuje bardzo podobną ofertę. Zanim ustawię canonicale i reguły indeksowania, sprawdzam, które z tych stron powinny rzeczywiście pojawiać się w Google.

Zasady indeksowania trzeba ustalić osobno dla produktów, kategorii, filtrów, paginacji i wersji językowych. W przykładzie pięć filtrów daje 7 559 możliwych kombinacji. Jest to wyliczenie na podstawie wariantów filtrów, a nie wynik pomiaru konkretnego sklepu.

Audyt SEO sklepu zaczyna się od mapy typów stron

Audyt SEO sklepu internetowego to sprawdzenie całego systemu, który generuje adresy i dane produktowe. Obejmuje kategorie, filtry, warianty, paginację, wyszukiwarkę wewnętrzną i stany magazynowe. Do tego dochodzą JavaScript, dane Product, feed Merchant Center i wydajność najważniejszych szablonów. Zakres analizy i datę można zapisać w karcie audytu. Przykładowe wypełnienie znajduje się dalej.

Twój sklep może mieć inne typy, więc zacznij od spisu szablonów i parametrów. Google opisuje strukturę sklepu głównie przez relacje między stronami i linki. Sitemapa i feed Merchant Center pomagają odkrywać adresy, ale architekturę budujesz linkami.

1. Każdy typ URL-a w sklepie ma zapisany stan docelowy

Dla każdej grupy adresów zapisz w macierzy indeksacji URL-i, czy Google ma ją pobierać i indeksować, jaki ma canonical, czy jest w sitemapie, skąd prowadzą do niej linki i co potwierdza Search Console. Taki zapis rozdziela cztery pytania, które łatwo pomylić.

robots.txt kontroluje crawl, czyli pobieranie strony przez robota. noindex działa dopiero wtedy, gdy robot przeczyta dyrektywę, więc na adresie zablokowanym w robots.txt Google go nie zobaczy.

W Search Console porównaj canonical zadeklarowany przez właściciela z wybranym przez Google. Rozjazd sprawdź od strony sygnałów: przekierowań i linków wewnętrznych, a potem sitemapy i tagu. Moduł SEO w CometWeb Insight wyłapuje te bariery wcześniej, razem z canonicalem i statusem HTTP.

2. Filtry i sortowanie mają kontrolowaną przestrzeń URL-i

Nawigacja fasetowa, czyli zawężanie listingu po cechach produktu, pomaga kupującemu, ale źle zaprojektowana tworzy praktycznie nieograniczone zbiory adresów. Dokumentacja Google o nawigacji fasetowej nazywa ryzyko wprost: overcrawling, czyli crawl zmarnowany na zbędne adresy, i wolniejsze odkrywanie wartościowych stron.

Indeksuj tylko filtry z własnym popytem

Kombinacja filtrów zasługuje na indeksowalny URL, gdy na każde z tych pytań odpowiesz „tak”.

• Czy ktoś naprawdę szuka tej kombinacji, czyli czy istnieje realna intencja wyszukiwania?
• Czy wynik filtra jest stabilny w czasie i ma wystarczającą ofertę produktów?
• Czy landing da coś więcej niż tę samą listę z innym parametrem?

Reszta stanów ma działać dla kupującego i dostaje osobną politykę crawla i indeksacji. Masowy noindex na wszystkich filtrach tego nie uporządkuje, bo część z nich odpowiada na własny popyt i powinna mieć stabilny URL.

Ten sam stan filtrów ma jeden URL

Platforma sklepu potrafi tworzyć dla tego samego stanu filtrów takie adresy:

?brand=acme&color=black&size=m
?size=m&brand=acme&color=black
?color=black&size=m&brand=acme

To ten sam zestaw, więc router powinien trzymać jedną kolejność parametrów. W ilustracyjnym przykładzie pięć różnych parametrów ma 120 możliwych kolejności. Ile z nich sklep wygeneruje, zależy od routera, więc normalizację testuj jawnie. Liczbę ze wstępu policzyłem skryptem.

To kombinatoryka na przykładzie, bez crawla żadnego sklepu. W pakiecie badań leży przykład, skrypt i zapis wyniku.

Crawl filtrów hamuj osobną polityką

Canonical konsoliduje duplikaty, ale robot i tak może odwiedzać warianty. Filtry, których robot ma nie pobierać, potrzebują więc osobnej polityki crawla, a filtry do indeksu stabilnych URL-i i poprawnej odpowiedzi dla pustych kombinacji.

3. Każdy produkt jest osiągalny przez linki, także przy paginacji

Reguła „produkt maksymalnie cztery kliknięcia od strony głównej” krąży po branży, ale Google takiego progu nie publikuje. Każdy ważny produkt musi za to być osiągalny zwykłymi linkami <a href>.

Infinite scroll i przycisk „Load more” są w porządku, jeśli dalsza część katalogu ma też własne URL-e i linki. Dokumentacja Google o paginacji zaleca osobne adresy stron wyników połączone linkami. Googlebot pobiera adresy z linków, a przycisków nie klika.

Zrób szybki test i otwórz drugą stronę listingu w nowej karcie, bo jeśli nie ma własnego adresu, robot też go nie ma.

4. Warianty produktu mają canonical zgodny z modelem strony

Kolor czy rozmiar obsłużysz na jednej stronie albo pod osobnymi adresami. Dokumentacja Google o wariantach produktu opisuje oba modele dla ProductGroup i Product.

• Jeden URL, na którym wybrany wariant zmienia w interfejsie cenę i dostępność, a także zdjęcia oraz SKU.
• Osobne URL-e, gdzie każdy wariant ma stabilny adres i własne dane Product, a relacje ProductGroup, hasVariant i variesBy są spójne.

Decyzja o canonicalu wynika z modelu strony i intencji. Zasady „wszystkie warianty wskazują rodzica” w ciemno bym nie stosował, bo wariant z własnym popytem może potrzebować własnego adresu.

5. Strona, schema i Merchant Center podają te same dane produktu

Google zaleca udostępniać dane produktowe przez dane strukturalne na stronie, feed Merchant Center albo oba kanały naraz. Według dokumentacji Google o danych Product użycie obu może zwiększyć zakres kwalifikacji, więc porównaj co najmniej te pola.

Product snippets i merchant listings mają różne wymagania, więc luka w jednej kolumnie bywa błędem tylko dla części funkcji. 14 kwietnia 2026 Google opublikowało kolejną aktualizację specyfikacji danych Merchant Center, m.in. z nowymi atrybutami dostawy na poziomie produktu. W raporcie z audytu zapisz więc wersję i datę sprawdzanej specyfikacji.

6. JavaScript daje po renderowaniu tę samą cenę i dostępność

Podstawy JavaScript SEO od Google opisują renderowanie JavaScriptu i JSON-LD generowany po stronie klienta. Cena dodawana skryptem jest więc w porządku, dopóki wynik renderowania jest spójny, a sprawdzasz to po kolei:

1. co jest w początkowej odpowiedzi HTML, a co trafia do DOM po renderowaniu;
2. czy żaden z zasobów potrzebnych do renderowania nie jest zablokowany;
3. czy dane Product zgadzają się z widoczną ceną i dostępnością, także po zmianie wariantu;
4. co pokazują dla tej samej strony Rich Results Test i URL Inspection.

Pierwszy punkt sprawdzisz za darmo: Ctrl+U pokazuje początkowy HTML, a zakładka Elements w DevTools DOM po renderowaniu. Najbardziej uważaj przy cenie pobieranej z API i geo-pricingu.

7. Produkty niedostępne i wycofane mają osobne zasady

Jeśli produkt ma wrócić, strona zostaje i pokazuje stan, a availability i feed dostają aktualizację. Pomoc Merchant Center o dostępności wskazuje wtedy out_of_stock, jeśli sklep nie przyjmuje na niego zamówień.

Przy produkcie wycofanym na stałe decyduje to, co stara strona jeszcze daje kupującemu.

• Jest następca, który odpowiada tej samej potrzebie, więc oceń przekierowanie.
• Strona dalej się przydaje, bo ma wartość informacyjną albo popyt, więc możesz ją zachować bez możliwości zakupu.
• Nic nie zostało, a wtedy 404/410 jest poprawnym stanem usuniętego zasobu.

Masowe przekierowanie wycofanych produktów na stronę główną gubi sens poprzedniego adresu. Błędem bywa za to niezamierzone 404 na produkcie, który dalej powinien istnieć. Pomoc Merchant Center o niedostępnych stronach ostrzega, że niedostępna strona docelowa może wyłączyć produkt z reklam i bezpłatnych listingów, dopóki znów nie zadziała.

8. Kategoria odpowiada na intencję i ma ofertę

Uniwersalnej minimalnej liczby słów dla kategorii nie ma, więc oceniaj ją po tym, czy trafia w intencję, pomaga wybrać produkt i ma wystarczającą ofertę. Zobacz też, czy puste kategorie i kombinacje filtrów nie tworzą thin pages, czyli stron bez realnej treści.

9. Sitemapa, canonicale i parametry mają jedną politykę

Sitemapa ma zawierać adresy, które chcesz indeksować, a typowe konflikty z tą zasadą wyglądają tak.

• sitemapa zawiera URL z noindex albo przekierowanie, a czasem wariant z parametrem, którego canonical wskazuje gdzie indziej;
• wycofane produkty zostają w sitemapie miesiącami;
• kilka hostów albo wersji językowych wskazuje sprzeczne canonicale.

Sam miałem ostatnio taki rozjazd na cometweb.io, bo sitemapa zgłaszała 281 adresów, a mój crawler dotarł do 273. Brakujące 8 to stare wpisy ukryte z bloga filtrem kategorii, o którym generator sitemapy nie wiedział.

Po poprawce mają noindex, follow i wypadły z sitemapy, choć dalej zwracają 200. W sklepie tak samo znikają z listingów wycofane produkty i ukryte kategorie, tylko adresów jest więcej.

Przy większym sklepie podzieliłbym sitemapę według typów stron, bo raport map witryny w Search Console pokaże wtedy każdy typ osobno. Jak zgrać te sygnały, pokazuję w tekście jak ustawić canonical i sitemapę razem z robots.txt.

10. Sklep wielojęzyczny ma osobny audyt rynków i URL-i

Przy kilku rynkach sprawdzasz osobne URL-e dla języków albo krajów i hreflang, czyli oznaczenie wersji językowych. Do tego walutę, dostawę ze zwrotami i feed Merchant Center dla każdego kraju. To samo SKU na dwóch rynkach to dwa stany, bo cena i możliwość zakupu mogą się różnić.

11. Wydajność mierzysz per szablon i scenariusz

Wydajność sklepu mierz osobno w co najmniej pięciu scenariuszach: kategoria, karta produktu z dużą galerią, produkt z wariantami, listing po użyciu filtra i najważniejszy publiczny krok przed checkoutem.

Z Core Web Vitals liczą się LCP (czas wyświetlenia największego elementu), INP (opóźnienie reakcji) i CLS (przesunięcia układu). Przyczyn szukaj w zasobie LCP i skryptach, a w sklepie także w pracy przy zmianie wariantu. Moduł wydajności w Insight rozdziela dane terenowe z CrUX od pomiaru z Lighthouse, a gdy danych brakuje, pokazuje powód zamiast zera. Procedurę przed i po opisałem w przewodniku po przyspieszaniu strony.

12. Dane z crawlera, Search Console i Merchant Center zestawiasz obok siebie

Każde z tych źródeł odpowiada na inne pytanie, więc wniosek „tego adresu nie ma” opieraj na co najmniej dwóch z nich.

Crawl w Insight grupuje powtarzające się problemy według szablonów, a więcej o nim przeczytasz na stronie Crawl w Insight. Stron za logowaniem może nie znaleźć, a do crawla z custom extraction lepszy zostaje Screaming Frog.

Ile kosztuje audyt SEO sklepu w 2026?

We wrześniu 2026 publiczne cenniki w Polsce zaczynały się od 4 900 zł netto za audyt sklepu (Semgence), a orientacyjne widełki dla rozbudowanego e-commerce wynosiły 2 500–8 000 zł netto, powyżej 10 000 zł przy bardzo dużych sklepach (Ansite).

W deklarowanym zakresie cennika Semgence są technika i treść, profil linków i konkurencja. Widełki Ansite to szacunek jednego dostawcy z aktualizacji z 8 sierpnia 2026 (artykuł Ansite o kosztach audytu), więc z takich przykładów mediany rynku nie policzysz.

Co najbardziej zmienia koszt audytu sklepu

Porównując wyceny, dopytaj wykonawcę, które z tych punktów obejmuje jego oferta.

1. liczba i typy szablonów, liczba produktów i skala przestrzeni URL;
2. liczba rynków i języków, Merchant Center z feedami i logi serwera;
3. ręczne testy filtrów i wariantów, także z renderowaniem, oraz retest w cenie;
4. treść i konkurencja czy tylko technika, a w wyniku priorytety i zadania oraz pomoc przy wdrożeniu.

„Audyt 100 000 URL-i” może być płytszy niż audyt dwunastu reprezentatywnych scenariuszy z renderowaniem i danymi GSC, bo o zakresie mówi lista wykonanych kontroli, a nie liczba adresów. Ja bym zaczął rozmowę od punktu 3, bo ręczne testy i retest sprawdzają, czy poprawki działają.

Jak powinien wyglądać wynik audytu SEO sklepu

Żeby ustalenie dało się przekazać do realizacji, zapisuję osiem pól: problem, zakres, dowód, wpływ z poziomem pewności, rekomendację, właściciela, warunek akceptacji i retest, jak w przykładowym wierszu poniżej.

Powyższy wiersz pokazuje tylko format i nie jest wynikiem audytu CometWeb ani klienta. Liczby w prawdziwym raporcie muszą pochodzić z konkretnego sklepu. Strukturę raportu dla klienta znajdziesz w artykule raport audytu strony dla klienta.

Retest audytu sklepu: co sprawdzić po wdrożeniu

Retest sklepu ma cztery części, a zadanie zamykasz dopiero wtedy, gdy przejdą wszystkie.

• Filtry mają tyle odkrywanych kombinacji, ile zakładał plan, wybrane landingi dalej się indeksują, a parametry mają stałą kolejność.
• Warianty otwierają się pod właściwymi URL-ami, a schema zgadza się z ceną i dostępnością.
• Produkty mają availability zgodne ze stroną i feedem, a przekierowania prowadzą do rzeczywistych następców.
• Dane Google sprawdzasz w Rich Results Test, w Search Console po ponownym crawlu i w Merchant Center po synchronizacji feedu.

Warunki przed i po zapiszesz w karcie retestu, a w Insight zestawisz dwa crawle obok siebie. Pojedynczy link sprawdzisz przyciskiem „Sprawdź ponownie”.

Trzy wnioski

1. Najpierw mapa, potem błędy. Decyzja o każdym typie URL-a porządkuje resztę audytu, ale szablon potrafi ją złamać przy kolejnym wdrożeniu.
2. Filtry mnożą adresy. Pięć filtrów daje w przykładzie 7 559 stanów kategorii. Canonical je konsoliduje, ale crawl hamujesz osobną polityką.
3. Audyt zamyka retest. Przy wycenie pytaj najpierw o testy ręczne i retest, bo to one pokazują, czy poprawki działają.

Jutro rano rozpisz typy stron swojego sklepu i przy każdym wpisz, czy ma być w indeksie. Jeśli chcesz crawl sklepu z listą priorytetów i porównaniem przebiegów po wdrożeniu, załóż darmowe konto w Insight.

Jeśli robisz to inaczej i działa, napisz do mnie na maciej@cometweb.io.

Najczęstsze pytania o audyt SEO sklepu

Źródła

1. Google: Managing crawling of faceted navigation URLs.
2. Google: Pagination, incremental page loading, and Search.
3. Google: Product variant structured data.
4. Google: Share your product data with Google.
5. Google: Product structured data.
6. Google Merchant Center: product data specification update 2026.
7. Google: JavaScript SEO basics.
8. Google Merchant Center: availability.
9. Google Merchant Center: product page unavailable.
10. Semgence: Audyt SEO, cennik i zakres 2026.
11. Ansite: Ile kosztuje audyt SEO?.
12. Google: ecommerce website navigation structure.

Artykuł nie gwarantuje wzrostu pozycji, sprzedaży ani kwalifikacji do funkcji Google.