Strona, która wygląda dobrze na pierwszy rzut oka, może jednocześnie tracić dziesiątki pozycji w wynikach wyszukiwania z powodu błędów niewidocznych dla zwykłego użytkownika. Uszkodzone przekierowania, zduplikowane tagi canonical, nieindeksowane podstrony — to problemy, które audyt techniczny SEO wyłapuje zanim przerodzą się w poważny spadek ruchu organicznego. Z naszych obserwacji wynika, że około 70% witryn, które trafiają do analizy, ma co najmniej 3-4 powtarzające się błędy techniczne wpływające na crawlowanie i indeksację. Ten artykuł omawia najczęstsze z nich i pokazuje konkretne sposoby naprawy — bez ogólników, z konkretnymi parametrami i narzędziami.
Z naszego artykułu dowiesz się:
Czym jest audyt techniczny SEO i kiedy go przeprowadzić
Audyt techniczny SEO to systematyczny przegląd infrastruktury witryny pod kątem jej dostępności dla robotów wyszukiwarek. Nie chodzi o treść ani o linki — skupiamy się wyłącznie na warstwie technicznej: jak serwer odpowiada na zapytania, czy strony są prawidłowo indeksowane, jak szybko się ładują i czy struktura URL-i jest logiczna.
Sygnały wskazujące na potrzebę audytu strony
Nie trzeba czekać na dramatyczny spadek ruchu. Są wcześniejsze sygnały ostrzegawcze, które sugerują narastające problemy techniczne SEO. Spadek liczby zaindeksowanych stron w Google Search Console o więcej niż 10-15% w ciągu miesiąca to wyraźny alarm. Podobnie nagły wzrost błędów crawlowania w raporcie „Strony" (dawniej „Stan") — jeśli liczba stron z błędami przekracza 5% ogółu, warto działać natychmiast.
Regularność też ma znaczenie. Przy witrynach e-commerce z tysiącami podstron rekomendujemy pełny audyt co kwartał. Mniejsze serwisy z 50-200 stronami mogą wystarczająco dobrze funkcjonować przy audycie raz na pół roku, o ile nie wdrażają dużych zmian technologicznych. Migracja na nowy CMS, zmiana struktury URL-i lub wdrożenie nowego szablonu — każda z tych sytuacji wymaga audytu natychmiast po zakończeniu prac, a najlepiej także przed nimi, żeby mieć punkt odniesienia.
Narzędzia do przeprowadzenia audytu technicznego
Screaming Frog SEO Spider (wersja darmowa crawluje do 500 URL-i) pozwala przeskanować witrynę w sposób zbliżony do robota Google. Sitebulb oferuje bardziej wizualne raporty z priorytetyzacją błędów. Google Search Console pozostaje niezastąpione jako źródło danych bezpośrednio od wyszukiwarki — to jedyne narzędzie, które pokazuje rzeczywisty stan indeksacji, a nie tylko symulację crawlera. Ahrefs Webmaster Tools i Semrush Site Audit dobrze sprawdzają się jako uzupełnienie, ale nie zastępują ręcznej weryfikacji krytycznych elementów.
Błędy crawlowania — jak roboty tracą dostęp do treści
Crawl errors to jedna z najczęstszych kategorii problemów wykrywanych podczas audytu strony. Jeśli Googlebot nie może dotrzeć do podstrony lub otrzymuje błędną odpowiedź serwera, ta strona po prostu nie pojawi się w wynikach wyszukiwania — niezależnie od jakości treści.
Błędy 404 (strona nie istnieje) na pojedynczych podstronach to normalny element życia witryny. Problem zaczyna się, gdy takich błędów są setki, a prowadzą do nich linki wewnętrzne. Oznacza to, że budżet crawlowania jest marnowany na próby odwiedzenia stron, które nie istnieją. Naprawę zaczynamy od identyfikacji źródła linków — w Screaming Frog wystarczy sprawdzić kolumnę „Inlinks" dla każdego URL-a z kodem 404. Następnie albo przywracamy brakującą stronę, albo ustawiamy przekierowanie 301 na najbliższy tematycznie odpowiednik, albo usuwamy wewnętrzny link prowadzący donikąd.
Błędy 5xx (błędy serwera) są poważniejsze, bo dotyczą infrastruktury. Jeśli Googlebot regularnie otrzymuje odpowiedzi 500 lub 503, może zmniejszyć częstotliwość crawlowania całej domeny. Przy powtarzających się błędach 5xx sprawdzamy logi serwera (access log i error log) pod kątem wzorca — czy błędy pojawiają się w konkretnych godzinach (przeciążenie), przy konkretnych URL-ach (błąd w kodzie) czy losowo (problem z hostingiem).
Osobną kategorią błędów crawlowania są problemy z plikiem robots.txt. Zdarza się, że reguła Disallow blokuje przypadkowo całe katalogi z wartościową treścią. Widzieliśmy przypadek, gdzie po migracji CMS plik robots.txt nadal zawierał regułę Disallow: /staging/, a nowa struktura URL-i zaczynała się od /staging-area/ — efektem była blokada ponad 200 podstron przez trzy miesiące, zanim ktokolwiek to zauważył.
Duplikacja treści i problemy z tagami canonical
Duplikacja treści to problem, który rzadko wynika z celowego kopiowania. Najczęściej powstaje z powodu parametrów URL, wersji z www i bez, protokołów HTTP i HTTPS działających równolegle, oraz stron paginacji lub filtrów generujących setki wariantów tego samego contentu.
Wyobraźmy sobie sklep internetowy z 500 produktami i 12 filtrami kategorii. Każda kombinacja filtrów generuje osobny URL. Efekt? Zamiast 500 stron do zaindeksowania, Googlebot widzi 6000 adresów z w dużej mierze powtarzającą się treścią. Budżet crawlowania wyczerpuje się na warianty filtrów, a właściwe strony produktów tracą pozycje.
Rozwiązanie opiera się na trzech mechanizmach stosowanych łącznie:
Typowy błąd, który spotykamy regularnie: tag canonical wskazuje na stronę z kodem 404 lub na stronę z przekierowaniem 301. Google traktuje taki canonical jako sygnał, nie dyrektywę — może go zignorować, ale częściej po prostu obniża zaufanie do sygnałów z całej domeny. Weryfikację spójności canonicali najłatwiej przeprowadzić w Screaming Frog: zakładka „Canonicals" → filtr „Non-Indexable Canonical" pokaże wszystkie problematyczne przypadki.
Szybkość ładowania i Core Web Vitals — błędy techniczne strony z realnym wpływem na ranking
Od 2021 roku Google oficjalnie uwzględnia Core Web Vitals jako czynnik rankingowy. Trzy metryki — LCP (Largest Contentful Paint), INP (Interaction to Next Paint, od marca 2024 zastąpił FID) i CLS (Cumulative Layout Shift) — mierzą odpowiednio czas ładowania głównego elementu, responsywność na interakcje i stabilność wizualną strony.
| Metryka | Dobry wynik | Wymaga poprawy | Słaby wynik | |
| LCP | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s | |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms | |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Najczęstszy problem z LCP to niezoptymalizowane obrazy. Zdjęcie produktu o wymiarach 4000×3000 px i wadze 2,5 MB ładowane na baner, który wyświetla się w rozdzielczości 800×600 — to marnowanie przepustowości i czasu. Konwersja do formatu WebP (lub AVIF dla nowoczesnych przeglądarek) z odpowiednim srcset w HTML potrafi skrócić LCP o 40-60%.
CLS powstaje najczęściej z powodu brakujących atrybutów width i height przy obrazach, dynamicznie ładowanych czcionek (FOUT — Flash of Unstyled Text) i reklam wstawianych bez zarezerwowanego miejsca w layoucie. Naprawienie CLS to często kwestia kilku linii CSS rezerwujących przestrzeń dla elementów ładowanych asynchronicznie — technicznie proste, ale łatwe do przeoczenia bez audytu.
Z doświadczenia wiemy, że poprawa Core Web Vitals z „czerwonej" do „zielonej" strefy rzadko powoduje natychmiastowy skok pozycji. To raczej czynnik, który eliminuje barierę — strona z dobrymi CWV nie dostanie za nie bonusu, ale strona z fatalnymi wynikami traci pozycje wobec konkurencji z porównywalnymi treściami.
Problemy z indeksacją i strukturą witryny — jak je zdiagnozować i naprawić
Raport „Strony" w Google Search Console (dawniej „Pokrycie") to najważniejsze źródło informacji o stanie indeksacji. Dzieli URL-e na cztery kategorie: prawidłowe, prawidłowe z ostrzeżeniami, wykluczone i z błędem. Kategoria „wykluczone" wymaga szczególnej uwagi, bo zawiera zarówno celowo nieindeksowane strony, jak i te wykluczone przez przypadek.
Status „Wykryto — nie zaindeksowano" oznacza, że Google zna URL, ale nie uznał go za wart zaindeksowania. Przy kilkudziesięciu takich stronach to normalne. Przy setkach lub tysiącach — sygnał problemów z jakością lub z architekturą informacji. Strony głęboko zagnieżdżone (więcej niż 3-4 kliknięcia od strony głównej) mają mniejsze szanse na regularne crawlowanie. Spłaszczenie struktury nawigacji i dodanie linków wewnętrznych z powiązanych tematycznie podstron to najskuteczniejsza metoda poprawy.
Status „Zablokowane przez robots.txt" przy stronach, które powinny być zaindeksowane, to jeden z częstszych błędów pojawiających się po migracjach. Warto co miesiąc porównywać liczbę zaindeksowanych stron w GSC z liczbą URL-i w sitemapie. Rozbieżność powyżej 20-30% wskazuje na problem, który wymaga diagnozy.
Mapa witryny sama w sobie bywa źródłem problemów technicznych SEO. Sitemap zawierający URL-e z kodem 301, 404 lub oznaczone jako noindex generuje w GSC ostrzeżenia i obniża wiarygodność całego pliku. Automat generujący sitemapę powinien filtrować wyłącznie strony z kodem 200, tagiem index i poprawnym canonicalem — raz na kwartał warto to ręcznie zweryfikować, bo automatyczne generatory potrafią „zgubić" filtry po aktualizacji wtyczki czy CMS-a.
Regularne powtarzanie audytu technicznego SEO w ustalonej kadencji — z listą kontrolną dostosowaną do specyfiki witryny — to jedyny sposób, żeby błędy techniczne strony nie kumulowały się w tle. Każdy audyt powinien kończyć się priorytetyzowaną listą zadań: najpierw błędy blokujące indeksację, potem problemy z duplikacją, na końcu optymalizacja wydajności. Taki porządek zapewnia, że ograniczony czas developerów idzie na zmiany o największym wpływie na widoczność w wyszukiwarkach.
