Audyt techniczny SEO 2026 – co obejmuje, kiedy go zlecić i jak ocenić jego jakość

Audyt techniczny SEO to systematyczna analiza technicznych aspektów strony internetowej pod kątem zgodności z zasadami crawlingu, indeksacji, renderowania i wydajności, których nieprzestrzeganie obniża widoczność w organicznych wynikach wyszukiwania oraz w cytowaniach AI. W 2026 roku obejmuje 12 obszarów: dostępność dla crawlerów, indeksację, Core Web Vitals, Mobile-First Index, renderowanie JavaScript, dane strukturalne, architekturę informacji, przekierowania i kody odpowiedzi, HTTPS i bezpieczeństwo, hreflang, analizę logów serwera oraz nową warstwę AISO – dostępność dla botów AI.

Warto na początku rozdzielić dwa pojęcia, które bywają używane wymiennie. Audyt SEO w pełnej formule pokrywa też analizę treści, intencji wyszukiwania, profilu linków przychodzących i konkurencji – to znacznie szersza usługa. Audyt techniczny SEO jest jego podzbiorem dotyczącym wyłącznie warstwy infrastruktury. Jeśli na rynku spotykasz ofertę “audyt SEO bez analizy treści”, to praktycznie zawsze chodzi o audyt techniczny.

Co zmieniło się w zakresie audytu w ostatnich trzech latach? Pięć rzeczy. 

Po pierwsze, Core Web Vitals przeszły reformę – INP (Interaction to Next Paint) zastąpił First Input Delay w marcu 2024 roku, co obniżyło globalny wskaźnik zaliczanych pomiarów dla urządzeń mobilnych o około 5 punktów procentowych. 

Po drugie, Mobile-First Index został oficjalnie zakończony 31 października 2023 – to standard, nie projekt w toku. 

Po trzecie, boty AI stały się odrębną kategorią ruchu wymagającą osobnej polityki w robots.txt. 

Po czwarte, schema.org zyskało na znaczeniu jako sygnał dla modeli językowych ekstraktujących treść do AI Overview, ChatGPT i Perplexity. 

Po piąte, analiza logów serwera – wcześniej domena tylko największych klientów enterprise – stała się dziś standardem dla każdej strony powyżej kilku tysięcy URL-i, bo bez logów nie da się odpowiedzieć na podstawowe pytanie: co Googlebot rzeczywiście robi na Twojej stronie.

Standard branżowy 2026 zawiera 12 obszarów. Poniżej każdy z nich z definicją, najczęstszymi błędami i narzędziami diagnostycznymi.

Dostępność dla botów wyszukiwarek i robotów AI to fundament całej dyscypliny. Audytowi podlegają: poprawność pliku robots.txt, polityka per bot AI, struktura sitemap.xml, architektura linkowania wewnętrznego, głębokość URL-i oraz pułapki indeksacyjne – parametryczne URL-e, kalendarze, faceted navigation generujące tysiące śmieciowych ścieżek. Typowe błędy: zostawione z etapu testów Disallow: /, zablokowane CSS i JavaScript niezbędne do renderowania, sitemap z URL-ami w stanie noindex lub 404. 

Według badania Oncrawl średnia strona klasy enterprise marnuje 47% budżetu indeksacji na parametryzowane URL-e bez wartości rankingowej, które powinny być zablokowane dla botów na poziomie pliku robots.txt..

Indeksacja to drugi obszar – pokrycie tego, co Google rzeczywiście włącza do indeksu. Audytowi podlegają: meta robots (noindex/nofollow) z perspektywy stron generujących przychody, canonical tags (czy są self-referencing, czy nie wchodzą w konflikt z hreflang), duplikaty treści (wersje do druku, AMP, parametryczne duplikaty), soft 404 i thin content. Najczęstsze sytuacje, które wychwytuje audyt: noindex zostawiony po teście wdrożeniowym na priorytetowych podstronach, canonical wskazujący na URL 404, canonical sprzeczny z hreflang oraz puchnięcie indeksu z parametrycznych URL-i, których nikt nie chce w indeksie.

Core Web Vitals to dziś trzy metryki: LCP (Largest Contentful Paint, próg dobry <2,5 s), INP (Interaction to Next Paint, próg dobry <200 ms – zastąpił FID w marcu 2024) oraz CLS (Cumulative Layout Shift, próg dobry <0,1). Wszystkie mierzone są na 75. percentylu rzeczywistych użytkowników z danych Chrome User Experience Report (CrUX). Według HTTP Archive Web Almanac 2025 zaledwie 48% mobilnych stron przechodzi wszystkie trzy progi. 

Wprowadzenie INP obniżyło globalny wskaźnik zaliczeń dla urządzeń mobilnych o około 5 punktów procentowych. W audycie kluczowe jest porównanie danych z testów laboratoryjnych (Lighthouse) z danymi z rzeczywistego ruchu (CrUX) – różnica większa niż 20 punktów oznacza problem systemowy. 

Sposoby pomiaru i interpretacji opisaliśmy w poradniku Jak mierzyć prędkość strony, a tło algorytmiczne w artykule o Core Web Vitals jako nowym algorytmie Google.

Po zakończeniu wdrożenia MFI w październiku 2023 audyt skupia się dziś nie na “czy strona jest mobile-first”, ale na spójności treści mobile-desktop – czy wersja mobilna ma tożsamą treść z desktopową, czy nie jest okrojona, czy ma te same dane strukturalne. Sprawdzane: status w GSC URL Inspection (“Crawled as: Googlebot Smartphone”), porównawczy crawl mobile vs desktop, natrętne reklamy pełnoekranowe, elementy klikalne i viewport. Kompletny przewodnik po MFI znajduje się w artykule Co to jest Mobile-First Index.

To obszar, który w 2026 zmienił charakter najmocniej. Sprawdzane: czy strona jest renderowana po stronie serwera (SSR), czy ładuje się dopiero po wykonaniu JavaScriptu (CSR), jak Web Rendering Service Google obsługuje stronę, czy w logach widać wzorzec podwójnego pobrania (zapytanie HTML plus zapytanie renderowania przez WRS). 

Kluczowa zmiana w 2026: spośród sześciu głównych crawlerów internetowych tylko AppleBot (oparty na WebKit) i Googlebot renderują JavaScript. GPTBot, ClaudeBot, PerplexityBot i CCBot pobierają wyłącznie surowy HTML. Oznacza to, że strona w 100% JavaScript bez SSR jest praktycznie niewidoczna dla AI search – modele językowe zobaczą pustą stronę z linkiem do pakietu JS, nie treść. Szybki test diagnostyczny: curl -s [URL] | grep “nazwa kluczowa” na krytycznej podstronie. Jeśli kluczowej frazy nie ma w wyniku – boty AI też jej nie widzą.

Schema.org jest dziś jednym z sygnałów dla Google i wszystkich modeli językowych. Audytowi podlegają: obecność i poprawność typów (Article, Product, BreadcrumbList, Organization), spójność schemy mobile vs desktop, walidacja przez Rich Results Test, łączenie encji przez właściwość sameAs (do Wikipedia, G2, oficjalnych social mediów). Ocenia się też semantyczność HTML – czy treść jest opisana strukturalnie, czy tylko stylowana CSS-em. Według badania DemandLocal z 2026 tylko 12,4% stron internetowych ma wdrożone dane strukturalne schema.org – to ogromna przewaga konkurencyjna dla tych, którzy je wdrażają. Pogłębienie tematu w poradniku: Schema.org na produkcie w sklepie internetowym.

Tu audytowi podlega: struktura URL-i (głębokość, semantyka, parametry vs ścieżki), linkowanie wewnętrzne (rozkład PageRank, teksty linków, strony osierocone bez wewnętrznych odnośników), breadcrumbs (zarówno z perspektywy UX, jak i danych strukturalnych), paginacja i faceted navigation – szczególnie w e-commerce. Faceted navigation to jedno z najczęstszych źródeł marnowania budżetu indeksacji w e-commerce: każda kombinacja filtrów generuje osobny URL, którego Google nie powinien indeksować. Sposoby zarządzania filtrami z perspektywy SEO opisaliśmy w artykule Indeksowanie produktów z filtrami.

Sprawdza się: semantykę użycia 301 vs 302, łańcuchy przekierowań (każdy skok kosztuje osobne zapytanie crawlera i traci część equity), pętle przekierowań, błędy 4xx (rozróżnienie 404 vs 410 ma znaczenie semantyczne), błędy 5xx (alerty na produkcji). Klasyczny problem klientów klasy enterprise: łańcuch przekierowań z 3-4 skokami, który powstał przez wielokrotne migracje – każda dorzuciła kolejne 301, nikt nie spłaszczył wynikowego łańcucha. Dla zespołu deweloperskiego pięć minut pracy, dla bota wielokrotny strzał w budżet indeksacji.

Audyt techniczny obejmuje warstwę serwerową: poprawność TLS (ważność, algorytm, obsługa HTTP/2 lub HTTP/3), mieszane zasoby HTTPS/HTTP, HSTS, Time To First Byte (TTFB) jako element wpływający na LCP. Wolny serwer to LCP w czerwonej strefie niezależnie od jakości frontu – dlatego TTFB jest priorytetowo audytowany.

Dla stron wielojęzycznych lub międzynarodowych audyt sprawdza: poprawność tagów hreflang (kody językowe, self-reference, x-default), spójność z canonical, architekturę (subfolder vs subdomain vs ccTLD), geotargetowanie w GSC. Błędy hreflang to jeden z najczęstszych problemów klientów klasy enterprise – typowo audyty znajdują 15-30% URL-i z błędnymi lub niespójnymi tagami hreflang.

Analiza logów to obszar, który oddziela poważny audyt od powierzchownego. W logach widzisz, co bot rzeczywiście robi – których URL-i odwiedza, które ignoruje, jakie kody odpowiedzi dostaje. Analiza logów pokazuje: rzeczywistą dystrybucję crawla per szablon strony (produkt, kategoria, blog), wzorzec błędów w czasie, marnowanie budżetu indeksacji w liczbach (typowo 20-40% budżetu na URL-e o niskiej wartości w nieaudytowanych stronach), aktywność botów AI. 

Stabilne duże strony generują 50 000+ zapytań Googlebota dziennie – bez analizy logów zostajesz z domysłami zamiast danymi. Narzędzia: Screaming Frog Log File Analyser dla średnich projektów, Botify / OnCrawl / JetOctopus dla enterprise, własne data flow na bazie BigQuery lub ClickHouse dla największych. Dla stron poniżej 1000 URL-i analiza logów nie jest niezbędna; dla wszystkiego powyżej staje się stopniowo standardem, a dla enterprise jest obowiązkowa.

To dwunasty i najnowszy obszar audytu, którego w 2022 roku jeszcze nie było. Sprawdza się: reguły w robots.txt per bot AI (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, CCBot, Bytespider, AppleBot-Extended), czy strona nie blokuje wszystkich botów AI (co odcina ją od cytowań w ChatGPT, Claude, Perplexity, AI Overviews), czy istnieje plik llms.txt (opcjonalny, ale Anthropic i OpenAI oficjalnie go wspierają), czy treść jest możliwa do ekstrakcji w surowym HTML, czy semantyczny HTML i ARIA poprawnie reprezentują strukturę dla drzewa dostępności (używanego przez Playwright MCP i ChatGPT Atlas).

Cloudflare w pierwszym kwartale 2026 podzielił boty AI na trzy kategorie wymagające osobnych decyzji:

Krytyczna obserwacja: w sierpniu 2025 ponad 2,5 miliona stron zablokowało crawlery treningowe AI przez Cloudflare. Wiele z tych decyzji była nadmiarowa – blokady objęły także crawlery wyszukiwania, co odcięło te strony od cytowań w ChatGPT, Perplexity i AI Overviews. Według seoscore.tools strony blokujące wszystkie boty AI tracą 15-25% potencjalnego ruchu informacyjnego. Pogłębienie tematu znajdziesz w artykule oAI SEO, a praktyczny przewodnik po audycie pod kątem AI w naszym poradniku Audyt SEO pod kątem AI.

Te trzy terminy bywają używane wymiennie w propozycjach od agencji, ale opisują różne usługi. Rozróżnienie ma znaczenie budżetowe i decyzyjne.

Audyt techniczny vs audyt SEO – pierwszy jest podzbiorem drugiego. Audyt SEO pokrywa też treść, intencje wyszukiwania, profil linków, brand. Jeśli oferta mówi “audyt SEO bez przeglądu treści”, praktycznie zawsze oznacza to audyt techniczny.

Audyt techniczny vs pogłębiony audyt diagnostyczny – to dwie różne usługi sprzedawane czasem pod tą samą nazwą. Audyt podstawowy identyfikuje problemy używając crawlerów i automatów. Audyt diagnostyczny idzie głębiej: analiza logów (jak boty rzeczywiście odwiedzają stronę), walidacja renderowania JavaScript (czy WRS poprawnie renderuje krytyczne szablony), optymalizacja budżetu indeksacji i analiza przyczyn problemów (dlaczego ten konkretny problem powstał, nie tylko że istnieje). Audyt diagnostyczny zawiera framework priorytetyzacji oraz plan wdrożeniowy, nie tylko listę problemów.

Najważniejszy sygnał ostrzegawczy w propozycji od agencji: brak wzmianki o analizie logów dla strony powyżej 10 tysięcy URL-i. Oznacza to, że “audyt” sprowadzi się do eksportu CSV ze Screaming Frog, bez wglądu w rzeczywiste zachowanie Googlebota.

Zanim zlecisz audyt zewnętrznej agencji, warto sprawdzić, jak pilna jest sytuacja. Poniższa lista to konkretne, mierzalne sygnały podzielone na trzy poziomy pilności – większość z nich możesz zweryfikować w 5-10 minut, mając dostęp do Google Search Console i GA4.

Poziom 1 – krytyczne (audyt natychmiast):

Poziom 2 – ostrzegawcze (audyt w ciągu 3 miesięcy):

Poziom 3 – kontrolne (cykl roczny):

Jeśli rozpoznajesz co najmniej dwa sygnały z Poziomu 1 lub trzy z Poziomu 2 – audyt jest decyzją racjonalną, nie ostrożnościową.

Zanim zlecisz pełny audyt, możesz sam wykonać szybką wstępną diagnozę. 30 minut, darmowe narzędzia, sześć kroków. Cel: ustalić, czy są oznaki problemów, które uzasadniają głębszy audyt, oraz wyłapać krytyczne błędy, które można zlecić zespołowi deweloperskiemu natychmiast. Rozszerzony przewodnik po samodzielnym audycie krok po kroku znajdziesz w naszym osobnym poradniku Audyt SEO strony – jak samemu wykonać prosty audyt.

Zaloguj się do Google Search Console i sprawdź trzy rzeczy. Pierwsza to raport Pokrycie (Coverage) – porównaj liczbę zindeksowanych URL-i z całkowitą liczbą URL-i Twojej strony. Jeśli różnica jest powyżej 30%, zobacz, co Google wyklucza i z jakich powodów. Wyklucz “Excluded by ‘noindex’ tag” – to zwykle celowe – ale skup się na kategoriach “Discovered – currently not indexed” oraz “Crawled – currently not indexed”. To są URL-e, które Google widzi, ale uznał za niewarte indeksacji.

Druga to raport Core Web Vitals. Sprawdź osobno mobile i desktop. Jeśli mobile pokazuje powyżej 30% URL-i jako “Poor”, masz konkretny, mierzalny problem wpływający na pozycje.

Trzecia to raport Skuteczność (Performance). Sprawdź trend ruchu i pozycji w ostatnich 16 miesiącach. Czy w widocznych spadkach możesz znaleźć korelat z Google Core Updates z tego okresu? Jeśli tak, audyt powinien zweryfikować, jakie sygnały update’a najsilniej Cię dotknęły.

Wejdź na pagespeed.web.dev i przetestuj trzy reprezentatywne URL-e: stronę główną, jedną kategorię (lub kluczową usługę) i jeden produkt (lub artykuł). Sprawdź wynik mobile – powinien być powyżej 70, optymalnie powyżej 85. Porównaj dane z pomiarów rzeczywistych użytkowników CrUX z danymi z testów laboratoryjnych Lighthouse. Jeśli różnica jest większa niż 20 punktów, masz problem niewidoczny z perspektywy programisty testującego stronę w warunkach idealnych – to sygnał do audytu.

Trzy zapytania w wyszukiwarce Google ujawniają więcej, niż się wydaje:

Otwórz twojadomena.pl/robots.txt w przeglądarce. Sprawdź dwie rzeczy: czy nie ma Disallow: / (klasyczny błąd pozostały po środowisku testowym) i czy są zdefiniowane reguły per bot AI (GPTBot, ClaudeBot, PerplexityBot). Jeśli żaden bot AI nie pojawia się w pliku, oznacza to, że nikt nie podejmował świadomej decyzji o ich dostępności – przy obecnej skali ruchu AI to luka.

Otwórz twojadomena.pl/sitemap.xml. Sprawdź, czy istnieje, czy zwraca kod 200 i czy jest aktualna (data ostatniej modyfikacji). Jeśli plik ma format sitemap index, sprawdź też pliki podrzędne.

Otwórz terminal lub konsolę online z curl-em. Wykonaj test na krytycznej podstronie produktowej lub artykule:

curl -s https://twojadomena.pl/produkt-x | grep “nazwa produktu”

Jeśli kluczowa treść (nazwa produktu, cena, opis) nie pojawia się w wyniku – Twoja strona ładuje treść dopiero z JavaScriptu. Większość botów AI nie wykonuje JS – widzi pustą stronę z linkiem do paczki kodu. To znaczy, że jesteś praktycznie niewidoczny dla ChatGPT, Perplexity i Claude.

Drugi test: wejdź na ChatGPT lub Perplexity i zapytaj “najlepsze [Twoja kategoria]” lub “co warto wiedzieć o [Twój produkt]”. Czy Twoja marka pojawia się w cytowaniach? Jeśli nie – masz problem z widocznością w AI search niezależny od tradycyjnych pozycji w Google.

Pobierz Screaming Frog SEO Spider w wersji darmowej (limit 500 URL-i). Wykonaj crawl strony głównej. Sprawdź zakładki: Response Codes (błędy 4xx, 5xx), Page Titles (zduplikowane tytuły), Meta Description (brakujące), oraz Redirects (łańcuchy przekierowań). To zwykle wystarcza, żeby wykryć podstawowe problemy, ale dla strony powyżej 500 URL-i ten test pokrywa tylko fragment.

Samodzielny audyt pozwala wykryć: krytyczne problemy (Disallow: /, noindex na stronach generujących przychody, masowe błędy 5xx), symptomy wskazujące na konieczność głębszego audytu (niski wskaźnik zaliczeń CWV, duże luki w pokryciu indeksu), natychmiastowe efekty do zlecenia zespołowi deweloperskiemu (popraw konkretne 404 z linkami wewnętrznymi).

Czego nie wykryjesz samodzielnie: marnowania budżetu indeksacji (potrzebujesz logów), problemów z renderowaniem JavaScript na poziomie WRS (potrzebujesz porównania źródłowego HTML z renderowanym DOM w Lighthouse), analizy przyczyn problemów (potrzebujesz skrzyżowania wielu źródeł danych), błędów hreflang w skali, walidacji schema w skali, priorytetyzacji 50+ problemów.

Samodzielny audyt wystarcza dla: stron poniżej 500 URL-i, comiesięcznej kontroli kondycji po dużych zmianach, diagnostyki przed decyzją o zleceniu pełnego audytu. Nie wystarcza dla: stron średnich i dużych stron, e-commerce z fasetami, wielojęzycznych, po nagłym spadku ruchu, przed migracją.

Niezależnie od symptomów wymienionych wcześniej, cztery sytuacje są twardymi sygnałami do audytu w trybie projektowym, nie cyklicznym.

Sytuacja 1: Migracja, redesign, zmiana platformy. Branżowe szacunki wskazują, że 60-70% migracji bez audytu kończy się spadkiem ruchu organicznego o 20-50% w pierwszych 3 miesiącach. Audyt przed migracją mapuje istniejące URL-e i sygnały rankingowe; audyt po migracji weryfikuje, czy mapy przekierowań zadziałały i czy nowa architektura nie wprowadziła regresji. Tematy z tym związane: Migracja strony – jak uniknąć katastrofy oraz Przebudowa strony a SEO.

Sytuacja 2: Nagły spadek ruchu organicznego. Jeśli widzisz spadek powyżej 10-15% w miesiąc bez oczywistej przyczyny (sezonowość, kampania konkurencji, krytyczna wiadomość), pogłębiony audyt diagnostyczny z analizą logów jest jedynym sposobem ustalenia przyczyny źródłowej. Bez logów wpadasz w spekulację – może to update algorytmu, może migracja u dostawcy hostingu, może błąd wdrożeniowy.

Sytuacja 3: Google Core Update. Google publikuje Core Updates 3-4 razy w roku, każdy redystrybuuje ruch między domenami. Jeśli widzisz wpływ na swoją widoczność, audyt po update powinien zweryfikować, jakie sygnały update wzmocnił i czy Twoja strona je spełnia.

Sytuacja 4: Plan inwestycji w treści lub link building powyżej 50 tysięcy PLN miesięcznie. Jeśli planujesz znaczącą inwestycję w content marketing lub pozyskiwanie linków, najpierw zaudytuj infrastrukturę techniczną. Inaczej skalujesz problem – robisz świetne treści, na które Google nie chce wysłać botom, albo budujesz linki do podstron z noindex.

Cykl audytów poza sytuacjami wyzwalającymi: dla stron 1k-50k URL-i pełny audyt techniczny co 6-12 miesięcy plus ciągły monitoring przez GSC i alerty crawlerowe. Dla enterprise (50k+ URL-i, e-commerce z 100k+ SKU, media z dużą produkcją treści) pełny audyt w cyklu kwartalnym, pogłębiony audyt diagnostyczny raz w roku, ciągły monitoring przez Botify lub OnCrawl. Większy artykuł o specyfice klientów klasy enterprise znajdziesz w Enterprise SEO.

Pytanie “czy warto inwestować w profesjonalny audyt techniczny SEO” sprowadza się do prostego rachunku: porównaj koszt audytu z kosztem nieaudytowania. W typowych przypadkach koszt nieaudytowania jest 3-10 razy wyższy od kosztu samego audytu – i mówimy o stratach mierzalnych w kwartalnych przychodach z ruchu organicznego. Pełniejsze rozważania na ten temat opisaliśmy w osobnym poradniku Płacić czy nie za audyt strony.

Cztery typowe sytuacje pokazujące koszt nieaudytowania:

Sytuacja 1: Migracja bez audytu. 60-70% migracji bez profesjonalnego audytu przed migracją kończy się spadkiem ruchu organicznego o 20-50% w pierwszych trzech miesiącach. Dla strony generującej ruch organiczny wart 100 tysięcy PLN miesięcznie oznacza to stratę 240-600 tysięcy PLN rocznie. Audyt przed migracją na takiej stronie kosztuje typowo 15-50 tysięcy PLN. Zwrot z nieaudytowania jest ujemny już w pierwszych dwóch miesiącach.

Sytuacja 2: Niewykorzystany budżet indeksacji. Średnia strona enterprise bez audytu marnuje 30-60% budżetu indeksacji na URL-e bez wartości – duplikaty parametryczne, faceted navigation, soft 404, łańcuchy przekierowań. Konsekwencja: nowe produkty czekają tygodniami na indeksację, szczyt sezonowy mija, zanim Google dotrze do świeżych treści. Optymalizacja budżetu indeksacji po audycie zwraca typowo 15-25% poprawy efektywności crawla i 10-15% odzysku ruchu w 6 miesięcy.

Sytuacja 3: Niezauważone problemy CWV. 48% mobilnych stron globalnie nie przechodzi trzech progów CWV. Po wprowadzeniu INP w marcu 2024 wiele stron uznawanych wcześniej za responsywne pod FID musiało dopracować INP. Bez audytu nie wiesz, czy Twoja strona jest w tych 48%, ani które szablony są krytyczne. Spadek pozycji wynikający z CWV nie jest widoczny w GSC jako “ostrzeżenie” – pozycje po prostu spadają.

Sytuacja 4: Niewidoczność w AI search. Strona blokująca boty AI lub zbudowana w 100% na kliencie (SPA bez SSR) jest praktycznie niewidoczna dla ChatGPT, Claude, Perplexity i AI Overview. Gartner przewiduje 25% spadek tradycyjnej liczby wyszukań do 2026 – to ruch, który nie wraca. Tematy z tym związane: Zero-click searches oraz AI Overviews a e-commerce.

Próg opłacalności: średni audyt 15-30 tysięcy PLN zwraca się przy odzyskaniu 3-5% ruchu w 90 dni dla strony generującej ruch organiczny wart 100 tysięcy PLN miesięcznie. Audyt enterprise 50-150 tysięcy PLN zwraca się przy odzyskaniu 5-10% ruchu dla strony generującej powyżej 300 tysięcy PLN miesięcznie. To nie są spekulacje – to typowe wyniki wdrożeń audytów z branżowych wskaźników referencyjnych.

Propozycja audytu technicznego powinna jasno określać zakres prac (które z 12 obszarów pokrywa), dane wejściowe (jaki dostęp do GSC, GA4, logów wymaga), harmonogram (typowo 2-8 tygodni), rezultaty końcowe (priorytetyzowana lista zadań plus raport plus sesja przekazania wiedzy), zaangażowane narzędzia (typowo 4-5, nie jedno) oraz wsparcie wdrożeniowe (30-90 dni po dostarczeniu raportu). Jeśli któregoś z tych elementów brakuje, to nie audyt – to wygenerowany plik CSV.

Lista do weryfikacji przed podpisaniem umowy:

1. “Audyt w 24 godziny” lub “audyt w 72 godziny”. Realny audyt techniczny dla strony powyżej 10 tysięcy URL-i trwa minimum 2 tygodnie. 24 godziny = szablon plus eksport ze Screaming Frog, nie audyt.

2. Rezultat to plik CSV lub Excel. Screaming Frog generuje przydatne dane, ale to nie jest audyt. Audyt = priorytetyzowana lista zadań plus interpretacja, nie surowy zrzut danych.

3. Brak wzmianki o analizie logów dla strony powyżej 10 tysięcy URL-i. Bez logów audyt zgaduje, co robi bot. To sygnał ostrzegawczy zwłaszcza dla klientów klasy enterprise.

4. Brak listy nazwanych narzędzi. “Używamy najlepszych narzędzi SEO” oznacza, że propozycja nie precyzuje, jakie. Realny audyt: Screaming Frog plus Lighthouse plus GSC plus analizator logów plus monitor CWV jako minimum.

5. Brak zapytania o dostęp do GSC lub GA4. Audyt bez danych o pozycjach w wyszukiwarce jest o połowę słabszy. Bez GSC nie wiesz, które szablony rankują, więc nie wiesz, które problemy zagrażają pozycjom, a które są kosmetyką.

6. Brak frameworka priorytetyzacji. 200 problemów bez priorytetów jest niemożliwe do wdrożenia. Realny audyt: framework ICE (Impact × Confidence × Ease) lub podobny, z osobą odpowiedzialną per problem, z estymatą nakładu pracy.

Profesjonalny audyt techniczny SEO przebiega w pięciu fazach. Poniżej typowy harmonogram dla audytu średniej wielkości (3-4 tygodnie); dla enterprise wszystkie fazy są proporcjonalnie dłuższe (6-8 tygodni łącznie).

Tydzień 0: Spotkanie startowe (1-3 dni). Spotkanie inicjujące, uzgodnienie zakresu i KPI. Agencja zbiera dostęp do GSC, GA4, robots.txt do edycji, ewentualnie do CMS-a. Po stronie klienta wyznaczane są osoby odpowiedzialne: lider zespołu deweloperskiego, lider treści, sponsor projektu. Określane są kanały komunikacji (typowo Slack lub dedykowany kanał Microsoft Teams).

Tydzień 1: Zbieranie danych. Pełny crawl strony przez Screaming Frog lub Sitebulb. Eksport i wstępne przetwarzanie logów serwera (jeśli audyt obejmuje analizę logów). Pobranie GSC z 16 miesięcy historii. Audyt Lighthouse na priorytetowych URL-ach. Walidacja schema przez Rich Results Test i Schema.org Validator.

Tygodnie 2-3: Analiza. To najbardziej intensywna część projektu. Skrzyżowanie danych z crawla, logów, GSC i GA4. Walidacja renderowania JavaScript per krytyczny szablon. Identyfikacja przyczyn źródłowych (nie tylko symptomów). Punktacja ICE lub RICE każdego problemu. W przypadku pogłębionego audytu diagnostycznego – szczegółowa analiza zachowania botów per szablon, identyfikacja pułapek indeksacyjnych, mapowanie łańcuchów przekierowań.

Tydzień 4: Wstępna wersja raportu i iteracja. Pierwsza wersja raportu i listy zadań trafia do klienta. Sesja przeglądu (typowo 1-2 godziny) – klient przegląda ustalenia, koryguje priorytety według wiedzy biznesowej (np. “ten szablon przestajemy używać za 3 miesiące, więc poprawka nie ma sensu”). Agencja iteruje raport.

Tydzień 5: Dostarczenie finalne i sesja przekazania. Klient otrzymuje trzy dokumenty: podsumowanie dla zarządu (2-4 strony dla CFO/CMO), raport z ustaleniami (szczegółowa diagnostyka per obszar) oraz priorytetyzowaną listę zadań w formacie gotowym do importu do Jira lub Asany. Następnie 2-godzinna sesja przekazania wiedzy z zespołem deweloperskim, SEO i treściowym. To kluczowy moment – interpretacja w rozmowie face-to-face przekłada się na lepsze wdrożenia.

Tygodnie 6-12: Wsparcie wdrożeniowe (opcjonalnie). Dostęp do konsultacji dla zespołu deweloperskiego, rozmowy weryfikacyjne po wdrożeniach najbardziej krytycznych problemów, raportowanie kamieni milowych dla sponsora projektu.

Pełen pakiet audytowy powinien obejmować:

Taki standard audytów realizujemy w Delante. Dla pogłębionego audytu diagnostycznego dochodzą jeszcze: raport z analizy logów (dystrybucja crawla per szablon, procent marnotrawstwa, udział botów AI) oraz diagnostyka przyczyn zidentyfikowanych spadków ruchu.

Polskie zakresy cenowe według skali i typu audytu:

Co wpływa na cenę: wielkość strony (liczba URL-i, liczba języków), złożoność (e-commerce z fasetami, SPA, międzynarodowy), włączenie analizy logów (typowo +30-50% kosztu), wsparcie wdrożeniowe (typowo +20%), wersja diagnostyczna vs podstawowa (mnożnik 1,5-2 razy).

Audyt szybki poniżej 3 tysięcy PLN jest typowo zrzutem ze Screaming Frog plus krótkim komentarzem – to nie audyt w pełnym sensie. Audyt enterprise poniżej 50 tysięcy PLN dla strony powyżej 10 tysięcy URL-i prawdopodobnie pomija analizę logów i wsparcie wdrożeniowe – warto zweryfikować zakres.

Realne audyty używają 4-5 narzędzi w kombinacji. Lista pogrupowana:

Jeśli agencja w propozycji wymienia tylko jedno narzędzie (najczęściej Screaming Frog) – to nie jest audyt, to crawl. Pełen audyt sięga po 4-5 z tych narzędzi w kombinacji, zależnie od specyfiki strony.

Poziom 1: Lista zadań dla zespołu deweloperskiego. Lista problemów w arkuszu (Google Sheets, Notion, lub bezpośrednio Jira / Asana / Linear). Każdy problem zawiera: tytuł, opis, impact, effort, osobę odpowiedzialną, termin, status oraz ocenę ICE. Możliwa do przełożenia na ticket w 5 minut.

Poziom 2: Plan wdrożeniowy. Harmonogram 30/60/90/180 dni. Natychmiastowe efekty (wysoki impact, niski effort) trafiają do pierwszego sprintu. Krytyczne ryzyka (wysoki impact, wysoki effort) do pierwszych 60 dni. Zależności między problemami są oznaczone – np. “wdrożenie schema musi być po refaktorze layoutu”.

Poziom 3: Podsumowanie dla zarządu. 2-4 strony dla CFO, CMO, CEO. Top 5 krytycznych problemów z biznesowym tłumaczeniem (nie “łańcuch przekierowań w nawigacji”, ale “tracimy 15% potencjalnego budżetu indeksacji na ścieżki, których nikt nie indeksuje, co przekłada się na opóźnioną indeksację nowych produktów”). Oczekiwane efekty wyrażone w liczbach. Estymata inwestycji: godziny pracy deweloperów plus koszty narzędzi plus opcjonalne zewnętrzne usługi.

To pytanie, które Marketing Manager musi umieć odpowiedzieć przed CFO. Łańcuch przyczynowy ma cztery ogniwa:

Ogniwo 1: Audyt identyfikuje techniczne bariery. Konkretne przykłady: łańcuchy przekierowań marnujące budżet indeksacji, zablokowane zasoby, słabe Core Web Vitals na priorytetowych szablonach, brakujące schema, treść w JavaScript niewidoczna dla botów AI.

Ogniwo 2: Wdrożenie naprawia te bariery. Zespół deweloperski usuwa łańcuchy przekierowań, odblokowuje zasoby, optymalizuje LCP/INP/CLS, wdraża schema, dodaje SSR.

Ogniwo 3: Bot zachowuje się efektywniej. Efektywność crawla rośnie – Googlebot odwiedza priorytetowe URL-e częściej. Renderowanie się udaje – WRS dostaje pełną treść w pierwszej fazie. Boty AI widzą treść w surowym HTML. Sygnały Core Web Vitals wzmacniają się.

Ogniwo 4: Pozycje reagują. Najczęściej w oknie 3-9 miesięcy. Najszybciej reagują pozycje na świeże treści (lepszy czas do indeksacji oznacza szybsze rankowanie nowych URL-i). Najwolniej reagują pozycje na konkurencyjne frazy główne (gdzie czynników rankingowych jest dużo, a CWV są tylko jednym z wielu sygnałów).

Konkretne mechanizmy z branżowymi wskaźnikami referencyjnymi:

Ostrzeżenie: te liczby zakładają, że treść i profil linków są w porządku. Audyt techniczny nie naprawi słabej treści ani niskiego autorytetu – naprawi wyłącznie warstwę techniczną. Jeśli problem jest w jakości treści lub w E-E-A-T, sam audyt techniczny nie wystarczy.

Poziom 1 (twarde, wpływające na pozycje): liczba zindeksowanych URL-i w GSC, redukcja marnotrawstwa budżetu indeksacji (procent budżetu indeksacji na URL-e bez wartości), wskaźnik zaliczeń CWV per szablon, ruch organiczny per szablon (segment GA4), zmiany pozycji na priorytetowe frazy (Ahrefs, Senuto).

Poziom 2 (miękkie, brandowe): widoczność w AI (cytowania w AI Overview, ChatGPT, Perplexity – mierzalne w ChatBeat lub Profound), wzmianki o marce w SERP, czas do indeksacji dla nowych podstron, czas odpowiedzi serwera p50 i p95.

Audyt nie zastąpi strategii treści, link buildingu, optymalizacji współczynnika konwersji, ani decyzji biznesowych – informuje, ale nie zastępuje osądu Marketing Managera.

Audyt nie gwarantuje wzrostu ruchu o konkretne X%, rankingu na konkretne frazy, ani pierwszej pozycji. Tego nigdy nie gwarantuje rzetelny audytor. Zwrot z audytu zależy od jakości wdrożenia, jakości treści, autorytetu domeny i konkurencji w niszy.

W 2026 audyt techniczny SEO bez warstwy AISO jest niekompletny. Większość botów AI (GPTBot, ClaudeBot, PerplexityBot, CCBot) nie renderuje JavaScriptu, większość polskich e-commerce nadal blokuje je w robots.txt z lat 2022-2023, a globalnie tylko 12,4% stron ma wdrożone dane strukturalne schema.org. Każdy z tych trzech faktów to konkretna, mierzalna luka audytowa.

Trzy kluczowe pytania, które audyt 2026 musi zadać:

Pytanie 1: Czy moja strona jest dostępna dla botów AI? Audyt reguł robots.txt per bot AI, weryfikacja, czy żaden z crawlerów wyszukiwania (OAI-SearchBot, Claude-SearchBot, PerplexityBot) nie jest zablokowany, decyzja o pliku llms.txt (opcjonalnym, ale wspieranym oficjalnie przez Anthropic i OpenAI).

Pytanie 2: Czy boty AI widzą treść mojej strony? Szybki test: curl -s [URL] na krytycznej podstronie, grep za kluczową frazą. Jeśli treść jest w JavaScript bez SSR – boty AI widzą pustą stronę. SSR, dynamiczne renderowanie lub statyczna generacja stron dla aplikacji SPA to dziś obowiązek dla widoczności w AI search.

Pytanie 3: Czy moja treść jest możliwa do ekstrakcji dla LLM? Schema.org Article, Product, Organization z linkami sameAs (do Wikipedia, G2, oficjalnych social mediów). Semantyczny HTML z poprawną hierarchią nagłówków. Tabele porównawcze (LLM-y ekstraktują tabele szybciej niż prozę). FAQ jako semantyczny markup, nie tylko UI akordeon bez schema.

Z tego samego mechanizmu wynika też wzrost znaczenia zero-click searches – coraz więcej zapytań kończy się na poziomie SERP-u lub odpowiedzi AI, bez kliknięcia w stronę źródłową. Marka pojawiająca się w cytowaniu AI Overview zyskuje widoczność nawet bez tradycyjnej wizyty mierzonej w GA4.

Audyt techniczny SEO to dziś jeden z fundamentów dyscypliny SEO obok content marketingu i link buildingu. W połączeniu z Enterprise SEO i warstwą AI SEO tworzy operacyjny rdzeń pracy każdego senior SEO Managera w 2026.