Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Serwisy z treścią tworzoną przez użytkowników mają w SEO specyficzny problem: ich struktura adresów rośnie sama, bez decyzji redakcji. Każdy nowy wątek, każdy profil, każda strona paginacji, każde sortowanie listy tematów to osobny adres, który Google może odwiedzić i zaindeksować.
Efekt widzę zawsze podobny. Serwis ma kilkaset stron, które ktoś świadomie stworzył, i kilkadziesiąt tysięcy, które powstały automatycznie. Wśród nich są wątki z realnie wartościowymi odpowiedziami, po które ludzie przychodzą z wyszukiwarki — i całe kategorie adresów, których nie powinno tam być w ogóle.
Porządkowanie takiego serwisu nie polega na masowym blokowaniu wszystkiego, co wygląda niechlujnie. Kilka razy widziałem, jak taka operacja zabrała stronie najlepiej pracujący ruch. Poniżej opisuję kolejność, w której to robię, i decyzje, które trzeba podjąć świadomie.
Zanim zacznę cokolwiek zmieniać, rozumiem, skąd biorą się adresy. Prawie zawsze są to te same kilka rodzin.
Dopóki tego podziału nie ma na papierze, każda decyzja o indeksacji jest zgadywaniem. Sam podział zajmuje mi zwykle więcej czasu niż późniejsze wdrożenie.
Do inwentaryzacji używam trzech źródeł i żadne z nich osobno nie wystarcza.
Pierwsze to raport indeksowania stron w Search Console. Interesuje mnie nie tyle liczba stron zaindeksowanych, ile rozkład przyczyn wykluczenia: ile adresów jest zablokowanych, ile ma inny adres kanoniczny, ile zostało przeskanowanych i nie zaindeksowanych. Ta ostatnia kategoria przy serwisach z treścią użytkowników jest zwykle największa i to ona mówi najwięcej o jakości.
Drugie to własne przejście serwisu programem skanującym witrynę. Daje pełną listę adresów, do których prowadzą odnośniki, wraz z tytułami i statusami. Dopiero po zestawieniu tej listy z danymi z Search Console widać rozdźwięk: adresy, które istnieją, ale nie są linkowane, i adresy linkowane, których Google nie odwiedza.
Trzecie to raport statystyk indeksowania. Pokazuje, na co robot poświęca czas. Widok, w którym połowa żądań idzie na profile użytkowników albo na wyniki wyszukiwania wewnętrznego, jest bardzo częsty i bardzo wymowny.
Regułę mam prostą, choć jej zastosowanie wymaga pracy: w indeksie zostaje adres, który potrafi być najlepszą odpowiedzią na jakieś realne zapytanie. Wszystko inne jest kandydatem do wypadnięcia.
W praktyce oznacza to trzy grupy do zostawienia: wątki z odpowiedziami, których nie ma nigdzie indziej w tej formie, strony kategorii, które sensownie grupują tematy, i pojedyncze strony pomocnicze serwisu. To zwykle kilka procent całości.
Z indeksowania wyłączam profile użytkowników, wyniki wyszukiwania wewnętrznego, adresy sortowań i filtrów, strony tagów z jedną pozycją oraz wątki, które nie mają ani jednej odpowiedzi. Ostatnia kategoria jest sporna i klienci najczęściej się przy niej opierają, bo „przecież to pytanie ktoś kiedyś wpisze”. Odpowiadam wtedy pytaniem, czy strona z pytaniem bez odpowiedzi jest dla kogoś przydatna. Rozwiązanie kompromisowe, które stosuję na aktywnych forach: wątek wchodzi do indeksu automatycznie po pierwszej merytorycznej odpowiedzi, a przed nią zostaje wyłączony. To da się zrobić szablonem, bez ręcznej pracy moderatorów.
Sekcje komentarzy pod artykułami to inny przypadek — komentarze zwykle nie mają osobnych adresów, więc nie są problemem indeksacyjnym. Problemem staje się dopiero podział komentarzy na strony i osobne adresy dla pojedynczego komentarza.
Tu popełnia się najwięcej błędów, bo mechanizmy wyglądają na wymienne, a nie są.
Kolejność wdrożenia ma znaczenie. Najpierw ustawiam noindex i czekam, aż Google przetworzy zmianę na zauważalnej części adresów. Dopiero potem, jeśli chcę dodatkowo ograniczyć skanowanie, dokładam blokadę w pliku robots. Odwrotna kolejność zamraża stan na miesiące.
Osobny temat, bo w serwisach dyskusyjnych paginacja to nie dodatek, a główna część struktury.
Strony dalsze niż pierwsza traktuję jako normalne, indeksowalne adresy z własnym adresem kanonicznym wskazującym na siebie. Wskazywanie kanonicznego na pierwszą stronę wątku jest błędem: treść drugiej i trzeciej strony jest inna, a takim ustawieniem mówimy Google, że jej nie ma. Traci się wtedy ruch z długiego ogona zapytań, na które odpowiada właśnie dalsza część dyskusji.
Nie stosuję też starych znaczników wskazujących następną i poprzednią stronę — Google przestało ich używać kilka lat temu i potwierdziło to publicznie. Zamiast nich liczy się to, czy z każdej strony paginacji prowadzą zwykłe odnośniki do sąsiednich stron, dostępne bez skryptów.
Warto dopracować tytuły. Dziesięć stron wątku z identycznym tytułem to dziesięć adresów, które w oczach wyszukiwarki konkurują ze sobą o to samo zapytanie. Dodanie numeru strony do tytułu jest zmianą na kilka minut, a rozwiązuje realny problem.
To wątek, który w tym roku zrobił się ważniejszy niż wcześniej.
W marcu Google ogłosiło nowe zasady dotyczące spamu, wśród nich dwie istotne dla serwisów z treścią użytkowników. Pierwsza dotyczy masowej produkcji treści bez wartości dodanej, bez względu na to, kto lub co je wyprodukowało. Druga dotyczy wykorzystywania reputacji witryny do publikowania obcych treści bez nadzoru gospodarza — pisano o niej głównie w kontekście dużych wydawców goszczących cudze artykuły, ale mechanizm jest ten sam: na naszej domenie odpowiadamy za to, co publikują inni.
Praktyczny wniosek dla forum czy sekcji komentarzy jest prosty. Brak moderacji przestaje być kwestią estetyki, a staje się kwestią oceny całej domeny. Sekcja z tysiącami wpisów niskiej jakości, generowanych masowo i wystawionych w indeksie, obciąża także tę część serwisu, którą redakcja przygotowuje sama.
Nie oznacza to, że treść użytkowników jest ryzykiem, którego lepiej unikać. Dobre forum jest jednym z najtrudniejszych do skopiowania zasobów, jakie firma może mieć — właśnie dlatego, że zawiera prawdziwe pytania i prawdziwe odpowiedzi. Oznacza to, że część tej treści świadomie zostawia się poza indeksem.
Zmiany indeksacyjne działają z opóźnieniem i to jest najtrudniejszy element tej pracy do wytrzymania.
Zanim cokolwiek wdrożę, zapisuję stan wyjściowy: liczbę adresów w każdej kategorii raportu indeksowania, liczbę kliknięć i wyświetleń dla najważniejszych sekcji, rozkład żądań robota w statystykach indeksowania. Bez tej fotografii za dwa miesiące nie odpowiem na pytanie, czy operacja pomogła.
Potem wdrażam etapami, po jednej rodzinie adresów, z odstępem kilku tygodni. Najpierw rzeczy bezdyskusyjne — wyniki wyszukiwania wewnętrznego, sortowania, puste profile. Dopiero na końcu rzeczy sporne, czyli słabe wątki, bo tylko przy nich istnieje realne ryzyko utraty ruchu. Mapę witryny zostawiam wyłącznie z adresami, które mają być w indeksie.
Na koniec rzecz, którą mówię klientom przed startem: spadek liczby zaindeksowanych stron nie jest porażką tej operacji, a jej celem. Wskaźnikiem sukcesu jest ruch i to, ile żądań robota trafia na strony, na których nam zależy — nie licznik w raporcie indeksowania.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |