Technika
Audyt techniczny w cztery godziny
Cztery godziny wystarczą, żeby znaleźć większość problemów blokujących ruch, jeśli sprawdzasz w kolejności od najtańszego testu do najdroższego. Zaczynam zawsze od jednego pytania: czy treść w ogóle istnieje w źródle HTML. To 5 sekund pracy, a rozstrzyga więcej niż cała reszta audytu.
Dlaczego kolejność ma znaczenie?
Bo problemy techniczne układają się warstwowo. Nie ma sensu optymalizować prędkości strony, której robot nie może zaindeksować, ani dopracowywać treści, której crawler nie widzi. Każde sprawdzenie na liście ma sens tylko wtedy, gdy poprzednie wypadło pozytywnie.
Sprawdzenie 1: czy treść jest w HTML?
Najtańszy test w całym audycie i najczęściej pomijany. Wciśnij Ctrl+U i poszukaj fragmentu swojego tekstu w źródle strony. Jeśli widzisz głównie puste kontenery i skrypty, treść powstaje dopiero w przeglądarce.
Dla Google to problem umiarkowany - Googlebot renderuje JavaScript, choć z opóźnieniem. Dla modeli AI to problem zasadniczy, bo crawlery AI z reguły nie wykonują JavaScriptu. Strona zbudowana w całości po stronie klienta jest dla nich pusta.
Wersja z linii poleceń, która sprawdza to bez renderowania:
| Co sprawdzasz | Komenda |
|---|---|
| Czy treść jest w źródle | curl -sL twojadomena.pl | grep "fragment tekstu" |
| Czy sitemapa odpowiada | curl -I twojadomena.pl/sitemap.xml |
| Co widzi bot AI | curl -A "OAI-SearchBot" https://twojadomena.pl/ | head -c 500 (UA-spoof nie testuje blokad po IP - te sprawdzisz w logach) |
Ostatnia komenda bywa najbardziej odkrywcza - pokazuje, czy serwer albo CDN nie odsyła botowi innego kodu odpowiedzi niż przeglądarce.
Sprawdzenie 2: robots.txt i sitemapa
Dwie rzeczy, które psują się cicho. Sitemapa wskazana w robots.txt, która zwraca 404, jest gorsza niż jej brak - bot dostaje wskazówkę prowadzącą donikąd.
Przy botach AI trzeba znać jedno rozróżnienie: GPTBot zbiera dane treningowe, a OAI-SearchBot obsługuje wyszukiwanie w ChatGPT. Blokując wszystko w obawie przed treningiem, odcinasz się od cytowań.
Sprawdzenie 3: co jest w indeksie
W Search Console porównaj liczbę stron zaindeksowanych z liczbą w sitemapie. Duża rozbieżność w którąkolwiek stronę to sygnał: albo marnujesz crawl budget na śmieci, albo wartościowe strony nie wchodzą do indeksu.
Najczęstsze przyczyny, w kolejności częstości: parametry generujące duplikaty, paginacja bez kontroli, strony filtrowania w sklepach i wersje testowe, które nigdy nie zostały zablokowane.
Sprawdzenie 4: kanibalizacja
W raporcie skuteczności filtruj po zapytaniu i sprawdź, ile różnych adresów wyświetla się na tę samą frazę. Jeśli Google raz pokazuje jedną podstronę, raz drugą, obie tracą.
Sprawdzenie 5–8: reszta
Wydajność. Core Web Vitals z danych terenowych, nie laboratoryjnych. Liczy się to, co widzą użytkownicy, nie wynik z narzędzia na szybkim łączu.
Linkowanie wewnętrzne. Sprawdź, ile kliknięć od strony głównej dzieli podstrony, które zarabiają. Powyżej trzech to zwykle za daleko.
Dane strukturalne. Waliduj, zanim cokolwiek dodasz - w badaniu Digital Applied na 5000 witryn 49% próby miało schema z błędami walidacji, więc naprawa jest statystycznie pilniejsza niż rozbudowa.
Przekierowania. Łańcuchy i pętle, zwłaszcza po migracjach. Stary adres bywa cytowany przez modele jeszcze 2–4 miesiące po zmianie.
Czego cztery godziny nie wystarczą
Powiem uczciwie, gdzie kończy się ta metoda. Nie zrobisz w tym czasie analizy treści na dużym serwisie, pełnego przeglądu profilu linkowego ani mapy tematycznej wobec konkurencji. To jest triage, nie audyt kompletny - służy do znalezienia rzeczy, które krwawią najbardziej.
Przy sklepie z dziesiątkami tysięcy adresów sama analiza indeksacji potrafi zająć więcej niż te cztery godziny.
Pełna checklista: co obejmuje audyt techniczny?
Cztery godziny to triage - znajduje to, co krwawi najbardziej. Pełny audyt techniczny przechodzi systematycznie przez wszystkie obszary. Poniżej mapa, której używam, żeby niczego nie pominąć:
| Obszar | Co konkretnie sprawdzam | Typowy błąd |
|---|---|---|
| Indeksacja | Pokrycie w GSC, noindex, canonicale, duplikaty parametryczne | Wartościowe strony wykluczone „przez przypadek" |
| Crawlowanie | robots.txt, sitemapa, kody odpowiedzi, łańcuchy przekierowań | Sitemapa wskazująca 404 i przekierowania |
| Renderowanie | Treść w HTML vs budowana w JS, dostępność dla botów AI | Kluczowa treść niewidoczna bez JavaScriptu |
| Wydajność | Core Web Vitals z danych terenowych, waga strony, obrazy | Hero 2 MB bez wymiarów i priorytetu |
| Mobilność | Responsywność, tap targets, brak poziomego scrolla | Menu znikające na mobile bez zamiennika |
| Struktura URL | Czytelność adresów, głębokość, trailing slash, wielkość liter | Ta sama strona pod 3 wariantami adresu |
| Linkowanie wewnętrzne | Sieroty, głębokość kliknięć, anchory, dystrybucja | Strony zarabiające 4+ kliknięcia od głównej |
| Duplikacja | Wersje www/bez, http/https, parametry, paginacja | Brak jednego kanonicznego wariantu domeny |
| Dane strukturalne | Walidacja, zgodność z treścią widoczną | Schema opisująca coś, czego nie ma na stronie |
| Bezpieczeństwo | HTTPS wszędzie, mixed content, nagłówki | Zasoby ładowane po http na stronie https |
Jakich narzędzi używam i do czego?
Zestaw jest krótszy, niż sugerują listy „50 narzędzi SEO" - bo w audycie technicznym liczy się dostęp do danych źródłowych, nie liczba zakładek:
Google Search Console - jedyne źródło prawdy o tym, jak Google widzi serwis: raport indeksowania, statystyki crawlowania, realne zapytania. Audyt bez GSC to zgadywanie z zewnątrz.
Crawler (Screaming Frog lub odpowiednik) - przechodzi serwis jak robot i wypluwa surowe fakty: kody odpowiedzi, canonicale, głębokość, duplikaty title. Przy dużych serwisach crawluję z limitem i próbkuję sekcje.
PageSpeed Insights / CrUX - dane terenowe Core Web Vitals, czyli to, czego doświadczają realni użytkownicy. Wynik laboratoryjny traktuję pomocniczo - laptop na światłowodzie to nie jest Twój klient.
Logi serwera - przy problemach z crawlowaniem niezastąpione: pokazują, gdzie robot naprawdę chodzi i na czym marnuje czas. Google Analytics tego nie pokaże, bo odfiltrowuje boty.
curl - najprostsze narzędzie na liście i jedyne, które pokazuje stronę oczami bota bez renderowania. Trzy komendy z sekcji wyżej załatwiają połowę diagnozy dostępności.
Core Web Vitals: trzy liczby, które trzeba rozumieć
| Metryka | Mierzy | Próg „dobry" | Najczęstsza przyczyna problemu |
|---|---|---|---|
| LCP | Czas do wyświetlenia największego elementu | ≤ 2,5 s | Ciężki obraz hero bez priorytetu ładowania |
| INP | Opóźnienie reakcji na interakcję | ≤ 200 ms | Ciężki JavaScript blokujący wątek główny |
| CLS | Przesunięcia układu podczas ładowania | ≤ 0,1 | Obrazy i reklamy bez zarezerwowanych wymiarów |
Dwie uwagi z praktyki. Po pierwsze: licz się z danymi terenowymi, nie laboratoryjnymi - do progów Google odnosi się 75. percentyl realnych wizyt. Po drugie: CWV to czynnik dopełniający, nie główny - widziałem strony z fatalnym LCP w TOP3, bo treść wygrywała. Napraw najpierw indeksację i treść, wydajność potem.
Które błędy techniczne spotykam najczęściej?
Subiektywny ranking z moich audytów - bez procentów, bo próbka to moi klienci, nie rynek:
1. Rozjazd sitemapy z rzeczywistością. Adresy z 404, przekierowania, strony noindex w mapie. Tani do naprawy, a psuje zaufanie robota do całego pliku.
2. Kanibalizujące się warianty adresów. Parametry, wielkość liter, trailing slash - ta sama treść pod kilkoma URL-ami bez kanonicznych wskazań.
3. Treść zależna od JavaScriptu. Coraz częstszy od boomu na frameworki; od czasów wyszukiwarek AI podwójnie kosztowny, bo ich crawlery JS zwykle nie wykonują.
4. Łańcuchy przekierowań po migracjach. http → https → www → bez www → nowy adres. Każdy skok to strata; łańcuchy 3+ potrafią gubić roboty.
5. Sieroty. Strony istniejące tylko w sitemapie, bez ani jednego linku wewnętrznego. Robot może je znaleźć, ale nie dostają żadnego sygnału ważności.
Jak wygląda pełny audyt techniczny krok po kroku?
Dla porządku - bo czterogodzinny triage i pełny audyt to dwa różne produkty. Pełny proces u mnie:
| Etap | Co się dzieje | Czas |
|---|---|---|
| 1. Dostępy i zakres | GSC, analityka, ustalenie kluczowych sekcji serwisu | dzień 1 |
| 2. Crawl pełny | Przejście serwisu crawlerem, eksport surowych danych | 1-3 dni zależnie od skali |
| 3. Analiza indeksacji | Crawl vs indeks vs sitemapa - trzy zbiory, które muszą się zgadzać | 2-3 dni |
| 4. Warstwy z checklisty | Systematyczne przejście 10 obszarów z tabeli wyżej | 3-5 dni |
| 5. Priorytetyzacja | Każde znalezisko dostaje wpływ, nakład i właściciela | 1-2 dni |
| 6. Raport i omówienie | Dokument + rozmowa wdrożeniowa z zespołem | 1 dzień |
Stąd realny czas pełnego audytu liczony w tygodniach, nie godzinach. Triage z tego tekstu odpowiada na pytanie „gdzie krwawi najbardziej” - pełny audyt na pytanie „co dokładnie i w jakiej kolejności naprawić w całym serwisie”. Pierwszego nie sprzedawaj jako drugiego.
Audyt techniczny a widoczność w AI - co dochodzi?
Klasyczna checklista powstała pod Googlebota, który renderuje JavaScript i wybacza sporo. Crawlery modeli AI wybaczają mniej, więc do audytu w 2026 dokładam warstwę: dostępność treści w czystym HTML, jawny stan botów AI w robots.txt i na poziomie CDN, spójność danych na stronie (modele składają odpowiedzi z fragmentów - sprzeczne liczby w dwóch miejscach serwisu to proszenie się o błędną odpowiedź o Twojej firmie) oraz sensowność treści po wycięciu wszystkiego, co nie jest główną treścią.
To nie jest osobny „audyt AI” do dokupienia - to cztery dodatkowe wiersze w tej samej checkliście. Tak to traktuję i tak radzę traktować oferty, w których te wiersze sprzedawane są jako osobny produkt premium.
Częste pytania
Od czego zacząć audyt techniczny, jeśli mam godzinę?
Od sprawdzenia, czy treść jest w źródle HTML bez JavaScriptu, i czy sitemapa wskazana w robots.txt zwraca kod 200. Te dwa testy zajmują minuty, a wykrywają problemy, które unieważniają całą resztę pracy.
Czy darmowe narzędzia wystarczą do audytu?
Do wykrycia błędów - często tak. Do ich uszeregowania - nie. Narzędzie potrafi zgłosić 300 problemów, z których realnie liczy się pięć, a to hierarchia decyduje o efekcie.
Jak sprawdzić, czy bot AI widzi moją stronę?
Poleceniem curl z nagłówkiem user-agent bota, na przykład OAI-SearchBot, i porównaniem odpowiedzi z tym, co widzi przeglądarka. Różnica w kodzie odpowiedzi lub treści oznacza problem.
Co zrobić, gdy strona działa tylko z JavaScriptem?
Wdrożyć renderowanie po stronie serwera lub prerender, tak by treść była w źródle HTML. To jedyna naprawa, która działa dla crawlerów AI - one w większości nie wykonują JS.
Wolisz, żebym przeszedł przez to z Tobą?
Na konsultacji robimy ten przegląd wspólnie na Twoim serwisie i wychodzisz z listą zadań w kolejności wdrożenia. Jeśli serwis jest duży, sensowniejszy będzie pełny audyt - powiem to na wstępie.
Umów konsultacjęPowiązane materiały
- Google Search Central, dokumentacja indeksacji, 2026
- OpenAI, dokumentacja crawlerów, 2026
- Dane branżowe o walidacji schema, 2026
Autor
Adrian Grabski
Konsultant SEO i AI search. W wyszukiwarkach od 2002 roku - przez wszystkie aktualizacje Google i teraz przez wyniki generowane przez AI. Robię audyty, prowadzę konsultacje i szkolę zespoły marketingowe.