Raport tygodniowy to obowiązek, który najczęściej umiera po trzech miesiącach. Ktoś eksportuje CSV z Search Console, wkleja do arkusza, koloruje komórki, a w poniedziałek rano okazuje się, że nie zdążył. Automatyczny raport SEO w Make rozwiązuje to raz: scenariusz odpala się sam o siódmej rano, pobiera dane z Search Console, porównuje je z poprzednim tygodniem i wrzuca gotową wiadomość na Slacka. Zero kodu, zero utrzymania, kilkanaście minut na złożenie.
Co powinien zawierać raport tygodniowy
Najczęstszy błąd to raport, który pokazuje wszystko. Wiadomość na Slacku ma być czytana na telefonie w dwie minuty, więc mieści się w niej najwyżej sześć liczb i jedna lista. Reszta to hałas, który sprawia, że po miesiącu nikt już nie klika.
Zestaw minimalny wygląda tak: kliknięcia i wyświetlenia za ostatnie siedem pełnych dni, zmiana procentowa wobec poprzednich siedmiu, średnia pozycja i CTR, trzy zapytania z największym wzrostem kliknięć oraz trzy z największym spadkiem. Do tego jedna lista adresów, które straciły najwięcej. Tyle wystarczy, żeby wychwycić deindeksację, wdrożenie, które zepsuło szablon, albo sezonowy skok popytu.
Ważne zastrzeżenie metodyczne: dane w Search Console dojrzewają. Ostatnie dwie doby prawie zawsze są niepełne, więc okno raportu przesuwa się o trzy dni wstecz. Porównujesz dni od minus dziesiątego do minus czwartego z dniami od minus siedemnastego do minus jedenastego. Bez tego przesunięcia co poniedziałek zobaczysz fałszywy spadek i po dwóch tygodniach przestaniesz ufać własnemu raportowi.
Autoryzacja do Search Console w Make
Make ma gotowy moduł Google Search Console, ale w wersji podstawowej zwraca ograniczony zestaw wymiarów. Wygodniejsze i tańsze w utrzymaniu jest wywołanie Make an API Call na tym samym połączeniu, bo dostajesz pełny dostęp do metody searchanalytics.query i sam decydujesz o wymiarach, filtrach i limicie wierszy.
Połączenie zakładasz raz. W panelu Make wybierasz Google Search Console, klikasz nowe połączenie i logujesz się kontem, które ma dostęp do usługi w Search Console. Uprawnienie „pełny użytkownik” wystarczy, „właściciel” nie jest potrzebny. Jeśli pracujesz na koncie klienta, poproś o dodanie osobnego adresu roboczego zamiast korzystać z prywatnego, bo przy rotacji zespołu scenariusz przestanie działać z dnia na dzień.
Osoby, które wolą trzymać integracje po swojej stronie, mogą zrobić to samo przez konto serwisowe i własny pipeline. Opisaliśmy ten wariant w tekście o tym, jak działa API GA4 i Search Console w praktycznym pipelinie. Wybór jest prosty: Make, gdy zależy ci na czasie wdrożenia, własny skrypt, gdy raport ma zasilać hurtownię danych.
Struktura zapytania jest niemal identyczna jak w dokumentacji Search Analytics API. Podajesz zakres dat, listę wymiarów (query albo page), typ wyszukiwania i limit wierszy. Do raportu tygodniowego w zupełności wystarczy 250 wierszy, bo i tak pokażesz z nich sześć.
Pobranie danych i porównanie tydzień do tygodnia
Scenariusz składa się z siedmiu modułów. Pierwszy to wyzwalacz czasowy ustawiony na poniedziałek, godzina siódma. Drugi i trzeci to dwa wywołania API: jedno dla okna bieżącego, drugie dla okna poprzedniego. Daty liczysz funkcjami Make na dacie uruchomienia, więc nic nie trzeba podmieniać ręcznie.
Czwarty moduł agreguje wiersze bieżącego okna, piąty robi to samo dla poprzedniego. Szósty to Set multiple variables, w którym wyliczasz różnice procentowe. Jedna pułapka: jeśli poprzedni tydzień miał zero kliknięć na danym zapytaniu, dzielenie przez zero wysypie scenariusz. Zabezpiecz to warunkiem, który przy zerze w mianowniku zwraca etykietę „nowe” zamiast liczby.
Porównanie zapytań robi się przez dopasowanie po kluczu. W Make najprościej zbudować z poprzedniego okna kolekcję, w której kluczem jest treść zapytania, a wartością liczba kliknięć, a następnie odpytywać ją przy przetwarzaniu bieżących wierszy. Sortujesz malejąco po różnicy i bierzesz trzy pierwsze pozycje, potem rosnąco i znów trzy pierwsze. To cały algorytm rankingu wzrostów i spadków.
| Element raportu | Wymiar zapytania | Po co |
|---|---|---|
| Kliknięcia i wyświetlenia | brak wymiaru | Kondycja całej usługi w jednej liczbie |
| Wzrosty i spadki fraz | query | Wczesny sygnał kanibalizacji i utraty pozycji |
| Adresy tracące ruch | page | Namierzenie wdrożenia, które zepsuło szablon |
| Podział na urządzenia | device | Wykrycie problemu wyłącznie mobilnego |
Formatowanie wiadomości na Slacku
Moduł Slack „Create a Message” przyjmuje zwykły tekst, ale czytelny raport wymaga bloków. W polu Blocks wklejasz strukturę JSON, w której nagłówek zawiera nazwę usługi i zakres dat, sekcja z polami pokazuje cztery metryki obok siebie, a dwie kolejne sekcje listują wzrosty i spadki. Ograniczenie Slacka to pięćdziesiąt bloków na wiadomość, czyli znacznie więcej, niż potrzebujesz.
Kilka rzeczy poprawia czytelność bardziej niż jakakolwiek grafika. Liczby zaokrąglaj do pełnych jednostek, procenty do jednego miejsca po przecinku. Kierunek zmiany oznaczaj emotikoną zamiast koloru, bo kolor tła w Slacku działa tylko w załącznikach starego typu. Nazwy zapytań skracaj do czterdziestu znaków, inaczej wiadomość na telefonie rozjedzie się na sześć linii. Na końcu dodaj przycisk z odnośnikiem do Search Console, żeby przejście do szczegółów było jednym kliknięciem.
Kanał wybierz osobny, na przykład #seo-raporty, i zaproś do niego osoby spoza zespołu SEO. Regularny, krótki raport w miejscu, gdzie widzi go product owner, robi dla priorytetyzacji więcej niż kwartalna prezentacja.
Alerty przy nietypowych spadkach
Raport tygodniowy nie zastąpi alertu. Spadek o czterdzieści procent w środę zobaczysz dopiero w poniedziałek, czyli pięć dni za późno. Dlatego obok scenariusza tygodniowego warto uruchomić drugi, codzienny, który nic nie wysyła, dopóki nie przekroczy progu.
Progi ustaw na dwóch poziomach. Pierwszy to spadek kliknięć dzień do dnia względem tego samego dnia tygodnia sprzed tygodnia, bo poniedziałek porównany z niedzielą zawsze wygląda dramatycznie. Drugi to spadek liczby wyświetleń, który wyprzedza spadek kliknięć i częściej wskazuje na problem indeksacyjny niż na sezonowość. Praktyczne wartości startowe to minus trzydzieści procent dla kliknięć i minus dwadzieścia pięć procent dla wyświetleń, przy minimum stu kliknięciach w dniu bazowym, żeby małe liczby nie generowały szumu.
Alert wysyłaj na inny kanał niż raport i dodawaj do niego surowy kontekst: które adresy odpowiadają za największą część spadku i czy zmiana dotyczy jednego urządzenia. Bez tego pierwsze pytanie po alercie brzmi „gdzie szukać”, a odpowiedź zajmuje pół godziny.
Koszt operacji i limity planu
Make rozlicza operacje, czyli pojedyncze wykonania modułu. Raport tygodniowy w opisanej konfiguracji zużywa około dziesięciu operacji na uruchomienie, czyli mniej więcej czterdzieści miesięcznie. Scenariusz alertowy działający codziennie to kolejne sto pięćdziesiąt. Dla jednej usługi mieści się to spokojnie w planie darmowym, który daje tysiąc operacji miesięcznie.
Skala zmienia rachunek. Przy dziesięciu usługach dochodzisz do około dwóch tysięcy operacji, więc potrzebny jest plan Core. Da się to zbić: zamiast dziesięciu osobnych scenariuszy zbuduj jeden, który iteruje po liście usług z arkusza. Iteracja liczy się jako operacja za każdy przebieg modułu, ale wyzwalacz i moduły wspólne odpalają się raz, co przy dziesięciu usługach daje oszczędność rzędu trzydziestu procent.
Po stronie Google limity nie są problemem. Search Analytics API pozwala na tysiąc dwieście zapytań na minutę i trzydzieści tysięcy dziennie na projekt, a raport tygodniowy zużywa dwa. Jedyny realny limit to szesnaście miesięcy historii, więc jeżeli chcesz porównywać rok do roku dłużej, dane trzeba archiwizować u siebie.
Rozszerzenia: GA4, pozycje i Core Web Vitals
Kiedy raport podstawowy działa od miesiąca i nikt go nie wyłączył, warto go rozbudować. Naturalny pierwszy krok to GA4: dokładasz moduł Data API i dokładasz do wiadomości sesje organiczne oraz konwersje z kanału organic. Dopiero zestawienie kliknięć z konwersjami pokazuje, czy wzrost widoczności przełożył się na cokolwiek. Warto przy tym pamiętać, że część ruchu z modeli językowych rozlicza się inaczej, co opisaliśmy w tekście o atrybucji ruchu z AI.
Drugi krok to pozycje z narzędzia zewnętrznego. Search Console podaje średnią pozycję ważoną wyświetleniami, co jest czymś innym niż pozycja na konkretnej frazie w konkretnym mieście. Jeżeli masz już abonament w Ahrefs czy Semrush, ich API doda do raportu twardy ranking; różnice między tymi narzędziami rozbieramy w porównaniu Ahrefs, Semrush i Sistrix.
Trzeci krok to Core Web Vitals z CrUX API, najlepiej w ujęciu miesięcznym, bo tygodniowa zmienność tych wskaźników jest zbyt duża, żeby cokolwiek z niej wnioskować. Całość układa się w spójny zestaw narzędzi, który opisujemy szerzej przy okazji stacku marketingowego na 2026.
FAQ
Ile czasu zajmuje zbudowanie takiego scenariusza w Make?
Pierwsze wdrożenie to zwykle 60–90 minut, z czego połowa schodzi na autoryzację i testy formatowania wiadomości. Kolejna usługa to już kwadrans, bo scenariusz kopiujesz i podmieniasz adres witryny.
Czy potrzebuję płatnego planu Make?
Nie, jeżeli obsługujesz jedną lub dwie usługi. Raport tygodniowy plus codzienny alert mieszczą się w darmowym limicie tysiąca operacji miesięcznie. Płatny plan zaczyna być potrzebny mniej więcej od piątej usługi.
Dlaczego liczby w raporcie różnią się od tych w interfejsie Search Console?
Najczęściej z powodu innego zakresu dat lub innego typu wyszukiwania. Interfejs domyślnie pokazuje wyniki wyszukiwania w sieci, a API zwróci sumę wszystkich typów, jeżeli tego nie ograniczysz. Drugi powód to dojrzewanie danych z ostatnich dwóch dób.
Czy zamiast Slacka mogę wysyłać raport mailem?
Tak, wystarczy podmienić ostatni moduł na Email lub Gmail, a bloki JSON zastąpić prostym HTML. Reszta scenariusza pozostaje bez zmian, bo logika porównania tygodni jest niezależna od kanału dostarczenia.
Co zrobić, gdy scenariusz przestanie działać po kilku miesiącach?
W 90 procentach przypadków wygasło połączenie Google, zwykle po zmianie hasła lub odebraniu dostępu w Search Console. W Make widać to jako błąd 401 w historii wykonań. Wystarczy odświeżyć połączenie i uruchomić scenariusz ręcznie, żeby potwierdzić naprawę.