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.
To było intensywne lato dla wszystkich, którzy patrzą na wykresy widoczności. W czerwcu Google wypuściło aktualizację nastawioną na spam, rozbitą na dwie części wdrażane w odstępie kilku dni, a pod koniec lipca doszła osobna aktualizacja dotycząca spamu linkowego. Do tego w tym samym okresie ruszyły dwie szerokie aktualizacje algorytmu rdzeniowego, co znacząco utrudniło przypisywanie skutków do przyczyn.
Efekt jest przewidywalny: telefon od klienta ze zdaniem „dostaliśmy karę od Google”. W większości przypadków, które sprawdzam, kary nie ma. Jest spadek, który ma inną przyczynę, a słowo „kara” utrudnia postawienie właściwej diagnozy, bo wysyła myślenie w stronę odwoływania się, a nie naprawiania.
Poniżej opisuję, jak rozróżnić te sytuacje i w jakiej kolejności je sprawdzać.
To dwie zupełnie inne rzeczy i pierwszy krok diagnozy polega na ustaleniu, o którą chodzi.
Kara ręczna to decyzja człowieka pracującego w zespole antyspamowym Google. Zawsze zostaje zgłoszona w Search Console w raporcie ręcznych działań. Jeśli tego raportu nie widzisz albo jest pusty, kary ręcznej nie ma — nie ma tu miejsca na domysły. Kara ręczna ma określony zakres: może dotyczyć całej witryny albo pojedynczych adresów, i ma określony powód, na przykład nienaturalne linki wychodzące albo cienką treść bez wartości.
Spadek algorytmiczny nie jest karą i nigdzie nie jest zgłaszany. Algorytm ocenił stronę inaczej niż wcześniej — czasem dlatego, że zmieniły się kryteria, czasem dlatego, że ktoś inny zrobił coś lepiej. Nie ma tu procedury odwołania, bo nie ma od czego się odwoływać.
Różnica praktyczna jest zasadnicza. W pierwszym przypadku po naprawie składasz wniosek o ponowne rozpatrzenie i czekasz na decyzję człowieka. W drugim naprawiasz i czekasz na kolejne przetworzenie danych przez algorytm, co przy szerokich aktualizacjach może oznaczać oczekiwanie na następną taką aktualizację.
Warto rozumieć zakres, bo od tego zależy, gdzie szukać.
Czerwcowa aktualizacja nastawiona na spam celowała w klasyczne naruszenia wytycznych dotyczących jakości: strony generowane maszynowo bez wartości, przekierowania mylące użytkownika, ukryty tekst, treść skopiowaną i podmienianą w celu wyłudzenia ruchu. Google wdrożyło ją w dwóch turach, więc obserwacja wyłącznie pierwszego dnia dawała niepełny obraz.
Lipcowa aktualizacja dotycząca spamu linkowego to inny obszar — ocena odnośników. Google zapowiedziało, że skuteczniej rozpoznaje i unieważnia linki kupione, wymieniane w schematach i publikowane w artykułach gościnnych tworzonych wyłącznie dla linku. Kluczowe słowo to unieważnia: takie linki przestają działać, a więc strona, która na nich stała, spada, choć nie została ukarana.
To rozróżnienie jest ważne dla oceny skali problemu. Utrata wartości linków to spadek do poziomu, na którym strona byłaby bez nich. Kara to obniżenie poniżej tego poziomu.
Nie zaczynam od hipotez, tylko od danych. Kolejność jest zawsze taka sama.
Dopiero po tych pięciu punktach zaczynam się zastanawiać, co się właściwie stało.
Data jest najmocniejszą przesłanką, jaką masz, ale trzeba ją porównać z czymś sensownym.
Interesuje mnie, czy spadek zaczął się w oknie wdrażania jednej ze znanych aktualizacji, czy wypadł w zupełnie innym terminie. Google potwierdza szerokie aktualizacje publicznie i podaje przybliżone okresy wdrażania — te informacje warto zestawić z własnym wykresem, zanim wyciągnie się wnioski. Wdrażanie trwa zwykle od kilku dni do dwóch tygodni, więc nie należy oczekiwać jednego pionowego uskoku.
Trzy wzorce, które rozróżniam:
Spadek nagły i całkowity, w ciągu jednego dnia, do bliska zera. Prawie nigdy nie jest to aktualizacja algorytmu. Zwykle to problem techniczny: blokada indeksowania, wygaśnięcie certyfikatu, awaria serwera albo zmiana adresów bez przekierowań.
Spadek stopniowy w ciągu tygodnia lub dwóch, obejmujący część fraz. To wygląda na aktualizację algorytmu i tak zwykle jest.
Spadek dotyczący wybranej sekcji serwisu przy nietkniętej reszcie. To sugeruje problem z konkretnym typem treści, a nie z domeną jako całością.
Jeśli w raporcie ręcznych działań jest wpis, ścieżka jest jasna. Czytam dokładnie powód i zakres, usuwam przyczynę naprawdę, a nie pozornie, dokumentuję, co zostało zrobione, i składam wniosek o ponowne rozpatrzenie z opisem konkretnych działań. Wniosek bez opisu albo z obietnicami na przyszłość zamiast wykonanej pracy jest odrzucany. Warto się nastawić na to, że rozpatrywanie potrwa i że jeden wniosek na tydzień to maksimum, jakie ma sens.
Jeśli kary nie ma, a spadek nastąpił po aktualizacji dotyczącej linków, sprawdzam profil odnośników. Nie po to, żeby masowo zgłaszać linki do narzędzia odrzucania — z mojego doświadczenia jest ono nadużywane i częściej szkodzi, niż pomaga. Chodzi o zrozumienie, czy widoczność opierała się na linkach, które właśnie przestały mieć znaczenie. Jeśli tak, to zadaniem nie jest ratowanie starych linków, a zbudowanie widoczności na czymś innym.
Jeśli spadek nastąpił po aktualizacji nastawionej na spam, a strona nie robi nic z wytycznych, przyczyny szukam w treści: czy nie ma na niej sekcji generowanych automatycznie, skopiowanych opisów producenta na tysiącach kart produktu, podstron tworzonych wyłącznie pod frazy.
Największym błędem po spadku jest gwałtowna reakcja. Widziałem serwisy, w których panika zrobiła więcej szkody niż sama aktualizacja.
Nie przebudowuję serwisu w ciągu tygodnia od spadku, bo przy kolejnym pomiarze nie będę w stanie odróżnić skutków aktualizacji od skutków własnych zmian. Nie usuwam masowo treści — usuwanie jest nieodwracalne, a często okazuje się, że spadły frazy, nie ruch na tych konkretnych podstronach. Nie zgłaszam hurtowo linków do odrzucenia bez analizy każdej domeny osobno.
Zamiast tego robię coś nudnego: zapisuję stan wyjściowy. Eksport danych z Search Console, lista pozycji dla najważniejszych fraz, zrzut struktury serwisu. Bez punktu odniesienia nie ocenisz później, czy cokolwiek pomogło — a to jest jedyna informacja, na której da się oprzeć dalsze decyzje.
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 |