Spadek pozycji rzadko boli od razu. Boli wtedy, gdy zespół dowiaduje się o nim z raportu miesięcznego, czyli średnio trzy tygodnie po fakcie. W jednym z naszych projektów e-commerce policzyliśmy ten koszt dokładnie: zanim ktokolwiek zauważył, że kategoria z najwyższą marżą wypadła z pierwszej trójki, minęły 23 dni. Poniżej opisujemy system alertów, który skrócił ten czas do dwóch dni, razem z progami, fałszywymi alarmami i kalibracją, która zajęła cały pierwszy kwartał.
Dlaczego raport miesięczny to za późno
Raport miesięczny odpowiada na pytanie „co się stało”, a nie „co się właśnie dzieje”. W praktyce oznacza to opóźnienie liczone nie w dniach, lecz w cyklach: spadek z 12 sierpnia trafia do raportu wysyłanego 5 września, a do backlogu deweloperskiego wchodzi w połowie września. Sześć tygodni na naprawę czegoś, co często sprowadza się do przywrócenia usuniętego bloku treści albo cofnięcia przekierowania.
Policzyliśmy straty na trzech projektach z ostatniego roku. W każdym przypadku ruch nie wracał liniowo po naprawie: po dłuższej nieobecności w top 3 strona wracała najpierw na pozycję 6 lub 7 i potrzebowała kolejnych dwóch do czterech tygodni, żeby odzyskać poprzednie miejsce. Im dłużej trwa spadek, tym droższy jest powrót, i to jest jedyny argument, który przekonał klienta do sfinansowania monitoringu.
Źródła danych do alertów i ich opóźnienia
Pierwsza wersja systemu opierała się wyłącznie na Search Console i przez to reagowała za wolno. Dane w GSC pojawiają się z opóźnieniem od 24 do 48 godzin, a ostatnie dwa dni są jeszcze niekompletne, więc alert oparty na wczorajszych danych regularnie kłamał. Dołożyliśmy więc drugie i trzecie źródło o innej charakterystyce.
| Źródło | Opóźnienie | Do czego służy |
|---|---|---|
| Search Console API | 24–48 h, dane niepełne przez 3 dni | pozycje i kliknięcia na poziomie zapytań oraz adresów URL |
| Codzienny rank tracker | 2–6 h | szybki sygnał na koszyku 120 fraz priorytetowych |
| Crawler własny (status, tytuł, canonical, noindex) | 15 minut | wykrywanie zmian technicznych zanim odbiją się w SERP |
| Logi serwera | 1 h | zmiany w częstotliwości crawlu i błędy podawane botom |
Kluczowa decyzja projektowa: dane z Search Console pobieramy przez API, a nie z eksportu interfejsu, bo interfejs próbkuje i ucina wiersze. Szczegóły takiego pobrania opisaliśmy w tekście o pełnych danych z Search Console API, a limity i format zapytania są opisane w oficjalnej dokumentacji Search Analytics. Bez tego kroku alerty potrafiły ignorować frazy o niskim wolumenie, czyli dokładnie te, na których zarabia sklep.
Czwarte źródło, logi serwera, dołożyliśmy najpóźniej i okazało się najbardziej niedocenione. Nagły spadek liczby odwiedzin Googlebota na kategorii wyprzedzał spadek pozycji o kilka dni. Podobną mechanikę, tyle że dla botów AI, opisaliśmy przy okazji monitoringu botów AI w logach serwera.
Progi alertów: jak uniknąć szumu
Pierwsza konfiguracja wysyłała alert przy spadku o trzy pozycje. W ciągu tygodnia zespół dostał 41 powiadomień i przestał je czytać, co jest najgorszym możliwym wynikiem: system działa, a nikt na niego nie patrzy. Przebudowaliśmy progi tak, żeby zależały od pozycji wyjściowej, bo spadek z 2 na 5 znaczy coś zupełnie innego niż spadek z 34 na 37.
- Pozycje 1–3: alert przy spadku o 2 miejsca utrzymującym się przez 2 kolejne pomiary.
- Pozycje 4–10: alert przy spadku o 4 miejsca lub wypadnięciu z pierwszej dziesiątki.
- Pozycje 11–30: alert wyłącznie zbiorczy, raz w tygodniu, bez powiadomienia natychmiastowego.
- Poniżej 30: brak alertów pozycyjnych, te frazy monitorujemy przez kliknięcia.
Drugi filtr dotyczy wartości strony, a nie samej pozycji. Alert natychmiastowy wysyłamy tylko dla adresów, które w ostatnich 90 dniach wygenerowały co najmniej 1% kliknięć serwisu albo należą do ręcznie oznaczonej listy stron przychodowych. Reszta trafia do podsumowania tygodniowego. Ta jedna reguła obcięła liczbę powiadomień o 78% i nie przepuściła żadnego incydentu, który później okazał się istotny.
Rozróżnienie wahań algorytmu od problemu na stronie
Najtrudniejsza część systemu to nie wykrywanie spadku, tylko odpowiedź na pytanie, czy w ogóle należy reagować. Zbudowaliśmy prostą regułę trzech pytań, którą alert rozstrzyga automatycznie, zanim trafi do człowieka.
- Czy spadek dotyczy jednego adresu URL, czy całego koszyka fraz? Pojedynczy adres wskazuje na problem lokalny, cały koszyk na aktualizację algorytmu lub na coś systemowego.
- Czy w tym samym oknie czasowym zmienił się kod odpowiedzi, tytuł, canonical albo znacznik noindex? Crawler porównuje migawkę sprzed 24 godzin i dopisuje różnicę do treści alertu.
- Czy Google potwierdził trwającą aktualizację? Tu podpinamy Search Status Dashboard, bo potwierdzona aktualizacja zmienia rekomendację z „napraw” na „obserwuj przez 14 dni”.
Alert, który dociera do zespołu, ma więc od razu wstępną diagnozę. W praktyce w 6 na 10 przypadków punkt drugi wskazywał sprawcę natychmiast, najczęściej wdrożenie z poprzedniego dnia: zmieniony szablon kategorii, przypadkowy noindex na paginacji, podmieniony tekst opisu. To są naprawy na godzinę, pod warunkiem że ktoś wie o nich w środę, a nie trzy tygodnie później.
Ścieżka eskalacji w zespole
Alert bez właściciela to tylko powiadomienie. Ustaliliśmy jedną zasadę: każdy alert natychmiastowy ma z góry przypisaną osobę dyżurną na dany tydzień i termin pierwszej odpowiedzi wynoszący 4 godziny robocze. Odpowiedź nie oznacza naprawy, tylko klasyfikację: incydent techniczny, zmiana treści, ruch algorytmu, fałszywy alarm.
Powiadomienia idą na dedykowany kanał w Slacku, oddzielony od kanału raportowego, żeby alerty nie ginęły między wykresami. Mechanika wysyłki jest ta sama, którą opisaliśmy w poradniku o automatycznym raporcie SEO w Make i Slacku, z jedną różnicą: alert zawiera przycisk z linkiem do porównania migawek strony, więc dyżurny widzi diff bez otwierania trzech narzędzi.
Eskalacja ma dwa progi. Po 4 godzinach bez klasyfikacji alert dubluje się do lidera zespołu, po 24 godzinach trafia do cotygodniowego przeglądu z klientem jako pozycja otwarta. Brzmi surowo, ale to właśnie ten element, a nie technologia, skrócił medianę reakcji.
Fałszywe alarmy i kalibracja po pierwszym kwartale
Po trzech miesiącach przejrzeliśmy wszystkie 214 alertów natychmiastowych. Fałszywych alarmów było 63, czyli 29%, i miały cztery powtarzalne przyczyny.
- Personalizacja i lokalizacja wyników w rank trackerze, głównie przy frazach z intencją lokalną.
- Niekompletne dane GSC z ostatnich dwóch dni, traktowane przez skrypt jak realny spadek kliknięć.
- Zmiana typu wyniku, na przykład utrata rozszerzenia lub wejście strony do bloku AI, gdzie pozycja formalnie spadła, a ruch został.
- Sezonowość na frazach zakupowych, gdzie spadek kliknięć nie miał związku z pozycją.
Kalibracja polegała na trzech zmianach: wydłużyliśmy okno potwierdzenia do dwóch kolejnych pomiarów, wykluczyliśmy z porównania dwa ostatnie dni danych GSC i dodaliśmy do alertu informację o typie wyniku. Odsetek fałszywych alarmów spadł z 29% do 11% w kolejnym kwartale, przy zachowaniu wykrywalności realnych incydentów. Warto podkreślić: zejście poniżej 10% wymagałoby progów tak wysokich, że przepuszczałyby wolne, kilkutygodniowe osunięcia, a to najczęstszy scenariusz utraty ruchu.
Efekt: czas reakcji i uratowany ruch
Porównanie dwóch półroczy, przed wdrożeniem i po nim, wygląda następująco.
| Miara | Przed | Po |
|---|---|---|
| Mediana czasu do wykrycia spadku | 21 dni | 2 dni |
| Mediana czasu do naprawy | 34 dni | 6 dni |
| Incydenty wykryte przed klientem | 4 na 11 | 17 na 18 |
| Powiadomienia tygodniowo | 0 | 5,3 po kalibracji |
Najbardziej wymowna liczba nie jest w tabeli. Trzy incydenty z drugiego półrocza dotyczyły stron, które wcześniej odpowiadały łącznie za 18% ruchu organicznego serwisu, i każdy z nich został zamknięty w mniej niż tydzień. Przy poprzednim trybie pracy oznaczałyby one kwartał ze spadkiem, a potem kolejny kwartał odbudowy. Podobny mechanizm, czyli zamiana cyklicznego raportu na ciągły sygnał, opisaliśmy też w case o automatycznym monitoringu cen konkurencji.
Koszt utrzymania systemu to około 3 godziny miesięcznie na przegląd progów i mniej niż 200 zł na infrastrukturę oraz limity API. Największym wydatkiem był pierwszy kwartał kalibracji, kiedy zespół musiał ręcznie oceniać każdy alert. Bez tego etapu system zostałby wyciszony po dwóch tygodniach, jak większość monitoringów, które widzieliśmy u klientów.
Najczęstsze pytania
Od ilu fraz ma sens budowanie alertów?
Od kilkunastu. Nie chodzi o liczbę, tylko o wartość: jeśli 20 fraz odpowiada za większość przychodu z organiku, alerty na tych 20 frazach dadzą więcej niż monitoring tysiąca słów kluczowych o niejasnej wartości biznesowej.
Czy Search Console wystarczy jako jedyne źródło?
Do wykrycia trendu tak, do szybkiej reakcji nie. Opóźnienie 24–48 godzin plus wymagane potwierdzenie z drugiego pomiaru daje realny czas wykrycia na poziomie 3–4 dni. Rank tracker skraca go do jednego dnia, a crawler techniczny do kilkunastu minut przy zmianach na stronie.
Jaki próg spadku ustawić na start?
Dwa miejsca dla pozycji 1–3 i cztery miejsca dla pozycji 4–10, z potwierdzeniem w drugim pomiarze. Progi warto rewidować po pierwszym miesiącu, licząc odsetek alertów, które okazały się fałszywe.
Jak odróżnić aktualizację algorytmu od błędu wdrożeniowego?
Po zasięgu i po korelacji z wdrożeniami. Spadek na wielu niepowiązanych adresach jednocześnie wskazuje na algorytm, spadek na jednej sekcji serwisu w dniu wdrożenia prawie zawsze oznacza zmianę techniczną. Migawki tytułu, canonicala i kodu odpowiedzi rozstrzygają to w kilka sekund.
Ile fałszywych alarmów jest do zaakceptowania?
Około 10 do 15%. Poniżej tego poziomu progi zwykle robią się na tyle wysokie, że system przestaje wykrywać powolne osunięcia pozycji, które kosztują najwięcej.