Audyt SEO: co powinien zawierać, krok po kroku

Audyt SEO daje największą wartość wtedy, kiedy każdą znalezioną nieprawidłowość można przełożyć na konkretną decyzję. Najpierw ustalam, które podstrony mają być widoczne w Google. Następnie sprawdzam, czy wyszukiwarka może je odkryć i pobrać, czy otrzymuje poprawne informacje o adresach oraz czy ich treść odpowiada intencji użytkownika.

Kontrolę porządkuję według indeksowania, przekierowań, linkowania, danych strukturalnych i wydajności. Każde ustalenie powinno dać się odtworzyć, żeby po wdrożeniu poprawki można było powtórzyć test.

Audyt SEO: co to jest i co powinien zawierać

Audyt SEO to przegląd strony, którego wynikiem jest lista rzeczy blokujących ruch z wyszukiwarki, ułożona w kolejności wdrażania. Spis wszystkiego, co dałoby się poprawić, nie ma końca i nikomu nie pomaga. Pełny audyt obejmuje trzy obszary, a każdy z nich w innym stopniu da się sprawdzić maszynowo.

Czwarty element najłatwiej przeoczyć, a jest nim raport, bo audyt, którego nikt poza autorem nie umie wdrożyć, jest tylko kosztem. Każde znalezisko potrzebuje w nim dowodu, wskazanego adresu i kryterium, po którym poznasz, że problem zniknął. Rozpisałem to w tekście o raporcie z audytu dla klienta.

Audyt nie obieca ci pozycji ani terminu. Nie zdecyduje też za ciebie, dla kogo jest strona i o czym ma być.

Audyt SEO krok po kroku

Audyt SEO ma osiem kroków i ich kolejność ma znaczenie, bo poprawianie treści na stronie, której crawler nie pobiera, to praca do kosza.

1. Ustal zakres i punkt odniesienia. Zapisz, co mierzysz i skąd bierzesz dane (Search Console, crawler, dane z pola), bo bez punktu wyjścia nie udowodnisz później, że coś się poprawiło.
2. Sprawdź, czy robot w ogóle dociera do strony. Statusy HTTP, robots.txt, noindex, budżet crawlowania (crawl budget). Tu kończy się większość problemów, które wyglądały na „słabe treści”.
3. Zweryfikuj sygnały kanoniczne. Canonicale i redirecty muszą mówić to samo co sitemapa i linkowanie wewnętrzne. Sprzeczne sygnały to najczęstsza przyczyna tego, że Google indeksuje inny adres, niż chciałeś.
4. Zmierz wydajność na danych z pola, oprócz laboratorium. Laboratorium mówi, co da się poprawić, a dane od użytkowników, czy to się opłaca.
5. Przejrzyj treści pod kątem intencji. Strona, która odpowiada na inne pytanie niż to wpisane w wyszukiwarkę, nie wygra żadnym nagłówkiem.
6. Obejrzyj profil linków. Liczy się, kto linkuje i w jakim kontekście, bo licznik domen da się zawyżyć spamem w tydzień.
7. Uszereguj znaleziska według wpływu i kosztu wdrożenia.
8. Ustal termin retestu, bo audyt bez powtórki jest opinią, a dopiero drugi pomiar tą samą metodą pokazuje, czy naprawa zadziałała.

Kroki 2–4 da się w dużej mierze zautomatyzować i od nich zaczyna moduł SEO w CometWeb Insight, a kroki 5–7 wymagają człowieka, który zna biznes. Krok 6 ilustruję przykładem profilu linków CometWeb opisanym w dalszej części. Sieć PBN, czyli sieć stron zakładanych do handlu linkami, pokazywała moją domenę jako próbkę w ofertach.

Ręcznej kary nie było, więc nie zrobiłem disavow. Wniosek? Liczba linków nic mi nie powiedziała, za to rozkład anchorów tak.

Techniczne SEO: czym jest i co obejmuje

Techniczne SEO to wszystkie działania, które ułatwiają botom Google i innych wyszukiwarek pobranie strony, zrozumienie jej struktury i zaindeksowanie treści. Ten sam porządek, od odkrycia strony do jej zrozumienia, opisuje przewodnik SEO od Google dla początkujących, a samo techniczne SEO obejmuje pięć obszarów:

• indeksowanie i crawlability, czyli to, czy Google w ogóle „widzi” twoje strony,
• szybkość ładowania (Core Web Vitals),
• strukturę URL i linkowanie wewnętrzne,
• bezpieczeństwo (HTTPS),
• dane strukturalne (Schema.org).

Checklista audytu technicznego SEO

Dobry audyt technicznego SEO łączy crawl całej witryny z ręczną kontrolą reprezentatywnych adresów. Nie kończ na stronie głównej, bo problemy często siedzą tylko w szablonie artykułu, modułu albo produktu, albo w starej wersji URL-a.

Sitemapa XML zawiera tylko adresy do indeksacji

Mapa witryny to plik XML, którym mówisz Google: „Oto ważne strony, zaindeksuj je”. Bez niej boty odkrywają strony tylko po linkach i mogą coś przeoczyć.

• Wygeneruj ją w Yoast SEO albo Rank Math, a jeśli ich nie masz, zrobi to też Screaming Frog, choć większość CMS-ów ma tę funkcję wbudowaną.
• Zgłoś jej adres (np. domena.pl/sitemap.xml) w Google Search Console > Mapy witryn.
• Trzymaj w niej tylko strony, które chcesz zaindeksować, a to, co z niej wyrzucić, pokazuje tabela wyżej.

Sitemapa pomaga też przy orphan pages, czyli stronach, do których nie prowadzi żaden link wewnętrzny, bo bez niej Google może ich nie znaleźć. Jak je wyłapać i podlinkować, pokazałem w tekście o linkowaniu wewnętrznym i stronach osieroconych.

Robots.txt blokuje tylko strony bez wartości dla wyszukiwarki

Robots.txt mówi botom, które części witryny mogą crawlować, a których mają unikać. Według dokumentacji Google o robots.txt plik służy przede wszystkim do zarządzania ruchem crawlerów, więc żeby trzymać stronę poza indeksem, użyj noindex.

• Zablokuj koszyk, wewnętrzne wyniki wyszukiwania (/search/) i panele administracyjne, bo te strony marnują budżet crawlowania, czyli liczbę adresów, które Googlebot chce i może pobrać.
• Trzymaj plik w katalogu głównym: domena.pl/robots.txt.
• Sprawdź go w raporcie robots.txt w Google Search Console. Raport pokazuje, które pliki robots.txt Google znalazł i jakie błędy napotkał, a błąd w jednej linii potrafi zablokować crawlowanie całej witryny.

Szybkość strony mieści się w progach Core Web Vitals

Według dokumentacji Google o page experience szybkość ładowania jest jednym z sygnałów systemów rankingowych Google, a nie samodzielnym czynnikiem, który przeważy nad trafnością. Google mierzy ją za pomocą Core Web Vitals, trzech metryk doświadczenia użytkownika. Progi „dobrego” wyniku podaje web.dev, a zestawiam je w tabeli w artykule o przyspieszaniu strony.

Na stronie głównej cometweb.io hamulcem LCP okazał się JavaScript ładowany przed pierwszym renderem, a pomiar przed i po opisałem w tekście o danych laboratoryjnych i CrUX. Tłumaczę tam też, czemu laboratorium rzadko zgadza się z danymi z pola, których używa Google, i co to zmienia w kolejności napraw.

• Kompresuj obrazy w TinyPNG albo Squoosh, a na WordPressie wtyczką (ShortPixel, Imagify), i używaj formatów WebP i AVIF.
• Ładuj obrazy i media dopiero przy przewinięciu (loading="lazy"), ale nie na obrazie, który jest elementem LCP.
• Postaw CDN, bo na przykład Cloudflare (darmowy plan wystarczy na start) serwuje zasoby z serwera najbliższego użytkownikowi.
• Minifikuj CSS, JS i HTML, czyli wytnij z kodu zbędne znaki, na przykład spacje i komentarze.

Szczególnie sprawdź zalecenia dotyczące render-blocking resources, excessive DOM i enormous network payloads. Przewodnik po szybkości strony pokazuje, jak odróżnić przyczynę problemu od samej metryki, a w Insight kolejność napraw układa moduł wydajności.

Strona działa na telefonie (mobile-first indexing)

Google stosuje mobile-first indexing, więc podstawą oceny i rankingu jest mobilna wersja strony. Strona, która świetnie wygląda na komputerze, a na telefonie jest nieczytelna, dla Google jest słaba.

• Testuj responsywność w kilku rozdzielczościach, na przykład w Chrome DevTools (F12 > przełącznik urządzenia mobilnego), bez wychodzenia z przeglądarki.
• Daj przyciskom i linkom co najmniej 48x48 px i odstępy, żeby nikt nie klikał ich przypadkiem.
• Ustaw główny tekst na telefonie na minimum 16 px, bo mniejszy wymusza powiększanie.

Adresy URL są krótkie, opisowe i blisko strony głównej

Czytelny URL pomaga użytkownikowi zorientować się, jakiej strony dotyczy link. Słowa w adresie mogą także informować wyszukiwarkę o temacie podstrony. Przykładowy adres www.domena.pl/blog/techniczne-seo opisuje temat lepiej niż www.domena.pl/?p=12345. Nie oznacza to jednak, że długość lub liczba słów w URL-u przesądza o pozycji strony.

• Oddzielaj słowa myślnikami, które Google zaleca zamiast podkreśleń, bo łatwiej z nich odczytać osobne słowa.
• Unikaj znaków specjalnych i wielkich liter, bo prosty adres łatwiej zaindeksować i udostępnić.
• Trzymaj płaską architekturę. Każda ważna strona powinna być 2–3 kliknięcia od strony głównej, bo im głębiej ją ukryjesz, tym mniej „soku SEO” do niej dociera. Głębokość pokaże crawler, np. kolumna Crawl Depth w Screaming Frogu.

Cała strona działa na HTTPS

Chrome od lat oznacza strony bez SSL jako „niezabezpieczone”, a HTTPS jest częścią page experience, które biorą pod uwagę systemy rankingowe Google, a wdrożenie nic nie kosztuje.

• Weź bezpłatny certyfikat Let’s Encrypt, który większość hostingów instaluje jednym kliknięciem.
• Przełącz na HTTPS linki wewnętrzne i zasoby (obrazy, skrypty).
• Przekieruj 301 każdy adres HTTP na HTTPS, bez wyjątków, bo inaczej Google widzi dwie wersje tej samej strony.

Sprawdzisz to poleceniem curl -I http://domena.pl: ma zwrócić 301 z nagłówkiem Location na adres z https. Stan całej witryny pokaże raport HTTPS w Search Console.

Każda treść ma jeden adres kanoniczny

Zduplikowane treści to jeden z najczęstszych problemów technicznych i powstają zwykle nieumyślnie, przez warianty URL (z www i bez, z ukośnikiem na końcu i bez), parametry filtrowania albo wersje językowe. Jak wskazać Google preferowany adres, opisuje dokumentacja Google o kanonikalizacji.

• Oznacz oryginał tagiem rel=canonical, który mówi Google, którą wersję strony zaindeksować.
• Znajdź duplikaty w Screaming Frog albo Siteliner.
• Wybierz jedną wersję adresu i przekieruj pozostałe przez 301.

Po zmianie adresów porównaj w GSC „Kanoniczny zadeklarowany przez użytkownika” z polem „Kanoniczny wybrany przez Google”, bo gdy się różnią, Google wybrał wersję za ciebie. Jak wykryć konflikt tych sygnałów i przejść całą migrację adresów, pokazuję w artykule o canonical, sitemap i robots.txt.

W sklepach duplikaty rzadko biorą się z kopiowanego tekstu, bo mnożą je filtry, które tworzą adresy z tą samą listą produktów, i warianty produktu. Audyt SEO sklepu internetowego opisuje, jak policzyć te adresy i którą wersję zostawić w indeksie.

Dane strukturalne opisują widoczną treść (rich snippets)

Dane strukturalne „tłumaczą” Google, czym są konkretne elementy strony, a część typów kwalifikuje stronę do wyników rozszerzonych, takich jak oceny w gwiazdkach, ceny produktów, przepisy czy okruszki nawigacyjne. JSON-LD ma opisywać to, co czytelnik widzi, bo wytyczne Google dla danych strukturalnych każą oznaczać tylko widoczną treść, więc ocena albo cena obecna wyłącznie w znacznikach łamie zasady.

Wyniki rozszerzone FAQ i HowTo zostały wycofane i we wrześniu 2026 nie ma ich już w galerii Google. Oba typy dalej opisują treść, ale Google nie wyświetla już dla nich wyniku rozszerzonego.

• Standard Schema.org obsługują Google, Bing i Yahoo, a najczęściej używane typy to Article, Product i LocalBusiness.
• Na WordPressie dodasz dane strukturalne wtyczką (Yoast SEO, Rank Math) bez pisania kodu, a na stronie budowanej na zamówienie wstaw JSON-LD w sekcji <head>.

Schema validator sprawdza składnię i strukturę danych, schema checker pomaga znaleźć typowe problemy, a Google Rich Results Test sprawdza kwalifikację do wybranych wyników rozszerzonych. Żadne z tych narzędzi nie gwarantuje rich result ani wyższej pozycji.

Cały proces opisałem w glossary danych strukturalnych i w artykule Schema Validator i Schema Checker. Moduł SEO w Insight wykrywa JSON-LD na publicznej stronie i wskazuje problemy, które da się zweryfikować automatycznie, ale ostatnie słowo ma walidator Google.

Narzędzia do audytu technicznego SEO

Do audytu technicznego wystarczą cztery narzędzia, a trzy z nich są darmowe albo mają darmową wersję.

Ja bym zaczął od Search Console i crawlera, bo Search Console pokazuje, co widzi Google, a crawler, co widzi robot idący po twoich linkach. W Insight połączysz audyt SEO z modułem Crawl, gdy chcesz zestawić sygnały pojedynczego HTML-a z przepływem adresów, w tym z redirectami i sitemapą. Zakres obu modułów opisuje metodologia audytu.

Insight uzupełnia Search Console i pełny crawler. Najbardziej przydaje się przy kroku 8, bo zestawia dwa crawle i pokazuje nowe błędy, naprawione adresy i zmienione statusy.

Na koniec: od czego zacząć techniczne SEO

Większość błędów technicznych naprawiasz raz, a potem tylko pilnujesz, żeby nie wróciły. Najpierw napraw krytyczne błędy, a resztę w tej kolejności:

Treść dopniesz z przewodnikiem po on-page SEO, a kroki 2–4 i retest zautomatyzujesz w Insight. Zacznij darmowy audyt w CometWeb Insight.

Robisz audyt w innej kolejności i u ciebie działa? Napisz do mnie na maciej@cometweb.io.

Najczęstsze pytania

Źródła

1. Google Search Central: SEO Starter Guide, podstawy odkrywania, indeksowania i opisu treści.
2. Google Search Central: robots.txt, zakres i ograniczenia reguł robots.
3. Google Search Central: kanonikalizacja, wybór preferowanego adresu.
4. web.dev: Core Web Vitals, metryki doświadczenia i progi jakości.
5. Google Search Central: page experience, miejsce Core Web Vitals i HTTPS w page experience.
6. Pomoc Search Console: raport robots.txt, które pliki robots.txt Google znalazł i jakie błędy napotkał.
7. Google Search Central: struktura adresów URL, zalecenie myślników zamiast podkreśleń.
8. Google Search Central: wytyczne dla danych strukturalnych, oznaczanie wyłącznie widocznej treści.

Artykuł zaktualizowano 7 września 2026: doszedł zakres pełnego audytu SEO i przebieg krok po kroku, obok wcześniejszej części technicznej. Poprawki zgodne z dokumentacją Google (raport robots.txt, page experience, HTTPS) weszły 24 września 2026.