Audyt techniczny SEO w 2026 obejmuje 12 obszarów — od crawlingu i indeksacji po warstwę AI Search Optimization (AISO) — i zwykle skraca diagnozę błędów krytycznych do około 24 godzin przy serwisach poniżej 10 000 URL‑i, o ile istnieją pełne dostępy do GSC/logów i środowiska testowego. Zapytanie „audyt techniczny strony” dostaje odpowiedź poprzez analizę logów serwera z minimum 30 dni historii, crawl 1–5 mln URL‑i oraz porównanie Chrome User Experience Report (CrUX) i Lighthouse dla TTFB, LCP i INP — przy celach orientacyjnych: LCP ≤ 2,5 s i INP ≤ 200 ms (wg zaleceń Google/web.dev).
W środowiskach Single Page Application (SPA)/Server‑Side Rendering (SSR) audyt sprawdza renderowanie, kolejność hydracji i zgodność z Mobile‑First Index — standard obowiązuje od 31 października 2023 r. dla wszystkich indeksowanych domen. Kontrola linkowania wewnętrznego, canonicali, noindex, robots.txt i sitemap pomaga ograniczyć typowe straty budżetu crawl na URL‑e o niskiej wartości.
Raport z audytu porządkuje zadania według wpływu na ruch i kosztu wdrożenia, nadając priorytety P0–P2, estymacje godzinowe i wskaźniki monitoringu w oknach 7/28/90 dni. Przed startem wymagany jest dostęp do GSC (rola „Właściciel domenowy”), logów HTTP z co najmniej 30 dni rotacji i środowiska testowego — to pozwala bezpiecznie odtworzyć błędy i potwierdzić poprawki bez ryzyka regresji produkcyjnej.
„Audyt techniczny SEO” — w tym kontekście — to zorganizowany zestaw testów indeksacji, renderu i wydajności obejmujący 12 obszarów, którego wyniki mapuje się na priorytety P0–P2 z estymacjami godzinowymi.
Jak przebiega audyt techniczny strony krok po kroku
Audyt techniczny SEO to uporządkowana diagnoza crawlingu, indeksacji, renderowania i wydajności — jej celem jest usunięcie barier widoczności prowadzących do utraty około ≥15% ruchu organicznego. Wpływ oceny obejmuje TTFB i INP w danych CrUX (75. percentyl) oraz widoczność w AI Overview — różne systemy mogą inaczej interpretować JS, dlatego wnioski formułuje się warunkowo. W praktyce zaczyna się od blokad indeksacji, Core Web Vitals i parytetu mobilnego, a następnie optymalizuje szablony i warstwę AISO.
Jakie są etapy audytu od szybkiej diagnozy do pełnej analizy?
Proces przechodzi od triage błędów P0 do pełnej analizy 12 obszarów z warstwą AISO. Dla serwisów poniżej 1 000 URL‑i pierwsza diagnoza P0 zamyka się zwykle w ciągu 4–8 godzin; dla 10 000+ URL‑i pełny cykl orientacyjnie trwa 2–4 tygodnie robocze.
- Szybka diagnoza (dzień 1–2): Google Search Console (Coverage, Crawl Stats), robots.txt, statusy 5xx/4xx, indeksacja kluczowych szablonów — cel orientacyjny: lista P0 w ciągu ~24 godzin przy pełnych dostępach.
- Pełny crawl (dzień 3–5): mapowanie architektury URL‑by‑URL, paginacja, kanonikalizacja, parametry URL, sitemap, linkowanie wewnętrzne — narzędzia: Screaming Frog lub Sitebulb.
- Renderowanie (dzień 4–6): SPA, SSR, dynamiczne renderowanie i statyczna generacja (SSG — Static Site Generation); test HTML po renderze, wykrywanie blank HTML i zasobów blokowanych w robots.txt.
- Wydajność (dzień 5–7): Core Web Vitals z CrUX (75. percentyl), INP zastępujący FID od marca 2024 r. (wg Google/web.dev), historyczny FID do porównań.
- Warstwa AISO (dzień 6–8): wzorce treści generowanych przez AI, ustawienia meta dla botów, dostępność schema.org.
- Porównanie narzędzi (dzień 7–9): Lighthouse (lab) vs CrUX (field), różnice w TTFB i INP — bywa 20–50% rozbieżności; parytet Mobile‑First Index.
- Priorytetyzacja ICE i dokumentacja (dzień 8–14): backlog z P0–P2, estymacje godzinowe, akceptowalne regresje, rekomendacje schema.org z testami walidacji.
W liczbach: dla serwisów poniżej 1 000 URL‑i zwykle wystarcza 1 pełny crawl i weryfikacja MFI — przy 10 000+ pomocna jest korelacja z logami i testy renderu, co dodaje 3–5 dni pracy analitycznej.
| Zakres | Audyt techniczny SEO | Pełny audyt SEO |
|---|---|---|
| Warstwa | Infrastruktura i render (12 obszarów) | Technika + content + linki zewnętrzne |
| Czas trwania | ~2 tygodnie (orientacyjnie; do ~6 tygodni w enterprise) | ~4–10 tygodni (orientacyjnie) |
| Efekt | Indeksacja, CWV, budżet crawl, INP ≤ 200 ms (cel orientacyjny wg web.dev) | Pozycje, ruch organiczny, konwersje |
Zakresy w tabeli są przykładowe i zależą od architektury serwisu oraz jakości dostępnych danych.
Kiedy audyt staje się audytem diagnostycznym z analizą logów serwera?
Tryb diagnostyczny uruchamia się w 4 przypadkach: strona ma 10 000+ URL‑i, nastąpiła migracja domeny, Google Core Update spowodował spadek ruchu o około ≥15%, lub budżet crawl marnuje się na URL‑e z parametrami (próg orientacyjny: ≥20% hitów Googlebota). Analiza logów serwera staje się konieczna, gdy dane Crawl Stats w GSC nie pokrywają się z realnym ruchem bota — w enterprise monitoring logów często prowadzi się co ~3 miesiące.
W średnich organizacjach i enterprise analizuje się korelację kodów 304/200/404 z mapą linków wewnętrznych oraz segmentację SPA/SSR — to pozwala ustalić listy wykluczeń, reguły robots.txt i priorytety renderowania po stronie serwera. Sygnały ilościowe wymagające analizy logów: udział parametrów w hitach Googlebota ≥20% (wartość orientacyjna), odsetek stron 404 w crawl Googlebota ≥10% (wartość orientacyjna), lub stosunek stron zindeksowanych do crawlowanych poniżej ~60%.
Jakie błędy krytyczne trzeba wyłapać w pierwszej kolejności?
Priorytet P0 obejmuje blokery indeksacji i renderu powodujące natychmiastową utratę widoczności: błędne robots.txt, meta noindex oraz kody 5xx/4xx na kluczowych szablonach. W pierwszym kroku sprawdza się też canonicale, przekierowania 302 zamiast 301 i parytet Mobile‑First Index — jeden błąd robots.txt potrafi zablokować całą sekcję serwisu i wyzerować jej widoczność w ciągu 1–2 cykli crawlu (zazwyczaj 3–14 dni).
- Blokady robots.txt lub meta noindex na szablonach kategorii i produktu.
- Puste HTML po renderze SPA bez SSR lub błędne dynamiczne renderowanie — częsty problem w projektach React/Vue pozbawionych SSR.
- Pętle canonical, 302 zamiast 301 w głównych ścieżkach, 5xx na sitemap.xml.
- Rozjazdy Mobile‑First Index: brak parytetu contentu/linków między mobile a desktop.
- Core Web Vitals: INP > 200 ms, LCP > 2,5 s, CLS > 0,1 — cele wg Google/web.dev; wartości orientacyjne.
- Nieprawidłowe schema.org skutkujące utratą rich results.
Audyt techniczny SEO — jako fundament obok content marketingu oraz link buildingu — dostarcza mierzalny backlog P0–P2 z rekomendacjami wdrożeniowymi, który zespół realizuje w sprintach 2‑tygodniowych.
Jak przygotować dane i środowisko do audytu
Do audytu potrzebne są pełne dostępy i plan próbkowania gotowy na dzień 0 — bez nich diagnoza P0 może się opóźnić o 2–5 dni roboczych. Start przyspiesza, gdy na dzień 0 istnieje lista priorytetowych URL‑i (minimum 100 reprezentatywnych adresów), potwierdzona wersja mobile/desktop i zakres subdomen. Komplet dostępów ogranicza większość opóźnień komunikacyjnych.
Jakie dostępności i konta są potrzebne przed startem?
Prace ruszają po nadaniu ról „Właściciel domenowy” do Google Search Console, dostępu edytorskiego do CMS i repozytorium konfiguracji robots.txt oraz sitemap. Lista musi obejmować logi serwera (produkcyjny i CDN z minimum 30 dni rotacji), narzędzie crawlingu (np. Screaming Frog lub Sitebulb), system tagów (GTM lub równoważny) i dane Core Web Vitals z CrUX wraz z INP i archiwalnym First Input Delay (FID — do porównań trendów).
- Konto GSC: własność domenowa, dostęp do Coverage, Crawl Stats, Removals i raportu Indeksacja.
- Serwer/CDN: logi HTTP z UA i IP Googlebota, rotacja minimum 30 dni — dla 10 000+ URL‑i zalecane ~90 dni.
- CMS i repo: edycja robots.txt, mapa strony XML, możliwość wdrożenia schema.org i testowania zmian w środowisku staging.
- Narzędzia: Screaming Frog/Sitebulb do crawlingu, raporty Lighthouse/CrUX, podgląd renderu (GSC).
Bez logów i własności domenowej GSC część ustaleń pozostaje hipotezą bez możliwości weryfikacji — co opóźnia priorytetyzację P0–P2.
Jak zebrać próbki danych z GSC, crawla i logów?
Plan próbkowania obejmuje 1–5% adresów z kluczowych szablonów (minimum 500 URL‑i na szablon przy serwisach powyżej 50 000 stron) — wraz z eksportem GSC z ostatnich 90 dni. Eksport logów serwera powinien zawierać statusy 200/304/404/5xx i pełne ścieżki, aby zweryfikować budżet crawl, zachowanie SPA/SSR oraz dynamiczne renderowanie i statyczną generację.
- GSC: wyciąg indeksacji, strony wykluczone, statystyki skanowania z 16 tygodni, błędy renderu.
- Crawl: pełny run + próbka kontrolna, paginacja, kanonikalizacja, parametry URL — Screaming Frog obsługuje duże wolumeny.
- Logi: filtr Googlebot po polu User‑Agent, częstotliwość hitów per segment URL, nietrafione URL‑e z sitemap.
W liczbach: próbka 1–5% często ujawnia większość błędów krytycznych — pod warunkiem że segmentacja obejmuje wszystkie typy szablonów (kategoria, produkt, artykuł, landing, strona techniczna).
Jak przygotować zakres dla małej, średniej i dużej strony?
Zakres dla małej strony (do 1 000 URL‑i) to jeden pełny crawl, kontrola Mobile‑First Index i lista P0 metodą ICE — czas pracy orientacyjnie: 8–16 godzin. Dla średnich organizacji (1 000–50 000 URL‑i) cykl audytu bywa dłuższy, z budżetem na dwa crawle różnicowe oraz testy AISO pod AI Overview — czas pracy: około 3–5 dni.
| Wielkość | Liczba URL‑i | Zakres | Czas pracy |
|---|---|---|---|
| Mała | do 1 000 | 1 pełny crawl, GSC, próbka logów 30 dni | 8–16 godzin (orientacyjnie) |
| Średnia | 1 000–50 000 | 2 crawle różnicowe, CrUX/Lighthouse, analiza logów ~90 dni | 3–5 dni (orientacyjnie) |
| Enterprise | 50 000+ | Stała analiza logów, crawl różnicowy co 4–6 tygodni, testy renderu SPA/SSR | 10–20 dni (orientacyjnie) + monitoring ciągły |
Zakresy w tabeli są przykładowe i zależą od architektury serwisu oraz jakości danych wejściowych.
Brak logów serwera przy serwisie 10 000+ URL‑i to sygnał ostrzegawczy: bez nich audyt może pominąć realny rozkład budżetu crawl i nie wykryć pułapek parametrów marnujących w skrajnych przypadkach do ~47% hitów Googlebota.
Co sprawdzić w indeksacji, robots.txt i sitemap.xml
W bloku indeksacji sprawdza się dostępność URL‑i dla crawlerów, poprawność reguł robots.txt i jakość sitemap.xml pod kątem indeksowalności — bez wyjątków dla żadnego szablonu. Audyt rozszerza to o analizę linkowania wewnętrznego, kanonikalizacji i renderowania SPA/SSR, by nie marnować budżetu indeksacji — straty potrafią sięgać orientacyjnie 20–40% na URL‑e bez wartości SEO. Często spotykane wzorce: ukryte blokady CSS/JS oraz niespójne canonicale wskazujące na wiele wersji tego samego URL.
Jak wykryć blokady crawlerów i błędne reguły robots.txt?
Plik robots.txt sprawdza się pod kątem 5 krytycznych wzorców: pozostawionej po testach reguły „Disallow: /”, blokowania CSS lub JavaScript (utrudnia render MFI), błędnych dyrektyw Sitemap, blokady botów AI i reguł case‑sensitive. Analiza logów oraz raport Crawl Stats w GSC pokazują realne hity Googlebota i zablokowane zasoby — wpływa to na indeksację i odczyt danych strukturalnych. Zmiana jednej reguły Disallow może przywrócić indeksację dziesiątek tysięcy URL‑i w ciągu 1–2 tygodni.
Jak znaleźć problemy z canonicalami, noindex i duplikatami?
Tag rel=canonical, meta robots i nagłówki X‑Robots‑Tag trzeba zestawić z HTTP 200 oraz wynikiem renderu — SPA bez SSR generują czasem pusty HTML i soft 404. Budżet indeksacji zużywany na URL‑e o niskiej wartości bywa wysoki (orientacyjnie 20–40%), a łączność hreflang często zawiera błędy — kontrole szablonów i parametryzacji są obowiązkowe dla serwisów z 500+ URL‑i.
Jak ocenić sitemap.xml, linkowanie wewnętrzne i pułapki indeksacyjne?
Sitemap.xml powinien zawierać wyłącznie URL‑e indexable (0 adresów z noindex, 404 lub 5xx) i odzwierciedlać kanonikalne adresy bez parametrów — Google rekomenduje maksymalnie 50 000 URL‑i na jeden plik sitemap (limit 50 MB nieskompresowanego XML). Zgodnie z dokumentacją Google (Search Central) limity 50 000 URL‑i i 50 MB na plik to twarde wymagania specyfikacji sitemap. Struktura linkowania wewnętrznego powinna kierować budżet crawl na strony o wysokiej wartości — pożądana głębokość kluczowych URL‑i to do ~3 kliknięć od strony głównej (wartość orientacyjna).
- robots.txt: brak „Disallow: /”, brak blokady CSS/JS, obecne wskazanie sitemap.xml z pełną ścieżką HTTPS.
- sitemap.xml: URL‑e ze statusem 200 i indexable, bez duplikatów i parametrów, plik < 50 MB / < 50 000 URL‑i (wg dokumentacji Google).
- Indeksacja: spójne canonicale (1 wersja URL), brak noindex w kluczowych szablonach, kontrola soft 404.
- Budżet crawl: eliminacja parametrów odpowiadających orientacyjnie za ≥20% hitów Googlebota oraz stron thin content.
Połączenie tych kontroli często daje mierzalne efekty w ciągu 4–8 tygodni: wzrost odsetka stron indexable i zmniejszenie rozbieżności w GSC Coverage.
Jak ocenić Core Web Vitals, renderowanie i Mobile-First Index
Audyt techniczny SEO ocenia Core Web Vitals, renderowanie JavaScriptu i zgodność z Mobile‑First Index — celem jest wyższa indeksowalność i stabilniejsza widoczność w Google. Mierzone są LCP (cel orientacyjny: ≤ 2,5 s), INP (cel orientacyjny: ≤ 200 ms) i CLS (cel orientacyjny: ≤ 0,1) z danymi z CrUX na 75. percentylu rzeczywistych użytkowników — rekomendacje wg Google/web.dev; wartości orientacyjne. Rozbieżności między Lighthouse a CrUX bywają 20–50% dla metryki INP i wynikają z różnic urządzeń, sieci i zachowań użytkowników.
Jak porównać Lighthouse z danymi CrUX i interpretować rozbieżności?
Porównanie Lighthouse (środowisko laboratoryjne, symulowane urządzenie i łącze) z CrUX (rzeczywiste dane 28‑dniowe, 75. percentyl) odsłania wpływ realnych sieci, urządzeń i historii użytkowników. Interpretacja rozjazdów wymaga oceny TTFB (dobrze: ≤ 800 ms — wartość referencyjna wg web.dev), wag JS/CSS i wpływu skryptów third‑party. Od marca 2024 r. kluczowa jest metryka INP zamiast FID. Jeden skrypt third‑party potrafi dodać +100–200 ms INP na urządzeniach mobilnych — to różnica między oceną „dobry” a „wymaga poprawy”.
Jak sprawdzić renderowanie JavaScriptu w SPA, SSR i CSR?
Weryfikacja SPA obejmuje 4 strategie renderowania: SSR (Server‑Side Rendering — render po stronie serwera), CSR (Client‑Side Rendering — render po stronie klienta), dynamiczne renderowanie (osobna wersja dla botów) i statyczną generację (SSG — Static Site Generation, build‑time). Wiele botów AI (np. GPTBot, ClaudeBot, AppleBot) może nie renderować JS — serwis bez SSR/SSG bywa dla nich mniej widoczny; zachowanie botów może się zmieniać. Test zawiera inspekcję HTML po renderze (narzędzie: podgląd w GSC), wykrycie bardzo ubogiego HTML oraz identyfikację zasobów blokowanych w robots.txt — i porównanie statusu HTTP z treścią po renderze.
Jak zweryfikować zgodność mobilną po zakończeniu Mobile-First Index?
Kontrola MFI sprawdza parytet 4 elementów między mobile a desktop po 31.10.2023 r.: treści głównej (tekst, nagłówki, dane strukturalne), linków wewnętrznych (różnice w nawigacji), schema.org (wersja mobile musi zawierać tożsame znaczniki) oraz CWV na urządzeniach mobilnych (CrUX/Lighthouse). Gdy parytet nie jest zachowany — Google indeksuje wersję mobilną, co może skutkować utratą części treści z indeksu — korekty planuje się przed pracami nad CWV.
Jak czytać raport audytu i wdrażać rekomendacje po audycie
Raport łączy diagnozę z planem wdrożenia i metrykami sukcesu: LCP ≤ 2,5 s i INP ≤ 200 ms z CrUX (75. percentyl), odsetek stron indexable ≥ 90% w GSC Coverage — to cele wg Google/web.dev, traktowane jako orientacyjne. Odwołuje się do danych GSC (Crawl Stats, indeksacja z 90 dni) oraz logów serwera w celu weryfikacji efektów przed i po wdrożeniu. Porównanie stanu „przed” i „po” w oknach 7/28/90 dni najczęściej pozwala wykryć regresje w ciągu 48–72 godzin od wdrożenia, pod warunkiem skonfigurowanych alertów i dashboardów (GSC/CrUX/logi).
Jak powinien wyglądać dobry raport i dokumentacja techniczna z audytu?
Dobry raport zawiera 6 elementów: priorytetyzowaną listę zadań P0–P2 (minimum 10–50 pozycji z szacunkami czasowymi), podsumowanie dla zarządu (1–2 strony), plan wdrożeniowy z podziałem na sprinty 2‑tygodniowe, sesję transferu wiedzy (2–4 godziny), testy akceptacyjne i 30–90 dni wsparcia po wdrożeniu. Dokumentacja dołącza uzasadnienia oparte na danych (nie opiniach), testy akceptacyjne, mierzalny wpływ na LCP/INP oraz wskazania zmian w robots.txt, schema.org i renderowaniu SPA/SSR — z przykładami implementacji na kluczowych szablonach.
Jak ustawić priorytety wdrożenia i kolejność zadań?
Zadania punktuje się metodą ICE (Impact 1–10, Confidence 1–10, Ease 1–10) i poziomami P0–P2, z uwzględnieniem zależności technicznych i ryzyka regresji. Kolejność układają 3 sprinty: Sprint 1 — blokady indeksacji P0 i błędy 5xx (tydzień 1–2), Sprint 2 — CWV/INP i linkowanie wewnętrzne (tydzień 3–4), Sprint 3 — refaktoryzacja JS i warstwa AISO (tydzień 5–6). W praktyce 2–3 sprinty 2‑tygodniowe zamykają znaczną część zadań P0 i P1 w serwisach do 50 000 URL‑i.
Jak monitorować efekty po wdrożeniu poprawek?
Monitoring opiera się na 4 źródłach danych: CrUX (75. percentyl LCP/INP/CLS, aktualizacja co 28 dni), GSC (Crawl Stats tygodniowo, Coverage — zmiany ±5% jako alert), analiza logów serwera (filtr Googlebot, hity per segment) i alerty 5xx (próg orientacyjny: ≥0,1% żądań) — z adnotacjami czasowymi pod Core Updates Google. Kontrola po wdrożeniu obejmuje przeglądy post‑release po 7 dniach (alerty krytyczne) i 28 dniach (metryki CrUX), z przykładowymi kryteriami rollback: wzrost błędów 5xx > 0,5%, spadek indeksacji > 10% lub regres LCP > 0,5 s.
Ile kosztuje audyt techniczny i jak wybrać audytora
Audyt techniczny SEO kosztuje orientacyjnie 3 000–5 000 PLN za szybki przegląd (do 1 000 URL‑i, 1–3 dni pracy), 5 000–10 000 PLN za audyt średni (1 000–50 000 URL‑i, 1–2 tygodnie) i 10 000–50 000 PLN w enterprise (50 000+ URL‑i, 4–6 tygodni). Cykl powtarzania: około 6 miesięcy dla średnich organizacji i ~3 miesiące w enterprise. Różnice w budżecie wynikają z liczby URL‑i, potrzeby analizy logów serwera (orientacyjnie dodatkowe 1 000–3 000 PLN), zakresu 12 obszarów, testów SSR/CSR i pracy na wielu środowiskach (staging, produkcja, CDN).
Od czego zależy wycena audytu technicznego strony?
Wycena zależy od 6 czynników: wolumenu URL‑i (każde 10 000 URL‑i to orientacyjnie +1–2 dni pracy), złożoności SPA/SSR (testy renderu: +0,5–1 dzień), obecności AISO (analiza botów: +0,5 dnia), liczby środowisk (każde środowisko staging: +0,5 dnia), obowiązkowej analizy logów przy 10 000+ URL‑i (+1–3 dni) oraz zakresu wsparcia po wdrożeniu (30 dni: +10–15% wartości audytu). Dobór audytora warto oprzeć na: próbkach raportów, zakresie testów (CWV, logi, render), transparentnych kryteriach akceptacyjnych i planie wdrożeń ze sprintami oraz miernikach sukcesu opartych o dane GSC/CrUX (wg zaleceń Google/web.dev — wartości traktowane jako orientacyjne).
