Jak wyszukać thin content w obrębie witryny

Thin content rzadko wygląda jak całkowicie pusta podstrona. Częściej jest to poprawnie działający adres URL z tytułem, nagłówkiem, menu, stopką i kilkoma zdaniami, który nie daje użytkownikowi niczego ponad to, co znajduje się na dziesiątkach innych stron witryny. Problem szczególnie łatwo przeoczyć w sklepach internetowych, serwisach ogłoszeniowych, katalogach usług oraz witrynach korzystających z automatycznie generowanych tagów, filtrów i stron lokalnych.

Najgorsza metoda audytu polega na wyeksportowaniu wszystkich stron mających mniej niż 300 słów i zleceniu dopisania do każdej kilku akapitów. Google nie określa minimalnej ani optymalnej liczby słów potrzebnej do uzyskania widoczności. Krótka strona kontaktowa może spełniać swoją funkcję doskonale, a artykuł liczący 1500 słów nadal może być wtórny, rozwodniony i pozbawiony własnej wartości.

Rzetelny audyt musi połączyć co najmniej cztery elementy: liczbę i unikalność treści, przeznaczenie strony, dane o widoczności oraz sposób osadzenia adresu URL w strukturze witryny. Dopiero ich przecięcie pokazuje, które strony naprawdę wymagają interwencji.

Thin content to nie liczba słów: kryteria oceny stron

Google używa określenia „thin content with little or no added value” między innymi w raporcie działań ręcznych. Jako typowe przykłady wskazuje płytkie strony afiliacyjne, treści przejęte z innych źródeł oraz strony przejściowe, czyli doorway pages. Oddzielnym ryzykiem jest produkowanie dużej liczby nieoryginalnych podstron głównie po to, aby przechwytywać ruch z wyszukiwarki — niezależnie od tego, czy treści powstały automatycznie, z użyciem AI, czy ręcznie.

To oznacza, że podczas audytu trzeba rozdzielić trzy zjawiska:

• Krótka treść — strona ma niewiele tekstu, ale może poprawnie odpowiadać na potrzebę użytkownika.
• Powielona treść — zawartość występuje pod kilkoma adresami URL albo różni się tylko pojedynczymi elementami.
• Treść niskiej wartości — strona nie wnosi wystarczająco dużo informacji, funkcji, danych lub doświadczenia, aby zasługiwała na samodzielne miejsce w wynikach wyszukiwania.

Dobrym przykładem jest karta produktu. Opis liczący 90 słów nie musi być problemem, jeśli strona zawiera aktualną cenę, dostępność, dokładne parametry, wymiary, warianty, informacje o dostawie, kompatybilność, instrukcję oraz własne zdjęcia lub opinie klientów. Ten sam opis staje się podejrzany, gdy został skopiowany od producenta i jest jedynym elementem odróżniającym produkt od setek podobnych kart.

Podobnie wygląda sytuacja ze stronami kategorii. Kategoria z krótkim wprowadzeniem, ale z dobrze dobranym asortymentem, cenami, użytecznymi filtrami i czytelną strukturą może być wartościowa. Kategoria zawierająca trzy produkty, pusty opis i identyczne bloki tekstu jak pozostałe sekcje serwisu zwykle nie ma wystarczającego uzasadnienia do indeksowania.

Progi, które służą do przesiewu, a nie wydawania wyroku

W praktycznym audycie stosuję różne progi dla różnych typów stron:

• Artykuły i poradniki: mniej niż 400–500 słów kieruje stronę do ręcznej kontroli. Nie oznacza automatycznie thin content.
• Strony usług i kategorii: mniej niż 150–200 słów unikalnej treści głównej jest sygnałem ostrzegawczym, jeżeli reszta strony składa się wyłącznie z szablonu.
• Karty produktów: ważniejsza od liczby słów jest liczba unikalnych informacji. Sam tytuł, EAN, cena i opis producenta to zwykle za mało.
• Tagi, filtry i wyniki wyszukiwania wewnętrznego: priorytetem jest sprawdzenie, czy strona odpowiada na odrębne zapytanie i pokazuje inny zestaw wyników. Sam dodatkowy akapit nie rozwiązuje problemu.
• Strony lokalne: podmiana nazwy miasta w identycznym tekście jest mocnym sygnałem doorway pages. Strona „serwis klimatyzacji Kraków” powinna zawierać inne realizacje, obszar obsługi, terminy, cennik lub dane kontaktowe niż wersja dla Tarnowa.
• Strony techniczne i formalne: regulamin, polityka prywatności, logowanie, koszyk, kontakt czy reset hasła mogą być krótkie. Nie należy ich rozbudowywać tylko po to, aby podnieść licznik słów.

Google rekomenduje ocenianie między innymi tego, czy materiał zawiera oryginalne informacje, pełną odpowiedź, własną analizę i wartość wykraczającą poza proste przepisanie innych źródeł. Pytanie kontrolne jest brutalnie proste: czy po przeczytaniu strony użytkownik może zakończyć poszukiwania, czy musi wrócić do Google po lepszą odpowiedź?

Model punktowy do ustalania kolejności pracy

Przy większej witrynie nie da się od razu ręcznie przejrzeć kilku czy kilkudziesięciu tysięcy stron. Pomaga prosty system punktowy. Nie jest to algorytm Google, lecz sposób na ustawienie kolejki audytowej:

• +3 punkty: strona jest dokładnym duplikatem albo ma co najmniej 90% podobieństwa do innej strony.
• +3 punkty: po usunięciu menu, stopki i innych elementów szablonu nie zostaje unikalna odpowiedź na intencję użytkownika.
• +2 punkty: strona starsza niż 12 miesięcy miała 0 kliknięć i 0 wyświetleń w Google w ciągu ostatnich 16 miesięcy.
• +2 punkty: prowadzi do niej najwyżej jeden link wewnętrzny albo znajduje się co najmniej cztery kliknięcia od strony głównej.
• +2 punkty: adres jest indeksowalny i zwraca kod 200, lecz Google wybiera inną stronę kanoniczną albo regularnie oznacza go jako zeskanowany, ale niezaindeksowany.
• +1 punkt: treść znajduje się poniżej progu przesiewowego przyjętego dla danego typu strony.

Wynik 0–2 punkty oznacza niski priorytet. 3–5 punktów wymaga ręcznej kontroli. 6 punktów lub więcej kieruje adres do pierwszej partii analizy.

Sam brak ruchu nie wystarcza. Strona może obsługiwać bardzo wąskie zapytanie, wspierać sprzedaż, zbierać leady albo dotyczyć sezonowego wydarzenia. Z kolei wysoki ruch nie zawsze chroni stronę — może pochodzić z przypadkowych zapytań, które nie realizują celu serwisu.

Jak znaleźć podejrzane adresy URL za pomocą crawla i danych

Najpierw trzeba zbudować pełny inwentarz adresów URL. Crawl wykonany od strony głównej nie pokaże stron osieroconych, do których nie prowadzą linki wewnętrzne. Sam eksport z Google Search Console pominie strony bez wyświetleń. Mapa XML może natomiast zawierać tylko adresy uznane przez właściciela serwisu za ważne.

Dlatego lista powinna powstać z połączenia:

• crawla witryny,
• map XML,
• eksportu adresów z CMS-a lub bazy produktów,
• stron docelowych z GA4,
• danych Google Search Console,
• logów serwera — szczególnie przy dużych serwisach,
• list adresów zewnętrznie linkowanych, jeżeli są dostępne.

Podczas łączenia danych trzeba ujednolicić format adresów: protokół, wariant hosta, końcowy ukośnik i wielkość liter. Nie należy jednak automatycznie kasować wszystkich parametrów. Parametr ?kolor=czarny może w jednym sklepie tworzyć bezwartościowy duplikat, a w innym prowadzić do ważnej kategorii z własnym popytem.

Konfiguracja Screaming Frog SEO Spider

Do pierwszego audytu wystarczy najczęściej Screaming Frog SEO Spider. Bezpłatna wersja skanuje do 500 adresów URL w jednym przebiegu. W lipcu 2026 roku licencja europejska kosztuje 245 euro rocznie i usuwa limit, umożliwia zapisywanie crawli, renderowanie JavaScriptu, integracje z API oraz korzystanie z zaawansowanej konfiguracji. Niedogodność jest oczywista: przy dużym serwisie crawl obciąża komputer, zajmuje miejsce na dysku i może trwać wiele godzin.

Przed uruchomieniem skanowania należy wykonać kilka ustawień:

1. W sekcji Config → Content → Area określ obszar treści głównej. Program domyślnie pomija elementy nav i footer, ale nie rozpozna każdego niestandardowego menu, banera cookies, panelu filtrów czy sekcji polecanych produktów. Jeżeli zostaną wliczone, wynik Word Count będzie sztucznie zawyżony.
2. W Config → Spider → Preferences → Low Content Word Count ustaw próg przesiewowy. Domyślna wartość wynosi 200 słów. Nie zostawiałbym jednego progu dla całego serwisu — artykuły, produkty i kategorie trzeba później rozdzielić w arkuszu.
3. W Config → Content → Duplicates włącz analizę Near Duplicates. Domyślny próg podobieństwa wynosi 90%. Po zakończeniu crawla uruchom Crawl Analysis → Start, ponieważ podobieństwo nie jest obliczane na bieżąco.
4. Włącz skanowanie map XML lub dodaj ich adresy ręcznie. Pozwoli to wychwycić strony występujące w mapie, ale nieosiągalne przez linki wewnętrzne.
5. W serwisie React, Vue lub innym serwisie renderowanym po stronie klienta wykonaj również crawl z renderowaniem JavaScript. Skanowanie wyłącznie surowego HTML może pokazać zerową liczbę słów na stronach, których treść pojawia się dopiero po wykonaniu skryptów.

Do arkusza należy wyeksportować przynajmniej następujące kolumny:

• Address,
• Status Code,
• Indexability i przyczynę braku indeksowalności,
• Canonical URL,
• Word Count,
• Exact Duplicate,
• Closest Similarity Match,
• Crawl Depth,
• Unique Inlinks,
• obecność w mapie XML,
• tytuł strony i H1,
• datę ostatniej modyfikacji,
• typ strony lub katalog, na przykład /blog/, /produkt/, /tag/.

Dodanie danych z Google Search Console

Dla każdej strony warto pobrać kliknięcia, wyświetlenia, średnią pozycję i CTR z możliwie szerokiego zakresu. W przypadku treści sezonowych należy użyć pełnych 16 miesięcy, aby objąć co najmniej jeden cały cykl roczny i fragment poprzedniego okresu.

Tu pojawia się częsty błąd. Eksport z Search Console zawiera strony, dla których zapisano dane. Nie pokaże adresów mających dokładnie zero wyświetleń. Trzeba więc wykonać lewe złączenie, w którym punktem wyjścia jest pełna lista z crawla lub CMS-a, a dane Search Console są do niej dopisywane. Brak dopasowania można dopiero wtedy oznaczyć jako zero.

Przy większej witrynie nie należy opierać się wyłącznie na interfejsie Search Console. Tabela pokazuje maksymalnie 1000 wierszy, więc długi ogon adresów może zostać pominięty. Search Analytics API pozwala pobrać do 25 000 wierszy w jednym zapytaniu, a limit eksportowanych danych wynosi 50 000 wierszy dziennie dla każdego typu wyszukiwania i właściwości. Jeszcze większe serwisy powinny uruchomić codzienny eksport do BigQuery, który obejmuje dostępne dane o skuteczności poza zanonimizowanymi zapytaniami.

Trzeba też uwzględnić sposób raportowania danych. Search Console przypisuje większość kliknięć i wyświetleń do kanonicznego adresu URL, a nie do jego duplikatów. Wariant z parametrem może więc mieć zero kliknięć nie dlatego, że jest bezwartościowy, lecz dlatego, że wyniki zostały zapisane przy stronie kanonicznej.

Dane z URL Inspection API są przydatne, ale nie nadają się do sprawdzania każdego adresu dużej witryny. Limit dla jednej właściwości wynosi 2000 zapytań dziennie. Lepiej pobrać próbkę po 20–50 adresów z każdego szablonu niż zużyć limit na pierwsze dwa tysiące produktów z jednego katalogu.

Segmentacja jest ważniejsza niż jeden filtr

Nie należy porównywać artykułów z kartami produktów ani kategorii z regulaminem. Najpierw podziel adresy według szablonu lub katalogu:

• artykuły,
• produkty,
• kategorie,
• usługi,
• miasta i regiony,
• tagi,
• filtry,
• profile użytkowników,
• strony wyszukiwania wewnętrznego,
• dokumenty formalne.

Dopiero wewnątrz każdej grupy sortuj po liczbie słów, podobieństwie, wyświetleniach i liczbie linków wewnętrznych. To często ujawnia problem na poziomie szablonu. Jeżeli 87% stron /tag/ ma mniej niż 100 słów, zero wyświetleń i ponad 95% podobieństwa, nie ma sensu poprawiać ich pojedynczo. Trzeba zmienić zasady generowania tagów.

Najwięcej czasu oszczędza szukanie części wspólnej kilku filtrów. Przykładowo, w witrynie z 10 000 indeksowalnych adresów:

• 2400 może mieć mniej niż 200 słów,
• 1800 może nie mieć wyświetleń,
• 900 może być niemal identycznych z innymi stronami,
• ale tylko 260 może spełniać wszystkie trzy warunki jednocześnie.

Audyt zaczyna się od tych 260 adresów, a nie od ręcznego czytania wszystkich 2400 krótkich stron.

Przydatne wyszukiwania w Google

Operator site: nadaje się do kontroli wzorców, ale nie do liczenia zaindeksowanych stron. Google wprost zaznacza, że operator nie musi zwracać wszystkich adresów znajdujących się w indeksie.

Przydatne są zapytania:

• site:domena.pl inurl:/tag/
• site:domena.pl inurl:/wyszukiwarka/
• site:domena.pl inurl:?sort=
• site:domena.pl "stały fragment tekstu z szablonu"
• site:domena.pl intitle:"wyniki wyszukiwania"
• site:domena.pl "brak produktów w tej kategorii"

Takie wyszukiwania szybko pokazują, czy Google eksponuje puste kategorie, kombinacje filtrów, nieaktualne wyniki wyszukiwania albo masowo generowane strony lokalne. Wyniki są jednak tylko próbką.

Co zrobić z wykrytym thin content: poprawić, scalić czy usunąć

Samo oznaczenie strony jako podejrzanej nie daje jeszcze odpowiedzi, co z nią zrobić. Każdy adres należy przepuścić przez następującą kolejność decyzji.

1. Rozbuduj stronę, gdy ma odrębną intencję

Rozbudowa ma sens, gdy strona odpowiada na osobne zapytanie, ma znaczenie sprzedażowe albo prezentuje temat, którego nie obsługuje inny adres.

Nie chodzi o dopisanie 600 słów ogólnego tekstu. Trzeba uzupełnić dokładnie to, czego brakuje użytkownikowi:

• zakres usługi i wyłączenia,
• ceny lub orientacyjne widełki,
• warunki dostawy, zwrotu albo rezerwacji,
• konkretne parametry,
• porównanie wariantów,
• problemy i ograniczenia produktu,
• przykłady zastosowania,
• wyniki własnych testów,
• data aktualizacji,
• źródła informacji,
• odpowiedzi na pytania pojawiające się przed zakupem.

Dla karty produktu większą wartość może mieć tabela kompatybilności niż pięć akapitów o „najwyższej jakości wykonania”. Dla strony usługi ważniejszy będzie cennik, czas realizacji i obszar dojazdu niż kolejny tekst o indywidualnym podejściu.

2. Scal i zastosuj przekierowanie 301, gdy strony realizują tę samą intencję

Jeżeli dwa artykuły odpowiadają na to samo pytanie albo kilka kategorii pokazuje niemal identyczny zestaw produktów, zwykle lepiej stworzyć jedną mocniejszą stronę.

Jako adres docelowy wybierz stronę, która ma:

• więcej wartościowych linków zewnętrznych,
• lepszą historię widoczności,
• bardziej logiczne miejsce w strukturze,
• krótszy i stabilniejszy adres,
• większy potencjał sprzedażowy.

Przed przekierowaniem przenieś unikalne informacje ze słabszej strony. Następnie wdroż 301, zmień linki wewnętrzne i usuń stary adres z mapy XML.

Nie należy scalać stron tylko dlatego, że mają podobny temat. „Buty do biegania po asfalcie” i „buty trailowe” należą do tej samej kategorii produktowej, ale odpowiadają na inne potrzeby. Nieprzemyślane połączenie może ograniczyć widoczność na wartościowe zapytania długiego ogona.

3. Użyj rel="canonical", gdy duplikat musi pozostać dostępny

Canonical jest właściwy dla duplikatów lub bardzo podobnych wariantów, które muszą działać dla użytkowników, systemu analitycznego albo kampanii. Przykładem mogą być adresy z parametrami śledzącymi lub kilka ścieżek prowadzących do tej samej zawartości.

Nie jest to narzędzie do „naprawiania” słabej strony. Jeżeli dwa adresy mają różne treści i inne intencje, canonical może zostać zignorowany. Google traktuje przekierowanie i rel="canonical" jako mocne sygnały, ale zachowuje możliwość wybrania innego adresu kanonicznego.

4. Zastosuj noindex, gdy strona jest potrzebna użytkownikom, ale nie wyszukiwarce

Noindex sprawdza się między innymi przy:

• wynikach wyszukiwania wewnętrznego,
• wybranych kombinacjach filtrów,
• stronach sortowania,
• panelach użytkownika,
• wersjach do druku,
• bardzo wąskich tagach,
• technicznych stronach procesu zakupowego.

Nie wolno jednocześnie blokować takiej strony w robots.txt, jeżeli Google ma odczytać dyrektywę noindex. Robot musi wejść na adres i zobaczyć znacznik. Przy rzadko skanowanych stronach usunięcie z indeksu może potrwać nawet kilka miesięcy.

5. Usuń stronę, gdy nie ma wartości ani sensownego następcy

Kod 404 lub 410 jest właściwy, gdy adres:

• nie ma ruchu ani wyświetleń,
• nie zdobył wartościowych linków,
• nie realizuje konwersji,
• nie odpowiada na potrzebne zapytanie,
• nie ma odpowiedniego zamiennika,
• powstał wskutek błędu lub niekontrolowanego generowania adresów.

Nie przekierowuj każdej usuniętej strony na stronę główną. Taki ruch dezorientuje użytkownika i nie przekazuje mu odpowiednika usuniętej zawartości. Jeżeli istnieje bliski następca, zastosuj 301 właśnie do niego. Jeżeli nie istnieje, uczciwy błąd 404 jest lepszy.

Po usunięciu adresu trzeba również usunąć go z map XML, nawigacji, linkowania wewnętrznego i automatycznie generowanych modułów. Inaczej crawler nadal będzie go znajdował.

Najpierw naprawiaj mechanizm, później pojedyncze strony

Kolejność prac powinna wyglądać następująco:

1. Szablony generujące tysiące adresów: filtry, tagi, wyszukiwarka, puste kategorie, warianty parametrów.
2. Grupy stron będących niemal identycznymi duplikatami.
3. Indeksowalne strony bez wyświetleń, linków wewnętrznych i wyraźnego przeznaczenia.
4. Wartościowe strony z brakami merytorycznymi.
5. Pojedyncze krótkie strony, które nie należą do żadnego powtarzalnego wzorca.

Przed masową zmianą wybierz próbkę 50–100 adresów z jednego szablonu. Wdróż decyzję, wykonaj ponowny crawl i sprawdź kod odpowiedzi, canonical, dyrektywy indeksowania oraz mapę XML. Dopiero po poprawnej weryfikacji rozszerz zmianę na całą grupę.

Jeżeli witryna otrzymała ręczne działanie za thin content, samo poprawienie kilku przykładowych stron nie wystarczy. Trzeba usunąć wzorzec naruszenia w całym serwisie, a we wniosku o ponowne rozpatrzenie podać przykłady treści usuniętych i poprawionych.

Po wdrożeniu nie oceniaj efektu wyłącznie po liczbie stron w indeksie. Lepsze wskaźniki to:

• spadek liczby indeksowalnych duplikatów,
• mniejsza liczba adresów bez linków wewnętrznych,
• wzrost liczby wyświetleń przypadających na pozostawioną stronę,
• poprawa kliknięć i konwersji w oczyszczonych grupach,
• ograniczenie skanowania niepotrzebnych parametrów w logach,
• stabilność ruchu po przekierowaniach i usunięciach.

Pierwsza partia do kontroli powinna obejmować indeksowalne strony zwracające kod 200, mające co najmniej 90% podobieństwa do innego adresu, zero wyświetleń w pełnym zakresie danych i brak wyraźnie unikalnej funkcji. Dopiero później warto zajmować się stronami, których jedynym problemem jest niski Word Count.

FAQ: najczęstsze pytania o thin content

Czy każda strona mająca mniej niż 300 słów jest thin content?
Nie. Google nie stosuje uniwersalnego minimalnego limitu słów. Strona powinna być oceniana na podstawie intencji, unikalności, kompletności informacji oraz funkcji w witrynie, a nie samej długości.

Czy thin content może spowodować karę od Google?
Tak. Google może nałożyć ręczne działanie „Thin content with little or no added value”, szczególnie w przypadku płytkich stron afiliacyjnych, treści przejętych z innych źródeł i doorway pages. W wielu przypadkach nie pojawia się jednak ręczna kara — słaba strona po prostu nie jest indeksowana albo nie zdobywa widoczności.

Czy zero kliknięć z Google oznacza, że stronę trzeba usunąć?
Nie. Najpierw sprawdź wyświetlenia, wiek strony, sezonowość, konwersje, linki i jej znaczenie dla użytkowników. Brak kliknięć jest mocnym sygnałem dopiero wtedy, gdy łączy się z brakiem wyświetleń, unikalnej treści i logicznego miejsca w strukturze.

Czy dopisanie FAQ albo kilkuset słów rozwiązuje problem?
Tylko wtedy, gdy nowe informacje odpowiadają na rzeczywiste pytania użytkowników. Generyczny tekst dodany pod produktami lub listą kategorii podniesie licznik słów, ale nie zmieni strony w wartościowy wynik wyszukiwania.

Czy można znaleźć thin content bez płatnych narzędzi?
Tak, przy witrynie do 500 adresów można użyć bezpłatnej wersji Screaming Frog, map XML, Search Console i eksportu z CMS-a. Ograniczeniem darmowej wersji są zaawansowane ustawienia, integracje API, zapisywanie crawli oraz pełna analiza podobieństwa.

Czy noindex jest lepszy od usunięcia strony?
Tylko gdy strona nadal jest potrzebna użytkownikom. Jeżeli nie ma żadnej funkcji ani sensownej zawartości, usuń ją. Jeżeli obsługuje filtry, konto użytkownika lub wewnętrzne wyszukiwanie, noindex zwykle będzie rozsądniejszy.

Jak często wykonywać audyt thin content?
W stabilnej witrynie wystarczy kontrola raz na kwartał. Duży sklep, portal lub katalog generujący dynamiczne adresy powinien sprawdzać wzorce co miesiąc. Dodatkowy audyt jest konieczny po zmianie CMS-a, wdrożeniu nowych filtrów, migracji, imporcie produktów albo masowej publikacji treści.

Od czego zacząć przy kilku tysiącach podejrzanych stron?
Od grup tworzonych automatycznie: filtrów, tagów, pustych kategorii i niemal identycznych stron lokalnych. Naprawienie jednego błędu w szablonie może usunąć tysiące słabych adresów. Ręczne dopisywanie tekstu do każdej strony zostaw na koniec — i tylko dla adresów, które mają odrębną intencję oraz realny potencjał.