Strona może mieć dobry content, sensowną ofertę i poprawny kod, a mimo to nie zdobywać widoczności, jeśli Google nie indeksuje właściwych adresów albo indeksuje wersje, których nie powinno. Właśnie dlatego audyt pozycjonowania zaczynam od techniki i indeksacji, bo tam zwykle ukrywają się błędy blokujące dalszy wzrost.
W tym tekście pokazuję, co sprawdzić, jak czytać wyniki i które problemy naprawdę mają znaczenie: od robots.txt i sitemap, przez canonicale i noindex, po Search Console, logi serwera i budżet crawlowania. Jeśli chcesz zrozumieć, dlaczego strona nie rośnie mimo publikowania treści, to jest właściwy punkt startowy.Najważniejsze rzeczy o audycie i indeksacji
- Dobry audyt SEO nie kończy się na liście błędów, tylko prowadzi do konkretnych decyzji: co blokuje crawl, co psuje indeksację i co trzeba wdrożyć najpierw.
- robots.txt ogranicza crawlowanie, ale nie jest narzędziem do ukrywania stron z wyników wyszukiwania.
- noindex, canonical, sitemap i linkowanie wewnętrzne działają razem, a nie osobno.
- W Google Search Console najwięcej wnoszą raport indeksacji, URL Inspection i dane o błędach, ale przy większych serwisach warto dorzucić logi serwera.
- Na małej stronie audyt trwa zwykle kilka dni, na większym sklepie lub portalu 2-4 tygodnie, a koszt w Polsce najczęściej zaczyna się od ok. 1200-3000 zł netto.
- Najlepszy raport kończy się backlogiem wdrożeniowym z priorytetami, a nie samymi screenami i ogólnikami.
Co naprawdę daje audyt widoczności strony
Ja traktuję taki audyt jak diagnostykę, nie jak formalność. Najpierw sprawdzam, czy roboty w ogóle mogą wejść na stronę, czy strony trafiają do indeksu i czy Google wybiera właściwe wersje adresów. Dopiero później oceniam treści, linkowanie i zgodność z intencją użytkownika.
W praktyce to oznacza, że audyt odpowiada na trzy pytania: co Google widzi, czego nie widzi i dlaczego widzi nie to, co trzeba. To ważne zwłaszcza wtedy, gdy serwis przeszedł migrację, ruch spadł po wdrożeniu nowej wersji strony albo sklep zaczął generować tysiące parametrów, filtrów i duplikatów. Sama publikacja nowych treści nie rozwiąże takiego problemu, jeśli fundament indeksacji jest krzywy.
Przeczytaj również: Pozycjonowanie organiczne - Jak naprawić błędy i zwiększyć widoczność
Kiedy traktuję go jako priorytet
- po migracji CMS-a, domeny lub struktury URL,
- po nagłym spadku ruchu organicznego,
- gdy nowe podstrony długo nie pojawiają się w indeksie,
- gdy sklep lub portal ma dużo filtrów, paginacji i adresów parametrycznych,
- gdy strona oparta na JavaScript zachowuje się inaczej dla użytkownika i dla bota.
Co sprawdzam w indeksacji i technicznym fundamencie
Google Search Central wyraźnie rozróżnia crawlowanie i indeksowanie: robots.txt służy do kontrolowania dostępu robotów, a nie do ukrywania treści z wyników. Jeśli chcę wykluczyć stronę z indeksu, używam noindex albo zabezpieczenia dostępu, a nie liczę na samo zablokowanie crawla.
Na tym etapie patrzę przede wszystkim na to, czy Google ma szansę zobaczyć właściwe zasoby, zrozumieć strukturę i wybrać jedną, spójną wersję każdej ważnej podstrony. W 2026 to nadal fundament, szczególnie w serwisach technologicznych, sklepach i portalach z dynamiczną zawartością.
| Obszar | Co sprawdzam | Co zwykle psuje wynik |
|---|---|---|
| robots.txt | Czy nie blokuje ważnych katalogów, CSS, JS i zasobów potrzebnych do renderowania | Przypadkowy Disallow, zbyt szerokie reguły, chaos po zmianach wdrożeniowych |
| noindex | Czy nie został zostawiony na stronach, które mają rankować | Tag po środowisku testowym, kopiowanie szablonu bez kontroli |
| canonical | Czy wskazuje właściwą wersję adresu i nie miesza Google w interpretacji duplikatów | Sprzeczne canonicale, wersje URL z parametrami, wskazywanie 404 lub niewłaściwego szablonu |
| sitemap.xml | Czy zawiera adresy kanoniczne, aktualne i rzeczywiście warte indeksacji | Adresy 404, noindex, przekierowania, stare podstrony po migracji |
| Linkowanie wewnętrzne | Czy najważniejsze strony są osiągalne z sensownej liczby kliknięć | Sierotki, zbyt płytkie menu, ukryte kategorie, słabe linki kontekstowe |
| Renderowanie JS | Czy bot widzi treść po renderze, a nie tylko pusty szkielet HTML | Treść ładowana po interakcji, błędy hydracji, zasoby blokowane przez skrypty |
| Logi i crawl stats | Na co bot faktycznie wydaje budżet crawlowania | Parametry, filtry, paginacja, niepotrzebne duplikaty i ślepe zaułki |
W robots.txt jest jeszcze jedna rzecz, o której ludzie często zapominają: Google podaje limit pliku na poziomie 500 KiB. Na dużych serwisach ten szczegół ma znaczenie, bo przeładowany plik przestaje być wygodnym narzędziem kontroli, a zaczyna być źródłem błędów. Ja wolę prostą, czytelną logikę niż rozbudowane reguły, których nikt potem nie kontroluje.
Jeśli strona korzysta z JavaScriptu, sprawdzam też, czy najważniejsza treść jest dostępna bez „pomocy” użytkownika. To szczególnie ważne w serwisach technicznych i e-commerce, gdzie filtracja i dynamiczne moduły potrafią wyglądać dobrze na ekranie, ale dla bota są słabo czytelne. Gdy fundament jest opisany, można przejść do procesu.
Jak wygląda sensowny proces krok po kroku
Nie robię audytu od przypadkowego klikania po stronie. Najpierw zbieram dane, potem porównuję je między narzędziami, a dopiero na końcu wyciągam wnioski. Dzięki temu nie mylę jednorazowego błędu z powtarzalnym problemem systemowym.
- Zaczynam od danych wejściowych: Google Search Console, GA4, mapa strony, lista szablonów i dostęp do CMS-a lub repozytorium.
- Mapuję strukturę serwisu, czyli to, które typy podstron mają realnie pracować na ruch i konwersję.
- Uruchamiam crawl i porównuję jego wynik z sitemapą oraz z tym, co faktycznie trafia do indeksu.
- Sprawdzam blokady techniczne: robots.txt, noindex, canonical, przekierowania, błędy 4xx/5xx i łańcuchy 301.
- Weryfikuję renderowanie oraz linkowanie wewnętrzne, szczególnie na stronach kluczowych dla biznesu.
- Układam priorytety: co daje szybki efekt, co wymaga wdrożenia developerskiego, a co jest tylko kosmetyką bez wpływu na widoczność.
W tym miejscu ważna jest dyscyplina. Dobry audyt nie polega na opisaniu stu rzeczy, tylko na rozróżnieniu kilku naprawdę ważnych. Ja zawsze pytam: czy ten problem blokuje indeksację, osłabia interpretację treści, czy tylko wygląda groźnie w raporcie? To pytanie oszczędza budżet i czas zespołu.
Jakie problemy najczęściej blokują indeksowanie
Najczęściej nie chodzi o jeden wielki błąd, tylko o kilka drobnych decyzji, które razem robią bałagan. Google Search Console jest tu bardzo pomocne, bo pokazuje, czy adres został znaleziony, przeskanowany, odrzucony przez canonical, czy uznany za niewystarczająco wartościowy. W przypadku pojedynczych URL-i narzędzie URL Inspection dobrze wyjaśnia, dlaczego konkretny adres nie wszedł do indeksu.
Poniżej zestawiam problemy, które widzę najczęściej. To nie jest pełna lista wszystkiego, co może pójść nie tak, ale właśnie te rzeczy najczęściej robią największą różnicę.
| Objaw | Najczęstsza przyczyna | Co robię najpierw |
|---|---|---|
| „Discovered - currently not indexed” | Google zna adres, ale odkłada go na później, bo nie ma silnych sygnałów odkrycia lub priorytetu | Sprawdzam linkowanie wewnętrzne, sitemapę i to, czy URL jest naprawdę ważny dla serwisu |
| „Crawled - currently not indexed” | Bot widział stronę, ale nie uznał jej za wartą indeksacji lub trafił na duplikację | Weryfikuję jakość treści, canonical, podobieństwo szablonów i sygnały kanoniczności |
| Zaindeksowana jest zła wersja adresu | Sprzeczne canonicale, parametry URL, mieszanie wersji www i non-www albo http i https | Porządkuję preferowaną wersję, przekierowania i spójność linkowania wewnętrznego |
| Po migracji znikają ważne podstrony | Brak mapy przekierowań, pomieszane statusy 301/302, błędy 404 i stare linki | Porównuję stare i nowe adresy, szukam łańcuchów oraz luk w przekierowaniach |
| Indeks puchnie od filtrów i parametrów | Faceted navigation, sortowania i warianty generują tysiące mało wartościowych URL-i | Ograniczam indeksację wersji technicznych, ustawiam canonicale i porządkuję sitemapę |
| Strona wygląda dobrze, ale nie rankuje | Treść jest dostępna wizualnie, ale słabo powiązana z intencją lub osłabiona technicznie | Sprawdzam dopasowanie do zapytania, strukturę nagłówków i jakość linkowania |
W praktyce okazuje się, że problem rzadko siedzi w jednym tagu. Często to mieszanka słabego linkowania, błędnego canonicala i nadmiaru adresów technicznych, które rozpraszają sygnały. Dlatego przy większych serwisach nie ufam samemu crawlerykowi; logi serwera i raporty indeksacji pokazują, jak bot zachowuje się naprawdę, a nie tylko jak powinien się zachowywać na papierze.
Po zidentyfikowaniu problemów naturalnie pojawia się pytanie o koszt i sens zlecenia całego procesu na zewnątrz. Tu też widzę sporo nieporozumień.
Ile kosztuje audyt i jak odróżnić dobrą ofertę od zbyt ogólnej
W Polsce ceny są mocno zależne od skali serwisu, liczby szablonów, dostępu do danych oraz tego, czy audyt ma obejmować same rekomendacje, czy także konsultację wdrożeniową. W 2026 za prosty audyt strony firmowej najczęściej widuję widełki od około 1200 do 3000 zł netto, za średni sklep lub serwis 3000-8000 zł netto, a za duże projekty z analizą logów i rozbudowaną diagnozą 8000-20 000+ zł netto.
| Typ projektu | Zakres | Czas | Orientacyjna cena |
|---|---|---|---|
| Mała strona firmowa | Podstawowa technika, indeksacja, sitemap, podstawowe rekomendacje | 3-5 dni | 1200-3000 zł netto |
| Średni sklep lub serwis | Szablony, filtry, canonicale, crawl budget, analiza treści i struktury | 1-2 tygodnie | 3000-8000 zł netto |
| Duży e-commerce lub portal | Logi serwera, renderowanie, migracje, indeksacja na wielu typach podstron, warsztat wdrożeniowy | 2-4 tygodnie | 8000-20 000+ zł netto |
Jeśli ktoś proponuje kompleksowy audyt dużego serwisu za symboliczną kwotę, najczęściej dostajesz ogólną checklistę, a nie diagnozę. Ja patrzę nie tylko na cenę, ale też na to, czy w ofercie jest priorytetyzacja, opis wpływu na biznes, lista URL-i lub szablonów oraz sposób weryfikacji po wdrożeniu. Bez tego raport bywa efektowny wizualnie, ale słaby operacyjnie.
Równie ważne są terminy. Mała strona może być sensownie przeanalizowana w kilka dni, ale duży sklep bez logów i bez dostępu do danych nie powinien być „diagnozowany” na szybko. To zwykle kończy się błędnymi wnioskami albo zaleceniami, które brzmią poprawnie, lecz niczego realnie nie zmieniają.
Co powinno zostać po audycie, żeby naprawdę ruszyć z miejsca
Najlepszy rezultat nie wygląda jak długi PDF, tylko jak uporządkowany plan działania. Ja oczekuję po audycie trzech rzeczy: priorytetów, właścicieli zadań i sposobu weryfikacji. Bez tego zespół wraca po kilku tygodniach do tych samych problemów, tylko już z ładniejszym dokumentem w folderze.
- lista problemów uporządkowana według wpływu na indeksację i ruch,
- wskazanie konkretnych szablonów, sekcji lub typów URL-i, a nie tylko pojedynczych przykładów,
- propozycja zmian technicznych i treściowych z rozróżnieniem na szybkie oraz strukturalne,
- plan walidacji po wdrożeniu, najlepiej z ponownym sprawdzeniem w Search Console i crawlach kontrolnych,
- krótka interpretacja: co da efekt od razu, a co trzeba będzie monitorować przez kolejne tygodnie.
Jeżeli miałbym wskazać jeden błąd, który najczęściej marnuje dobrze zrobiony audyt, to byłby nim brak kolejności działań. Sama diagnoza nie poprawia widoczności. Poprawia ją dopiero wdrożenie tam, gdzie indeksacja blokuje wzrost najbardziej, a potem konsekwentna kontrola efektów.
W praktyce zaczynam zawsze od tego samego: najważniejsze adresy mają być widoczne, zrozumiałe dla bota i spójne z intencją użytkownika. Kiedy ten warunek jest spełniony, treści i linkowanie zaczynają pracować znacznie lepiej, a cały SEO przestaje przypominać zgadywanie.
