Audyt techniczny SEO: 50 punktów kontrolnych

Audyt techniczny SEO to nie 3-godzinne „skanowanie Screaming Frogiem” – to 50+ punktów, które decydują, czy Google i LLM-y w ogóle zobaczą treść. W projektach 2024–2026 audyty techniczne odblokowały średnio 27% ruchu organicznego – bez jednego nowego artykułu, tylko przez naprawę indeksacji, renderowania i sygnałów crawla.

Poniższa lista to 50 punktów kontrolnych ułożonych w 7 bloków – od dostępności serwera po JSON-LD. Każdy punkt ma przypisany priorytet (P0/P1/P2), typowe narzędzie i konkretne kryterium „pass/fail”. Nie jest to teoria – to ta sama checklist używana w 80+ projektach w latach 2023–2026.

Czym jest audyt techniczny SEO i czym nie jest

Audyt techniczny SEO to systematyczna diagnoza warstwy infrastrukturalnej strony pod kątem zdolności wyszukiwarek do jej crawlowania, renderowania, indeksowania i rankowania. Warstwa techniczna – nie treści, nie linków. Chociaż te obszary często nakładają się w praktyce, audyt techniczny nie ocenia jakości artykułów ani profilu linków.

Różnica w stosunku do ogólnego audytu SEO: ten drugi to szerokie spojrzenie na stan projektu (technika + treść + linki + konkurencja). Audyt techniczny to głęboki dive w jednej warstwie – tej, która najczęściej blokuje cały projekt, chociaż sama w sobie rzadko generuje bezpośrednio wzrosty.

Kiedy audyt techniczny jest konieczny

• Nagły spadek widoczności bez zmiany treści ani linków – prawie zawsze diagnoza techniczna.
• Migracja domeny, struktury URL, CMS – audyt przed i po obowiązkowy.
• Nowa strona starsza niż 6 miesięcy bez wzrostów – sprawdź najpierw infrastrukturę, potem treść.
• Core Web Vitals failing – LCP > 2,5 s, INP > 200 ms, CLS > 0,1.
• Planowany redesign – audyt bazowy, żeby zmierzyć wpływ zmian.

Kiedy audyt techniczny nie jest pierwszym ruchem

• Strona bez treści – nie ma co audytować, zacznij od audytu treści.
• Strona ranguje na niekomercyjne frazy – problem jest w doborze keywords, nie w technice.
• Strona ma < 3 miesięcy – Google jeszcze ją poznaje, cierpliwość.

Blok 1: Serwer i dostępność (punkty 1–7)

Fundament wszystkiego – jeśli Googlebot nie może odpytać serwera, nic więcej nie ma znaczenia. Ten blok zajmuje ~1 godzinę przy standardowej infrastrukturze, do 3 godzin przy hostingu enterprise z CDN i load balancerem.

Punkt 1 (P0): Kod odpowiedzi dla strony głównej i kluczowych URL-ów

Kryterium: homepage zwraca 200, strony kategorii 200, top 20 artykułów 200. Narzędzie: curl -I https://example.pl lub Screaming Frog. Typowe problemy: 302 zamiast 200 (powoduje wyczerpanie crawl budgetu na redirecty), 500/502 przy częstych godzinach (sprawdź monitoring uptime).

Punkt 2 (P0): TTFB – czas odpowiedzi serwera

Kryterium: TTFB < 600 ms dla Googlebota, idealnie < 200 ms. Narzędzie: Chrome DevTools Network tab, WebPageTest, GSC Crawl Stats. Powyżej 800 ms Google zacznie ograniczać crawl rate. Rozwiązania: cache na poziomie serwera (Redis, Varnish), CDN (Cloudflare), upgrade hostingu z shared na VPS/dedicated.

Punkt 3 (P0): HTTPS na całej domenie

Kryterium: wszystkie URL-e zwracają 200 na HTTPS, HTTP redirectuje 301 na HTTPS, certyfikat ważny minimum 30 dni. Sprawdź SSL Labs (A lub A+), brak mixed content w DevTools Console. Częsty błąd: wewnętrzne linki z http:// w starych artykułach lub szablonie – wymuszaj HTTPS w canonical tag i sitemap. Temat ten rozwijamy w przewodniku SEO 2026.

Punkt 4 (P1): HTTP/2 lub HTTP/3

Kryterium: serwer obsługuje HTTP/2 (multipleksacja requestów, mniejszy narzut). Sprawdź w Chrome DevTools Network tab w kolumnie Protocol. Wpływ: 5–15% szybsza strona przy wielu małych zasobach. HTTP/3 (QUIC) to bonus, głównie dla mobilki w niestabilnych sieciach.

Punkt 5 (P1): Kompresja Brotli/Gzip

Kryterium: HTML, CSS, JS, JSON są kompresowane (response header content-encoding: br lub gzip). Brotli daje ~20% lepszą kompresję niż Gzip. Sprawdź w DevTools lub curl -I -H "Accept-Encoding: br, gzip". Oszczędność pasma i czasu ładowania proporcjonalna do rozmiaru.

Punkt 6 (P1): Cache headers i CDN

Kryterium: zasoby statyczne (CSS, JS, obrazki, fonty) mają Cache-Control: public, max-age=31536000, immutable i są serwowane z CDN. HTML może być prywatny lub cache 5–60 minut zależnie od charakteru treści. Brak cache headers = Googlebot ciągle pobiera te same zasoby, marnując crawl budget.

Punkt 7 (P2): Geolokalizacja serwera i CDN coverage

Kryterium: serwer lub edge CDN w regionie docelowej publiczności (dla Polski – Frankfurt, Warszawa, Amsterdam). Sprawdź w Cloudflare Analytics lub ping z różnych regionów. Dla stron międzynarodowych sprawdź, czy CDN ma obecność w kluczowych rynkach. Pomijalne dla stron lokalnych, istotne dla międzynarodowych.

Blok 2: Indeksacja (punkty 8–15)

Drugi fundament – URL, który nie jest zaindeksowany, nie ma prawa rankować. Punkty 8–15 zajmują 2–3 godziny, przy większych stronach 4–5 godzin (więcej ręcznych sprawdzeń w GSC).

Punkt 8 (P0): robots.txt – poprawność i dostępność

Kryterium: robots.txt istnieje na /robots.txt, zwraca 200, nie zawiera globalnego Disallow: /. Częste wpadki: staging robots.txt wgrany na prod (32% problemów P0 w moich audytach), literówki w User-agent, blokada katalogu /wp-content/ blokująca CSS/JS.

Punkt 9 (P0): Meta robots i X-Robots-Tag

Kryterium: strony, które mają być zaindeksowane, nie zawierają noindex w HTML ani X-Robots-Tag headerze. Sprawdź masowo przez Screaming Frog (filtr Directives). Typowy błąd: WordPress w ustawieniach „Discourage search engines” zostawionym po migracji z staging.

Punkt 10 (P0): Sitemap XML – istnienie, rozmiar, świeżość

Kryterium: sitemap.xml lub sitemap_index.xml istnieje, max 50 tys. URL na plik, max 50 MB, zawiera tylko URL-e z kodem 200 i bez noindex. Sprawdź ostatnią modyfikację w <lastmod>. Sitemap z 50% URL-ów 404 lub noindex to silny negatywny sygnał dla Google.

Punkt 11 (P0): Sitemap zarejestrowany w Search Console

Kryterium: wszystkie sitemapy zgłoszone w GSC, status „Success”, liczba URL „Discovered” zbliżona do liczby URL w sitemap. Różnica > 20% między „Submitted” a „Indexed” wymaga diagnozy – najczęściej thin content, duplicate, lub problem z renderowaniem.

Punkt 12 (P0): Raport Coverage w GSC

Kryterium: wszystkie kluczowe kategorie i top artykuły w statusie „Indexed”. Zakładka „Not indexed” z powodami: Crawled – currently not indexed, Discovered – currently not indexed, Duplicate without user-selected canonical. Każda z tych kategorii wymaga innej diagnozy i innego działania.

Punkt 13 (P1): Canonical tag – spójność z href i sitemap

Kryterium: każdy URL ma <link rel="canonical" href="..."/> wskazujący na preferowaną wersję. Canonical URL zwraca 200, jest w sitemap, i linkuje sam do siebie na tej wersji. Sprzeczność: canonical wskazuje na URL X, a ten X ma canonical na URL Y – Google ignoruje i wybiera sam.

Punkt 14 (P1): Parametry URL i filtrowanie

Kryterium: parametry (?utm=, ?sort=, ?color=) nie generują duplikatów w indeksie. Narzędzie: Screaming Frog z opcją „Include URL parameters”, Ahrefs Site Audit raport „URL parameters”. Rozwiązania: canonical do wersji bez parametru, blokada w robots.txt dla parametrów utm/source, parametry filtracji pod noindex, follow.

Punkt 15 (P1): Strony paginacji

Kryterium: strony typu ?page=2 mają canonical do siebie (nie do strony 1), zawierają unikalne listy produktów/artykułów, nie są noindex. Google oficjalnie przestał używać rel=prev/next w 2019 – obecna best practice to self-canonical plus linki w paginacji HTML zamiast JavaScript.

Blok 3: Crawl budget i logi (punkty 16–22)

Dla stron < 10 tys. URL crawl budget rzadko jest wąskim gardłem. Dla większych – kluczowy. Ten blok to 3–6 godzin analizy logów serwera (najlepsza diagnoza) lub GSC Crawl Stats.

Punkt 16 (P1): Crawl rate w GSC

Kryterium: raport GSC Crawl Stats pokazuje stabilną lub rosnącą liczbę żądań Googlebota. Średnia waha się 10–50% – to normalne. Spadek o 60%+ trwający > 14 dni sygnalizuje problem (serwer wolny, robots.txt, lub Google zdecydował, że strona nie jest warta crawla).

Punkt 17 (P1): Rozkład crawla na typy plików

Kryterium: 60–70% crawla to HTML, 20–30% obrazki/CSS/JS, reszta inne. Jeśli 80%+ to obrazki, Googlebot traci czas na zasoby zamiast treści – sprawdź, czy obrazki nie są zduplikowane przez różne URL-e (CDN z wieloma wariantami).

Punkt 18 (P1): Logi serwera – segmentacja ruchu Googlebota

Kryterium: minimum 14 dni logów serwera przeanalizowane w Screaming Frog Log File Analyser, Semrush Log Analyzer, lub własnym pipeline BigQuery. Weryfikacja User-agent Googlebot przez reverse DNS (nslookup) – 3–8% ruchu podaje się za Googlebota fałszywie.

Punkt 19 (P1): Strony odwiedzane często a ich wartość biznesowa

Kryterium: top 100 URL-i najczęściej crawlowanych powinno zawierać strony z największym ruchem organicznym i konwersjami. Jeśli Googlebot spędza 40% czasu na /tag/ lub ?sort=, masz crawl waste. Rozwiązanie: noindex + nofollow na tagach, blokada parametrów w robots.txt.

Punkt 20 (P2): Strony nieosiągane przez Googlebota (orphan pages)

Kryterium: URL-e w sitemap lub GSC, które nie pojawiają się w logach > 60 dni. Narzędzie: Screaming Frog porównanie „Crawled URLs” vs „URLs in sitemap”. Orphan pages nie rankują, nawet jeśli są technicznie indeksowalne. Rozwiązanie: dodaj internal link z pokrewnej kategorii lub top artykułu.

Punkt 21 (P2): 404 i 5xx w logach

Kryterium: < 2% żądań Googlebota kończy się 404, < 0,5% to 5xx. Wyższe wartości = crawl waste. Top 20 najczęściej 404-owanych URL-i to zwykle kandydaci na redirect 301 do aktualnej wersji.

Punkt 22 (P2): Średni czas odpowiedzi per sekcja

Kryterium: średni response time dla Googlebota < 500 ms per sekcja (blog, sklep, strony statyczne). Sekcja znacząco wolniejsza = prawdopodobnie generowana dynamicznie bez cache, Googlebot zmniejszy crawl rate tej sekcji.

Blok 4: Renderowanie i JavaScript (punkty 23–29)

W 2026 roku większość nowoczesnych stron to JavaScript framework (Next.js, Nuxt, Angular). Nieprawidłowe renderowanie to najczęstszy ukryty problem SEO. Ten blok wymaga 2–4 godzin i dobrego zrozumienia renderowania JavaScript pod SEO.

Punkt 23 (P0): URL-e renderują treść bez JS (server-side rendering)

Kryterium: curl https://example.pl zwraca HTML z treścią, tytułem, meta tagami, linkami. Jeśli curl zwraca pustą stronę z <div id="root"></div>, masz SPA bez SSR – Google poradzi sobie z tym gorzej niż z SSR (opóźniona indeksacja 3–5x, niestabilne rendery).

Punkt 24 (P0): Wszystkie kluczowe meta tagi w HTML od razu

Kryterium: title, description, canonical, hreflang, JSON-LD są w pierwszym response HTML, nie doinstalowywane przez JS. Narzędzie: „View page source” (nie „Inspect”) w Chrome. Sprawdź Googlebot Rendering w GSC URL Inspection – porównaj HTML źródłowy vs wyrenderowany.

Punkt 25 (P0): Linki wewnętrzne działają z wyłączonym JS

Kryterium: menu, paginacja, related content są zwykłymi <a href>, nie <div onclick>. Test: wyłącz JS w DevTools i sprawdź, czy klikalne elementy dalej prowadzą gdzieś. Linki button/div nie przenoszą PageRanku i nie są crawlowane.

Punkt 26 (P1): Czas renderu Googlebota w GSC

Kryterium: GSC URL Inspection → „Tested page” → „View rendered page”. Wyrenderowana strona wygląda jak w przeglądarce, nie jest pusta ani z błędami. Typowe problemy: zablokowane pliki CSS/JS (patrz punkt 8), zewnętrzne API timeoutują dla Googlebota, CORS blokuje.

Punkt 27 (P1): Infinite scroll z fallbackiem paginacji

Kryterium: jeśli strona używa infinite scroll, istnieje też wersja z paginacją HTML (?page=2 działające) lub użyty jest pattern z History API i prawdziwymi URL-ami per sekcja. Googlebot nie scrolluje – bez paginacji widzi tylko pierwsze 10–20 elementów.

Punkt 28 (P1): Lazy loading obrazów z atrybutem loading=”lazy”

Kryterium: obrazki poniżej folda mają loading="lazy", obrazki z LCP (zwykle powyżej folda) mają loading="eager" i fetchpriority="high". Błąd: lazy na hero image daje LCP 4–6 sekund zamiast 1,5 s. Test: Lighthouse „Largest Contentful Paint element” pokazuje, który element jest LCP.

Punkt 29 (P2): Dynamiczne elementy i ich wpływ na rendering

Kryterium: widgety typu „Personalizowane rekomendacje” ładują się przez JS, ale nie modyfikują title/description/canonical. Test: porównaj JSON-LD w HTML źródłowym vs wyrenderowanym – powinny być identyczne dla tych samych tagów (Article, Product, BreadcrumbList).

Blok 5: Struktura URL i linkowanie wewnętrzne (punkty 30–36)

URL-e i linki to szkielet architektury informacji. Ten blok – 2–3 godziny analizy z Screaming Frog i Sitebulb. Błędy na tym poziomie są drogie w naprawie, bo wymagają migracji URL.

Punkt 30 (P0): Struktura URL logiczna i płaska

Kryterium: URL-e mają 2–4 segmentów (/kategoria/artykul/), zawierają słowa kluczowe, są czytelne. Unikaj ID-ów (?id=4572), parametrów sortowania w ścieżce, hash-fragments (#) zamiast prawdziwych URL-ów. Struktura > 5 segmentów zwykle sygnalizuje za głębokie zagnieżdżenie architektury.

Punkt 31 (P0): Spójność trailing slash

Kryterium: /url/ i /url nie zwracają obie 200 – jedna wersja 301-uje na drugą. WordPress domyślnie trailing slash, statyczne strony często bez. Niespójność tworzy duplikaty i rozmywa sygnały.

Punkt 32 (P0): Brak mieszanki wielkich/małych liter

Kryterium: URL-e zawsze małe litery. /Kontakt/ i /kontakt/ to dla serwera (i Google) dwa różne URL-e. Jeśli zdarzają się wielkie litery w URL-ach, redirect 301 do wersji małych liter.

Punkt 33 (P1): Głębokość kliknięć (click depth)

Kryterium: 90% ważnych stron dostępne w max 3 kliknięciach od homepage. Mierzone przez Screaming Frog → „Crawl Depth”. Strony w depth 5+ rankują gorzej. Rozwiązania: hub pages, breadcrumbs, related content, contextual internal links.

Punkt 34 (P1): Gęstość internal linków na top stronach

Kryterium: top 20 artykułów ma 15–40 linków wychodzących (nie licząc menu/footer) – w tym linki do pokrewnych tematów, nie tylko do tag pages. Zbyt mało linków = izolacja autorytetu, zbyt dużo (> 100) = rozmycie.

Punkt 35 (P1): Broken internal links

Kryterium: < 0,5% linków wewnętrznych zwraca 404, 302, lub 5xx. Narzędzie: Screaming Frog zakładka „Response Codes”. Top źródła linków do 404: stare artykuły, szablon footera, migrowane treści bez update linków.

Punkt 36 (P2): Redirect chains (> 1 hop)

Kryterium: nie więcej niż 1 krok redirect 301 dla żadnego URL-a. Łańcuch 3+ redirectów traci część link equity i marnuje crawl budget. Narzędzie: Screaming Frog → „Redirects & Canonical Errors”. Rozwiązanie: aktualizuj końcowy URL w wszystkich redirect rules, skracając łańcuchy do 1 hop.

Blok 6: Core Web Vitals (punkty 37–43)

Core Web Vitals to trzy metryki: LCP, INP, CLS. Nie są deal-breakerem dla rankingów (mały, ale realny sygnał), ale wpływają bezpośrednio na UX i konwersje. Ten blok – 2–4 godzin.

Punkt 37 (P1): LCP < 2,5 s na 75 percentylu

Kryterium: GSC Core Web Vitals report lub PageSpeed Insights z field data (CrUX). LCP powyżej 2,5 s to „Poor”. Typowe optymalizacje: preload LCP image, CDN, server-side rendering, eliminacja render-blocking CSS/JS.

Punkt 38 (P1): INP < 200 ms na 75 percentylu

Kryterium: INP (Interaction to Next Paint) zastąpił FID w marcu 2024. < 200 ms „Good”, 200–500 ms „Needs improvement”, > 500 ms „Poor”. Główne przyczyny wysokiego INP: ciężki JavaScript blokujący main thread, third-party scripts (chat widgets, analytics), synchroniczne operacje na liście.

Punkt 39 (P1): CLS < 0,1

Kryterium: Cumulative Layout Shift < 0,1. Główne przyczyny: obrazki bez width/height, dynamiczne treści wstawiane nad foldem, web fonts bez font-display: optional. Narzędzie: Chrome DevTools „Performance” tab pokazuje konkretne shift events.

Punkt 40 (P2): Obrazki optymalizowane (format, rozmiar)

Kryterium: format WebP/AVIF zamiast JPG/PNG dla zdjęć, SVG dla ikon, responsywne srcset. Rozmiar obrazka mobile < 200 KB, desktop < 500 KB. Narzędzie: Lighthouse zakładka „Opportunities” wskazuje konkretne obrazki do naprawy.

Punkt 41 (P2): Fonty – preload i font-display

Kryterium: web fonty preloadowane (<link rel="preload" as="font">), font-display: swap lub optional. Nigdy font-display: block – powoduje niewidoczny tekst przez 3+ sekundy (FOIT).

Punkt 42 (P2): JavaScript – code splitting i lazy load

Kryterium: main bundle < 200 KB (gzip), reszta kodu ładowana on-demand. Third-party scripts (Google Tag Manager, FB Pixel) z async lub defer. Sprawdź w Coverage tab DevTools – jeśli > 50% JS jest „unused” przy pierwszym ładowaniu, masz over-delivery.

Punkt 43 (P2): CSS krytyczny inline, reszta async

Kryterium: CSS dla powyżej folda jest inline w <head> (< 14 KB), reszta CSS ładowana po onload. Efekt: LCP o 300–600 ms krótszy, bo render nie czeka na zewnętrzny CSS file. Narzędzie: Critical npm package, Penthouse.

Blok 7: Sygnały semantyczne i schema (punkty 44–50)

Ostatni blok – sygnały strukturalne, które pomagają Google zrozumieć treść i LLM-om (ChatGPT, Perplexity, Gemini) cytować stronę. 1,5–2,5 godziny.

Punkt 44 (P1): JSON-LD schema.org na kluczowych stronach

Kryterium: Organization na homepage, WebSite z SearchAction, Article/BlogPosting na artykułach, Product na produktach, Breadcrumb na wszystkich. Walidacja: schema.org validator i Google Rich Results Test. Nawet pojedynczy błąd parsowania JSON może zepsuć cały schema dla strony.

Punkt 45 (P1): Hreflang dla stron wielojęzycznych

Kryterium: każda strona z tłumaczeniem ma kompletne <link rel="alternate" hreflang="..."/> wskazujące na wszystkie wersje (w tym x-default). Weryfikacja: strona A linkuje do B, strona B linkuje do A – symetria obowiązkowa. Narzędzie: Screaming Frog zakładka „Hreflang”.

Punkt 46 (P1): Meta tagi unikalne (title, description)

Kryterium: każdy URL ma unikalny title (50–60 znaków) i description (140–160 znaków), brak duplikatów > 5% strony. Narzędzie: Screaming Frog → „Page Titles” → „Duplicate”. Typowe źródła duplikatów: paginacja bez numeru strony w title, produkty z generowanymi title z templata.

Punkt 47 (P2): Nagłówki H1 – jeden per strona

Kryterium: każda strona ma dokładnie 1 <h1>, zawierający główny temat/keyword. Sprawdź w Screaming Frog → „H1”. Wiele H1 to zwykle błąd szablonu (H1 w logo + H1 w tytule artykułu). Google toleruje, ale to podstawowy audit item.

Punkt 48 (P2): Image alt tags – kompletność i jakość

Kryterium: 100% obrazów w <img> ma atrybut alt, dekoracyjne mogą mieć pusty alt="". Kluczowe (ilustracje artykułów, produkty) – opisowy alt text z keywordem. Brak alt tagów = utracona szansa rankowania w Google Images i dostępność.

Punkt 49 (P2): Breadcrumbs w HTML i schema

Kryterium: breadcrumb widoczny w HTML (nawigacja użytkownika), zduplikowany w BreadcrumbList JSON-LD. Google wyświetla breadcrumbs w SERP zamiast URL, poprawiając CTR o 5–10%. Szczególnie ważne dla e-commerce i blogów.

Punkt 50 (P2): Social meta – OpenGraph i Twitter Cards

Kryterium: każda strona ma og:title, og:description, og:image, og:url, og:type. Twitter Cards – twitter:card summary_large_image. Nie wpływa bezpośrednio na SEO, ale CTR z social shareów – tak. Walidacja: Facebook Sharing Debugger, Twitter Card Validator.

Priorytety i mapa czasowa – co naprawiać najpierw

50 punktów to dużo, ale nie wszystkie wymagają akcji. Priorytetyzacja według rzeczywistego wpływu na ruch organiczny.

Tabela priorytetów

Priorytet	Kryterium	Czas naprawy	Wpływ na ruch
P0 – krytyczne	Blokada indeksacji, serwer failing, mixed HTTP/HTTPS	24–72h	20–80% ruchu zagrożone
P1 – wysokie	Crawl waste, renderowanie, sitemap, canonical, meta	1–4 tygodnie	10–30% wzrost możliwy
P2 – średnie	CWV optymalizacje, schema, fine-tuning	4–12 tygodni	3–10% wzrost możliwy

Typowy harmonogram po audycie

• Tydzień 1: wszystkie P0 naprawione, deploy na prod.
• Tygodnie 2–4: P1 w sprintach, każdy blok (sitemap, canonical, rendering) jako osobna iteracja z testami.
• Tygodnie 5–12: P2 w rytmie regularnych optymalizacji wydajności i dopieszczania schema.
• Tydzień 13+: powtórka audytu – sprawdź, które punkty wróciły do stanu pre-fix (najczęściej sitemap świeżość, meta description na nowych stronach, broken internal links).

Stack narzędziowy audytu

Pełen audyt techniczny można wykonać za 1,5–2,5 tys. zł miesięcznie w narzędziach. Przy jednorazowym audycie – nawet wersje trial/free wystarczą na 5-dniowy projekt.

Narzędzie	Rola w audycie	Cena 2026	Alternatywy
Screaming Frog	Crawl, technical SEO, sitemap	€239/rok (~1000 zł)	Sitebulb, Netpeak Spider
Google Search Console	Coverage, CWV, Crawl Stats	free	brak alternatywy
Ahrefs Site Audit	Diagnoza problemów, monitoring	$99/mies od Starter	Semrush Site Audit
Chrome DevTools	Rendering, network, performance	free	Firefox DevTools
Lighthouse / PageSpeed	Core Web Vitals, opportunities	free	WebPageTest, GTmetrix
Log File Analyser	Diagnoza crawl budgetu	€99/rok	Semrush Log Analyzer
Validator schema.org	Walidacja JSON-LD	free	Google Rich Results Test

Najczęstsze błędy w audytach technicznych

Błąd 1: Audyt = lista 200 problemów bez priorytetów

Większość generowanych raportów z Semrush/Ahrefs pokazuje 300–800 issues, z czego 90% to P2 lub „information only”. Naprawianie wszystkiego po kolei zabiera 6 miesięcy i nie przynosi wzrostów. Zawsze priorytetyzuj P0 → P1 → P2.

Błąd 2: Ignorowanie rendera Googlebota

„Strona wygląda OK w przeglądarce” – to nie znaczy, że Googlebot ją widzi. Zawsze sprawdzaj rendered HTML w GSC URL Inspection, szczególnie jeśli frontend to Next.js/Nuxt/Angular. 30% audytowanych stron ma rozbieżność rendered vs source.

Błąd 3: Audyt na staging zamiast prod

Staging to często inna konfiguracja niż prod – inna robots.txt, inne redirect rules, inny CDN. Audytuj produkcję, a staging używaj tylko do testowania fixów przed deployem.

Błąd 4: Pomijanie logów serwera

Logi to jedyne źródło prawdy o tym, co Googlebot naprawdę crawluje. GSC Crawl Stats to aproksymacja. Dla stron > 5 tys. URL logi są obowiązkowe, a nie opcjonalne.

Błąd 5: Mierzenie sukcesu audytu liczbą fixów, nie wpływem

Naprawienie 150 z 200 issues wygląda dobrze w raporcie, ale jeśli te 150 to P2, a 5 P0 zostało niezaadresowanych – ruch nie wzrośnie. KPI audytu: % wzrostu organic traffic w 90 dni po naprawach P0/P1.

Przykład: audyt techniczny e-commerce (3,5 tys. URL)

Klient: sklep internetowy z kosmetykami, Magento 2, 3,5 tys. URL, spadek organic traffic o 38% w 4 miesiącach bez zmian w treści. Audit time: 18 godzin w 5 dni. Pełen obraz tematu znajdziesz w kompletnym przewodniku seo 2026.

Znalezione problemy

• P0: filtr „opinie” generował 800 duplikatów z parametrem ?rating=, wszystkie zaindeksowane, rozmywające sygnały.
• P0: migracja na nowy template 3 miesiące wcześniej zepsuła 220 internal links do starych URL-ów (nieaktualizowane).
• P1: LCP na PDP (Product Detail Page) = 3,8 s z powodu niezoptymalizowanego hero image i render-blocking CSS.
• P1: brak Product schema na 60% kart produktów (stare produkty z czasów sprzed plugin schema).
• P2: image alt tags puste na 40% zdjęć produktów.

Harmonogram napraw

• Tydzień 1: blokada parametru ?rating= w robots.txt + canonical do URL bez parametru. Update 220 internal links do aktualnych URL-ów przez search-replace w bazie.
• Tydzień 2–3: LCP fix – preload hero image, critical CSS inline, lazy load poniżej folda. Target: LCP 1,8 s.
• Tydzień 4–5: Product schema doinstalowany na 100% kart produktów, walidacja w Rich Results Test. Alt tags na top 200 zdjęć produktów.

Wyniki po 90 dniach

• Organic traffic: +47% vs pre-fix baseline (overshoot oczekiwań).
• Indeksowane URL-e: z 8,2 tys. zduplikowanych spadły do 3,6 tys. unikalnych (więcej nie znaczy lepiej).
• LCP 75th percentile: z 3,8 s do 1,9 s (Core Web Vitals „Good” dla 78% URL-i).
• CTR na PDP w SERP: +12% dzięki rich results z Product schema (cena, ocena, dostępność).

FAQ – najczęstsze pytania

Ile trwa pełny audyt techniczny SEO?

Mała strona (< 500 URL) – 8–12 godzin pracy, 2–3 dni kalendarzowe. Średnia (500–5 tys. URL) – 14–20 godzin, 3–5 dni. Duża (5 tys.–50 tys. URL) – 30–60 godzin, 7–14 dni z analizą logów. Enterprise (50 tys.+) – 80+ godzin, minimum 3 tygodnie z testami na stagingu. Nie licząc czasu fixów po audycie (4–12 tygodni).

Czy audyt techniczny wystarczy, żeby wzrósł ruch?

Sam audyt – nie. Audyt + naprawa P0 i P1 – często tak, średnio +15–30% ruchu w 90 dni, o ile treść i linki są na akceptowalnym poziomie. Jeśli strona nie ma treści na główne frazy albo ma zerowy profil linków, audyt techniczny to tylko odblokowanie potencjału – wzrost wymaga równoległej pracy nad treścią i linkami.

Jak często powtarzać audyt techniczny?

Pełny audyt – raz na 6–12 miesięcy plus każda większa zmiana (redesign, migracja, zmiana CMS). Monitoring ciągły – cotygodniowe alerty z Ahrefs/Semrush Site Audit i GSC Coverage. Miesięczny mini-audit: nowe 404, regression CWV, nowe duplikaty, broken internal links. Kwartalny deep-dive: rendering, schema walidacja, hreflang consistency.

Czy da się zautomatyzować audyt techniczny?

Częściowo. 60–70% punktów (status codes, broken links, meta tags, schema walidacja, CWV) zautomatyzujesz przez cron Screaming Frog + alert w Slack. Pozostałe 30% (interpretacja priorytetu, decyzje architektoniczne, analiza logów) wymaga senior SEO. Automatyzacja wykrywa problemy – priorytetyzacja i fix strategy zostają ludziom. Narzędzia agentowe z LLM w 2026 pomagają w pre-analizie, ale nie zastępują audytora.

Co jest ważniejsze – Core Web Vitals czy indeksacja?

Indeksacja – bez porównania. Strona, która nie jest zaindeksowana, nie ma ruchu bez względu na CWV. CWV to sygnał o małym wpływie (< 5% zmiany rankingu), indeksacja to warunek konieczny. Zawsze naprawiaj indeksację (P0) przed CWV (P2). Wyjątek: jeśli CWV LCP > 6 s, Google może nie zaindeksować w pełni – wtedy to staje się P0.

Czy audyt na stronie w AI-generated content ma sens?

Tak, audyt techniczny jest niezależny od pochodzenia treści. Googlebot nie rozróżnia (oficjalnie) AI vs ludzki content – rozróżnia treść wartościową od spamu. Audyt techniczny wyłapuje problemy infrastruktury, niezależnie od tego, kto napisał artykuł. Dla stron AI-first dodatkowy punkt: sprawdź, czy generowane meta description nie są duplikatami (częsty problem przy szablonach promptów).

Jak przekonać klienta/zarząd do inwestycji w audyt?

Zrób 2-godzinny mini-audit z top 5 znaleziskami P0/P1 i przeliczeniem ich na utracony ruch/przychód. Przykład: „URL-e produktów mają noindex od miesiąca – to 2 400 utraconych sesji organicznych tygodniowo, przy konwersji 2,1% i AOV 180 zł to 45 tys. zł utraconego przychodu miesięcznie”. Liczby przemawiają silniej niż diagnostyczne ogólniki.

Audyt techniczny a wyszukiwarki AI

W 2026 roku audyt nie kończy się na Google — LLM-y (ChatGPT, Perplexity, Gemini) crawlują inaczej, mają inne wymagania. Dodajemy 5 dodatkowych punktów do checklistu, gdy strona ma być widoczna w odpowiedziach AI.

Punkt A1: User-agent wyszukiwarek AI nieblokowane

W robots.txt sprawdź, czy nie blokujesz: GPTBot, ChatGPT-User, anthropic-ai, Claude-Web, PerplexityBot, Google-Extended. Wielu autorów stron zablokowało je defensywnie w 2023–2024 — blokada = zero cytowań w odpowiedziach AI. Jeśli treść ma być źródłem dla LLM-ów, otwórz dostęp.

Punkt A2: HTML source zawiera pełną treść

Większość crawlerów AI nie renderuje JavaScript — widzą tylko HTML source. Jeśli twoja strona to SPA, która ładuje treść przez fetch po mount, LLM-y zobaczą pustą stronę. Rozwiązanie: SSR lub Static Site Generation dla stron, które mają być cytowane.

Punkt A3: Struktura treści przyjazna chunkowaniu

Krótkie akapity (2–4 zdania), konkretne odpowiedzi na początku sekcji, tabele porównawcze, listy — wszystko to pomaga LLM-om wyciągać fragmenty. Sprawdź top 20 artykułów pod kątem „quotability” — czy jakieś zdanie brzmi jak samodzielna odpowiedź?

Punkt A4: Schema dla encji (Organization, Person, Product)

LLM-y budują wiedzę o encjach z ich schema. Organization na homepage z sameAs wskazującym na Wikipedia, LinkedIn, social — pomaga AI zmapować, kim jesteście. Product z brand, review, aggregateRating — pomaga cytować w odpowiedziach zakupowych.

Punkt A5: Monitoring cytowań AI

Dodaj do stacka narzędzie mierzące, jak często wasza domena jest cytowana w ChatGPT/Perplexity/Gemini — Semrush AI Toolkit, Profound, Goodie. Bez monitoringu nie wiesz, czy audyt pomógł widoczności AIO.

Segmentacja audytu dla różnych typów stron

Nie każdy projekt ma ten sam bottleneck — dlatego waga poszczególnych punktów zmienia się zależnie od typu strony. Blog ma inne priorytety niż e-commerce, a marketplace różni się od SaaS landing page.

Blog/media content

• Krytyczne: punkty 8–15 (indeksacja), 23–29 (renderowanie dla nowoczesnych szablonów), 44–46 (schema Article, hreflang).
• Mniej ważne: punkty 30–32 (struktura URL, zwykle proste w blogu), 48–49 (breadcrumbs, choć wciąż warto).
• Specyficzne: audyt szybkości pierwszego widoku artykułu — LCP na hero image i renderowanie głównej treści bez blokady JS third-party.

E-commerce

• Krytyczne: punkt 14 (parametry URL), 19 (crawl budget marnowany na filtry), 44 (Product schema), 45 (hreflang dla sklepów międzynarodowych), 37–38 (CWV na PDP).
• Mniej ważne: punkt 50 (social meta — liczy się, ale to nie #1 sprawa).
• Specyficzne: facet navigation, out-of-stock handling (noindex follow czy 404 po delisting), duplikacja wariantów produktu (kolor/rozmiar).

SaaS/landing pages

• Krytyczne: punkty 23–26 (rendering — SPA frameworki), 37–39 (CWV wpływa na konwersję), 44 (SoftwareApplication schema).
• Mniej ważne: punkty 16–22 (crawl budget — strona ma zwykle < 100 URL).
• Specyficzne: docs site separation (subdomena vs subkatalog), A/B testing bez klonowania URL-ów.

Marketplace

• Krytyczne: cała sekcja crawl (16–22 — często miliony URL-ów), 14 (parametry), 34 (wewnętrzne linki między ofertami/kategoriami).
• Mniej ważne: brak — w marketplace prawie wszystko jest krytyczne z powodu skali.
• Specyficzne: duplicate listings (jeden produkt sprzedawany przez 20 merchantów), user-generated content moderation pod kątem spamu w title/description.

Zarządzanie audytem jako projektem

Audyt techniczny to nie tylko crawl — to też koordynacja zespołu, komunikacja do biznesu i dyscyplina w dokumentacji. W moich projektach 30% czasu to samo pisanie/przekazywanie znalezisk; 70% to diagnostyka i weryfikacja fixów.

Format raportu, który działa

• Executive summary (1 strona) — top 5 znalezisk, wpływ na ruch/przychód, czas fix.
• Issues log (Google Sheet) — każdy issue w osobnym wierszu z kolumnami: priorytet, opis, URL-e dotknięte, narzędzie, owner, status, czas naprawy.
• Technical deep-dives — dla P0 i top P1 osobny dokument Google Docs z contextem, screenshotami, konkretnym rozwiązaniem.
• Roadmapa 12-tygodniowa — timeline z milestones, zależnościami (co musi być pierwsze), punktami kontrolnymi co 2 tygodnie.

Komunikacja do biznesu

• Nie pokazuj surowych raportów Ahrefs/Semrush — zarząd nie rozumie „crawl depth”. Tłumacz w języku biznesowym: „te zmiany odblokują X sesji organicznych miesięcznie”.
• Zawsze dodawaj estymację ruchu/przychodu dla top 5 fixów — nawet przybliżoną.
• Ustal z zespołem dev „definition of done” dla każdego fixu: jaki test potwierdza, że problem zniknął (np. „Screaming Frog po crawlu nie pokazuje URL-i z rating= parametrem w indeksie”).
• Post-mortem po 90 dniach — co zadziałało, co nie, dlaczego. Dokumentuj, żeby następny audyt był szybszy.

Co dalej

Audyt techniczny to punkt startu, nie koniec. Kolejne kroki: (1) metodyka pełnego audytu SEO – jak łączyć technikę z treścią i linkami, (2) audyt treści – ocena portfolio artykułów i kategorii, (3) rendering JavaScript pod SEO – pogłębienie bloku 4, jeśli masz framework frontend.

Pełen kontekst w przewodniku SEO 2026 – audyt to warstwa diagnostyczna, strategia buduje się na podstawie jego wyników.