Audyt techniczny SEO krok po kroku

Krok 1. Przygotowanie, dostępy i konfiguracja crawla

Zanim uruchomię jakiekolwiek narzędzie, zbieram dostępy i dane: Google Search Console, analitykę, listę ważnych sekcji serwisu od klienta, a w większych projektach także logi serwera. Ustalam też, czy strona ma wersję testową, na której można sprawdzać poprawki.

Podstawowym narzędziem jest dla mnie Screaming Frog SEO Spider. Przed crawlem ustawiam renderowanie JavaScriptu, jeśli strona z niego korzysta, podłączam dane z Search Console i PageSpeed Insights, a w dużych serwisach ograniczam crawl do reprezentatywnych sekcji, żeby nie przeciążyć serwera. Pozostałe narzędzia SEO traktuję jako uzupełnienie crawla, np. do analizy linków czy widoczności fraz.

Sam crawl od strony głównej znajdzie tylko adresy, do których prowadzą linki. Dlatego pełną listę adresów do audytu zbieram też z mapy witryny. Zwykle jest dostępna publicznie, najczęściej pod adresem /sitemap.xml lub /sitemap_index.xml, i wskazana w pliku robots.txt. Wczytuję ją do Screaming Froga w trybie listy albo włączam w konfiguracji crawl map witryny, dzięki czemu narzędzie pokazuje też strony obecne w mapie, do których nie prowadzi żaden link wewnętrzny.

Większe serwisy często ukrywają mapę: nadają jej niestandardową nazwę, nie wpisują jej do robots.txt i zgłaszają wyłącznie w Search Console, żeby konkurencja nie mogła łatwo pobrać listy wszystkich produktów. Wtedy postępuję tak:

• Jeśli audytuję stronę klienta, biorę adres mapy z raportu Mapy witryn w Search Console albo proszę o niego zespół techniczny. To najprostsza i najpewniejsza droga.
• Sprawdzam typowe lokalizacje zależne od systemu, np. /wp-sitemap.xml w WordPressie czy mapy generowane przez wtyczki SEO dla wpisów, stron i produktów.
• Szukam w wyszukiwarce i archiwum, np. zapytaniem site:domena.pl filetype:xml, a także w archiwalnych wersjach robots.txt, w których mapa mogła być kiedyś wskazana.
• Buduję listę adresów z innych źródeł, gdy mapy nie ma lub jest niekompletna: łączę adresy z crawla, eksport stron z raportu skuteczności i raportu indeksowania w Search Console, strony docelowe z analityki oraz adresy z logów serwera. Po usunięciu duplikatów wczytuję całość do Screaming Froga w trybie listy.

Porównanie tych zbiorów samo w sobie jest cennym wynikiem audytu. Adresy obecne w mapie lub w Search Console, a nieznalezione przez crawl, to strony osierocone. Adresy z crawla, których nie ma w mapie, często wskazują na luki w jej generowaniu.

Krok 2. Indeksowanie i dostęp dla robotów

Najpierw sprawdzam rzeczy, które mogą wyłączyć całe sekcje serwisu z Google:

• reguły w pliku robots.txt i to, czy nie blokują ważnych stron, plików CSS i JavaScript,
• tagi noindex i nagłówki X-Robots-Tag na stronach, które powinny być w indeksie,
• raport stron w Search Console: które adresy są wykluczone i z jakiego powodu,
• zgodność mapy witryny z rzeczywistością: czy zawiera wyłącznie adresy kanoniczne zwracające 200.

W dużych serwisach porównuję też liczbę adresów znalezionych przez crawler z liczbą stron w indeksie. Duża różnica w którąkolwiek stronę to sygnał, że robot marnuje czas na zbędne adresy albo nie dociera do ważnych, czyli problem z crawl budgetem.

Krok 3. Kody odpowiedzi i przekierowania

Z crawla eksportuję wszystkie adresy z kodami 3xx, 4xx i 5xx oraz linki, które do nich prowadzą. Najczęściej trafiam na te sytuacje:

Każde przekierowanie w linku wewnętrznym to zbędne żądanie dla robota i użytkownika, a pomyłka w regułach serwera potrafi skończyć się pętlą przekierowań.

Krok 4. Architektura, duplikaty i linkowanie wewnętrzne

Sprawdzam, jak głęboko w strukturze leżą najważniejsze strony, czy są strony bez żadnych linków wewnętrznych i czy linki prowadzą do wersji kanonicznych. Analizuję też duplikaty: te same treści pod różnymi adresami, wersje z parametrami, z ukośnikiem i bez, z www i bez. Weryfikuję, czy canonicale wskazują właściwe adresy i nie są sprzeczne z przekierowaniami ani z mapą witryny.

W sklepach osobno analizuję paginację, filtry i sortowania, bo to one najczęściej generują tysiące zbędnych adresów. W serwisach wielojęzycznych sprawdzam znaczniki hreflang: czy każda wersja językowa wskazuje pozostałe, czy odnośniki są wzajemne i czy prowadzą do adresów kanonicznych zwracających 200.

Na tym etapie oceniam również tytuły, nagłówki H1 i opisy: duplikaty, braki i tytuły niepasujące do intencji. Wnioski o strukturze przekładam na konkretne zalecenia dotyczące linkowania wewnętrznego.

Krok 5. Renderowanie, wydajność i dane strukturalne

Porównuję kod HTML wysłany przez serwer z wersją wyrenderowaną. Jeśli treść, linki lub tagi kanoniczne pojawiają się dopiero po wykonaniu JavaScriptu, sprawdzam w Search Console, jak Google widzi stronę. Wydajność oceniam na danych od prawdziwych użytkowników, a nie tylko na testach laboratoryjnych, i grupuję problemy według szablonów stron, bo poprawka w jednym szablonie naprawia tysiące adresów. Przy słabych wynikach Core Web Vitals wskazuję konkretne elementy szablonu, które je pogarszają, i od razu ustalam z programistą sposób poprawki.

Na koniec weryfikuję dane strukturalne: czy są obecne na właściwych typach stron, czy nie mają błędów i czy zgadzają się z treścią. Sprawdzam też HTTPS, czyli przekierowania z HTTP i brak mixed content.

Ponieważ Google indeksuje strony w wersji mobilnej, porównuję, czy wersja na telefon zawiera tę samą treść, linki i dane strukturalne co wersja na komputer. Przy okazji przeglądam obrazy: ich wagę, formaty, wymiary i atrybuty alt, bo w wielu serwisach to one odpowiadają za największą część transferu.

Krok 6. Od ustaleń do wdrożonych poprawek

Lista problemów sama niczego nie poprawia. Każde ustalenie zamieniam w zadanie, które programista może podjąć bez dodatkowych pytań: co jest nie tak, ile adresów dotyczy, przykładowe adresy, oczekiwany efekt i sposób sprawdzenia, że poprawka zadziałała. Kolejność ustalam według wpływu na widoczność i ruch oraz nakładu pracy:

Zadania trafiają do narzędzia, w którym zespół pracuje na co dzień, a nie do osobnego pliku. Poprawki sprawdzam najpierw na środowisku testowym, a po wdrożeniu na produkcji ponownym crawlem tylko tych adresów, których dotyczyły. Dzięki temu wiem, że zadanie jest naprawdę zamknięte, a nie tylko oznaczone jako wykonane.

Krok 7. Stały nadzór zamiast jednorazowego audytu

Większość problemów technicznych nie istnieje od zawsze. Pojawiają się po aktualizacji wtyczki, zmianie szablonu, migracji czy nowej funkcji w sklepie. Dlatego po pierwszym, pełnym przejściu przez stronę przechodzę w tryb ciągłego nadzoru:

• zaplanowane crawle w regularnych odstępach z porównaniem do poprzedniego wyniku, żeby wychwycić nowe błędy 4xx, przekierowania czy zmiany w canonicalach,
• regularny przegląd raportów indeksowania i skuteczności w Search Console oraz reagowanie na powiadomienia,
• szybki przegląd techniczny przed każdym większym wdrożeniem, a nie dopiero po spadku ruchu,
• przy dużych serwisach okresowa analiza logów serwera, która pokazuje, czy zmiany rzeczywiście zmieniły zachowanie Googlebota.

Audyt techniczny przy migracji i na wersji roboczej

Przy zmianie domeny, CMS-a czy przebudowie strony audyt jest częścią szerszego procesu migracji. Zamiast sprawdzać jedną wersję serwisu, porównuję starą z nową, a nową audytuję na środowisku testowym, zanim trafi do użytkowników. Od strony technicznego SEO sprowadza się to do trzech momentów:

Najczęstszy błąd, jaki widzę, to przeniesienie na produkcję ustawień z wersji roboczej. Dlatego te trzy elementy sprawdzam w pierwszych minutach po przełączeniu, zanim zajmę się czymkolwiek innym.

Jeśli przygotowujesz się do przeniesienia strony, cały proces krok po kroku, od kopii zapasowych po weryfikację po wdrożeniu, znajdziesz w poradniku Migracja strony internetowej.

Automatyzacja całego procesu z Claude i agentami AI

Przez lata najwięcej czasu w audycie zajmowało mi nie znajdowanie problemów, tylko przekopywanie się przez eksporty: dziesiątki plików CSV z crawla, dane z Search Console, logi serwera. Dziś automatyzuję tę pracę z pomocą Claude i agentów AI i uważam to za jedno z najskuteczniejszych rozwiązań, jakie można obecnie zastosować w technicznym SEO. Nie chodzi o jedno narzędzie do jednego zadania, tylko o automatyzację całego procesu opisanego wyżej: od zebrania danych, przez analizę i przygotowanie poprawek, po stały nadzór. Na każdym etapie podział ról jest ten sam: agent wykonuje powtarzalną pracę na danych, a ja podejmuję decyzje.

Podział pracy na poszczególnych etapach wygląda u mnie tak:

Grupowanie po szablonach jest tu kluczowe. Zamiast tysiąca pojedynczych błędów dostaję kilka przyczyn, z których każda wymaga jednej poprawki w kodzie.

Instrukcje dla agenta zamiast jednorazowych poleceń

Podstawą jest dla mnie stały zestaw instrukcji, a nie pytania wpisywane za każdym razem od nowa. Lista kontrolna z kroków 2–5, opis oczekiwanego formatu wyników, progi istotności i zasady grupowania adresów są zapisane raz i używane w każdym audycie. Dzięki temu analiza dużego sklepu i małej strony firmowej przebiega według tych samych kryteriów, wyniki da się porównać między kolejnymi sprawdzeniami, a każda poprawka instrukcji, np. po fałszywym alarmie, działa we wszystkich następnych projektach.

Ręczna walidacja

Każde ustalenie weryfikuję samodzielnie. Otwieram przykładowe adresy, sprawdzam kod źródłowy i wersję wyrenderowaną, porównuję z danymi w Search Console, usuwam fałszywe alarmy i oceniam wpływ na biznes, którego żadne narzędzie nie zna tak dobrze jak rozmowa z klientem.

To nie jest formalność. Model potrafi poprawnie policzyć i pogrupować tysiące wierszy, ale bez kontekstu może uznać za błąd coś, co jest celową decyzją, np. noindex na stronach filtrów, albo przecenić problem dotyczący kilku nieistotnych adresów. Połączenie automatycznej analizy z ekspercką weryfikacją daje szybkość, kompletność przy dużych serwisach i pewność, że do zespołu trafia wyłącznie to, co faktycznie wymaga pracy.

Przygotowanie i wdrażanie poprawek

Po walidacji agent pomaga zamienić ustalenia w zadania i konkretne zmiany. Z listy usuniętych adresów przygotowuje propozycję mapy przekierowań, dopasowując stare adresy do najbliższych tematycznie stron. Przygotowuje poprawki szablonów, brakujące dane strukturalne, reguły dla serwera czy zmiany w mapie witryny, a do każdego zadania dołącza opis problemu, przykłady i sposób sprawdzenia efektu.

Każda taka zmiana przechodzi tę samą drogę co praca programisty: przegląd kodu, test na środowisku testowym i weryfikację po wdrożeniu. Mapę przekierowań zawsze przeglądam ręcznie, bo automatyczne dopasowanie potrafi wskazać stronę podobną w treści, ale nieodpowiednią dla użytkownika. Agent skraca przygotowanie poprawki z godzin do minut, ale decyzja o jej wdrożeniu zostaje po stronie człowieka.

Stały nadzór i powiadomienia

W nadzorze automatyzacja daje największy zwrot, bo porównywanie kolejnych crawli i eksportów z Search Console to praca powtarzalna, którą łatwo pominąć, gdy wszystko wydaje się działać. Agent uruchamiany według harmonogramu sprawdza kluczowe szablony stron, porównuje wyniki z poprzednim sprawdzeniem i przygotowuje krótkie podsumowanie zmian: nowe błędy 4xx i 5xx, zmienione canonicale, nagłe przyrosty adresów wykluczonych z indeksu, spadki widoczności konkretnych sekcji.

Ja dostaję tylko to, co przekroczyło ustalone progi, i oceniam, czy to problem, czy zamierzona zmiana. Dzięki temu błąd wprowadzony przy aktualizacji wtyczki czy nowej funkcji w sklepie wychwytuję w ciągu kilku dni, a nie po kilku tygodniach spadku ruchu.

Bezpieczeństwo danych

Wrzucanie danych klienta do narzędzi AI wymaga takiej samej ostrożności jak przekazanie ich każdemu innemu podwykonawcy. Trzymam się kilku zasad:

• Przekazuję tylko to, co potrzebne do analizy. Eksporty z crawla i Search Console zawierają adresy stron i statystyki, ale logi serwera zawierają też adresy IP i dane o użytkownikach. Przed analizą usuwam lub anonimizuję adresy IP, parametry z identyfikatorami sesji, adresy e-mail i wszystko, co pozwala zidentyfikować osobę.
• Nigdy nie przekazuję dostępów. Hasła, klucze API, tokeny i pliki konfiguracyjne z danymi logowania nie trafiają do modelu. Agent pracuje na eksportach, a nie na kontach klienta.
• Korzystam z wersji, które nie używają danych do trenowania. Pracuję na kontach i dostępach, w których przesyłane dane nie służą do uczenia modeli, i sprawdzam to w ustawieniach oraz warunkach usługi, a nie zakładam z góry.
• Mam zgodę klienta. Zakres danych, które mogą trafić do narzędzi AI, ustalam przed audytem, a przy danych osobowych uwzględniam to w umowie powierzenia przetwarzania danych.
• Gdzie się da, liczę lokalnie. Ciężkie przetwarzanie, np. agregację milionów wierszy logów, wykonuję skryptem na własnym komputerze, a do modelu przekazuję już zagregowane wyniki, a nie surowe dane.