Audyt techniczny SEO sklepu: checklista crawl budgetu, filtrów i indeksacji

Crawler pokazuje, co da się znaleźć na stronie. Logi pokazują, co Googlebot robi naprawdę, a to zwykle inny obraz. Bierzemy 30 dni logów, filtrujemy po zweryfikowanych adresach IP Google i grupujemy trafienia po wzorcach ścieżek: karty produktu, kategorie, kategorie z parametrami, wyszukiwarka wewnętrzna, zasoby statyczne.

Interesują nas trzy liczby. Odsetek trafień na adresy z parametrami, bo powyżej 30 procent oznacza, że nawigacja fasetowa zjada budżet. Odsetek kart produktu odwiedzonych w ciągu 30 dni, bo jeśli 40 procent aktywnego katalogu nie zostało odwiedzone ani razu, nowe produkty będą wchodzić do indeksu tygodniami. Oraz rozkład kodów odpowiedzi, w którym każdy zauważalny udział błędów 5xx i łańcuchów przekierowań jest bezpośrednią stratą.

Do tego czytamy statystyki indeksowania w Search Console: średnią liczbę żądań dziennie, średni czas odpowiedzi i podział według celu pobrania. Nagły wzrost czasu odpowiedzi powyżej 800 ms zwykle poprzedza spadek liczby indeksowanych stron o kilkadziesiąt procent, więc jest to wskaźnik wczesnego ostrzegania, a nie ciekawostka.

Sześć filtrów po osiem wartości z możliwością łączenia daje kilkaset tysięcy kombinacji na jedną kategorię. Sklep tego nie zauważa, bo nikt tych adresów nie ogląda, ale Googlebot chodzi po linkach i przy okazji przestaje odwiedzać karty produktu. Poprawka polega na świadomej decyzji, które kombinacje mają być adresami, a które nie mają prawa istnieć jako link.

Indeksowalne zostawiamy zwykle tylko pojedyncze fasety o realnym wolumenie wyszukiwań, na przykład kategoria plus kolor albo kategoria plus marka, i traktujemy je jako pełnoprawne strony z własnym tytułem i treścią. Wszystko inne powinno być dostępne dla użytkownika, ale niedostępne dla crawlera jako link do zaindeksowania. W praktyce robi się to przez obsługę zmiany filtru bez generowania klikalnego odnośnika w HTML albo przez parametry po znaku hash.

Częsty błąd to zablokowanie parametrów w robots.txt przy jednoczesnym poleganiu na adresach kanonicznych. Zablokowany adres nie zostanie pobrany, więc Google nigdy nie zobaczy znacznika kanonicznego i może zostawić taki URL w indeksie bez opisu. Kolejność ma znaczenie: najpierw przestań linkować, poczekaj, aż adresy wypadną z indeksu, i dopiero potem rozważ blokadę w robots.txt.

Wyniki wyszukiwarki wewnętrznej w indeksie to klasyk i najłatwiejszy zysk w całym audycie. Adresy z parametrem zapytania generują nieskończoną przestrzeń, często z zerową liczbą wyników, i wyglądają dla Google jak strony niskiej jakości. Blokada tej ścieżki w robots.txt plus usunięcie linków do popularnych wyszukiwań z zakładek zdejmuje zwykle kilkanaście procent trafień bota w pierwszym tygodniu.

Druga częsta pułapka to produkty niedostępne zwracające kod 200 z pustą treścią i komunikatem o braku dostępności. Google klasyfikuje je jako miękkie 404 i po jakimś czasie zaczyna z góry traktować podobne adresy podejrzliwie. Trzecia to strony stronicowania z adresem kanonicznym wskazującym na pierwszą stronę listy, przez co produkty z dalszych stron nie mają żadnej ścieżki do indeksu.

Warto też przejrzeć raport indeksowania pod kątem statusu wykryta, obecnie niezaindeksowana. Jeśli obejmuje ponad 30 procent adresów z mapy witryny, to nie jest kwestia cierpliwości, tylko sygnał, że Google nie widzi powodu, żeby te strony pobrać. Zwykle winne są duplikaty opisów z feedu producenta albo brak linkowania wewnętrznego do głębszych części katalogu.

Decyzja, co zrobić z produktem znikającym z oferty, ma bezpośredni wpływ na ruch, bo takie karty często mają najwięcej linków i historii. Jeśli produkt wróci w ciągu kilku tygodni, zostawiamy adres z kodem 200, jasnym komunikatem o dostępności i listą alternatyw z tej samej kategorii. Zmieniamy tylko atrybut dostępności w danych strukturalnych, żeby wynik w wyszukiwarce nie kłamał.

Jeśli produkt ma następcę, przekierowanie 301 na jego kartę jest właściwe i przenosi wartość linków. Przekierowanie wszystkich wycofanych produktów zbiorczo do kategorii to natomiast prosta droga do miękkich 404, bo Google rozpoznaje przekierowania do stron niepowiązanych tematycznie. Przy trwałym wycofaniu bez następcy najczyściej działa kod 410 i usunięcie adresu z mapy witryny.

Całe to zachowanie powinno wynikać z reguł w systemie, a nie z decyzji osoby dodającej produkty. W sklepie z rotacją kilkuset indeksów miesięcznie ręczne zarządzanie tym procesem nie ma szans, a błędy kumulują się przez lata i trafiają potem do nas jako niewyjaśniony spadek widoczności.

Google renderuje JavaScript, ale robi to w drugiej kolejce i przy dużych serwisach opóźnienie potrafi sięgać dni. Jeśli listing kategorii dociąga produkty po stronie klienta, część katalogu trafi do indeksu z opóźnieniem albo wcale. Test jest prosty: pobierz stronę z wyłączonym JavaScriptem albo porównaj HTML surowy i wyrenderowany w Screaming Frogu w trybie renderowania.

W projektach Next.js problem pojawia się najczęściej tam, gdzie kluczowa treść siedzi w komponencie klienckim doładowywanym dynamicznie z wyłączonym renderowaniem serwerowym. Opisy kategorii, dane produktu i linkowanie wewnętrzne muszą być w początkowym HTML, reszta może się doładować. Warto sprawdzić to osobno dla wersji mobilnej, bo indeksowanie odbywa się właśnie na niej i to ona jest podstawą oceny.

Audyt kończący się listą 120 uwag jest bezużyteczny, bo nikt nie wie, od czego zacząć. Każde zadanie opisujemy trzema liczbami: szacowanym wpływem na ruch, pewnością tego szacunku i kosztem wdrożenia w dniach. Sortowanie po tych trzech wartościach zwykle wypycha na górę rzeczy nudne, takie jak wyszukiwarka wewnętrzna w indeksie czy łańcuchy przekierowań, i spycha w dół ambitne przebudowy.

Drugi filtr to powiązanie z przychodem. Poprawa indeksacji w kategorii odpowiadającej za 2 procent obrotu jest mniej warta niż ta sama poprawa w kategorii z 30 procentami, nawet jeśli technicznie wygląda identycznie. Dlatego przed audytem prosimy o strukturę przychodu według kategorii, a raport piszemy w tej kolejności, a nie według kolejności zakładek w narzędziu.