Audyt techniczny SEO: jak go przeprowadzić krok po kroku

Audyt techniczny SEO to systematyczna diagnoza strony pod kątem dostępności dla robotów, indeksacji, szybkości i architektury, czyli czynników, od których zależy, czy Google w ogóle dotrze do Twoich treści i je zaindeksuje. Większość stron ma jednocześnie kilkanaście problemów technicznych, ale zwykle tylko kilka z nich naprawdę ogranicza widoczność. Jeśli prowadzisz firmę albo zarządzasz stroną B2B lub sklepem, ten przewodnik pokaże Ci, jak samodzielnie przeprowadzić audyt SEO, co naprawić najpierw i kiedy warto zlecić go specjaliście.

Czym jest audyt techniczny SEO i czym różni się od audytu SEO

Audyt techniczny SEO to diagnoza infrastruktury strony: sprawdza, czy Google może ją znaleźć, zrozumieć i zaindeksować, zanim w ogóle oceni jakość treści. To pierwsza warstwa każdego pełnego audytu i punkt wyjścia do jakiejkolwiek pracy nad widocznością.

Pełny audyt SEO obejmuje trzy warstwy: skanowanie, renderowanie i indeksację (czy robot może wejść na stronę i ją przetworzyć), on-page (treść, słowa kluczowe, meta tagi) i off-page (profil linków, wzmianki o marce). Techniczne SEO i audyt techniczny dotyczą pierwszej warstwy oraz elementów on-page ściśle związanych z infrastrukturą (meta tagi, dane strukturalne).

Dlaczego techniczne SEO to fundament? Jeśli Googlebot nie może przeczytać strony, najlepsza treść nie trafi do indeksu. Człowiek przeglądający stronę nie widzi błędów technicznych, bo w przeglądarce wszystko wygląda poprawnie, a robot zostaje zablokowany.

Co obejmuje audyt techniczny a czego nie

---

Kiedy przeprowadzić audyt techniczny SEO

Audyt techniczny SEO przeprowadzaj co najmniej raz na kwartał i zawsze po każdej większej zmianie w serwisie. Czekanie na „odpowiedni moment” to błąd, za który płaci się utratą ruchu organicznego.

Sześć triggerów, które wymuszają audyt:

1. Nagły spadek ruchu organicznego: sprawdzenie, czy przyczyną jest problem techniczny (np. przypadkowy noindex, zmiana w robots.txt)
2. Migracja domeny albo CMS: każda migracja może wprowadzić setki nowych problemów technicznych
3. Przebudowa strony: nowe szablony to nowe błędy
4. Przed rozpoczęciem pozycjonowania: inwestowanie w treści nie ma sensu, gdy fundamenty nie działają
5. Po core update Google: sprawdzenie, czy zmiany algorytmu nie ujawniły problemów, które wcześniej nie przeszkadzały
6. Regularnie co kwartał: profilaktyka techniczna, zanim problemy wpłyną na pozycje

Kiedy audyt jest pilny

---

Krok 1. Crawlability i indeksacja: fundament audytu

Zanim sprawdzisz cokolwiek innego, sprawdź, czy Googlebot może wejść na każdą ważną stronę. Bez tego reszta audytu nie ma znaczenia, bo Google nie zobaczy poprawek.

Crawlowanie poprzedza indeksowanie. Googlebot najpierw pobiera stronę (crawl), potem ją renderuje (przetwarza JavaScript), na końcu decyduje, czy zaindeksować. Problem na etapie crawl = strona nigdy nie pojawi się w wynikach, niezależnie od jakości treści.

Szczegółowe podejście do każdego z elementów opisuje audyt crawlability i indeksacji krok po kroku. W tym miejscu koncentruję się na tym, co sprawdzić w ramach ogólnego audytu technicznego.

Robots.txt i sitemap.xml

Robots.txt: sprawdź plik pod adresem twojadomena.pl/robots.txt. Częsty błąd to blokowanie katalogu /wp-admin/ (prawidłowo) razem z katalogami produktów albo kategorii (błąd). Sprawdź, czy żadna ważna sekcja serwisu nie jest objęta regułą Disallow.

Przykład poprawnego pliku robots.txt dla strony z katalogiem produktów:

User-agent: Googlebot
Disallow: /koszyk/
Disallow: /checkout/
Sitemap: https://twojadomena.pl/sitemap.xml

Sitemap.xml: zgłoś mapę witryny w Google Search Console (Indeksowanie > Mapy witryny). Mapa powinna zawierać wyłącznie strony z kodem HTTP 200. Strony z noindex, przekierowania i błędy 4xx nie powinny się w niej znaleźć.

Raport indeksacji w Google Search Console

GSC (Indeksowanie > Strony) pokazuje cztery kluczowe statusy:

• Zaindeksowane: strony widoczne w Google
• Wykluczone przez tag noindex: sprawdź, czy żadna ważna strona nie ma noindex przez pomyłkę
• Strona zeskanowana, ale jeszcze niezindeksowana: Google odwiedził stronę, ale jej nie zaindeksował (częsta przyczyna to cienka treść)
• Strona wykryta – obecnie niezindeksowana: Google zna adres, ale jeszcze go nie odwiedził (w dużych serwisach to często problem z budżetem indeksowania)

Operator site:twojadomena.pl w Google daje szybki pogląd na liczbę zaindeksowanych stron. Jeśli wynik jest wyraźnie niższy niż liczba Twoich adresów URL, masz problem z indeksacją.

Crawl budget i strony osierocone

Crawl budget to liczba URL, które Googlebot jest gotów odwiedzić w danym czasie. Dla serwisów poniżej 1000 stron rzadko stanowi problem. Dla dużych e-commerce (10k+ URL) optymalizacja crawl budget jest krytyczna.

Strony osierocone (zero linków wewnętrznych prowadzących do nich) w Screaming Frog: zakł. Bulk Export > All Inlinks, posortuj po liczbie linków przychodzących = 0. Strona bez linków wewnętrznych jest de facto niewidoczna dla bota.

---

Krok 2. Core Web Vitals i szybkość strony

Core Web Vitals to trzy oficjalne wskaźniki Google, LCP, INP i CLS, z twardymi progami, które wpływają na pozycje i konwersje.

Progi „Good” wg Google:

• LCP < 2,5 s (Largest Contentful Paint: czas do wyrenderowania największego elementu)
• INP < 200 ms (Interaction to Next Paint: czas reakcji na działanie użytkownika)
• CLS < 0,1 (Cumulative Layout Shift: stabilność układu strony)

TTFB (Time to First Byte) nie należy do Core Web Vitals, ale wpływa na LCP. Według Google dobry TTFB to 0,8 s lub mniej. Jako cel warto przyjąć około 200 ms, bo wolny serwer opóźnia wszystkie pozostałe wskaźniki.

Szczegółową optymalizację każdego wskaźnika opisuje przewodnik Core Web Vitals: LCP, INP, CLS. Tutaj opisuję, jak je mierzyć.

LCP, INP i CLS: progi i znaczenie

Najczęstsze przyczyny słabych wyników to duże, nieskompresowane obrazy (LCP), niezoptymalizowany JavaScript blokujący główny wątek (INP) i brak wymiarów obrazów oraz elementów dynamicznych (CLS). Mniej JavaScriptu to nie tylko większa szybkość, ale też treść łatwiejsza do odczytania dla systemów AI.

Jak mierzyć: PageSpeed Insights, CrUX, GSC

PageSpeed Insights (pagespeed.web.dev) pokazuje zarówno dane laboratoryjne (Lighthouse, symulacja), jak i dane od użytkowników (CrUX, prawdziwe wizyty). Jeśli się różnią, ufaj danym od użytkowników.

CrUX (Chrome User Experience Report) zbiera dane z prawdziwych przeglądarek Chrome. Jest dostępny w PSI, GSC i BigQuery. Wymaga minimalnego ruchu, więc dla małych stron danych może nie być.

Raport Podstawowe wskaźniki internetowe w GSC (Środowisko > Podstawowe wskaźniki internetowe) zbiera problemy dla całego serwisu i grupuje adresy. To dobry punkt startowy do znalezienia grup stron z problemami.

---

Krok 3. Architektura, linkowanie wewnętrzne i URL

Architektura strony decyduje, jak Googlebot rozdziela budżet indeksowania i które strony uznaje za najważniejsze; najważniejsze podstrony powinny być blisko strony głównej, najlepiej najwyżej trzy kliknięcia od niej.

Trzy kliknięcia to praktyczna zasada, nie limit Googlebota. Głębokość wpływa na to, jak często Google odwiedza stronę i ile sygnałów z linków wewnętrznych do niej trafia. Rozkład głębokości dla całego serwisu pokazuje raport Crawl Depth w Screaming Frog. Jeśli ważne kategorie lub produkty są na poziomie 5–7, przybliż je linkami z menu, kategorii albo stron filarowych.

Głębokość kliknięć

W Screaming Frog: uruchom crawl, przejdź do zakładki „Internal” > eksportuj, posortuj po kolumnie „Crawl Depth”. Strony głębokość >3: sprawdź, czy to strony paginacji (akceptowalne) czy strony produktów/usług (problem do naprawy).

Dla dużych serwisów: linkowanie hubowe (kategoria → podkategoria → produkt) jest lepsze niż płaska struktura z tysiącami linków ze strony głównej.

Redirect chains, pętle i błędy 4xx/5xx

Łańcuch przekierowań to przekierowanie A → B → C zamiast bezpośrednio A → C. Każde dodatkowe przekierowanie opóźnia przekazanie sygnałów i spowalnia ładowanie. Screaming Frog sam wykrywa łańcuchy: filtr Response Code = 3xx > kolumna „Redirect To”.

Pętla przekierowania (A → B → A) blokuje Googlebot na tym URL definitywnie. Screaming Frog oznacza je jako „Redirect Loop”.

302 czy 301: 301 to przekierowanie stałe, a 302 tymczasowe. Google przy długo utrzymywanym 302 może traktować je podobnie jak 301, ale przy stałej zmianie adresu poprawnym wyborem jest 301.

Błędy 4xx: każdy link wewnętrzny do strony 404 marnuje wartość linku. W Screaming Frog ustaw filtr Response Code = 4xx > wyeksportuj „Inlinks”, a zobaczysz, które strony linkują do nieistniejących adresów. Naprawa: przekierowanie 301 do nowej lokalizacji albo usunięcie linku.

Struktura URL i canonical

Dobre URL to: myślniki zamiast podkreśleń, małe litery, bez parametrów sesji, logicznie hierarchiczne. Przykład prawidłowy: /blog/techniczne-seo/audyt-techniczny-seo/, nieprawidłowy: /page?id=123&session=abc.

Canonical rozwiązuje problem duplikacji treści, bo wskazuje Google, która wersja adresu jest „oryginalna”. Typowe sytuacje, które wymagają canonical:

• Strony filtrowania i sortowania w e-commerce (parametry URL generują setki „kopii”)
• Wersje z www i bez www (tylko jedna powinna być kanoniczna)
• HTTP i HTTPS (zawsze HTTPS jako kanoniczny)

Sprawdzenie w Screaming Frog: w kolumnie „Canonical” dla każdego adresu sprawdź, czy canonical wskazuje na samą stronę albo na właściwą stronę nadrzędną.

---

Krok 4. Techniczne on-page: meta tagi, H1, dane strukturalne

Meta tagi i dane strukturalne to warstwa komunikacji z wyszukiwarką: poprawne tytuły i schema wpływają na CTR w wynikach i na możliwość wyświetlenia wyników rozszerzonych.

W audycie technicznym nie optymalizujemy fraz w meta tagach, tylko sprawdzamy ich poprawność techniczną: unikalność, długość i obecność.

Title tag, meta description, H1

Title tag: Google przycina po ok. 60 znakach w SERP. Sprawdzenie w Screaming Frog: Page Titles > Missing (brak) + Duplicate (duplikaty) + Over 60 Characters (za długie). Każda strona musi mieć unikalny title z głównym keywordem blisko początku.

Meta description: ok. 160 znaków. Nie jest bezpośrednim czynnikiem rankingowym, ale wpływa na CTR. Powtarzające się albo brakujące opisy świadczą o zaniedbanej stronie. Screaming Frog: Meta Description > Missing i Duplicate.

Pojedynczy tytuł albo opis przed wdrożeniem sprawdzisz w liczniku znaków z podglądem wyniku Google. Licznik mierzy szerokość w pikselach, więc pokaże też tytuł, który ma mniej niż 60 znaków, a mimo to zostanie ucięty.

H1: jeden nagłówek H1 na stronie, z główną frazą. Screaming Frog: H1 > Missing i Multiple. Kilka H1 na jednej stronie to według moich audytów błąd na ok. 15–20% polskich stron.

Lista kontrolna:

• Każda strona ma unikalny title tag ≤60 znaków
• Każda strona ma meta description ≤160 znaków
• Każda strona ma dokładnie 1 H1
• Brak duplikatów title i meta desc w całym serwisie

Schema markup: co daje i jak sprawdzić

Schema markup (dane strukturalne w formacie JSON-LD) pomaga Google i systemom AI rozpoznać encje i relacje na stronie, a efektem mogą być wyniki rozszerzone. Szczegółowe wdrożenie opisuję w artykule schema markup i dane strukturalne.

Podstawowe typy do sprawdzenia:

• Article: wpisy na blogu
• Product: strony produktów w e-commerce
• FAQPage: strony z pytaniami i odpowiedziami (od 7 maja 2026 r. bez wyników rozszerzonych FAQ)
• Service: strony usług
• BreadcrumbList: hierarchia serwisu

Do sprawdzenia służy Rich Results Test (bezpłatne narzędzie Google): wklej adres i sprawdź, czy schema jest poprawna i czy strona może mieć wyniki rozszerzone. Dane strukturalne w JSON-LD ułatwiają też systemom AI odczytanie, kto i co jest opisane na stronie.

---

Krok 5. HTTPS, bezpieczeństwo i mobile-first

HTTPS to słaby sygnał rankingowy Google. Ważniejsze są błędy mieszanej treści (mixed content) i jakość wersji mobilnej, bo Google ocenia strony na podstawie tego, co widzi na telefonie.

Sprawdzenie HTTPS jest proste: kłódka przy URL w przeglądarce. Ważniejsze są subtelniejsze problemy.

Certyfikat SSL, mixed content, Security Headers

Treści mieszane (mixed content) to sytuacja, gdy strona HTTPS ładuje zasoby (obrazy, skrypty, CSS) przez HTTP. Chrome blokuje aktywne treści mieszane (JavaScript, CSS), więc strona może się u użytkowników psuć. Narzędzia: Chrome DevTools (zakładka Console, ostrzeżenia o mixed content) albo Screaming Frog (Reports > Mixed Content).

Wszystkie wersje domeny powinny przekierowywać 301 do jednej preferowanej: http://, http://www. i https://www. → https://twojadomena.pl/ (albo konsekwentnie do wersji z www).

Nagłówki bezpieczeństwa: securityheaders.com szybko je ocenia. Najważniejsze dla SEO i bezpieczeństwa to Strict-Transport-Security (HSTS, wymusza HTTPS), X-Content-Type-Options i Content-Security-Policy. Bez HSTS przeglądarka może przy pierwszej wizycie połączyć się przez niezabezpieczone HTTP.

SSL expiry: sprawdź certyfikat (kliknięcie kłódki w Chrome > Certificate). Wygasły certyfikat = Chrome blokuje dostęp do strony = zero ruchu.

Mobile-first indexing: jak sprawdzić

Od 31 października 2023 r. Google indeksuje wszystkie strony na podstawie wersji mobilnej (indeksowanie mobile-first). Jeśli Twoja wersja mobilna ma inną treść, inne meta tagi albo słabszą strukturę niż wersja na komputery, Google ocenia to, co widzi na telefonie.

Raport „Użyteczność na urządzeniach mobilnych” Google wycofał z Search Console 1 grudnia 2023 r. Wersję mobilną sprawdzisz testem Lighthouse w Chrome DevTools (za małe elementy dotykowe, nieczytelny tekst, brak viewport) i narzędziem Sprawdzanie adresu URL w Search Console. Wymóg: znacznik <meta name="viewport" content="width=device-width, initial-scale=1"> w <head> każdej strony.

Responsywny szablon to dziś standard. Sprawdź, czy wersja mobilna ma tę samą treść co desktopowa, bo Google ocenia stronę po wersji mobilnej.

---

Krok 6. Ustal kolejność napraw

Audyt bez kolejności napraw to lista problemów, a nie plan. Każdy błąd ocenia się według wpływu na widoczność i nakładu pracy, a zaczyna od tych, które blokują indeksację.

Raport z 80–100 błędami bez kolejności zwykle kończy się tak samo: zespół poprawia drobiazgi, które łatwo zrobić, a problemy blokujące indeksację czekają. Dlatego wynik audytu warto ograniczyć do kilku priorytetów z krótkim uzasadnieniem, co się zmieni po naprawie.

Wpływ i nakład pracy

Przykładowa klasyfikacja błędów:

Poziomy pilności:

1. Krytyczne: blokują indeksację lub renderowanie; naprawiasz je najpierw, niezależnie od nakładu pracy.
2. Wysokie: wpływają na pozycje i widoczność.
3. Średnie: poprawiają wygodę użytkownika i porządek techniczny.
4. Niskie: dobra praktyka bez wyraźnego wpływu na wynik.

Szybkie poprawki i projekty

Szybkie poprawki (do 2 tygodni):

• zgłoszenie lub odświeżenie mapy witryny w GSC,
• usunięcie noindex z ważnych stron,
• poprawne canonicale wskazujące na samą stronę,
• skrócenie łańcuchów przekierowań (A→B→C zamienione na A→C),
• uzupełnienie brakujących opisów meta.

Projekty (1–3 miesiące):

• migracja na HTTPS, jeśli strona nadal działa na HTTP,
• renderowanie JavaScriptu po stronie serwera albo prerendering,
• przebudowa struktury adresów,
• poprawa Core Web Vitals do poziomu „dobre” w całym serwisie.

---

Audyt techniczny a wyszukiwarki AI

Do AI Overviews i Trybu AI Google wybiera strony z własnego indeksu, więc warunek jest ten sam co w zwykłych wynikach: strona musi być zaindeksowana i móc wyświetlać się z fragmentem. Inne wyszukiwarki AI mają własne roboty, które trzeba wpuścić w robots.txt.

Roboty wyszukiwarek AI w robots.txt

Najważniejsze user-agenty, które warto sprawdzić w pliku robots.txt:

Sprawdź plik twojadomena.pl/robots.txt i reguły Disallow. Reguły dla User-agent: * dotyczą wszystkich robotów, więc Disallow: /blog/ blokuje bloga także wyszukiwarkom AI.

Roboty do trenowania modeli (GPTBot, ClaudeBot, Google-Extended) możesz blokować bez wpływu na widoczność w wyszukiwarkach. Roboty wyszukiwania (Googlebot, Bingbot, OAI-SearchBot, PerplexityBot) zablokuj tylko wtedy, gdy świadomie rezygnujesz z widoczności w danej usłudze.

Lista kontrolna dla wyszukiwarek AI

• Ważne strony są zaindeksowane (raport Indeksowanie stron w GSC).
• Treść jest widoczna w HTML albo poprawnie renderowana; sprawdź to narzędziem Sprawdzanie adresu URL.
• Robots.txt wpuszcza roboty wyszukiwarek, na których Ci zależy.
• Strony nie mają nosnippet ani zbyt niskiego max-snippet, chyba że świadomie ograniczasz fragmenty.
• Wyświetlenia w funkcjach AI monitorujesz w raporcie generatywnej AI w Search Console, dostępnym dla wszystkich witryn od 31 sierpnia 2026 r.

Dane strukturalne pomagają wyszukiwarce zrozumieć typ treści, ale Google nie wymaga ich do AI Overviews. Więcej o tym, jak Google tworzy takie odpowiedzi, piszę w artykule o AI Overviews.

---

Narzędzia do audytu technicznego SEO

Do skutecznego audytu technicznego SEO wystarczą trzy narzędzia: Google Search Console (bezpłatne), Screaming Frog (bezpłatny do 500 adresów) i PageSpeed Insights (bezpłatne); pozostałe są opcjonalne.

Ważna uwaga: narzędzie to jeszcze nie audyt. Screaming Frog wyeksportuje Ci 10 000 adresów z 40 kolumnami danych, a ich interpretacja i właściwe wnioski wymagają doświadczenia. Na tym polega różnica między listą błędów a planem działania.

Narzędzia bezpłatne i płatne

Co możesz zrobić bez budżetu: pełny audyt techniczny do 500 URL dzięki GSC + PSI + darmowy Screaming Frog. Dla serwisów powyżej 500 URL płatna wersja Screaming Frog (199 GBP rocznie według cennika z 22.10.2026) to pierwsza inwestycja, która się zwraca po jednym wykrytym błędzie krytycznym.

Kiedy samodzielnie, kiedy zlecić specjaliście

Samodzielnie (DIY): do 200 URL, znasz podstawy HTML i GSC, masz czas na 4-8 godzin pracy. Standardowe błędy (noindex, brak sitemap, mixed content) można naprawić bez wsparcia.

Specjalista (wymagany): 10k+ URL z rozbudowaną architekturą, migracja domeny lub platformy CMS, JavaScript rendering problems, brak wiedzy technicznej po stronie klienta, potrzeba priorytetyzacji dla zespołu deweloperskiego.

Jeśli wolisz zlecić audyt: u mnie audyt SEO kosztuje od 2000 zł netto, a projekt technicznego SEO od 1500 zł netto dla serwisu do 500 adresów. Cena rośnie z liczbą adresów i złożonością technologii, szczegóły są w cenniku.

---

FAQ: pytania o audyt techniczny SEO

Jak zrobić audyt SEO?

Audyt SEO przeprowadza się w 6 krokach: (1) dostępność dla robotów i indeksacja w GSC, (2) Core Web Vitals w PSI, (3) architektura i linkowanie wewnętrzne, (4) meta tagi i schema, (5) HTTPS i wersja mobilna, (6) kolejność napraw według wpływu i nakładu pracy. Każdy krok wymaga odpowiednich narzędzi (GSC, Screaming Frog, PageSpeed Insights) i umiejętności interpretacji danych.

Co powinien zawierać audyt SEO?

Pełny audyt SEO obejmuje analizę techniczną (dostępność dla robotów, indeksacja, szybkość, wersja mobilna, HTTPS, architektura), on-page (meta tagi, treść, słowa kluczowe, dane strukturalne) i off-page (profil linków). Audyt techniczny SEO dotyczy tylko infrastruktury i jest punktem wyjścia przed pracą nad treścią i linkami.

Czy ChatGPT może przeprowadzić audyt SEO?

ChatGPT nie ma dostępu do danych Twojej strony (GSC, wyników skanowania, logów serwera) i sam nie wykryje realnych problemów technicznych. Może pomóc zinterpretować dane, które mu przekażesz, albo przygotować listę rzeczy do sprawdzenia, ale prawdziwy audyt wymaga narzędzi z rzeczywistymi danymi, a nie ogólnej wiedzy. Screaming Frog, GSC i PSI dostarczają danych, których żaden model językowy nie zastąpi.

Ile kosztuje audyt SEO?

Cena zależy od liczby adresów, zakresu analizy i tego, czy audyt obejmuje omówienie wyników. U mnie audyt SEO kosztuje od 2000 zł netto, a konsultacje 350 zł netto za godzinę; szczegóły są w cenniku.

Jak często przeprowadzać audyt techniczny SEO?

Minimum raz na kwartał cyklicznie, plus każdorazowo po większych zmianach: migracja domeny lub platformy CMS, redesign, wdrożenie nowego szablonu, lub po Core Update Google, gdy widoczność spada bez oczywistej przyczyny.

Jaka jest różnica między audytem technicznym SEO a pełnym audytem SEO?

Audyt techniczny SEO bada wyłącznie infrastrukturę: crawlability, indeksację, szybkość, architekturę, HTTPS i mobile. Pełny audyt SEO obejmuje dodatkowo warstwę on-page (treść, słowa kluczowe, duplikaty, dane strukturalne) i off-page (profil linków, porównanie z konkurencją). Audyt techniczny jest pierwszą częścią pełnego audytu.

Ile czasu zajmuje audyt techniczny SEO?

Dla małego serwisu (do 200 URL) samodzielnie: 4-8 godzin pracy. Dla średniego serwisu (do 1000 URL): 1-2 dni robocze. Dla dużego serwisu (10k+ URL) z profesjonalnym crawlem, analizą logów serwera i sesją omówienia: 3-5 dni roboczych. Czas rośnie nieliniowo z rozmiarem serwisu i liczbą wykrytych błędów.