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.
Telefon o spadku pozycji zawsze wygląda podobnie: klient widzi mniej ruchu, wpisuje swoją najważniejszą frazę, nie znajduje się na pierwszej stronie i pyta, co poszło nie tak. Prawie zawsze ma już gotową hipotezę — albo „algorytm nas ukarał”, albo „konkurencja coś zrobiła”.
Problem polega na tym, że te dwie odpowiedzi prowadzą do zupełnie różnych działań, a wybranie złej kosztuje kilka tygodni pracy w niewłaściwym miejscu. Przepisywanie treści, kiedy przyczyną jest błąd techniczny po wdrożeniu nowego szablonu, jest równie bezcelowe jak audyt serwera, kiedy dwóch konkurentów po prostu opublikowało lepszy materiał.
Mam na to procedurę i przechodzę ją zawsze w tej samej kolejności, od przyczyn najłatwiejszych do wykluczenia. Pierwsze cztery kroki nie wymagają żadnego narzędzia poza Search Console i przeglądarką.
Brzmi banalnie, a mniej więcej co trzecie zgłoszenie kończy się na tym punkcie.
Pozycja sprawdzona ręcznie w przeglądarce nie jest pozycją. Wyniki są personalizowane historią, zależą od lokalizacji, urządzenia i tego, czy jesteś zalogowany. Klient, który dwadzieścia razy wchodził na własną stronę z tego samego komputera, widzi ją wyżej, niż wynika to ze średniej — a gdy przestanie widzieć, uznaje to za spadek.
Dlatego pierwszym źródłem jest raport skuteczności w Search Console: kliknięcia, wyświetlenia, średnia pozycja i CTR dla konkretnych zapytań, w porównaniu dwóch okresów. Dopiero to jest dane.
Sprawdzam też, czy w ogóle spadł ruch, czy tylko pozycja jednej frazy. Zdarza się, że serwis stracił jedno zapytanie, a zyskał na dwudziestu innych i sumarycznie ma się lepiej. Odwrotna sytuacja też jest częsta: pozycje trzymają się bez zmian, a ruchu jest mniej, bo spadła liczba wyszukiwań albo zmienił się wygląd wyników.
Cała diagnoza opiera się na jednej rzeczy: na dokładnej dacie, w której wykres się złamał.
Ustawiam w Search Console zakres kilku miesięcy, przechodzę na dane dzienne i szukam dnia przełomu. Potem porównuję tę datę z kalendarzem aktualizacji Google. Oficjalnym źródłem jest panel statusu wyszukiwarki i blog Search Central, gdzie potwierdzone aktualizacje mają podane daty startu i zakończenia.
Trzy scenariusze i trzy różne wnioski:
Datę zapisuję. Bez niej wszystkie dalsze rozmowy zamieniają się w spór o wrażenia.
Zanim zacznę mówić o algorytmie, wykluczam rzeczy nudne, bo są zdecydowanie częstsze.
Sprawdzam raport indeksowania stron: czy liczba stron zaindeksowanych nie spadła, czy nie pojawiła się nowa kategoria wykluczeń. Otwieram najważniejsze adresy w narzędziu do sprawdzania URL i patrzę, czy Google widzi je tak samo jak ja. Sprawdzam nagłówki odpowiedzi, przekierowania i to, czy po ostatnim wdrożeniu na stronie nie zniknęły z kodu tytuły, nagłówki albo znaczniki danych strukturalnych. Zmiana szablonu, migracja na nowy motyw, przeniesienie na inny hosting — to najczęstsze niewidoczne przyczyny.
Osobno pytam klienta o rzeczy, o których nie zawsze informuje agencję: przebudowa strony, zmiana adresów, wyłączenie starych podstron, zmiana treści na kluczowych stronach, wygaśnięcie umowy z dostawcą, który obsługiwał jakąś część serwisu.
Sezonowość sprawdzam porównaniem rok do roku dla tych samych tygodni, a nie z poprzednim miesiącem. Sierpień w części branż wygląda jak katastrofa, gdy porównać go z czerwcem, i całkowicie normalnie, gdy porównać z sierpniem poprzedniego roku. Trendy Google pomagają odróżnić spadek zainteresowania tematem od spadku naszej widoczności.
Jeśli technika i sezonowość odpadły, wracam do wyników wyszukiwania — ale nie po to, żeby sprawdzić swoją pozycję, tylko po to, żeby zobaczyć, co jest teraz nad nami.
Wybieram pięć do dziesięciu zapytań, które straciły najwięcej, i dla każdego porównuję dzisiejszą pierwszą stronę z tym, jak wyglądała wcześniej. Jeśli nie mam własnych zrzutów, korzystam z archiwum internetowego i z historii pozycji w narzędziu do monitoringu, o ile klient je ma.
Interesują mnie trzy pytania. Czy nad nami są ci sami konkurenci co wcześniej, tylko wyżej? Czy pojawiły się nowe adresy, których wcześniej w ogóle nie było? Czy zmienił się charakter wyników — na przykład zapytanie, na które wcześniej wyświetlały się strony ofertowe, teraz zwraca poradniki albo listy porównawcze?
Trzecia sytuacja jest najczęściej mylona z karą. To zmiana interpretacji intencji zapytania: Google uznało, że użytkownik szuka czegoś innego, niż my mu podajemy. Wtedy nie ma czego naprawiać w istniejącej stronie — trzeba przygotować materiał odpowiadający na nową intencję albo zaakceptować, że to zapytanie nie jest już nasze.
Jeśli nad nami stoją nowe, wyraźnie lepiej opracowane materiały konkurencji, to jest odpowiedź na pytanie z tytułu. Konkurencja nie musiała robić nic podstępnego — wystarczyło, że opublikowała coś, co lepiej odpowiada na zapytanie.
Te dwie przyczyny da się odróżnić po zasięgu i rozkładzie strat.
Aktualizacja rdzenia działa na poziomie oceny witryny lub większych jej fragmentów. Objawia się szeroko: traci wiele podstron naraz, w tym takie, których nikt nie ruszał od roku i o które nikt się nie bije. Straty dotyczą też zapytań o różnych intencjach i różnym poziomie konkurencyjności.
Działania konkurencji objawiają się punktowo: tracimy konkretne zapytania, na które ktoś przygotował lepszy materiał, przy zachowanej widoczności w pozostałej części serwisu. Jeśli spadki układają się w wyraźne skupiska tematyczne, w których pojawili się nowi gracze, a reszta serwisu stoi stabilnie, to nie algorytm.
Jest też scenariusz mieszany i on jest najczęstszy: aktualizacja przetasowała kolejność, a konkurencja z tego skorzystała, bo miała lepiej przygotowane treści w tych samych obszarach. Wtedy odpowiedź na pytanie „algorytm czy konkurencja” jest po prostu niepełna, a plan działania i tak wychodzi z analizy zapytań, nie z nazwy aktualizacji.
Ostatnia rzecz, o którą pytam: czy spadek dotyczy również ruchu brandowego. Jeśli tak — zapytań o nazwę firmy jest mniej — to prawdopodobnie problem nie leży w wyszukiwarce, a w popycie, kampaniach lub sytuacji rynkowej klienta.
Dwa przypadki, w których dochodzenie trzeba odłożyć.
Pierwszy: aktualizacja rdzenia wciąż się wdraża. Dopóki Google nie ogłosi zakończenia, dane są ruchome i wnioski wyciągnięte w połowie wdrożenia zwykle się nie potwierdzają. Notuję stan, ustawiam przypomnienie i wracam po zakończeniu.
Drugi: skala spadku mieści się w zwykłej zmienności. Kilkuprocentowe wahania tygodnia do tygodnia to norma, a szukanie w nich przyczyny prowadzi do wprowadzania zmian, które psują coś, co działało. Ustalam z klientem z góry, jaki poziom zmiany uznajemy za sygnał wymagający reakcji, i trzymamy się tego progu.
Na koniec rzecz, którą powtarzam przy każdym takim zgłoszeniu: nie wprowadzam kilku poprawek naraz. Przy trzech zmianach w jednym tygodniu za miesiąc nie będziemy wiedzieć, która pomogła, a która zaszkodziła — i przy następnym spadku zaczniemy tę samą diagnozę od zera.
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 |