Audyt techniczny sklepu internetowego: co powinien obejmować

Audyt techniczny sklepu internetowego: od czego zacząć

Audyt techniczny sklepu internetowego zaczynam od sprawdzenia, czy wyszukiwarka może poprawnie dotrzeć do stron, które mają generować ruch, oraz czy otrzymuje z serwera właściwe informacje. Dopiero później przechodzę do szczegółów związanych z kodem, linkowaniem, danymi strukturalnymi czy wydajnością.

W sklepie internetowym problem rzadko dotyczy jednej strony. Błąd w szablonie może powielić się na setkach kart produktów. Nieprawidłowy filtr może tworzyć tysiące adresów URL. Zmiana struktury kategorii może pozostawić stare adresy bez przekierowań. Dlatego techniczny audyt SEO powinien obejmować zarówno pojedyncze adresy, jak i sposób, w jaki cały sklep generuje, łączy i udostępnia strony.

Jeżeli prowadzisz sklep samodzielnie, nie musisz zaczynać od przeglądania całego kodu źródłowego. Najpierw ustal, które typy stron istnieją w sklepie: strona główna, kategorie, podkategorie, produkty, strony informacyjne, blog, wyniki wyszukiwania, filtry i paginacja. Następnie sprawdź, które z nich powinny być indeksowane, a które nie powinny trafiać do wyników wyszukiwania.

Kompletny przewodnik po indeksowaniu sklepu dobrze uzupełnia ten etap, szczególnie gdy sklep ma dużo produktów, filtrów i wariantów.

Celem audytu nie jest stworzenie długiej listy drobnych uwag. Chodzi o ustalenie zależności: jaki problem występuje, których adresów dotyczy, dlaczego powstał, jaki może mieć wpływ na indeksowanie lub dostęp użytkownika do strony i co trzeba zmienić.

Co obejmuje audyt techniczny sklepu

Zakres kontroli powinien być dopasowany do wielkości i technologii sklepu, ale podstawowy audyt obejmuje kilka powtarzalnych obszarów. W praktyce sprawdzam przede wszystkim indeksowanie, statusy HTTP, przekierowania, canonicale, sitemapę, robots.txt, strukturę URL, linkowanie wewnętrzne, dane strukturalne, wydajność oraz duplikację.

Obszar audytu	Kontrola i typ wykrywanego problemu
Indeksowanie	Strony wykluczone, błędnie indeksowane, noindex, problemy z dostępnością URL
Statusy HTTP	Błędy 4xx i 5xx, soft 404, nieprawidłowe odpowiedzi serwera
Przekierowania	Brak przekierowań, łańcuchy, pętle, niewłaściwe adresy docelowe
Canonicale	Brak, błędne lub niespójne adresy kanoniczne
Sitemap	Nieaktualne, błędne lub niepożądane adresy w mapie witryny
robots.txt	Blokowanie istotnych zasobów lub błędne reguły dla crawlerów
Linkowanie wewnętrzne	Osierocone strony, zbyt głębokie podstrony, niewłaściwa struktura linków
Dane strukturalne	Brak danych, błędy implementacji, niezgodność z treścią strony
Wydajność	Problemy z ładowaniem, interakcją i stabilnością wizualną
Duplikacja	Powielone adresy, parametry, warianty i podobne strony
Adresy URL	Nieczytelna struktura, zbędne parametry, wiele wersji tego samego adresu
JavaScript	Treści lub linki niedostępne albo nieprawidłowo renderowane

Tak uporządkowany zakres pozwala później przypisać każdemu problemowi priorytet. Inaczej traktuje się blokadę indeksowania całej kategorii, a inaczej brak pojedynczego pola w danych strukturalnych.

Indeksowanie i dostęp robotów wyszukiwarki

Pierwsze pytanie brzmi: czy Google może znaleźć i przetworzyć strony, które chcesz mieć w wynikach wyszukiwania? Sam fakt, że produkt otwiera się w przeglądarce, nie odpowiada na to pytanie.

W Search Console sprawdź raport indeksowania oraz pojedyncze adresy za pomocą inspekcji URL. W przypadku problematycznych stron porównaj stan znany Google ze stanem aktualnym. Jeżeli strona ma zwracać prawidłową treść, a raport pokazuje wykluczenie, trzeba ustalić przyczynę zamiast od razu zmieniać ustawienia SEO.

Sprawdź także dyrektywy robots. noindex może wyłączyć stronę z indeksu, natomiast robots.txt służy przede wszystkim do kontrolowania dostępu crawlerów do adresów i zasobów. Nie należy traktować robots.txt jako zamiennika noindex.

W sklepie szczególnie dokładnie sprawdź kategorie, produkty, strony paginacji i adresy generowane przez filtry. Właśnie tam ustawienia platformy e-commerce lub dodatkowych modułów często powodują sytuację, w której część wartościowych stron jest blokowana, a jednocześnie wyszukiwarka dostaje dostęp do dużej liczby adresów o niewielkiej wartości.

Przydatne jest przygotowanie listy reprezentatywnych adresów. Wybierz kilka produktów, kilka kategorii, strony informacyjne oraz przykładowe adresy z parametrami. Sprawdź dla każdego z nich status indeksowania, robots meta, canonical i dostępność w kodzie HTML.

Nie ograniczaj kontroli do raportu narzędzia. Jeżeli problem dotyczy dużej grupy URL, sprawdź szablon lub regułę, która je generuje. Naprawa pojedynczego produktu nie rozwiązuje błędu, jeżeli wszystkie nowe produkty będą otrzymywać tę samą nieprawidłową konfigurację.

Statusy HTTP i przekierowania

Kolejny etap to sprawdzenie odpowiedzi serwera. Każdy istotny adres powinien zwracać odpowiedni status HTTP. Kod 200 oznacza poprawną odpowiedź, ale nie gwarantuje indeksowania. Kod 404 informuje, że zasób nie został znaleziony. Błędy 5xx wskazują natomiast na problemy po stronie serwera.

W audycie nie wystarczy policzyć błędów. Trzeba sprawdzić, jakie adresy je generują i czy powinny nadal istnieć. Usunięty produkt może być prawidłowym 404, jeśli nie ma odpowiedniego następcy. Jeżeli jednak produkt został przeniesiony na nowy adres, można rozważyć właściwe przekierowanie.

Szczególnej kontroli wymagają przekierowania 301 i 308, a także tymczasowe przekierowania 302, 303 i 307. Sprawdź, czy adres źródłowy prowadzi bezpośrednio do właściwego celu. Jeżeli URL A przekierowuje do B, a B do C, powstaje łańcuch, który można zwykle uprościć przez skierowanie A bezpośrednio do C.

Sprawdź również pętle przekierowań. Mogą pojawić się po zmianie domeny, wdrożeniu HTTPS, zmianie końcowych ukośników albo migracji sklepu. W praktyce dobrze jest przetestować zarówno wersję z www i bez www, jak również HTTP i HTTPS, jeśli takie warianty były wcześniej dostępne.

Przekierowanie powinno prowadzić do strony odpowiadającej intencji użytkownika. Nie przekierowuj masowo niepowiązanych starych adresów na stronę główną tylko po to, żeby pozbyć się błędów. Jeżeli dawny produkt ma konkretny następnik, kieruj użytkownika właśnie tam. Jeśli nie ma odpowiedniego zamiennika, oceń, czy adres powinien zwracać 404 lub 410.

Jeśli podczas audytu znajdziesz dużo błędów pochodzących z linków prowadzących poza sklep, osobnym tematem będzie wykrywanie zepsutych linków wychodzących, ponieważ ich naprawa wymaga sprawdzenia źródła każdego odnośnika.

Canonicale i problemy z duplikacją

W sklepach internetowych duplikacja często wynika z funkcji, które z punktu widzenia użytkownika są potrzebne. Sortowanie produktów, filtrowanie, parametry URL, warianty produktu czy różne sposoby prezentacji tej samej kategorii mogą tworzyć wiele adresów prowadzących do bardzo podobnej treści.

Audyt powinien odpowiedzieć na pytanie, które adresy są właściwymi stronami docelowymi, a które są tylko wariantami technicznymi. Następnie sprawdź element rel="canonical" na reprezentatywnych stronach.

Canonical nie jest prostym poleceniem, które automatycznie usuwa stronę z indeksu. To sygnał wskazujący preferowany adres spośród podobnych lub zduplikowanych wersji. Dlatego nie wystarczy sprawdzić, czy tag istnieje. Trzeba porównać jego wartość z rzeczywistą strukturą sklepu.

Typowy błąd wygląda tak: produkt znajduje się pod właściwym adresem, ale canonical wskazuje inną kartę produktu. Innym problemem może być canonical kierujący na adres przekierowujący, niedostępny albo zablokowany. Warto też sprawdzić, czy adresy umieszczone w sitemapie są zgodne z preferowanymi adresami kanonicznymi.

Duplikację badaj na kilku poziomach. Porównaj identyczne treści dostępne pod różnymi URL, strony kategorii różniące się tylko parametrem, produkty z wariantami oraz strony wyników filtrowania. W przypadku dużego sklepu potrzebujesz nie tylko listy duplikatów, lecz także informacji, jaka reguła je tworzy.

Przy migracji sklepu sprawdź dodatkowo stare i nowe adresy. Błędna mapa przekierowań może jednocześnie powodować utratę użytecznych wejść, błędy 404 i powstawanie niepotrzebnych wersji stron.

Sitemap i robots.txt

Sitemapę traktuj jako uporządkowaną listę adresów, które chcesz przekazać wyszukiwarce do crawlowania. W audycie sprawdź, czy plik istnieje, czy można go pobrać oraz jakie adresy zawiera.

Nie powinno być w nim przypadkowych stron technicznych, adresów przekierowujących, błędów 404 czy wariantów, których nie chcesz przedstawiać jako główne strony sklepu. Sprawdź również zgodność protokołu, domeny i wersji URL z faktyczną konfiguracją witryny.

Jeżeli sklep ma dużą liczbę produktów, zobacz, czy sitemap jest dzielona w sposób obsługiwany przez system i czy ewentualny indeks sitemap prowadzi do aktualnych plików. Google zaleca umieszczanie w sitemapie adresów, które właściciel uważa za kanoniczne.

Robots.txt sprawdź osobno. Przejrzyj każdą regułę Disallow i zadaj proste pytanie: czy blokuje ona coś, co Google powinien móc pobrać? Szczególnie ostrożnie podchodź do reguł dotyczących katalogów, parametrów, zasobów CSS i JavaScript.

Nie kopiuj gotowego robots.txt z innego sklepu. Reguły powinny wynikać z rzeczywistej struktury Twojej witryny. W przypadku platform takich jak WooCommerce czy PrestaShop konfiguracja może dodatkowo zależeć od modułów, filtrów i sposobu generowania URL.

Linkowanie wewnętrzne i struktura sklepu

Crawler nie porusza się po sklepie tak jak człowiek. Dlatego sprawdź, czy istotne strony można znaleźć przez normalne linki HTML prowadzące z innych podstron.

Zacznij od menu głównego. Następnie przejdź przez kategorie, podkategorie i produkty. Sprawdź, czy ważne produkty są dostępne z odpowiednich kategorii i czy nie istnieją podstrony, do których nie prowadzi żaden wewnętrzny link.

W sklepie można znaleźć produkt dostępny przez wyszukiwarkę wewnętrzną, ale niewidoczny podczas przechodzenia przez kategorie. To problem zarówno dla użytkownika, jak i dla crawlowania. Google nie musi wykonywać wyszukiwania w formularzu sklepu, aby znaleźć taki produkt.

Sprawdź też głębokość stron. Jeżeli wartościowa kategoria lub produkt jest osiągalny dopiero po wielu przejściach przez przypadkowo rozbudowaną strukturę, przeanalizuj, czy da się skrócić drogę. Pomocne mogą być linki z kategorii nadrzędnych, menu, sekcji bestsellerów, powiązanych produktów oraz treści poradnikowych.

Nie twórz jednak setek sztucznych linków tylko po to, żeby zwiększyć ich liczbę. Link powinien pomagać użytkownikowi przejść do kolejnej logicznej części oferty.

W ramach audytu sprawdź również anchor texty. Link z nazwą produktu może być naturalny, ale w treściach kategorii czy poradnikach można stosować bardziej opisowe odnośniki, jeśli odpowiadają kontekstowi. Osobno przeanalizuj strony osierocone, czyli takie, które istnieją, ale nie mają sensownego wejścia z innych podstron. Jeśli chcesz rozszerzyć tę kontrolę o wycenę, przydatny będzie audyt linkowania wewnętrznego i jego koszt.

Dane strukturalne w sklepie

Dane strukturalne sprawdzaj na poziomie konkretnych typów stron. Sklep może mieć inne informacje na stronie produktu, inne na kategorii, a jeszcze inne na stronie organizacji czy okruszkach nawigacyjnych.

Na karcie produktu sprawdź przede wszystkim, czy dane odpowiadają temu, co faktycznie widzi użytkownik. Nie powinno być sytuacji, w której kod deklaruje produkt, cenę, dostępność lub inne informacje, których nie ma na stronie albo które są nieaktualne.

Sprawdź również duplikowanie danych strukturalnych przez kilka wtyczek lub modułów. W WooCommerce może dojść do sytuacji, w której dane generuje jednocześnie motyw, wtyczka SEO i dodatkowy moduł. W PrestaShop podobny problem może powstać po instalacji kilku modułów modyfikujących szablon produktu.

Nie oceniaj danych strukturalnych wyłącznie przez pryzmat tego, czy narzędzie pokazuje zielony komunikat. Najpierw porównaj markup z rzeczywistą zawartością strony, a następnie sprawdź wymagania dla konkretnego typu danych.

W sklepie szczególnie przydatne mogą być dane związane z produktami i okruszkami nawigacyjnymi. Google wskazuje też inne typy danych strukturalnych związane z e-commerce, dlatego ich dobór powinien wynikać z rodzaju strony, a nie z listy wszystkich możliwych znaczników.

Wydajność i problemy techniczne strony

Audyt techniczny sklepu nie kończy się na indeksowaniu. Sklep może być poprawnie dostępny dla Google, ale jednocześnie mieć problemy z czasem ładowania, interakcją albo stabilnością layoutu.

Sprawdź Core Web Vitals dla rzeczywistych użytkowników oraz wyniki laboratoryjne dla reprezentatywnych stron. Nie ograniczaj się do strony głównej. Produkt, kategoria, koszyk i rozbudowana strona poradnikowa mogą zachowywać się zupełnie inaczej.

Analizuj przede wszystkim LCP, INP i CLS. LCP odnosi się do szybkości ładowania największego elementu treści, INP do reakcji strony na interakcje użytkownika, a CLS do stabilności wizualnej. Problemy mogą wynikać między innymi z ciężkich obrazów, niepotrzebnego JavaScriptu, opóźnionego ładowania zasobów, reklam, zewnętrznych skryptów lub źle przygotowanych fontów.

W sklepie sprawdź szczególnie zdjęcia produktów. Zobacz, czy obrazy mają właściwe rozmiary, czy nie są znacznie większe niż miejsce, w którym są wyświetlane, oraz czy mechanizmy optymalizacji nie powodują problemów z widocznością treści.

Przeanalizuj też liczbę skryptów ładowanych przez moduły marketingowe, analityczne, czaty, popupy i dodatkowe funkcje sklepu. Każdy plugin może działać poprawnie osobno, ale ich łączny wpływ na stronę może być odczuwalny.

Jeżeli chcesz przejść z audytu ogólnej wydajności do szczegółowej analizy metryk, dobrym kolejnym krokiem jest praktyczna kontrola Core Web Vitals w sklepie.

Audyt techniczny WooCommerce i PrestaShop

Platforma sklepu wpływa na sposób przeprowadzania audytu. W WooCommerce trzeba zwrócić uwagę na konfigurację WordPressa, motywu, wtyczek SEO, cache, filtrów produktów, wariantów i funkcji generujących dodatkowe adresy.

Sprawdź, które elementy odpowiadają za canonicale, sitemapę, robots meta i dane strukturalne. Jeżeli kilka narzędzi modyfikuje te same elementy, ustal, które z nich faktycznie generuje wynik widoczny w kodzie strony.

W PrestaShop przeanalizuj przede wszystkim strukturę kategorii, kombinacje produktów, przyjazne URL, przekierowania, parametry i działanie modułów SEO. Po aktualizacji platformy lub modułu warto ponownie sprawdzić te obszary, ponieważ zmiana jednego elementu szablonu może wpłynąć na wiele typów stron.

W obu przypadkach nie zakładaj, że ustawienie w panelu administracyjnym odpowiada temu, co otrzymuje crawler. Audyt powinien sprawdzać efekt końcowy, czyli kod HTML, nagłówki HTTP, odpowiedzi serwera, linki oraz faktyczną dostępność adresu.

To właśnie dlatego audyt techniczny PrestaShop lub audyt techniczny WooCommerce powinien być wykonywany na działającym sklepie, a nie wyłącznie na podstawie konfiguracji panelu.

Jak przygotować sklep do audytu SEO

Jeżeli chcesz zlecić audyt albo przeprowadzić go we własnym zakresie, przygotuj dostęp do danych, które pozwolą sprawdzić rzeczywisty stan sklepu. Bez tego część problemów może pozostać niewidoczna.

Przede wszystkim zbierz informacje o domenie, platformie, najważniejszych zmianach technicznych i ostatnich migracjach. Jeżeli sklep zmieniał domenę, strukturę URL, platformę lub system filtrowania produktów, zaznacz te informacje przed rozpoczęciem analizy.

Przygotuj dostęp do Google Search Console oraz, jeśli jest używane, narzędzia analitycznego. Przy większych sklepach przydatny będzie także eksport produktów i adresów URL. Pozwala to porównać listę stron istniejących w sklepie z adresami znalezionymi podczas crawlowania.

Jeżeli audyt ma obejmować serwer, potrzebne mogą być informacje o hostingu, CDN, cache i konfiguracji aplikacji. Nie zawsze trzeba udostępniać pełne dane administracyjne. Zakres dostępu powinien odpowiadać temu, co faktycznie ma zostać sprawdzone.

Przed audytem nie usuwaj masowo błędów z Search Console. Historia problemów może być przydatna do ustalenia, kiedy pojawiła się zmiana. Zamiast sprzątać raport, najpierw ustal przyczynę.

Dobrym przygotowaniem jest także lista najważniejszych kategorii i produktów. Jeżeli masz strony generujące sprzedaż, strony o największej liczbie wejść organicznych oraz produkty strategiczne, oznacz je. Dzięki temu można później połączyć problemy techniczne z rzeczywistą strukturą biznesową sklepu.

Jak ustalić kolejność napraw

Po zakończeniu kontroli nie zaczynaj od najdłuższej listy błędów. Najpierw pogrupuj problemy według przyczyny i zakresu.

Najwyżej powinny trafić błędy, które mogą ograniczać dostęp wyszukiwarki do dużej części wartościowych stron. Przykładem może być blokada indeksowania kategorii, błędna reguła robots.txt, nieprawidłowy canonical zastosowany na całym szablonie albo awaria serwera powodująca masowe błędy.

Następnie zajmij się problemami powtarzalnymi. Jeśli wszystkie produkty mają ten sam błąd w danych strukturalnych, poprawienie szablonu jest skuteczniejsze niż ręczna edycja każdej karty. Jeśli setki starych URL nie mają odpowiednich przekierowań, przygotuj regułę lub mapę przekierowań zamiast poprawiać adresy pojedynczo.

Kolejna grupa to problemy ograniczone do pojedynczych stron lub niewielkich grup URL. Nie oznacza to, że można je ignorować, ale ich priorytet zależy od znaczenia tych stron dla ruchu, sprzedaży i struktury sklepu.

Na końcu zostaw drobne kwestie techniczne, które nie wpływają na dostępność, indeksowanie ani działanie istotnych funkcji. Audyt ma pomóc podejmować decyzje, a nie generować listę kilkuset zadań bez wskazania kolejności.

Przy każdym błędzie zapisz adres lub wzorzec URL, rodzaj problemu, przyczynę, rekomendowane rozwiązanie i informację, czy problem występuje pojedynczo, czy masowo. Taki format pozwala programiście lub właścicielowi sklepu przejść od diagnozy do konkretnej zmiany.

Co sprawdza audyt techniczny w praktyce

Rzetelny audyt nie powinien kończyć się zdaniem: „sklep ma problemy z SEO”. Wynik powinien odpowiadać na znacznie bardziej praktyczne pytania.

Czy Google może wejść na najważniejsze strony? Czy kategorie i produkty mają prawidłowe statusy HTTP? Czy usunięte adresy są obsługiwane zgodnie z ich przeznaczeniem? Czy przekierowania prowadzą bezpośrednio do właściwych stron? Czy canonicale są spójne z sitemapą? Czy robots.txt nie blokuje istotnych elementów? Czy ważne produkty można znaleźć przez linkowanie wewnętrzne? Czy dane strukturalne odpowiadają zawartości? Czy wydajność wymaga zmian w kodzie, obrazach, cache lub skryptach? Czy filtry i parametry tworzą niepotrzebne kopie stron?

Dopiero odpowiedzi na te pytania pokazują, co rzeczywiście wymaga pracy. Techniczny audyt SEO nie powinien być raportem oderwanym od sposobu działania sklepu. Powinien wskazać konkretną przyczynę, zakres problemu i sposób jego usunięcia.

Jeżeli nie chcesz samodzielnie przechodzić przez wszystkie te elementy, możesz zlecić analizę sklepu wraz z uporządkowaniem problemów i wskazaniem kolejności działań: audyt techniczny sklepu internetowego.

Podsumowanie

Audyt SEO sklepu powinien obejmować znacznie więcej niż sprawdzenie kilku meta tagów. Najpierw trzeba ustalić, jak wyszukiwarka znajduje strony i czy może je prawidłowo przetworzyć. Później sprawdza się statusy HTTP, przekierowania, canonicale, sitemapę, robots.txt i strukturę linków.

Kolejna warstwa obejmuje dane strukturalne, wydajność, JavaScript, adresy URL i duplikację. W sklepie wszystkie te elementy są ze sobą powiązane, dlatego pojedynczy błąd w szablonie lub konfiguracji może dotyczyć dużej części witryny.

Najlepszy audyt kończy się listą konkretnych zmian uporządkowanych według zakresu i wpływu problemu. Dzięki temu właściciel sklepu wie, co poprawić najpierw, co może poczekać i które elementy wymagają pracy programisty, administratora lub osoby odpowiedzialnej za SEO.