Audyt techniczny SEO: checklista z progami liczbowymi

Audyt techniczny SEO znajduje i porządkuje problemy z crawlowaniem, indeksacją, wydajnością i danymi strukturalnymi, które blokują widoczność strony — a potem mówi, co naprawić najpierw. Jeśli masz dziś zrobić tylko jedną rzecz: uruchom pełny crawl i zestaw go z danymi z Google Search Console. Ta para wyłapuje większość blokerów szybko, niezależnie od tego, czy problemem jest Core Web Vitals, błędna reguła w robots.txt, czy sitemapa pełna martwych adresów.

• Przecrawluj serwis crawlerem desktopowym — Screaming Frog sprawdza do 500 adresów bezpłatnie, co małej firmowej stronie zwykle wystarcza
• Pobierz dane o indeksacji i skuteczności z Search Console — pełne 16 miesięcy, które przechowuje
• Oznacz wszystko, co blokuje indeksację, zanim dotkniesz szybkości ładowania

Ten ostatni punkt to rzecz, którą większość audytów robi w złej kolejności — i powód, dla którego ten poradnik idzie w takiej, a nie innej.

Kluczowe wnioski

Checklista audytu SEO zwraca się tylko wtedy, gdy problemy z indeksacją naprawiasz przed pracą nad wydajnością — Google nie zrankuje strony, której nie widzi.

Co sprawdza audyt techniczny SEO

Rzetelny audyt strony internetowej przechodzi przez kilka odrębnych obszarów — pominięcie któregokolwiek zostawia potencjał na stole.

• Crawlowalność i reguły robots. Składnia robots.txt, kody odpowiedzi serwera i to, czy boty docierają do stron, na których Ci zależy.
• Sitemapy i odkrywanie. Poprawność sitemap XML, segmentacja po typie treści i to, czy zawierają wyłącznie indeksowalne adresy z kodem 200.
• Budżet indeksowania. Na co boty realnie wydają swoje żądania. W serwisie powyżej kilku tysięcy adresów URL-e z parametrami, łańcuchy przekierowań i strony noindex po cichu pochłaniają crawl, który powinien iść na strony aktualizowane. Zarządzaj tym na podstawie logów serwera albo raportu Statystyki indeksowania — nie intuicji.
• Sygnały indeksacji. Tagi noindex, konflikty canonicali i nagłówki X-Robots-Tag, które po cichu usuwają strony z indeksu.
• Renderowanie i JavaScript. Czy Google widzi treść wyrenderowaną po stronie serwera, czy musi wykonać skrypty, żeby dotrzeć do tekstu. Sprawdzaj podglądem wyrenderowanego HTML w URL Inspection po każdym większym wdrożeniu frontendowym, nie raz do roku.
• Przekierowania i kondycja linków. Martwe linki, łańcuchy przekierowań i strony osierocone, które istnieją tylko w sitemapie. Sprawdź też rozkład: strony biznesowo najważniejsze powinny mieć najwięcej linków wewnętrznych — w większości audytów nie mają.
• Wydajność i Core Web Vitals. LCP, INP i CLS — progi niżej.
• Dane strukturalne. Typy, które nadal dają wynik rozszerzony, walidowane w Schema.org i teście wyników rozszerzonych.
• Bezpieczeństwo, mobile i duplikacja. HTTPS bez mixed content, użyteczność mobilna, powtarzalne bloki treści.

Jedna warstwa doszła do tej listy niedawno: gotowość na wyszukiwanie AI. Chodzi o to, czy crawlery AI mają dostęp do treści, czy kluczowy tekst jest w HTML-u zamiast w JavaScripcie po stronie klienta, i czy strukturę da się wyekstrahować i zacytować w odpowiedzi generatywnej.

Porada profesjonalisty: Sprawdź w robots.txt przypadkowe blokady botów AI — GPTBot, OAI-SearchBot, Claude-SearchBot. Sporo stron blokuje je domyślnie i nikt tego nie zauważa. Blokada może być świadomą decyzją biznesową — nigdy skutkiem ubocznym konfiguracji.

Kryteria binarne, żeby wynik nie był kwestią opinii

Checklista audytu SEO jest użyteczna dopiero wtedy, gdy każdy punkt ma próg. Większość każe „sprawdzić przekierowania” i zostawia ocenę audytorowi. Daj każdemu checkowi liczbę — wtedy dwie osoby dojdą do tego samego wyniku, a porównanie kwartał do kwartału zacznie coś znaczyć.

Czas odpowiedzi serwera zasługuje na komentarz. Stoi na górze tabeli, bo mnoży się przez wszystko inne: wolny origin ogranicza LCP od dołu, dławi tempo crawlowania i ciągnie konwersję w dół. To jednocześnie check najczęściej pomijany — crawlery raportują go jako liczbę, nie jako błąd, więc łatwo go nie zauważyć.

Progi Core Web Vitals, precyzyjnie

Audyt wydajności strony zaczyna się od trzech liczb, nie od wyniku Lighthouse. Ogólnikowe „popraw szybkość” to powód, dla którego ta praca utyka.

Dwie rzeczy, które audyty notorycznie mylą. INP zastąpił FID w marcu 2024 — checklista wymieniająca First Input Delay jest nieaktualna. I FCP nie jest metryką Core Web Vitals — to przydatna miara diagnostyczna, ale nie należy do tej tabeli. Raportuj z danych polowych: raport CWV w Search Console albo zbiór CrUX. Lighthouse służy do debugowania, nie do raportowania.

Nota o znacznikach FAQ i HowTo

Wiele checklist wciąż każe walidować schemę FAQ i HowTo. Ta instrukcja jest nieaktualna i warto ją usunąć z szablonu.

Google wycofał wyniki rozszerzone HowTo na desktopie we wrześniu 2023. Wyniki FAQ ograniczył do stron rządowych i medycznych w sierpniu 2023, a 7 maja 2026 wycofał całkowicie — raport w Search Console zniknął w czerwcu 2026, wsparcie w API w sierpniu 2026. Żaden z tych typów nie daje dziś wyniku w wyszukiwarce.

FAQPage pozostaje poprawnym typem Schema.org i istniejący markup może zostać — nieużywane dane strukturalne nie szkodzą. Ale to już nie jest brak do wykazania w audycie. Waliduj to, co nadal daje efekt: Article, Product z Offer, BreadcrumbList, Organization.

Jak zrobić audyt SEO krok po kroku

Kolejność poniżej nie jest przypadkowa: audyt najpierw potwierdza, że Google w ogóle dociera do strony, a dopiero potem ktokolwiek optymalizuje, jak szybko się ładuje. Praca nad wydajnością strony z tagiem noindex nie daje nic.

1. Crawl i próbka. Pełny crawl serwisu zestawiony z danymi Search Console i logami serwera. Deliverable: arkusz inwentaryzacyjny z każdym adresem, jego statusem, canonicalem i indeksowalnością.
2. Diagnoza indeksowalności. Tagi noindex, konflikty canonicali, luki w pokryciu sitemap. Każdy adres wykluczony z indeksu ma być wykluczony decyzją, nie przypadkiem. Deliverable: raport indeksowalności.
3. Diagnoza wydajności. Core Web Vitals na realnych szablonach, z danych polowych. Deliverable: lista poprawek z metrykami i zrzutami.
4. Scoring i grupowanie. Uporządkuj znaleziska według wpływu, pewności i łatwości, potem pogrupuj w paczki gotowe dla dewelopera.
5. Weryfikacja i monitoring. Potwierdź naprawy w Search Console i w danych polowych, potem ustaw cykliczne crawle.

Każdy krok kończy się czymś konkretnym do przekazania — to różnica między audytem a luźną listą obserwacji.

Jakie narzędzia i skany uruchomić

Żadne pojedyncze narzędzie nie pokrywa pełnej analizy technicznej SEO, więc łączysz wyniki z założenia, a nie z przypadku.

• Crawler desktopowy do odkrywania — powinien flagować problemy z renderowaniem JS, bo współczesne frameworki potrafią ukryć treść przed botami niewykonującymi skryptów. Screaming Frog w wersji bezpłatnej crawluje do 500 adresów.
• Search Console i Bing Webmaster Tools — status indeksacji i błędy crawlowania prosto ze źródła. Search Console trzyma 16 miesięcy danych, czyli minimum potrzebne do porównania okresu z tym samym okresem rok wcześniej.
• Lighthouse lub PageSpeed Insights do debugowania, w parze z raportem CWV albo CrUX do liczb, które faktycznie raportujesz.
• Analiza logów serwera — jak boty zachowują się naprawdę, a nie jak zakładasz; plus strony osierocone, do których crawler nigdy nie trafia. Kwartalnie wystarcza większości serwisów.
• Narzędzie crawlu ciągłego, które odpala się według harmonogramu — regresje wychodzą między audytami kwartalnymi, a nie na następnym.
• Test wyników rozszerzonych do walidacji danych strukturalnych przed wdrożeniem.

Jak ustalić, co naprawić najpierw

Dwie osie to za mało. Scoring wyłącznie po wpływie i nakładzie pracy kończy się tak, że pojedyncze niepotwierdzone ostrzeżenie z crawlera ląduje na szczycie roadmapy. Dodaj trzecią.

Impact (1–10). Szacuj w metryce biznesowej — przychodzie, leadach — nie w sesjach. Linijka w robots.txt blokująca /blog/ dostaje wysoką notę, bo wycina z indeksu całą sekcję.

Confidence (1–10). Jak dobrze znalezisko jest udokumentowane. Bloker potwierdzony jednocześnie w crawlu i w Search Console — górna półka. Ostrzeżenie z jednego narzędzia, bez niczego, co je potwierdza — nisko. Obniżaj pewność także wtedy, gdy opierasz się na „dobrej praktyce” zamiast na własnych danych.

Ease (1–10). Wszystko, co wymaga sprintu deweloperskiego, dostaje niższą notę niż to, co wdrożysz samodzielnie. Przebudowa szablonów pod Core Web Vitals to wysoki Impact i niski Ease; brakujący alt obrazka — odwrotnie.

Pomnóż trzy czynniki. Posortuj malejąco, weź z góry tyle, ile kwartał realnie pomieści, resztę przejrzyj w następnym — a zadania, które od dwóch kwartałów nie weszły do realizacji, usuń: ich prawdziwy wynik był niższy, niż wyglądał.

Każdą pozycję prezentuj interesariuszom z oczekiwanym efektem, szacunkiem czasu i ryzykiem zaniechania. Taka rama zdobywa budżet szybciej niż surowa lista błędów.

Porada profesjonalisty: Jeśli ktoś przy stole zapyta „co się stanie, jeśli tego nie naprawimy” — miej gotową jednozdaniową odpowiedź dla każdej pozycji z góry listy, zanim spotkanie się zacznie.

Jak raportować wyniki i ustawić rytm audytów

Raport zarabia na siebie wtedy, gdy czyta się go jak ocenę kondycji SEO w czasie, a nie jak migawkę. Śledź: liczbę stron indeksowalnych, błędy pokrycia, rozkład LCP/INP/CLS, błędy crawlowania, łańcuchy przekierowań i błędy danych strukturalnych.

• Wykres kondycji serwisu widoczny na pierwszy rzut oka
• Rozkład problemów po kategoriach, żeby było widać, gdzie się kumulują
• Trendy Core Web Vitals przed i po, powiązane z konkretnymi naprawami

Naprawę uznawaj za zakończoną po potwierdzeniu w Search Console i w danych polowych — zaliczony test laboratoryjny to nie to samo, co odczuwalna zmiana u realnych użytkowników.

Rytm: trzy cykle pracują razem. Lekki crawl co tydzień — regresja pokazuje się jako skok liczby problemów, a nie jako spadek ruchu. Pełny audyt co kwartał, razem z logami. Crawl porównawczy do 48 godzin po każdym większym wdrożeniu — większość katastrof SEO to niezamierzone skutki release'ów, wykryte za późno.

Kadencja łapie regresje. Zapobieganie im to osobny ruch: wpisz SEO do definition of done dla zmian frontendowych i infrastrukturalnych. Cztery warunki, każdy testowalny przed wypuszczeniem zmiany — kody 200/301 zgodne z intencją, meta robots i canonical bez nieintencjonalnych zmian, kluczowa treść obecna w wyrenderowanym DOM, Core Web Vitals w ustalonym z deweloperami budżecie wydajności. Release, który nie przechodzi któregokolwiek z czterech, nie wychodzi. To jedno ustalenie usuwa więcej znalezisk audytowych niż jakikolwiek harmonogram crawli.

Najszybsze wygrane audytu technicznego

Część napraw zajmuje popołudnie, a efekt widać w kilka dni. Te pięć warto zrobić przed wszystkim innym.

1. Cofnij przypadkowy Disallow na cały serwis albo noindex na poziomie szablonu, potem poproś o ponowne crawlowanie.
2. Napraw rozjazdy self-canonical na poziomie szablonu, żeby strony przestały konkurować same ze sobą.
3. Zwiń wieloskokowe łańcuchy przekierowań do pojedynczego 301 i skieruj linki wewnętrzne prosto do celu.
4. Preloaduj obraz hero, skonwertuj go do formatu nowej generacji i ustaw jawne wymiary — tnie LCP i CLS naraz.
5. Odrocz niekrytyczne skrypty zewnętrzne i zdejmij analitykę z głównego wątku, żeby poprawić INP.

Żadna z tych rzeczy nie wymaga przebudowy, wszystkie pięć mieści się w jednym sprincie, a każda ma mierzalne „przed i po” do raportu.

Jak AI SEO COMPANY przeprowadza audyt

Nasz proces idzie w kolejności: crawl odkrywczy, triage indeksowalności, priorytetyzowana naprawa, weryfikacja, monitoring ciągły — z powodu opisanego wyżej: praca nad wydajnością stron, których Google nie widzi, wydaje budżet bez efektu.

Audyt SEO obejmuje ponad 50 punktów kontrolnych w trzech obszarach: technikalia z Core Web Vitals, treści z semantyką oraz profil linków. Do pracy potrzebujemy dostępów do Search Console i Analytics; wyniki dostajesz w 3–5 dni roboczych jako raport z listą błędów, oceną wpływu na widoczność, priorytetyzacją według stosunku efektu do pracochłonności i rekomendacjami w formie gotowej do przekazania deweloperowi. Po przekazaniu omawiamy go na konsultacji.

Audyt prowadzimy w ramach abonamentu, obok pozostałych prac SEO; w wyjątkowych sytuacjach wyceniamy go jako samodzielne zlecenie, po uzgodnieniu zakresu przed startem. Wyniki zależą od punktu startowego i od tego, ile z listy napraw faktycznie zostanie wdrożone — żadna agencja nie może zagwarantować rezultatu.

Największe marnotrawstwo, jakie widujemy, to zespoły przepisujące szablony pod Core Web Vitals, podczas gdy tag noindex albo reguła w robots.txt dalej wycina stronę z indeksu. Najpierw odkrywanie. Szybkość ma znaczenie dopiero wtedy, gdy Google stronę widzi.

Jeśli chcesz zacząć od diagnozy, zamów bezpłatną analizę SEO i potencjału obecnej marki przez formularz kontaktowy — na zapytania odpowiadamy zwykle w mniej niż dwie godziny, wstępną propozycję wysyłamy w ciągu doby.

Najczęściej zadawane pytania

Ile trwa audyt SEO?

Audyt pojedynczej domeny zajmuje zwykle od kilku dni do tygodnia, zależnie od wielkości serwisu i tego, czy obejmuje analizę logów. U nas standardowo 3–5 dni roboczych. Serwisy z milionami adresów wymagają podejścia modułowego zamiast jednego pełnego crawlu.

Ile kosztuje audyt SEO?

Na polskim rynku audyty małych stron wyceniane są zwykle w przedziale kilkuset do dwóch tysięcy złotych, a rozbudowanych serwisów — od trzech do kilkunastu tysięcy. Rozpiętość bierze się z zakresu: sam crawl z automatu to co innego niż analiza logów, danych polowych i konsultacja wdrożeniowa. U nas audyt wchodzi w zakres abonamentu.

Jak często powtarzać audyt?

Lekki crawl co tydzień, pełny audyt co kwartał i dodatkowy crawl porównawczy natychmiast po każdym większym wdrożeniu, przebudowie albo migracji.

Przenosimy się na nową domenę. Kiedy audytować?

Dwa razy: raz na środowisku testowym przed startem — żeby złapać noindexy i blokady, które inaczej pojechałyby na produkcję — i potem codziennie przez pierwsze cztery tygodnie. Spadek ruchu o 10–20% przez dwa do sześciu tygodni bywa normalny i sam w sobie nie oznacza porażki. Brak odbicia po ośmiu tygodniach oznacza błąd w mapie przekierowań albo pokryciu indeksu — wtedy się szuka, a nie czeka.

Czym różni się checklista on-page od audytu technicznego?

Checklista on-page dotyczy elementów treści: tytułów, nagłówków, pokrycia fraz. Audyt techniczny obejmuje crawlowalność, indeksację, renderowanie i infrastrukturę — warstwy, do których poprawki w treści nie sięgają.

Czy potrzebny jest i crawler, i sprawdzenie ręczne?

Tak. Skan automatyczny szybko łapie problemy masowe — martwe linki, brakujące znaczniki. Weryfikacja ręczna łapie problemy kontekstowe, na przykład canonical technicznie poprawny, ale wskazujący złą stronę.

Czy dodawać schemę FAQ podczas audytu?

Nie jako taktykę pod SERP. Wyniki rozszerzone FAQ wycofano 7 maja 2026, HowTo w 2023. Blok pytań i odpowiedzi w treści — jak ten — nadal ma sens dla czytelników i odpowiedzi AI; sam markup przestał być brakiem do wykazania.

Źródła

Dokumentacja Google

• Google Search Central — Core Web Vitals; INP zastąpił FID jako metryka CWV w marcu 2024
• Google Search Central — dane strukturalne FAQPage, nota o wycofaniu z 7 maja 2026; raport w Search Console i teście wyników rozszerzonych usunięty w czerwcu 2026, wsparcie API w sierpniu 2026
• Google Search Central — dane strukturalne HowTo, wycofanie na desktopie wrzesień 2023
• Centrum pomocy Search Console — 16 miesięcy przechowywania danych

Pozostałe

• Schema.org — Getting Started

Ostatnia weryfikacja: sierpień 2026. Informacje o danych strukturalnych odzwierciedlają dokumentację Google na ten dzień.

Powiązane

• Analiza luk contentowych: praktyczny przewodnik — contentowa strona tego samego cyklu audytowego
• Audyt UX strony: co obejmuje i ile kosztuje — warstwa konwersji po domknięciu technikaliów
• Konfiguracja zdarzeń w GTM i GA4 — pomiar, na którym opiera się weryfikacja napraw