Audyt techniczny SEO – jak przeprowadzic krok po kroku

Audyt techniczny SEO to systematyczna diagnoza strony pod kątem crawlability, indeksacji, szybkości i architektury – czynników, które decydują o tym, czy Google w ogóle dotrze do Twoich treści i czy je zaindeksuje. Większość stron ma kilkanaście problemów technicznych jednocześnie, ale tylko 2-3 z nich odpowiadają za 80% strat widoczności. Jeśli prowadzisz firmę lub zarządzasz stroną B2B lub e-commerce, ten przewodnik pokaże Ci jak samodzielnie przeprowadzić audyt SEO, co priorytetyzować 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 kompleksowego audytu i punkt wyjścia do jakiejkolwiek pracy nad widocznością.

Pełne techniczne SEO dzieli się na trzy warstwy: crawl/render/index (czy robot może wejść i przetworzyć stronę), on-page (treść, słowa kluczowe, meta tagi) i off-page (profil linków, brand mentions). Audyt techniczny obejmuje wyłącznie pierwszą warstwę – plus elementy on-page ściśle powiązane z infrastrukturą (meta tagi, dane strukturalne).

Dlaczego techniczne SEO to fundament? Jeśli Googlebot nie może przeczytać strony, najlepsza treść świata nie trafi do indeksu. Błędy techniczne są niewidoczne dla człowieka przeglądającego stronę – wyglądają poprawnie w przeglądarce, ale blokują bota.

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, który kosztuje straty ruchu organicznego.

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

1. Nagły spadek ruchu organicznego – diagnostyka, czy przyczyną jest problem techniczny (np. przypadkowy noindex, zmiana robots.txt)
2. Migracja domeny lub CMS – każda migracja może wprowadzić setki nowych problemów technicznych
3. Redesign lub przebudowa strony – nowe szablony, nowe błędy
4. Przed startem kampanii SEO – bezcelowe inwestowanie w content, gdy fundamenty są niesprawne
5. Po Core Update Google – sprawdzenie, czy zmiany algorytmu ujawniły dotychczas tolerowane problemy
6. Cyklicznie co kwartał – proaktywna higiena techniczna, zanim problemy wpłyną na rankingi

Triggery audytu – lista z priorytetami

Krok 1 – Crawlability i indeksacja: fundament audytu

Zanim sprawdzisz cokolwiek innego, upewnij się, że Googlebot może wejść na każdą ważną stronę – crawlability to fundament, bez którego reszta audytu jest bez sensu.

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 – weryfikacja pod adresem twojadomena.pl/robots.txt. Częste błędy: blokowanie katalogu /wp-admin/ (prawidłowo) razem z katalogami produktów lub kategorii (błąd). Sprawdź, czy żadna ważna sekcja serwisu nie jest objęta regułą Disallow.

Jeden wzorowy fragment robots.txt, który powinieneś zobaczyć dla strony z katalogiem produktów:

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

Sitemap.xml – zgłoś sitemap w Google Search Console (Indeksowanie > Mapy witryny). Sitemap powinna zawierać wyłącznie strony ze statusem HTTP 200 OK. Strony z noindex, przekierowania i błędy 4xx nie powinny się w niej znajdować.

Raport indeksacji w Google Search Console

GSC (Indeksowanie > Strony) pokazuje cztery kluczowe statusy:

• Zindeksowane – strony widoczne w Google
• Wykluczone przez noindex – sprawdź, czy żadna ważna strona nie ma nieświadomego noindex
• Crawled, not indexed – Google przeszedł, ale odmówił indeksacji (częsta przyczyna: cienka treść)
• Discovered, not indexed – strona odkryta, ale jeszcze nie odwiedzona (problem z crawl budget w dużych serwisach)

Operator site:twojadomena.pl w Google daje szybki pogląd na liczbę zaindeksowanych stron – jeśli wynik jest znacząco niższy niż liczba Twoich 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 metryki Google – LCP, INP i CLS – z twardymi progami, które bezpośrednio wpływają na rankingi i konwersje.

Progi “Good” wg Google:
– LCP < 2,5 s (Largest Contentful Paint – czas do wyrenderowania najważniejszego elementu)
– INP < 200 ms (Interaction to Next Paint – czas reakcji na interakcję użytkownika)
– CLS < 0,1 (Cumulative Layout Shift – stabilność wizualna strony)

TTFB (Time to First Byte) nie jest oficjalną metryką Core Web Vitals, ale Semrush rekomenduje TTFB < 200 ms jako wstępny warunek dobrego LCP. Powolny serwer ciągnie wszystkie pozostałe wskaźniki.

Szczegółowy przewodnik optymalizacji każdej z metryk opisuje: Core Web Vitals – LCP, INP, CLS. Tutaj: jak mierzyć.

LCP, INP i CLS – progi i znaczenie

Najczęstsze przyczyny złych wyników: duże, nieskompresowane obrazy (LCP), niezoptymalizowany JavaScript blokujący wątek główny (INP), brakujące wymiary obrazów i elementów dynamicznych (CLS). Redukcja JavaScript poprawia nie tylko szybkość – ułatwia też interpretację treści przez systemy AI.

Jak mierzyć: PageSpeed Insights, CrUX, GSC

PageSpeed Insights (pagespeed.web.dev) – pokazuje dane zarówno lab (Lighthouse, symulacja) jak i field (CrUX, realni użytkownicy). Jeśli masz rozbieżność lab vs field – zawsze ufaj danym field.

CrUX (Chrome User Experience Report) – zbiera dane z realnych przeglądarek Chrome. Dostępny przez PSI, GSC i BigQuery. Wymaga minimalnego progowego ruchu (dane mogą być niedostępne dla małych stron).

GSC Vitals report (Wydajność > Core Web Vitals) – agreguje problemy per URL dla całego serwisu. Dobry punkt startowy do identyfikacji grup stron z problemami.

Krok 3 – Architektura, linkowanie wewnętrzne i URL

Architektura strony decyduje, jak Googlebot dystrybuuje crawl budget i które strony uznaje za najważniejsze – każda kluczowa podstrona powinna być dostępna w ≤3 kliknięciach od homepage.

Zasada ≤3 kliknięć to nie teoria – Googlebot z reguły nie chodzi głębiej. Screaming Frog (Crawl > Crawl Depth report) pokazuje rozkład głębokości dla całego serwisu. Jeśli ważne strony kategorii lub produktów są na poziomie 5-7, tracisz crawl equity.

Głębokość crawlowania (≤3 kliknięcia)

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 z homepage.

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

Redirect chain to łańcuch przekierowania A → B → C zamiast bezpośrednio A → C. Każde dodatkowe przekierowanie traci częściowo przekazywany autorytet i spowalnia ładowanie. Screaming Frog automatycznie wykrywa łańcuchy – filtr: Response Code = 3xx > sprawdź kolumnę “Redirect To”.

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

302 vs 301: 301 to przekierowanie permanentne (przekazuje autorytet), 302 to tymczasowe (teoretycznie nie przekazuje – w praktyce Google traktuje je podobnie po długotrwałym występowaniu, ale poprawna semantyka wymaga 301 dla stałych zmian).

Błędy 4xx: każdy 404 z linków wewnętrznych to stracony link equity. Screaming Frog: filter Response Code = 4xx > eksportuj “Inlinks” – widzisz, które strony wewnętrzne linkują do martwych URL. Naprawa: 301 do nowej lokalizacji lub usunięcie linku.

Struktura URL i canonical

Dobre URL to: myślniki zamiast podkreśleń, lowercase, 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 – wskazuje Google, która wersja URL jest “oryginalna”. Typowe scenariusze wymagające 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: kolumna “Canonical” per URL – weryfikuj, czy canonical wskazuje na siebie (self-canonical) lub 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ą – prawidłowe title tagi i schema markup bezpośrednio wpływają na CTR w SERP i kwalifikację do rich snippets.

W audycie technicznym nie optymalizujemy strategii keywordowej meta tagów – sprawdzamy ich poprawność techniczną: unikalność, długość, występowanie.

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. Duplikaty i brak meta desc to wskaźnik niskiej jakości strony. Screaming Frog: Meta Description > Missing + Duplicate.

H1: jeden H1 na stronie, zawiera główny keyword. Screaming Frog: H1 > Missing + Multiple (wiele H1 na jednej stronie – błąd na ok. 15-20% polskich stron w moim doświadczeniu audytorskim).

Checklist:
– [ ] 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 – efektem są rich snippets w SERP i wyższe szanse na pojawienie się w AI Overviews. Szczegółowa implementacja opisana jest w artykule schema markup i dane strukturalne.

Podstawowe typy, które powinieneś sprawdzić:

• Article – dla wpisów blogowych
• Product – dla stron produktów w e-commerce
• FAQPage – dla stron z pytaniami i odpowiedziami
• Service – dla stron usługowych
• BreadcrumbList – hierarchia serwisu

Narzędzie weryfikacji: Rich Results Test (Google, darmowy) – wklej URL i sprawdź, czy schema jest poprawna i kwalifikuje do rich snippets. Strony ze schema markup w JSON-LD są łatwiejsze do interpretacji przez systemy AI – to ważny sygnał AI-readiness.

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

HTTPS to minimalny sygnał rankingowy Google – ważniejsze są mixed content errors i mobile-first indexing, które od 2024 jest mobile-only i dotyczy całego indeksu.

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

Certyfikat SSL, mixed content, Security Headers

Mixed content występuje, gdy strona HTTPS ładuje zasoby (obrazy, skrypty, CSS) przez HTTP. Chrome blokuje aktywne mixed content (JavaScript, CSS) – strona może się psuć u użytkowników. Narzędzia: Chrome DevTools (zakładka Console – ostrzeżenia mixed content) lub Screaming Frog (Reports > Mixed Content).

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

Security Headers: securityheaders.com daje szybką ocenę nagłówków HTTP. Kluczowe dla SEO i bezpieczeństwa: Strict-Transport-Security (HSTS – wymusza HTTPS), X-Content-Type-Options, Content-Security-Policy. Brak HSTS to potencjalny downgrade attack.

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 2024 Google indeksuje strony wyłącznie w wersji mobile (mobile-only indexing). Oznacza to: jeśli Twoja wersja mobilna ma inną treść, inne tagi meta lub słabszą strukturę niż desktopowa – Google ocenia to, co widzi na mobile.

Sprawdzenie w GSC: Wyzwania > Używalność na urządzeniach mobilnych – lista specyficznych błędów (tap targets za małe, tekst za mały do czytania, viewport nieustawiony). Wymóg: znacznik <meta name="viewport" content="width=device-width, initial-scale=1"> w <head> każdej strony.

Responsive design to standard – upewnij się, że Twój szablon używa go poprawnie, a nie tylko symuluje mobilność przez ukrywanie elementów (Google widzi ukrytą treść).

Krok 6 – Priorytetyzacja błędów i plan wdrożenia

Audyt techniczny SEO bez priorytetyzacji to lista problemów, nie plan działania – framework impact × effort pozwala skupić się na 2-3 zmianach, które przyniosą 80% efektu.

Po audycie techniczny konsultant regularnie dostarczał klientom raporty z 80-100 błędami. Reakcja: paraliż – nie wiedzieli, od czego zacząć, wdrażali drobnostki i pomijali krytyczne problemy. Zmiana podejścia: 5 priorytetów z uzasadnieniem biznesowym i oszacowanym efektem.

Framework priorytetyzacji (impact × effort)

Matrix 2×2:

Przykładowa klasyfikacja błędów:

Kategorie priorytetów:
1. Krytyczne – blokują indeksację lub renderowanie (naprawa w pierwszej kolejności, niezależnie od effort)
2. Wysokie – wpływają na rankingi i widoczność
3. Średnie – poprawiają UX i techniczną czystość
4. Niskie – dobra praktyka, ale nie różnica robić vs nie robić

Quick wins vs projekty długoterminowe

Quick wins (≤2 tygodnie):
– Zgłoszenie lub odświeżenie sitemap w GSC
– Naprawienie noindex na ważnych stronach
– Konfiguracja prawidłowych canonical (self-canonical)
– Usunięcie redirect chains (A→B→C → A→C)
– Dodanie brakujących meta description

Projekty (1-3 miesiące):
– Pełna migracja do HTTPS (jeśli strona wciąż na HTTP)
– JavaScript SEO – renderowanie po stronie serwera lub pre-rendering
– Przebudowa architektury URL (zmiana struktury hierarchii)
– Optymalizacja CWV do progu “Good” dla całego serwisu

Audyt techniczny SEO a AI Search – co sprawdzić w 2026

W 2026 audyt techniczny SEO musi uwzględnić dostępność strony dla AI crawlers i eligibility do AI Overviews – to nowa warstwa, której brakuje w większości polskich checklist.

Tradycyjny audyt techniczny koncentruje się na Googlebot. Tymczasem strony są teraz crawlowane przez dziesiątki różnych botów AI – ChatGPT (OAI-SearchBot), Perplexity (PerplexityBot), Bing AI (Bingbot + Bing-AI), Claude (ClaudeBot) i inne. Co więcej, dobra kondycja techniczna strony w Google jest warunkiem wstępnym pojawienia się w AI Overviews – Google używa zaindeksowanych stron jako źródła dla generatywnych odpowiedzi.

Dostępność dla AI crawlers (robots.txt)

Twój plik robots.txt może nieświadomie blokować AI crawlers. Lista najważniejszych user agents AI:

Sprawdzenie: twojadomena.pl/robots.txt – przejrzyj reguły Disallow. Reguły dla User-agent: * (wszyscy) wpływają na wszystkie boty. Jeśli masz Disallow: /blog/ – blokujesz też AI crawlers dla tej sekcji.

Kiedy blokować AI crawlers: ochrona kodu źródłowego, unikalnych danych własności intelektualnej, niechciany scraping bez cytowania. Kiedy nie blokować: jeśli zależy Ci na widoczności w AI Search – blokowanie ogranicza szanse na cytowania w odpowiedziach AI.

Blokowanie AI crawlers ogranicza, jak Twoja treść jest odkrywana i używana przez systemy generatywne. Jeśli widoczność AI ma dla Ciebie znaczenie – upewnij się, że ważne strony pozostają dostępne.

AI-readiness: structured data, szybkość, indeksacja

Trzy filary AI-readiness w audycie technicznym:

1. Indeksacja w Google – strony niewidoczne dla Googlebota nie pojawią się w AI Overviews (AIO opiera się na zaindeksowanych stronach)
2. Szybkość i minimalizacja JavaScript – JavaScript-heavy strony są trudniejsze do interpretacji przez AI; redukcja JS poprawia zarówno CWV jak i “czytelność” dla systemów AI
3. Schema markup – dane strukturalne pomagają AI jednoznacznie rozpoznać typy encji i kontekst treści, co zwiększa szanse kwalifikacji do rich snippets i AI Overviews

Praktyczny checklist AI-readiness (5 punktów):

• [ ] Wszystkie ważne strony są zaindeksowane (GSC: Strony > Zindeksowane)
• [ ] LCP < 2,5 s, JavaScript nie blokuje renderowania (PSI)
• [ ] Schema markup wdrożony dla głównych typów stron (Rich Results Test)
• [ ] AI crawlers nie są blokowane przez robots.txt (weryfikacja per user-agent)
• [ ] GSC > Wydajność: monitoruj frazy z sygnałem “AI Overviews” (dostępne w niektórych regionach)

Narzędzia do audytu technicznego SEO

Do skutecznego audytu technicznego SEO wystarczają trzy narzędzia: Google Search Console (darmowy), Screaming Frog (freemium) i PageSpeed Insights (darmowy) – reszta to opcjonalne rozszerzenie.

Ważna uwaga: narzędzie ≠ audyt. Screaming Frog wyeksportuje Ci 10 000 URL-i z 40 kolumnami danych. Interpretacja tych danych i wyciągnięcie właściwych wniosków wymaga doświadczenia – to różnica między listą błędów a planem działania.

Darmowe vs płatne – porównanie

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 (£259/rok) 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.

Orientacyjne koszty profesjonalnego audytu SEO:
– Podstawowy audyt techniczny (do 1000 URL): 1500-5000 PLN
– Kompleksowy audyt (techniczny + on-page + off-page, dla dużych serwisów): 5000-15000 PLN

Cena zależy od rozmiaru serwisu, zakresu analizy i potrzeby warsztatu omówienia wyników.

FAQ – często zadawane pytania

Jak zrobić audyt SEO?

Audyt SEO przeprowadza się w 6 krokach: (1) crawlability i indeksacja w GSC, (2) Core Web Vitals w PSI, (3) architektura i linkowanie wewnętrzne, (4) meta tagi i schema markup, (5) HTTPS i mobile-first, (6) priorytetyzacja błędów frameworkiem impact x effort. 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 zawiera analizę techniczną (crawlability, indeksacja, szybkość, mobile, HTTPS, architektura), on-page (meta tagi, treść, słowa kluczowe, dane strukturalne) i off-page (profil linków). Audyt techniczny SEO dotyczy wyłącznie warstwy infrastruktury – 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 crawl, logów serwera) i nie może samodzielnie zidentyfikować realnych problemów technicznych. Może pomóc w interpretacji danych, które mu dostarczysz, lub wygenerować listę rzeczy do sprawdzenia – ale prawdziwy audyt wymaga narzędzi z danymi realnymi, nie wiedzy ogólnej. Screaming Frog, GSC i PSI dostarczają danych, których żaden LLM nie zastąpi.

Ile kosztuje audyt SEO?

Podstawowy audyt techniczny SEO kosztuje 1500-5000 PLN, kompleksowy (techniczny + on-page + off-page) 5000-15000 PLN. Cena zależy od rozmiaru serwisu (liczby URL), zakresu analizy i czy audyt obejmuje sesję omówienia wyników z rekomendacjami. Stawka godzinowa konsultanta to orientacyjnie 350 PLN netto.

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, gap analysis vs konkurencja). Audyt techniczny to ok. 30-40% 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.