Techniczny audyt SEO strony – checklista 2026

Treści są dopracowane, linki przychodzą, a strona od miesięcy stoi w miejscu albo zjeżdża w wynikach. Znamy ten scenariusz z dziesiątek kont – i w większości przypadków winowajcą nie jest „słaby content”, tylko coś, czego nie widać gołym okiem: robot Google nie potrafi porządnie przejść po stronie albo nie wpuszcza jej do indeksu. Dlatego zanim dorzucisz kolejny artykuł, zrób techniczny audyt SEO – to on wyłapuje ciche błędy, które kasują efekty całej reszty pracy.

Poniżej rozkładam audyt techniczny strony www na czynniki pierwsze: czym różni się od ogólnego audytu, jak działa crawlowanie i indeksacja, co mówią kody odpowiedzi serwera i jak sprawdzić dane strukturalne. Dostajesz konkretną checklistę i listę narzędzi – dokładnie to, czego używamy, wchodząc na nowe konto.

Spis treści

Czym jest techniczny audyt SEO i czym różni się od ogólnego

Ogólny audyt SEO patrzy szeroko: słowa kluczowe, treści, linki przychodzące, konkurencja. Techniczny audyt SEO schodzi pod maskę i sprawdza jedną rzecz – czy roboty wyszukiwarki potrafią Twoją stronę odnaleźć, przejść, zrozumieć i wpuścić do indeksu. To fundament. Najlepszy tekst świata nie zarobi ani jednego wejścia, jeśli robot dostanie do niego zakaz wstępu.

Najprościej zobrazować to tak: ogólny audyt pyta „czy mówimy do ludzi tym, czego szukają”, a audyt techniczny pyta „czy Google w ogóle widzi to, co mówimy”. Jedno bez drugiego nie działa. Jeżeli chcesz szerszego spojrzenia na całość, opisaliśmy je w artykule jak zrobić audyt SEO – tutaj skupiam się wyłącznie na warstwie technicznej.

Cztery filary, na których stoi cała ta warstwa, to crawlowanie, indeksacja, kody odpowiedzi serwera i dane strukturalne. Przejdziemy przez każdy po kolei, bo to one decydują o tym, czy reszta SEO ma na czym się oprzeć.

Crawlowanie – jak robot czyta Twoją stronę

Crawlowanie to moment, w którym Googlebot wchodzi na stronę i przechodzi po jej linkach, zbierając podstrony do późniejszej analizy. Jeśli nie dotrze do danej podstrony, ta po prostu dla wyszukiwarki nie istnieje. Dlatego pierwsze pytanie w każdym audycie brzmi: które adresy robot widzi, a których nie.

Crawlowaniem steruje przede wszystkim plik robots.txt oraz wewnętrzna struktura linków. Najgroźniejszy błąd, jaki regularnie spotykamy, to jedna linijka Disallow: / zostawiona po przenosinach z wersji testowej – blokuje całą domenę i potrafi tygodniami wycinać ruch, zanim ktokolwiek zauważy. Jak poprawnie ustawić ten plik, rozpisaliśmy w tekście o konfiguracji robots.txt.

Druga sprawa to crawl budget, czyli ile podstron robot jest skłonny przejść w danym czasie. Przy małej stronie firmowej to rzadko problem, ale przy sklepie z tysiącami filtrów, sortowań i parametrów w adresach robot potrafi marnować czas na śmieciowe URL-e zamiast na produkty. Temat rozwijamy w artykule o crawl budżecie i indeksacji.

Pro-tip: zanim cokolwiek zaczniesz naprawiać, wejdź w Google Search Console w raport „Statystyki indeksowania”. Jeśli widzisz, że robot codziennie odpytuje setki adresów z parametrami typu ?sort= albo ?filter=, masz przeciek crawl budżetu – to pierwsza rzecz do zatkania, zanim dosypiesz nowych treści.

Audyt indeksacji strony – co realnie siedzi w Google

Crawlowanie to wejście na stronę, indeksacja to wpisanie jej do „katalogu” wyszukiwarki. Można być przecrawlowanym i jednocześnie niezaindeksowanym – i właśnie ta luka jest sercem każdego audytu indeksacji strony. Robot był, zobaczył, ale podstrona nie trafiła do wyników. Powodów bywa kilka.

Najczęstsze blokery indeksacji, które wyłapujemy na kontach klientów:

  • Znacznik noindex zostawiony przypadkiem na podstronach, które mają się wyświetlać – klasyk po migracji ze środowiska testowego.
  • Błędny canonical wskazujący wszystkie podstrony na stronę główną, przez co Google traktuje cały serwis jak jedną stronę.
  • Cienka albo zduplikowana treść – wyszukiwarka crawluje, ocenia jako mało wartościową i świadomie nie indeksuje.
  • Strona osierocona – istnieje, ale nie prowadzi do niej żaden wewnętrzny link, więc robot dociera do niej rzadko lub wcale.

Jak to sprawdzić w praktyce? Raport „Strony” (dawniej „Pokrycie”) w Google Search Console pokazuje dokładnie, ile adresów jest zaindeksowanych, a ile odpadło – i z jakiego powodu. Z naszej praktyki to najczęściej pomijany ekran w całym SEO. Właściciel patrzy na ruch, a nie na to, że Google odrzuciło połowę podstron z adnotacją „Strona zeskanowana, obecnie bez indeksu”.

Pro-tip: wpisz w Google site:twojadomena.pl i porównaj liczbę wyników z liczbą podstron, które realnie chcesz mieć w indeksie. Duża różnica w którąkolwiek stronę to sygnał alarmowy – albo Google indeksuje śmieci (parametry, koszyk, wyszukiwarka wewnętrzna), albo nie widzi tego, co ważne.

Kody odpowiedzi serwera, których nie wolno ignorować

Za każdym razem, gdy robot lub użytkownik prosi o adres, serwer odpowiada kodem statusu. Te trzy cyfry to dla SEO sygnalizacja świetlna – i połowa cichych problemów technicznych siedzi właśnie tutaj. Najważniejsze, które sprawdzamy w każdym audycie:

Kod Co oznacza Co z tym zrobić
200 OK, strona działa poprawnie Stan docelowy dla wszystkich ważnych adresów
301 Trwałe przekierowanie Używaj przy zmianie adresów – przekazuje moc SEO
302 Tymczasowe przekierowanie Częsty błąd zamiast 301 – sprawdź i popraw
404 Strona nie istnieje Dopuszczalne, ale nie dla adresów z linkami i ruchem
5xx Błąd serwera Pali się czerwone światło – reaguj natychmiast

Najwięcej szkody robią dwa scenariusze. Pierwszy to łańcuchy przekierowań – adres A kieruje na B, B na C, C na D. Każdy przeskok rozmywa moc linków i spowalnia robota. Drugi to 404 na adresach, które wciąż mają linki przychodzące – to dziura, przez którą ucieka wartość zbudowana latami. Jak robić to poprawnie, opisaliśmy w artykule o przekierowaniach 301 w SEO.

Pamiętaj też o spójności wersji adresu. Strona dostępna jednocześnie pod http i https, z www i bez, bez wymuszonego przekierowania na jedną wersję, to klasyczna duplikacja, która rozprasza sygnały rankingowe na cztery różne adresy zamiast jednego.

Dane strukturalne – schema, która daje przewagę w SERP

Dane strukturalne (schema.org, najczęściej w formacie JSON-LD) to dodatkowy opis, który podpowiada Google, czym jest dana podstrona: produktem, artykułem, firmą lokalną, przepisem, zbiorem pytań FAQ. Robot i bez nich zrozumie treść, ale ze schemą rozumie ją precyzyjniej – i częściej nagradza rozszerzonym wynikiem: gwiazdkami opinii, ceną, rozwijanymi pytaniami.

W audycie technicznym sprawdzamy dwie rzeczy: czy schema w ogóle jest oraz czy jest poprawnie wdrożona, bo błędny kod potrafi zaszkodzić bardziej niż jego brak. Najczęstsze typy, które wdrażamy u klientów, to LocalBusiness dla firm usługowych, Product dla sklepów i FAQPage dla artykułów i podstron usług. Szerzej o doborze i wdrożeniu piszemy w tekście o danych strukturalnych schema markup.

Pro-tip: nie wdrażaj schemy „na zapas” pod treść, której na stronie nie ma. Google traktuje znaczniki FAQ czy opinii niezgodne z widoczną zawartością jako naruszenie wytycznych – zamiast rozszerzonego wyniku możesz dostać ręczną karę. Schema ma opisywać to, co użytkownik faktycznie widzi.

Narzędzia do audytu technicznego SEO

Dobra wiadomość: zestaw narzędzi do audytu technicznego SEO, który wyłapie zdecydowaną większość problemów, jest w dużej części darmowy. Oto co realnie mamy otwarte przy każdym audycie:

  • Google Search Console – bezpłatne i niezastąpione. Raport „Strony” pokazuje stan indeksacji, „Statystyki indeksowania” – jak robot chodzi po serwisie, a „Dane strukturalne” – błędy w schemie. To pierwsze, co podłączamy na każdym koncie.
  • Screaming Frog SEO Spider – desktopowy crawler, który przechodzi stronę tak jak robot Google i w jednej tabeli pokazuje kody odpowiedzi, tagi title, meta description, znaczniki noindex, canonical i łańcuchy przekierowań. Do 500 adresów działa za darmo.
  • Test wyników z elementami rozszerzonymi Google – weryfikuje, czy Twoja schema jest poprawna i kwalifikuje się do rozszerzonego wyniku.
  • PageSpeed Insights / Lighthouse – mierzy szybkość i Core Web Vitals, które od dawna są czynnikiem rankingowym. Temat rozwijamy w artykule o Core Web Vitals i szybkości strony.

Płatne pakiety typu Ahrefs czy Senuto przydają się do monitoringu i analizy konkurencji, ale do samej warstwy technicznej zestaw Search Console plus Screaming Frog w zupełności wystarcza, żeby znaleźć to, co realnie blokuje ruch.

Checklista technicznego audytu SEO krok po kroku

Tak wygląda kolejność, w której przechodzimy przez stronę. Każdy punkt da się sprawdzić jednym z narzędzi powyżej – to konkretny przepis na to, jak zrobić audyt techniczny SEO bez zgadywania.

  1. Plik robots.txt – czy nie blokuje ważnych sekcji i czy wskazuje na mapę strony (sitemap).
  2. Mapa strony XML – czy istnieje, jest aktualna, zawiera tylko adresy ze statusem 200 i jest zgłoszona w Search Console.
  3. Stan indeksacji – raport „Strony” w GSC: ile zaindeksowanych, ile wykluczonych i z jakiego powodu.
  4. Znaczniki noindex i canonical – czy nie ma ich tam, gdzie nie powinno, i czy canonical wskazuje na właściwe adresy.
  5. Kody odpowiedzi serwera – crawl Screaming Frogiem: wyłapanie 404, 5xx i łańcuchów przekierowań.
  6. Wersje adresu – jedna spójna wersja (https + wybrana forma www), reszta przekierowana 301.
  7. Tagi title i meta description – unikalne, w odpowiedniej długości, bez duplikatów. Więcej w tekście o meta tagach title i description.
  8. Dane strukturalne – obecne, poprawne, zgodne z widoczną treścią.
  9. Szybkość i Core Web Vitals – LCP, CLS i INP w zielonych progach, zwłaszcza na urządzeniach mobilnych.
  10. Wersja mobilna – Google indeksuje mobile-first, więc to ona jest punktem odniesienia, nie desktop.

Przejście tej listy zajmuje przy małej stronie kilka godzin, przy sklepie – kilka dni. Jeśli wolisz oddać to w ręce zespołu, który robi to na co dzień, tym właśnie zajmujemy się w ramach audytu strony WWW.

Ciche błędy techniczne SEO, które blokują ruch

Najgroźniejsze błędy techniczne SEO są ciche – nie wywalają strony, nie pokazują komunikatu, po prostu po cichu duszą widoczność. Oto te, na które wpadamy najczęściej, przejmując konta po poprzednich wykonawcach:

  • Cała domena pod noindex po migracji. Strona ruszyła na produkcję, ale ustawienie z wersji testowej zostało. Ruch organiczny spada do zera w kilka tygodni, a nikt nie wie dlaczego.
  • Canonical wszystkiego na stronę główną. Wtyczka albo motyw ustawia jeden canonical dla całego serwisu. Google indeksuje wtedy de facto jedną podstronę.
  • Indeksacja śmieciowych adresów. Wyniki wyszukiwarki wewnętrznej, koszyk, adresy z parametrami filtrów – lądują w Google, rozmywając crawl budżet i osłabiając wartościowe podstrony.
  • Mapa strony pełna martwych adresów. Sitemap z setkami URL-i zwracających 404 albo przekierowania to sygnał dla Google, że nie panujesz nad serwisem.
  • Brak linkowania wewnętrznego do nowych treści. Świeży artykuł bez żadnego linka z reszty serwisu to strona osierocona – robot dociera do niej z opóźnieniem albo wcale.

Łączy je jedno: żaden nie boli od razu, więc wszystkie zwykle siedzą miesiącami. Dlatego techniczny audyt warto powtarzać cyklicznie, a nie tylko raz na starcie. Jeśli prowadzisz też kampanie płatne, ta sama logika dotyczy stron docelowych – o tym, jak przeglądamy konto reklamowe, piszemy w tekście o audycie Google Ads.

W Social Plan techniczny audyt SEO to punkt startowy każdej nowej współpracy – bo to właśnie warstwa techniczna decyduje, czy reszta SEO i reklamy ma na czym pracować. Jeśli Twoja strona stoi w miejscu mimo dobrych treści, napisz do nas. Przejdziemy przez checklistę i powiemy wprost, co blokuje ruch.

Najczęściej zadawane pytania

Czym techniczny audyt SEO różni się od zwykłego audytu SEO?
Zwykły audyt patrzy szeroko – na słowa kluczowe, treści, linki i konkurencję. Techniczny audyt SEO sprawdza wyłącznie warstwę, której nie widać: czy robot Google potrafi stronę przejść, zrozumieć i wpuścić do indeksu. To fundament, bo bez niego najlepsze treści nie zarobią ruchu.

Jak często robić techniczny audyt strony www?
Pełny audyt warto zrobić na starcie współpracy i po każdej większej zmianie – migracji, przebudowie szablonu, zmianie adresów. Poza tym wystarczy przegląd raz na kwartał oraz bieżący monitoring raportu „Strony” w Google Search Console, który sam sygnalizuje nowe problemy.

Jakie narzędzia do audytu technicznego SEO wystarczą na początek?
Do większości problemów wystarczą dwa darmowe narzędzia: Google Search Console (stan indeksacji, statystyki indeksowania, błędy schemy) i Screaming Frog SEO Spider do 500 adresów (kody odpowiedzi, tagi, przekierowania). Płatne pakiety przydają się głównie do monitoringu i analizy konkurencji.

Co to znaczy, że strona jest zeskanowana, ale niezaindeksowana?
To sytuacja, w której robot wszedł na podstronę, ale świadomie nie dodał jej do wyników – najczęściej przez cienką lub zduplikowaną treść, błędny canonical albo znacznik noindex. Audyt indeksacji strony polega właśnie na zamykaniu tej luki między crawlowaniem a indeksem.

Czy mogę zrobić techniczny audyt SEO samodzielnie?
Na podstawowym poziomie tak – checklista z tego artykułu plus Search Console i Screaming Frog wyłapią większość błędów. Schody zaczynają się przy interpretacji canonicali, łańcuchów przekierowań, crawl budżetu i danych strukturalnych. Tu zwykle warto oddać temat komuś, kto robi to na wielu kontach.