Technical SEO audit 2026 — proces, narzędzia, checklist 50+

TL;DR: Audyt techniczny SEO w 2026 roku to już nie jednorazowy raport w PDF, tylko ciągły proces łączący crawl desktopowy, dane z Google Search Console, testy Core Web Vitals oraz kontrolę indeksacji w silnikach AI. W tym przewodniku pokazuję pełny workflow — od konfiguracji Screaming Frog, przez ekstrakcję danych z API GSC, po schema.org dla Article i Product. Znajdziesz tu tabelę pięciu kategorii audytu, numerowany 10-krokowy framework, listę 50+ punktów kontrolnych, typowe błędy oraz FAQ. Całość jest napisana pod redaktora i analityka — nie pod prezentację dla zarządu. Jeżeli robisz to pierwszy raz, potraktuj artykuł jak roboczą instrukcję: przejdź sekcje w kolejności, otwórz drugi monitor z narzędziami i notuj w osobnym pliku .md. Po pełnym przejściu będziesz mieć backlog zadań deweloperskich, priorytety na najbliższe 30 dni oraz bazę porównawczą do kolejnego audytu za kwartał.

Czym jest technical SEO audit w 2026 roku i co go odróżnia od audytu content?

Technical SEO audit to systematyczna kontrola warstwy technicznej witryny — tego, jak bot Google, Bingbot, Applebot-Extended czy GPTBot pobierają, renderują i interpretują strony. Audyt content zajmuje się jakością, intencją i topical authority — tu patrzymy na kod, infrastrukturę, konfigurację serwera i dane strukturalne. W 2026 roku te dwa światy coraz mocniej się przenikają, bo crawler AI Overviews używa zupełnie innych sygnałów priorytetu niż klasyczny Googlebot — dlatego w praktyce audyt techniczny musi dziś uwzględniać także warstwę semantyczną (HTML 5, microdane, entities).

Różnica sprowadza się do jednego pytania: „czy wyszukiwarka może w ogóle dotrzeć do treści i zrozumieć jej kontekst?”. Jeśli odpowiedź brzmi „nie”, każda praca nad jakością contentu jest zmarnowana. Dlatego audyt techniczny wykonujemy zawsze przed dużą migracją, przed relaunchem domeny oraz raz na kwartał jako kontrolę drift — czyli samoczynnej degradacji konfiguracji, którą wywołują wtyczki, aktualizacje frameworków i nieświadome zmiany redakcyjne.

Warto też rozgraniczyć trzy poziomy głębokości. Audyt ekspresowy (2-4 h) skupia się na crawlu, robots.txt, sitemapie i Core Web Vitals — daje listę pożarów. Audyt standardowy (2-3 dni) dokłada logi serwera, schema, duplicate content i problemy z renderowaniem JS. Audyt enterprise (1-3 tygodnie) to dodatkowo fasetowanie, crawl budget, analiza CDN, certyfikaty SSL, międzynarodowy hreflang, migrations risk assessment. Większość polskich serwisów potrzebuje wariantu standardowego — i na nim koncentruje się ten przewodnik.

Jakie narzędzia są niezbędne do audytu technicznego w 2026?

Najważniejsza zasada — nie wystarczy jedno narzędzie. Crawler pokazuje co jest na stronie, GSC pokazuje co widzi Google, logi pokazują co faktycznie odwiedza bot, a Lighthouse mierzy doświadczenie użytkownika. Dopiero crossreferencja tych czterech źródeł daje pełny obraz. W 2026 roku dołącza piąty wymiar — widoczność w silnikach AI (Perplexity, ChatGPT Search, Claude, Gemini), co wymaga oddzielnego zestawu narzędzi typu Profound, Otterly czy Peec.

Pod crawl używaj Screaming Frog SEO Spider (licencja 239 GBP/rok, standard branżowy, renderuje JS, integruje się z GSC, Ahrefs, GA4) lub Sitebulb (bardziej przyjazny w onboardingu, lepsza wizualizacja struktury). Alternatywy open source to Advertools w Pythonie oraz crawler wbudowany w Screaming Frog w trybie free do 500 URL. Do logów serwera sprawdza się JetOctopus, Oncrawl (enterprise) lub własny pipeline w BigQuery z plikami z Cloudflare Logpush.

Do audytu wydajności łącz Lighthouse (w DevTools i w CLI), PageSpeed Insights (dane CrUX z prawdziwego ruchu), WebPageTest (testy wieloetapowe, waterfall, filmstrip) oraz Chrome User Experience Report w BigQuery do analizy trendu miesiąc do miesiąca. Pomiar Core Web Vitals w 2026 zmienił się o tyle, że Interaction to Next Paint (INP) zastąpił FID już w marcu 2024, a pomiar odbywa się na 75. percentylu — nie na medianie.

Google Search Console pozostaje darmowym źródłem danych z pierwszej ręki. Raport Stan indeksu, Core Web Vitals, Ulepszenia oraz Linki dostarczają informacji, których nie ma nigdzie indziej. Eksportuj dane przez API do BigQuery, bo interfejs pokazuje tylko 1000 wierszy. Oficjalną dokumentację crawl budget i indeksowania znajdziesz w Google Search Central — to źródło, które warto mieć w zakładce podczas każdego audytu.

Jak wygląda proces audytu krok po kroku i ile trwa?

Dobrze poprowadzony audyt standardowy zajmuje 2-3 dni robocze plus 1 dzień na raport i priorytetyzację. Nie skracaj etapów „zbierania danych” — bez pełnego obrazu wszystkie rekomendacje są spekulacją. Zacznij od briefingu z klientem lub product ownerem: na jakie słowa kluczowe celują, kto jest konkurencją, jakie były ostatnie zmiany techniczne. Te informacje dają kontekst, bez którego dane same w sobie są bezużyteczne.

Dzień pierwszy poświęć na setup crawlu i import danych. Skonfiguruj Screaming Frog — user-agent Googlebot Smartphone, rendering JS włączony (jeśli SPA/React/Next.js), limit 5 URL/s dla małych serwerów, integracja z GSC i GA4. Równolegle uruchom crawl w Sitebulb dla drugiego zdania. Pobierz 90 dni logów serwera. Wyeksportuj z GSC: stan indeksu, pokrycie, raport wydajności, sitemap status. Dzień drugi to właściwa analiza: crawl depth, status codes, duplicate titles, thin content, orphan pages, hreflang, schema. Dzień trzeci przeznacz na Core Web Vitals, mobile usability, schema validation oraz render diff między raw HTML i rendered DOM.

Czwarty dzień to synteza. Pogrupuj znaleziska na trzy kubły priorytetów: blokery (noindex na kluczowych URL, błędy 5xx na produkcji, nieprawidłowy hreflang), dźwignie (poprawki, które dadzą mierzalny wzrost w 30-60 dni) i higiena (długi ogon drobnych poprawek). Każdy punkt opisz w formacie: problem, dowód (zrzut/URL/log), rekomendacja, estymata wpływu, estymata pracochłonności. Ten format przechodzi wprost do Jira/Linear.

Które kategorie audytu mają największy wpływ na ranking i AI search?

W 2026 roku podział audytu na pięć głównych kategorii ułatwia komunikację z deweloperami i produktem. Każda kategoria ma własne KPI, własny zestaw narzędzi i własną ścieżkę naprawy. Nie mieszaj ich w jednym ticketku — developer musi wiedzieć, czy rozwiązuje problem rendering, performance czy schema, bo każdy z nich wymaga innej ekspertyzy.

Kategoria	Co sprawdzamy	Główne narzędzie	Kluczowy KPI	Wpływ na AI search
Crawl	Dostępność URL dla bota, robots.txt, sitemap.xml, linki wewnętrzne, crawl budget, deep pages	Screaming Frog + logi	Stosunek crawled/discovered, hit rate Googlebota	Krytyczny — GPTBot i Applebot-Extended mają jeszcze ściślejsze budżety niż Googlebot
Index	Canonical, noindex, duplicate content, thin pages, 301/302/404, parametryzacja URL	GSC + crawler	% kluczowych URL w indeksie, indeks/discovered ratio	Wysoki — AI Overviews cytują tylko treści zaindeksowane
Performance	Core Web Vitals (LCP, INP, CLS), TTFB, rozmiar zasobów, lazy load, caching	Lighthouse + PSI + CrUX	% stron z „good” CWV na 75. percentylu	Średni — głównie przez satysfakcję użytkownika i bounce rate
Mobile	Responsive, viewport, tap targets, font size, mobile-first rendering, parity z desktop	GSC Mobile + Lighthouse	Błędów mobile usability = 0	Wysoki — indeks mobile-first od 2023, LLM-y wolą treści zwięzłe typowe dla mobile
Schema & semantics	JSON-LD Article/Product/FAQ, entities, HTML5, nagłówki H1-H3, microdata hreflang	Rich Results Test + Schema Validator	% URL ze schema pass + 0 błędów	Bardzo wysoki — LLM cytują strony ze schema 3x częściej (dane Profound 2026)

Zauważ, że kolumna „wpływ na AI search” nie zawsze koreluje z wpływem na klasyczne rankingi. Performance np. ma średni wpływ na cytowalność w LLM, bo modele pobierają treść jednorazowo przy indeksacji — natomiast schema ma wpływ krytyczny, bo zarówno klasyczne SERP-y, jak i silniki AI używają JSON-LD do rozpoznawania encji. Ten niuans przekłada się na priorytety pracy: jeśli widoczność w AI jest celem strategicznym, schema i semantics idą wyżej niż wyciskanie ostatnich 100 ms z LCP.

Jak zaplanować 10-krokowy framework audytu technicznego?

Poniższy framework stosuję od 2021 roku i z każdym rokiem uzupełniam go o nowe kategorie — w 2026 doszły kroki 8 i 9 związane z crawlingiem przez boty AI oraz semantyką pod LLM. Potraktuj tę listę jak protokół badania — wykonuj kroki po kolei, bez przeskakiwania, bo każdy kolejny korzysta z outputu poprzedniego. Całość zajmuje 2-3 dni robocze z przerwą na synchronizację z klientem w połowie.

Discovery i briefing (2 h). Zbierz cele biznesowe, historię domeny, listę kluczowych URL, dostęp do GSC, GA4, WP adminów, CDN. Zrzut konfiguracji DNS, listę subdomen, certyfikat SSL i daty ostatnich migracji.
Konfiguracja crawlu (1 h). Screaming Frog: user-agent Googlebot Smartphone, rendering JS on, max depth 10, limit 5 req/s, integracja GSC+GA4+Ahrefs, lista URL do wykluczenia (wp-admin, feed, /?s=). Uruchom crawl i czekaj 1-3 h.
Import danych historycznych (1 h). Pobierz 90 dni logów z serwera, eksport z GSC (stan indeksu, pokrycie, wydajność, core web vitals), dane GA4 o ruchu organicznym, ostatni audit jeśli był. Wszystko do jednego folderu projektu.
Analiza crawl + index (4 h). Rozkład status codes, liczba indexable URL, duplicate titles/meta, kanonikalizacja, paginacja, orphan pages, głębokość kliknięć od strony głównej, sitemap vs crawl gap.
Performance i Core Web Vitals (3 h). Lighthouse dla 20 reprezentatywnych szablonów, PageSpeed Insights na 75. percentylu, CrUX trend miesiąc do miesiąca, waterfall w WebPageTest dla najsłabszych stron. Identyfikacja hot spotów.
Mobile i accessibility (2 h). Raport GSC Mobile Usability, Lighthouse a11y score, tap targets, font sizes, viewport, parity raw HTML mobile vs desktop (diff renderowania).
Schema i dane strukturalne (2 h). Rich Results Test dla 10 szablonów, Schema.org validator, audyt typów (Article, Product, FAQ, HowTo, BreadcrumbList), poprawność encji (sameAs, author, publisher).
Crawling przez boty AI (2 h). Logi serwera pod kątem GPTBot, ChatGPT-User, ClaudeBot, Applebot-Extended, PerplexityBot. Kontrola llms.txt, kontrola robots.txt reguł dla AI user-agentów, audyt cytowalności w Perplexity/ChatGPT dla 5 topowych zapytań.
Semantyka i LLM-readiness (2 h). HTML 5 elementy (article, section, nav, main), struktura H1-H3, density faktów, TL;DR/summary, tabele danych, listy numerowane — wszystko pod ekstrakcję LLM.
Synteza, priorytetyzacja, raport (4 h). Zsynchronizuj wszystkie znaleziska do jednego backlogu, nadaj priorytet (bloker/dźwignia/higiena), estymuj pracochłonność i wpływ, napisz raport executive summary 1-2 strony plus techniczny załącznik.

Kroków nie da się zrównoleglić bez strat jakości — wyniki z punktu 4 informują, co badać w punkcie 5, a dane z 8 zmieniają priorytety w 9. Jedynym miejscem, gdzie warto pracować równolegle, jest crawl (punkt 2) — uruchamiasz go w tle i wracasz po kilku godzinach, w międzyczasie robiąc import danych historycznych i briefing.

Co wchodzi w pełną checklist 50+ punktów kontrolnych?

Poniższa lista to skondensowana checklist, której używam podczas audytu standardowego. Skopiuj ją do arkusza, dodaj kolumny „status”, „priorytet”, „owner”, „deadline” — dostajesz gotowy backlog. Pogrupowałem punkty tematycznie, a wewnątrz każdej grupy ułożyłem od najczęstszego problemu do najrzadszego.

Crawl i dostępność (12 punktów)

Robots.txt: istnieje, nie blokuje kluczowych ścieżek, zawiera sitemap, nie ma literówek w User-agent.
Sitemap.xml: aktualny, zawiera tylko indexable URL, <lastmod> odzwierciedla rzeczywiste zmiany.
Sitemap index: używany gdy >50 000 URL lub >50 MB, podzielony tematycznie.
Status codes: 0 błędów 5xx, <2% stron 4xx w sitemapie, wszystkie 301 prowadzą do 200.
Redirect chains: max 1 hop, brak pętli.
Internal linking: każda ważna strona ≤3 kliknięcia od strony głównej.
Orphan pages: zero stron bez linków wewnętrznych w sitemap.
Crawl depth: mediana ≤5, P90 ≤8.
Crawl budget: GSC raport Crawl stats — hit rate Googlebota rośnie lub stabilny.
Subdomeny: kontrola czy nie crawlowane niepotrzebnie (dev, staging).
Pagination: rel="next/prev" wycofane, ale linki wewnętrzne konsekwentne.
Parametry URL: lista parametrów skonfigurowana w GSC / ignorowana w sitemapie.

Indeksacja i canonicalizacja (10 punktów)

Canonical tags: obecne, self-referencing na stronach kanonicznych.
Noindex: tylko na stronach celowo wykluczonych (koszyk, filtry, wyniki wyszukiwania).
Duplicate titles: <5% URL z duplikacją.
Duplicate meta descriptions: <10%.
Duplicate H1: <5%.
Thin content: strony <300 słów oznaczone lub usunięte.
Stan indeksu GSC: % indexed vs discovered powyżej 70%.
Wykluczone strony w GSC: analiza kategorii (crawled – currently not indexed, duplicate without canonical).
Hreflang: poprawne kody języka, wzajemne linki, obecność x-default.
Protokół: 100% ruchu na HTTPS, brak mixed content.

Performance i Core Web Vitals (10 punktów)

LCP (Largest Contentful Paint) <2.5 s na 75. percentylu.
INP (Interaction to Next Paint) <200 ms.
CLS (Cumulative Layout Shift) <0.1.
TTFB <800 ms.
Obrazy: format WebP/AVIF, atrybuty width/height, lazy loading dla below-the-fold.
JavaScript: split bundles, defer dla non-critical, tree shaking włączony.
Critical CSS: inline dla above-the-fold, reszta async.
Fonty: font-display: swap, preload hero fontów.
Third-party scripts: audyt, removal nieużywanych, fasada iframe.
Caching: Cache-Control, ETag, CDN hit rate >90% dla statyków.

Mobile i UX (8 punktów)

Viewport meta tag obecny i poprawny.
Tap targets ≥48×48 px z odstępem 8 px.
Font size ≥16 px dla body.
Horizontal scroll: brak na szerokościach 360-428 px.
Parity desktop-mobile: ten sam content, same linki wewnętrzne.
Mobile nav: dostępne przez klawiaturę, aria-labels.
Pop-upy: brak intrusive interstitials (Google penalty).
Accelerated Mobile Pages (AMP): jeśli używane, migracja na responsive jest rekomendowana od 2022.

Schema, semantyka i AI (12 punktów)

JSON-LD Article: headline, author (z sameAs), datePublished, dateModified, image.
JSON-LD Organization: logo, sameAs dla social, adresy, kontakt.
JSON-LD BreadcrumbList na wszystkich szablonach.
JSON-LD FAQ tam, gdzie pytania w treści (ostrożnie po update z sierpnia 2023).
Rich Results Test: 0 błędów, ostrzeżenia udokumentowane.
HTML 5 elementy: article, main, nav, section, aside używane semantycznie.
Hierarchia nagłówków: dokładnie jeden H1, bez pominięć poziomów.
Alt text: wszystkie obrazy treściowe mają opisowy alt.
llms.txt: opcjonalnie, deklaracja dla LLM (standard aio.website/llms-txt).
robots.txt dla botów AI: świadoma decyzja Allow/Disallow dla GPTBot, ClaudeBot, PerplexityBot.
Entities (sameAs): powiązania Wikipedia/Wikidata dla autorów i marki.
Factoid density: co najmniej 3 liczby/fakty na 1000 słów w treści eksperckiej.

Łącznie wychodzi 52 punkty kontrolne. Dla audytu enterprise dołóż dodatkowo: międzynarodowy hreflang, faceted navigation, crawl budget simulation, log file analysis (GPTBot vs Googlebot share), CDN policy (Cloudflare/Fastly cache rules), edge SEO (Cloudflare Workers), progressive web app manifest. Tam lista rośnie do 80-100 punktów.

Checklist jest żywym dokumentem — raz na kwartał aktualizuję ją o zmiany w algorytmach i nowe standardy. W 2026 doszły punkty dotyczące botów AI (do tej pory nikt tego nie audytował) i factoid density — to metryka z research Profound pokazująca, że LLM znacznie chętniej cytują treści z dużą gęstością faktów. Warto wprowadzić ten wymiar na stałe.

Jak audytować indeksację w AI Overviews i LLM-ach w 2026?

W 2026 roku samo „jesteśmy w Google” nie wystarcza. AI Overviews pokazują się w ponad 30% zapytań informacyjnych w Polsce, a ChatGPT Search, Perplexity i Claude generują mierzalny ruch (2-8% sesji dla serwisów B2B). Audyt widoczności w LLM to nowa, obowiązkowa kategoria — i wymaga całkowicie innych narzędzi niż tradycyjny SEO.

Pierwszy krok to kontrola dostępu. Sprawdź w robots.txt, czy nie blokujesz ważnych crawlerów AI: GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Applebot-Extended, Google-Extended, Bytespider. Decyzja „blokować czy wpuścić” zależy od modelu biznesowego, ale świadomy wybór jest konieczny — domyślna konfiguracja WordPressa nie zawiera tych reguł, więc albo wszystko jest wpuszczane, albo blokuje wtyczka SEO bez Twojej wiedzy.

Drugi krok to audyt cytowalności. Wybierz 10-20 zapytań, na które serwis powinien pokazywać się w odpowiedziach AI, i sprawdź ręcznie w Perplexity, ChatGPT Search i Google AI Overviews, czy i które źródła są cytowane. Narzędzia typu Profound, Otterly, Peec lub Athena AI automatyzują to — skanują setki zapytań tygodniowo i mierzą share of voice w AI. Jeśli budżet jest ograniczony, prowadź ręczny tracking w Google Sheets raz w tygodniu — efekt i tak będzie użyteczny.

Trzeci krok to optymalizacja pod ekstrakcję. LLM preferują treści, które łatwo „wyciągnąć” — krótkie akapity 3-5 zdań, TL;DR na górze, pytania w H2 odwzorowujące intencję, tabele porównawcze z jednoznacznymi kolumnami, listy numerowane. Unikaj „lejącej” narracji bez jednoznacznych odpowiedzi. Dodaj FAQ z pytaniami w formie naturalnej i schema FAQPage. Zainstaluj llms.txt z deklaracjami dla LLM. Efekt wymierny zobaczysz po 30-60 dniach, bo LLM odświeżają swoje bazy wolniej niż Google.

Dlaczego warto łączyć crawl desktopowy, logi serwera i dane GSC?

Każde z tych trzech źródeł ma ograniczenia, których drugie źródło nie ma. Screaming Frog widzi „co jest dostępne do crawl” — ale nie wie, co faktycznie bot odwiedza i jak często. Logi serwera widzą „kto naprawdę nas odwiedza i jak często” — ale nie wiedzą, co Google faktycznie zaindeksowało. GSC widzi „co Google zaindeksował i jak to rankuje” — ale nie daje pełnego obrazu crawlu ani renderowania.

Dopiero krzyżowa analiza odkrywa niewidzialne problemy. Przykład: crawler pokazuje 10 000 indexable URL, logi pokazują, że Googlebot odwiedza tylko 3000 miesięcznie, GSC pokazuje 1800 w indeksie — to jest problem crawl budget + kanonikalizacja. Bez logów byś tego nie zobaczył, bo sam crawler nic o „hit rate bota” nie powie. Albo inny przykład: GSC pokazuje „crawled – currently not indexed” dla 40% URL, crawler pokazuje, że wszystkie mają <meta name="robots" content="index"> — znaczy, że problem jest po stronie quality/duplikacji, a nie konfiguracji.

Chcesz wejść głębiej w konfigurację crawlu — sprawdź mój osobny przewodnik po Screaming Frog w 2026, gdzie pokazuję krok po kroku integrację z GSC, ustawienie JS renderingu i tworzenie custom extractions. Dla analizy logów w kontekście crawl budget zerknij do studium CWV i wpływu na rankingi — są tam konkretne liczby „ile procent ruchu przejmuje konkurencja przy 2-sekundowym spadku LCP”. Warto też przeczytać naszą checklistę audytu contentowego, bo w audycie pełnym oba wymiary łączą się w jeden raport.

Jak często przeprowadzać audyt i kiedy wymusza go sytuacja?

Dla serwisów do 1000 URL: pełny audyt raz na 12 miesięcy plus kwartalny mini-audyt (5 kategorii, pół dnia). Dla serwisów 1000-10 000 URL: audyt co 6 miesięcy plus miesięczny monitoring KPI (CWV, indeksacja, status codes). Dla serwisów >10 000 URL (e-commerce, duży content hub): ciągły monitoring plus pełny audyt raz na kwartał. Enterprise z dedykowanym SEO teamem — audyt kwartalny plus daily monitoring przez log file analyzer.

Audyt ad-hoc wymuszają konkretne zdarzenia. Migracja domeny — zawsze pełny audyt przed i 14-30 dni po, plus monitoring 90 dni. Relaunch projektu lub zmiana technologii (np. WP → headless) — audyt techniczny na staging przed deployem. Spadek ruchu >15% week-over-week — mini-audyt 24 h, skupiony na crawl, index i ostatnich zmianach. Core update Google — audyt contentowo-techniczny 14 dni po starcie update’u. Zmiana agencji SEO — full audit jako baseline check. Nowy produkt / kategoria — audyt sekcji przed wypuszczeniem.

Kluczowe jest też tempo reakcji. Problemy typu „noindex na produkcji” czy „sitemap zwraca 500” nie czekają do następnego audytu — trzeba je łapać alertami. Skonfiguruj monitoring w Sitebulb, ContentKing (Conductor) albo własny skrypt w Pythonie, który raz dziennie sprawdza: 1) sitemap dostępny i zwraca 200, 2) status kluczowych URL = 200, 3) robots.txt nie blokuje kluczowych ścieżek, 4) canonical tag na home nie zmienił się. Takich „smoke testów” możesz dorzucić kilkanaście — koszt utrzymania zerowy, a bezpieczeństwo spore.

Najczęstsze błędy podczas audytu technicznego

Przez lata audytowania serwisów wyłapałem katalog powtarzających się pomyłek. Większość z nich wynika z tego, że audytor za szybko przechodzi z pomiaru do rekomendacji, bez upewnienia się, że dane są poprawne. Poniżej te, które najczęściej kosztują dni pracy po niewłaściwej stronie.

Crawl bez JS renderingu dla SPA. Jeśli serwis jest w React/Next bez SSR, crawl domyślny pokaże pusty DOM. Wynik: raport „thin content na 80% URL”, który jest nieprawdziwy.
Ignorowanie user-agenta. Crawl pod Chrome user-agent może ominąć blokady, które faktycznie dotykają Googlebot Smartphone. Zawsze użyj user-agenta, którego używa realny crawler.
Traktowanie danych GSC jako kompletnych. Interfejs pokazuje 1000 wierszy, API 50 000 dziennie na property. Bez eksportu do BigQuery widzisz wycinek — nie całość.
Porównanie CWR na stronie głównej vs. cała witryna. Home jest zwykle najszybszy, bo najbardziej zoptymalizowany. Core Web Vitals mierz na 75. percentylu CAŁEJ witryny.
Brak segmentacji rekomendacji. „Popraw title tags” dla 10 000 URL to nie zadanie — to wymówka. Podziel na typy stron i priorytety.
Duplicate titles liczone bez kontekstu paginacji. Strony /blog?page=2, /blog?page=3 domyślnie mają duplicate title — to nie jest problem, tylko artefakt paginacji.
Traktowanie „crawled – currently not indexed” jak błędu. Czasem to celowe — Google po prostu uznał stronę za mało wartościową. Rekomendacja to poprawa jakości, nie techniki.
Zero weryfikacji po wdrożeniu. Każda rekomendacja powinna mieć re-check 30 dni po wdrożeniu. Bez tego nie wiesz, czy deweloper faktycznie zamknął problem.
Zignorowanie logów. „Nie mamy dostępu do logów” to najsłabszy pretekst. Cloudflare Logpush, serwer Nginx, nawet archiwum z 30 dni — cokolwiek daje już obraz wystarczający.
Brak kontroli botów AI. W 2026 to już nie „nice to have”. Jeśli nie wiesz, ile razy w tygodniu odwiedza cię GPTBot, lecisz po omacku.

Wszystkie te błędy łączy jedno — pośpiech. Audyt techniczny to inwestycja czasu, która ma zwrot w postaci zaoszczędzonych miesięcy błędnej strategii contentowej czy link buildingu na stronach, które Google i tak nie indeksuje. Zrób go raz, zrób go dobrze, zapisz procedurę. Za pół roku będziesz wiedział, od czego zacząć.

FAQ — najczęstsze pytania o audyt techniczny SEO

Ile kosztuje audyt techniczny SEO w Polsce w 2026 roku?

Audyt ekspresowy (pół dnia, 5 kategorii) — 1500-3000 zł. Audyt standardowy (2-3 dni, pełne 50+ punktów, raport i priorytety) — 5000-12 000 zł. Audyt enterprise (serwis >10 000 URL, logi, migration risk, international SEO) — 18 000-45 000 zł. Ceny rosną o 30-50% dla serwisów w trakcie migracji lub po core update z widocznym spadkiem.

Czy mogę zrobić audyt sam, bez konsultanta?

Tak, dla serwisu do 500-1000 URL. Screaming Frog w wersji free crawluje 500 URL, GSC jest darmowy, Lighthouse też. Największym problemem jest interpretacja danych — crawler pokaże 2000 problemów, z których realnie 50 wpływa na wynik. Jeśli to Twój pierwszy audyt, przeznacz 3-4 dni, użyj tej checklisty i skonsultuj końcowy backlog z kimś doświadczonym (np. w grupie facebookowej SEO PL). Kolejny audyt zrobisz w pół czasu.

Screaming Frog czy Sitebulb — które narzędzie wybrać?

Screaming Frog dla zaawansowanych — pełne custom extractions, większa elastyczność, integracja z GA4/GSC/Ahrefs/Moz, lepsza obsługa JS renderingu, eksporty do CSV/Excel. Sitebulb dla początkujących i prezentacji klientom — ładniejsze wizualizacje, automatyczne hinty, „tłumaczenie” problemów na język biznesowy. W agencji warto mieć obie licencje — ja osobiście audyt robię w SF, a raport eksportuję w Sitebulb.

Jak wygląda audyt techniczny dla headless WordPress / Next.js?

Inaczej niż dla klasycznego WP. Musisz zweryfikować SSR vs CSR (strony dostarczane gotowe czy składane po stronie klienta), ISR revalidate (czy strony odświeżają się w sensownym cyklu), cache edge (Vercel/Cloudflare), status codes z headless cms, preview mode. Crawl musi być z renderingiem JS — inaczej zobaczysz pusty DOM. Logi zbieraj z edge, nie z origin — większość requestów w ogóle do origin nie dociera.

Czy crawl budget to nadal temat w 2026?

Tak, dla serwisów powyżej 50 000 URL — tam Googlebot musi wybierać, co crawlować. Dla małych serwisów (do 10 000 URL) crawl budget jest praktycznie nieograniczony i skupianie się na nim to strata czasu. Dla botów AI sytuacja jest inna — GPTBot ma zdecydowanie mniejszy budżet niż Googlebot, więc nawet średni serwis powinien zadbać o jego efektywność (sitemap, brak śmieciowych URL, szybki TTFB).

Ile czasu zajmuje wdrożenie rekomendacji z audytu?

Typowo 30-90 dni dla pełnego backlogu. Blokery (noindex, 5xx, pętle redirect) wdrożone w 1-7 dni. Dźwignie (schema, CWV, duplikaty) 14-45 dni. Higiena (alt text, mikro-poprawki tytułów) 30-90 dni z podziałem na sprinty. W agencji wdrażamy iteracyjnie — audyt odbywa się raz, ale fix-and-verify cykle trwają ciągle przez kolejny kwartał.

Co jest pierwsze — content audit czy technical audit?

Techniczny zawsze pierwszy. Nie ma sensu optymalizować treści, której Google nie jest w stanie pobrać, wyrenderować albo zaindeksować. Dopiero gdy warstwa techniczna jest czysta (<5% błędów, CWV green, schema pass), ma sens inwestycja w content audit i refresh. Wyjątek — sytuacja po core update, gdzie problem jest prawie na pewno contentowy, a technikalia i tak robimy profilaktycznie.

Jak często Google aktualizuje zalecenia techniczne?

Małe zmiany w dokumentacji — kilka razy w miesiącu. Duże — 2-4 razy w roku (np. wprowadzenie INP zamiast FID, deprekacja AMP, zmiany w FAQ rich results). Śledzenie oficjalnych blogów Google (Search Central Blog, Webmaster Blog) plus newsletter Sistrix lub Search Engine Journal daje aktualny obraz. Warto też raz na kwartał przejrzeć changelog dokumentacji na developers.google.com/search.

Jak zbudować raport z audytu, który deweloperzy faktycznie przeczytają?

Najczęstszy grzech audytów technicznych to 80-stronicowy PDF, który trafia do szuflady. Raport ma jeden cel — wywołać działanie. Oznacza to strukturę nastawioną na priorytetyzację, nie na demonstrację kompetencji audytora. Ja trzymam się układu trzywarstwowego: executive summary (1 strona, dla stakeholdera), techniczny backlog (arkusz w formacie Jira-ready), szczegółowe znaleziska (załącznik dla dewelopera, który będzie fixował konkretny punkt).

Executive summary zawiera wyłącznie: cel audytu, skalę (ile URL, kategorie sprawdzone), top 3 blokery z szacowanym wpływem w procentach ruchu, top 3 dźwignie z szacowanym czasem pracy, rekomendację kolejności wdrożenia i daty następnego re-checku. Nie ma w nim technicznych szczegółów — od tego są dalsze sekcje. Stakeholder czyta tę stronę w 5 minut i podejmuje decyzję o alokacji zasobów. Jeśli nie potrafisz zmieścić audytu w jednej stronie executive, prawdopodobnie sam nie zsyntetyzowałeś wniosków.

Techniczny backlog to arkusz w Google Sheets lub Airtable z kolumnami: ID, kategoria (crawl/index/performance/mobile/schema), tytuł zadania, opis problemu (2-3 zdania), dowód (URL + zrzut lub fragment logu), rekomendacja, estymata wpływu (high/medium/low), estymata pracochłonności (S/M/L/XL), owner, deadline, status. Każdy wiersz to jeden ticket do Jira/Linear. Developer czyta dokładnie ten wiersz, który go dotyczy — nie musi przekopywać całego raportu. Dodaj zakładkę z legendą kategorii, żeby PM wiedział, jak grupować zadania w sprincie.

Szczegółowe znaleziska to załącznik per kategoria, z pełnymi listami URL, screenshotami DevTools, fragmentami HTML, cytatami z logów. Ta sekcja pęcznieje do 40-60 stron, ale jej rolą jest bycie biblioteką referencyjną — nie lekturą. Developer sięga tam, gdy potrzebuje kontekstu konkretnego ticketu. Zorganizuj ją tak, żeby można było przeszukiwać CTRL+F po ID ticketu lub nazwie kategorii. Format Markdown w repo Git działa tu lepiej niż PDF, bo można wersjonować i komentować przez pull requesty.

Jak zmierzyć ROI z audytu technicznego — konkretne metryki i baseline?

Audyt techniczny kosztuje — konsultant 5-45 tys. zł, wewnętrzne zasoby to 2-4 tygodnie pracy seniora SEO. Biznes słusznie pyta, co z tego wyjdzie. Problem w tym, że większość efektów jest „zapobiegawcza” — nie widzisz ruchu, który byłby stracony, gdyby audytu nie było. Dlatego mierz ROI na trzech osiach: zaoszczędzony ruch, odzyskane indeksowanie, wzrost efektywności zespołu.

Pierwsza oś — zaoszczędzony ruch. Jeśli audyt wykrył blokera (np. noindex na szablonie kategorii w e-commerce), policz: ile URL było nim dotkniętych, jakiego ruchu nie generowały przez X miesięcy (porównaj z kategorią kontrolną), jaki byłby rolling średni ruch. Ta liczba często wynosi 10-40% całego ruchu organicznego i w prostym rachunku pokrywa roczny koszt audytu wielokrotnie. Użyj GA4 + GSC, zrób estymatę widełkową i zapisz ją w sekcji „business case” raportu.

Druga oś — odzyskane indeksowanie. Przed audytem: X% URL w indeksie. 60 dni po wdrożeniu: Y%. Różnica przełożona na sesje to konkretny przyrost. Dla serwisu contentowego z 5000 artykułami i wzrostem indeksacji z 60% do 85% mówimy o dodatkowych 1250 stronach w indeksie — przy średnim CTR 2% i 100 wyświetleniach/mc daje to 2500 dodatkowych sesji miesięcznie. Te liczby łatwo sprzedają audyt decydentom.

Trzecia oś — efektywność zespołu. Audyt wprowadza procesy (CI/CD checks, monitoring KPI, alerty) i standardy (checklista publikacji contentu, wymagane schema, limity wagi obrazów). Redukcja drift oznacza, że zespół nie traci czasu na gaszenie pożarów i może skupić się na strategicznej pracy. Ten efekt pojawia się dopiero po 6-12 miesiącach, ale jest najbardziej trwały. Mierzy go spadek liczby „nagłych” ticketów SEO oraz czas between-releases bez incydentów.

Baseline zapisz w dniu audytu i porównuj co 30/60/90 dni. Minimalny zestaw metryk do trackowania: całkowity organic traffic, średnia pozycja dla top 100 słów kluczowych, % URL w indeksie, INP/LCP/CLS na 75. percentylu, liczba błędów 4xx w GSC, liczba odwiedzin Googlebot/tydzień (z logów), cytowania w Perplexity/ChatGPT dla 20 kluczowych zapytań. Ten zestaw pozwala w każdym tygodniu odpowiedzieć na pytanie „czy audyt się opłaca”. Bez takiego trackingu audyt zostaje ćwiczeniem akademickim — a tego nikt nie chce.

Co dalej — jak przekształcić audyt w cykliczny proces?

Jednorazowy audyt daje listę znalezisk, ale realna wartość pojawia się dopiero wtedy, gdy audyt staje się rytmem zespołu. W pierwszym kwartale po audycie skup się na wdrożeniu blokerów i top 3 dźwigni — to da 70% potencjalnego efektu przy 20% pracy. Monitoruj KPI co tydzień: % stron w indeksie, CWV na 75. percentylu, liczba błędów 4xx/5xx w GSC, widoczność w AI. Każdy KPI powinien mieć wartość baseline z dnia audytu i trend tygodniowy — tak zobaczysz, czy wdrożenia przynoszą zmianę.

Drugi kwartał to weryfikacja i pogłębienie. Re-audit tych obszarów, gdzie wdrożenia były największe. Dodaj kategorie, które pominąłeś przy pierwszym audycie (logi, boty AI, międzynarodowy hreflang). Zainwestuj w automatyzację — co można monitorować skryptem raz dziennie, powinno być skryptem, nie ręcznym checkiem. Przykłady: alert na zmianę canonical home, alert na spadek CWV poniżej progu, alert na pojawienie się nowych 5xx w logach.

Trzeci i czwarty kwartał to ewolucja w kierunku SEO ops — podejście, w którym audyt techniczny jest wbudowany w pipeline dewelopera (CI/CD checks na staging: Lighthouse, schema validator, robots.txt diff, status codes), a zespół contentowy ma jasne wytyczne, co jest dopuszczalne w publikacji (maksymalna waga obrazów, wymagana schema, checklista meta). Taki model redukuje koszt kolejnych audytów o 60-80%, bo drift jest łapany w momencie pojawienia się, a nie po pół roku.

Na koniec — pamiętaj, że technical SEO to nie cel, tylko środek. Celem jest widoczność w wyszukiwarkach tradycyjnych i silnikach AI, a przez nią ruch, leady, sprzedaż. Jeśli dojdziesz do stanu „wszystko zielone” w audycie, a ruch nie rośnie — problem leży po stronie contentu, popytu na temat, intencji użytkownika albo konkurencji. Audyt techniczny da Ci pewność, że fundament jest w porządku. Reszta to robota strategiczna i contentowa — i dokładnie od tego zaczyna się kolejny etap pracy.