Alerty o spadkach ruchu w Sheets i Slacku

Spadek ruchu organicznego rzadko zaczyna się od dramatycznego tąpnięcia. Częściej to kilka procent tygodniowo, które w comiesięcznym raporcie wyglądają jak sezonowość, a po kwartale okazują się utratą kilkudziesięciu fraz. Dobrze ustawione alerty o spadku ruchu SEO skracają ten czas z tygodni do dni. W tym tekście budujemy prosty system: dane z Google Search Console trafiają do arkusza Google, reguły porównują je z bazą, a powiadomienie ląduje na Slacku lub w skrzynce. Bez płatnych narzędzi i bez serwera.

Jeżeli masz już arkusz do śledzenia pozycji opisany w tekście Google Sheets i Apps Script: monitoring pozycji bez opłat, alerty dobudujesz w tym samym pliku. Jeśli nie, poniższy schemat działa samodzielnie.

Co monitorować, a czego nie

Najczęstszy błąd przy pierwszym systemie alertów to próba pilnowania wszystkiego. Kilkaset fraz i kilkaset adresów, każdy z osobnym progiem, generuje kilkanaście powiadomień dziennie. Po tygodniu nikt ich nie czyta. Zasada jest odwrotna: monitorujemy mało, ale to, co faktycznie przekłada się na przychód lub widoczność marki.

Sensowny zestaw na start wygląda tak:

Kliknięcia całej domeny z Search Console, dzień po dniu. To główny wskaźnik i pierwszy sygnał problemów technicznych (noindex, błędy serwera, przekierowania po wdrożeniu).
Kliknięcia 10–20 kluczowych adresów: strony usług, kategorie sklepu, najlepiej konwertujące artykuły.
Wyświetlenia fraz markowych. Ich spadek przy stabilnym ruchu niemarkowym wskazuje zwykle na problem poza SEO (kampanie, PR), ale warto o nim wiedzieć.
Sesje organiczne z GA4 jako kontrola krzyżowa. Gdy GSC pokazuje stabilne kliknięcia, a GA4 spadek sesji, winny bywa tag lub baner zgód, a nie Google.

Czego nie warto alarmować? Pojedynczych pozycji długiego ogona, średniej pozycji całej domeny (ten wskaźnik zmienia się przy każdej zmianie miksu zapytań, co opisujemy w tekście o tym, jak czytać średnią pozycję w Search Console) oraz CTR na poziomie strony głównej. To metryki do analizy, nie do powiadomień.

Progi i okna porównawcze bez fałszywych alarmów

Ruch z wyszukiwarki ma silny rytm tygodniowy. Serwis B2B traci w weekend nawet połowę kliknięć, sklep z odzieżą bywa najmocniejszy w niedzielę wieczorem. Porównanie wczorajszego dnia z przedwczorajszym jest więc bezużyteczne: każdy poniedziałek wyglądałby jak wzrost, każda sobota jak katastrofa.

Działają trzy podejścia, od najprostszego:

Ten sam dzień tygodnia. Porównujesz wtorek z medianą czterech poprzednich wtorków. Mediana zamiast średniej chroni przed jednym nietypowym dniem (np. świętem) w bazie.
Suma krocząca 7 dni. Ostatnie siedem dni kontra poprzednie siedem. Wygładza rytm tygodniowy, ale reaguje z opóźnieniem 2–3 dni.
Rok do roku dla branż sezonowych. Ma sens dopiero przy co najmniej 16 miesiącach danych, czyli przy pełnym zakresie dostępnym w Search Console.

Progi dobieramy do wolumenu. Strona z 50 kliknięciami dziennie naturalnie waha się o 20–30%, więc próg 15% generowałby szum. Praktyczna reguła: alert wtedy, gdy spadek przekracza określony procent i jednocześnie minimalną liczbę bezwzględną. Na przykład: suma 7 dni niższa o ponad 20% i o więcej niż 100 kliknięć. Drugi warunek wycina alarmy dla adresów z kilkunastoma wejściami dziennie.

Warto też dodać regułę potwierdzenia: alert wysyłamy dopiero, gdy warunek jest spełniony dwa dni z rzędu. Kosztuje to dobę opóźnienia, ale eliminuje większość fałszywych powiadomień.

Pobieranie danych z GSC do arkusza

Najtańsza droga to Apps Script w arkuszu Google, który odpytuje Search Analytics API. W manifeście projektu (plik appsscript.json) dodajesz zakres https://www.googleapis.com/auth/webmasters.readonly oraz https://www.googleapis.com/auth/script.external_request, a w kodzie korzystasz z tokenu bieżącego użytkownika. Pełną specyfikację zapytań znajdziesz w dokumentacji Search Console API.

Szkielet funkcji pobierającej kliknięcia dzień po dniu:

function pobierzGSC() {
  var site = 'sc-domain:twojadomena.pl';
  var dni = 35;
  var koniec = new Date(Date.now()-3*864e5);
  var start = new Date(koniec.getTime()-dni*864e5);
  var fmt = function (d) { return Utilities.formatDate(d, 'UTC', 'yyyy-MM-dd'); };
  var url = 'https://www.googleapis.com/webmasters/v3/sites/' +
    encodeURIComponent(site) + '/searchAnalytics/query';
  var res = UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    headers: { Authorization: 'Bearer ' + ScriptApp.getOAuthToken() },
    payload: JSON.stringify({
      startDate: fmt(start), endDate: fmt(koniec),
      dimensions: ['date'], rowLimit: 1000
    })
  });
  var rows = JSON.parse(res.getContentText()).rows || [];
  var arkusz = SpreadsheetApp.getActive().getSheetByName('dane');
  arkusz.clearContents();
  arkusz.appendRow(['data', 'klikniecia', 'wyswietlenia']);
  rows.forEach(function (r) { arkusz.appendRow([r.keys[0], r.clicks, r.impressions]); });
}

Dwie rzeczy, o których łatwo zapomnieć. Po pierwsze, dane w Search Console mają opóźnienie około 2–3 dni, dlatego koniec zakresu przesuwamy o trzy dni wstecz. Ostatnie, niepełne dni zawsze wyglądają jak spadek i są głównym źródłem fałszywych alarmów. Po drugie, dla kluczowych adresów robisz osobne zapytanie z wymiarami date i page oraz filtrem na listę URL. Przy większych serwisach rozważ eksport do BigQuery; porównanie obu dróg opisaliśmy w tekście o GSC API i BigQuery w 2026 roku.

Reguły alertów krok po kroku

Gdy dane są w zakładce dane, reguły najlepiej trzymać w osobnej zakładce reguly, a nie w kodzie. Dzięki temu osoba bez znajomości Apps Script zmieni próg bez dotykania skryptu. Prosta tabela reguł ma kolumny: nazwa, metryka, okno (7 dni albo dzień tygodnia), próg procentowy, minimalna różnica bezwzględna, liczba dni potwierdzenia, kanał powiadomienia.

Logika sprawdzania dla reguły z oknem 7 dni wygląda następująco:

Sumujesz kliknięcia z ostatnich siedmiu dni dostępnych danych (bieżące okno).
Sumujesz kliknięcia z siedmiu dni wcześniej (okno bazowe).
Liczysz zmianę procentową i różnicę bezwzględną.
Jeżeli oba progi są przekroczone, zapisujesz datę w kolumnie ostatnie_trafienie.
Jeżeli warunek był spełniony także poprzedniego dnia, a od ostatniego powiadomienia minęły co najmniej 3 dni, wysyłasz alert.

Krok piąty to wyciszenie. Bez niego jeden trwały spadek przez tydzień zasypie kanał identycznymi wiadomościami. W treści alertu zawsze podawaj obie liczby (bieżące i bazowe okno) oraz link do odpowiedniego raportu w Search Console, żeby odbiorca nie musiał niczego szukać.

Powiadomienia na Slack i mail

Slack przyjmuje wiadomości przez tzw. incoming webhook: w ustawieniach aplikacji tworzysz adres przypisany do konkretnego kanału, a skrypt wysyła na niego zwykłe żądanie POST z treścią w JSON. Konfigurację opisuje dokumentacja Slack API. Adres webhooka zapisz we właściwościach skryptu (PropertiesService), nie w komórce arkusza, bo każdy z dostępem do pliku mógłby go odczytać.

function wyslijAlert(tekst) {
  var hook = PropertiesService.getScriptProperties().getProperty('SLACK_HOOK');
  UrlFetchApp.fetch(hook, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: tekst })
  });
  MailApp.sendEmail('seo@twojadomena.pl', 'Alert SEO', tekst);
}

Całość uruchamia wyzwalacz czasowy (time-driven trigger) raz dziennie, najlepiej rano, zanim zespół zacznie pracę. Mail traktuj jako kanał zapasowy: Slack bywa wyciszony, a skrzynka zostaje śladem na potrzeby późniejszej analizy. Jeżeli w firmie działa już n8n lub podobne narzędzie, te same reguły możesz przenieść do przepływu, co pokazujemy w artykule n8n dla SEO w 2026.

Procedura po alercie: pierwsze 30 minut

Alert bez procedury kończy się pytaniem „i co teraz?”. Krótka lista kontrolna, wpisana do opisu kanału na Slacku, oszczędza czas i nerwy:

Minuty 0–5: czy to w ogóle spadek? Sprawdź, czy dane w GSC są kompletne dla analizowanych dni i czy GA4 pokazuje podobny ruch. Rozbieżność wskazuje na problem z pomiarem.
Minuty 5–10: zasięg problemu. Cała domena, jeden katalog czy pojedyncze adresy? Raport Skuteczność z wymiarem stron odpowie na to w minutę.
Minuty 10–20: przyczyny techniczne. Sprawdź status HTTP kluczowych adresów, znaczniki noindex, canonical, plik robots.txt i ostatnie wdrożenia. Zapytaj dział IT, co zmieniło się w ostatnich dniach.
Minuty 20–25: czynniki zewnętrzne. Czy trwa aktualizacja algorytmu? Czy w wynikach pojawiły się AI Overviews lub nowe moduły dla Twoich fraz? Czy sezon nie spada naturalnie?
Minuty 25–30: decyzja i notatka. Zapisz w arkuszu hipotezę, właściciela sprawy i termin ponownej weryfikacji. Ten rejestr po kilku miesiącach staje się najlepszym źródłem wiedzy o tym, które alerty były realne.

Rejestr pomaga też kalibrować progi. Jeżeli przez kwartał połowa alertów okazała się szumem, podnieś próg bezwzględny lub wydłuż potwierdzenie. Jeżeli przegapiłeś realny spadek, obniż próg dla konkretnej grupy adresów, a nie dla całej domeny.

FAQ

Jak często system powinien sprawdzać dane z Search Console?

Raz dziennie w zupełności wystarcza. Dane GSC aktualizują się z opóźnieniem około 2–3 dni, więc częstsze uruchamianie skryptu nie przyniesie nowych informacji, a jedynie zwiększy liczbę zapytań do API.

Jaki próg spadku ustawić na początek?

Dla sumy 7 dni dobrym punktem startowym jest spadek o ponad 20% połączony z minimalną różnicą bezwzględną (np. 100 kliknięć dla domeny, 20 dla pojedynczego adresu). Po miesiącu pracy z rejestrem alertów dostosuj wartości do zmienności swojego serwisu.

Czy da się zbudować alerty bez programowania?

Częściowo. Dodatek do Arkuszy Google, który importuje dane z Search Console, oraz formatowanie warunkowe pozwolą zobaczyć spadki, ale do wysyłki powiadomień na Slack potrzebny jest krótki skrypt lub narzędzie typu n8n albo Zapier.

Dlaczego alert pojawia się, a w Search Console nie widzę spadku?

Najczęściej skrypt pobiera niepełne dane z ostatnich dni. Upewnij się, że koniec zakresu jest przesunięty o co najmniej trzy dni wstecz i że porównujesz okna o tej samej liczbie dni oraz tym samym układzie dni tygodnia.

Czy warto alarmować spadki pozycji zamiast kliknięć?

Tylko dla kilku najważniejszych fraz i najlepiej z danych narzędzia do śledzenia pozycji. Średnia pozycja z GSC zmienia się przy każdej zmianie miksu zapytań, więc jako źródło alertów generuje dużo szumu.