Praca SEO ma brzydką właściwość: im większy serwis, tym więcej czasu pochłania sprawdzanie rzeczy, które w 95 procentach przypadków są w porządku. Codzienny rzut oka na Search Console, comiesięczne klikanie raportu dla klienta, kwartalne polowanie na zepsute linki. To nie jest praca analityczna, to dyżur. I właśnie taki dyżur da się oddać maszynie.
n8n jest narzędziem do budowania automatyzacji z gotowych klocków, które łączy się z API bez pisania backendu od zera. Poniżej sześć scenariuszy, które w praktyce zdejmują z zespołu SEO najwięcej powtarzalnej roboty, wraz z tym, na czym każdy z nich zwykle się wykłada.
Dlaczego akurat n8n
Wybór między n8n, Make a Zapierem sprowadza się do trzech rzeczy: kosztu przy dużej liczbie operacji, dostępu do surowego kodu i możliwości postawienia całości na własnym serwerze. SEO generuje przepływy, które odpalają się często i przetwarzają tysiące wierszy danych z Search Console czy crawlera. W modelu rozliczanym za zadanie robi się z tego rachunek, który potrafi przekroczyć koszt narzędzia rankingowego.
n8n rozwiązuje ten problem dwojako. Wersja self hosted na małym VPS kosztuje kilkadziesiąt złotych miesięcznie niezależnie od liczby wykonań, a węzeł Code pozwala wrzucić w środek przepływu zwykły JavaScript. To ostatnie jest ważniejsze, niż się wydaje: dane SEO prawie nigdy nie przychodzą w formacie, w którym chcemy je zapisać. Trzeba je pogrupować, policzyć różnicę względem poprzedniego okresu, odfiltrować szum. W narzędziach bez węzła kodu kończy się to łańcuchem dwudziestu kroków transformujących, w n8n jednym blokiem na dwadzieścia linii. Dokumentacja poszczególnych węzłów jest opisana w oficjalnej dokumentacji n8n.
Jest też argument przeciw. n8n wymaga utrzymania. Aktualizacje potrafią zmienić zachowanie węzła, tokeny OAuth wygasają, a przepływ, który cicho przestał działać, jest gorszy niż brak przepływu, bo daje fałszywe poczucie kontroli. Do tego wrócimy w ostatniej sekcji.
Scenariusz 1: alert o spadku w Search Console
Najbardziej opłacalna automatyzacja w całym zestawie. Cel: dowiedzieć się o spadku ruchu w dniu, w którym nastąpił, a nie po dwóch tygodniach, gdy klient sam zauważy.
Konstrukcja jest prosta. Węzeł Schedule odpala przepływ codziennie rano. Węzeł HTTP Request odpytuje Search Console Analytics API o dane z ostatnich 3 dni oraz o analogiczny okres sprzed tygodnia, z wymiarem page lub query. Węzeł Code liczy różnicę kliknięć i wyświetleń, odfiltrowuje wszystko poniżej progu istotności i zwraca tylko te pozycje, które spadły o więcej niż zadany procent. Jeśli lista jest pusta, przepływ kończy się bez powiadomienia. Jeśli nie, leci wiadomość na Slacka albo mail.
Dwie rzeczy decydują o tym, czy alert będzie użyteczny czy zignorowany. Pierwsza to opóźnienie danych. Search Console raportuje z przesunięciem 2–3 dni, więc porównywanie wczoraj do przedwczoraj daje wyłącznie fałszywe alarmy z niekompletnych danych. Bezpieczne okno to trzydniowe średnie przesunięte o trzy dni wstecz.
Druga to próg. Alert ustawiony na spadek o 10 procent na pojedynczym adresie odezwie się codziennie i po tygodniu przestanie być czytany. Realistyczny próg to spadek minimum 30 procent przy co najmniej 50 kliknięciach w okresie bazowym. Strony z ruchem jednocyfrowym poruszają się losowo i nie ma sensu ich pilnować.
Scenariusz 2: monitoring pozycji kluczowych fraz
Search Console podaje uśrednioną pozycję po wszystkich lokalizacjach i urządzeniach, co przy frazach lokalnych bywa mylące. Własny monitoring pozycji rozwiązuje ten problem, ale wymaga źródła danych SERP.
Przepływ wygląda tak: lista fraz w arkuszu Google albo w bazie, węzeł Schedule odpalany raz dziennie lub raz na trzy dni, węzeł HTTP Request odpytujący API dostawcy danych SERP, węzeł Code normalizujący wynik do struktury z frazą, pozycją, adresem i datą, węzeł zapisujący do arkusza lub bazy. Na końcu warunek: jeśli któraś fraza wypadła z pierwszej dziesiątki albo do niej weszła, wyślij powiadomienie.
Pułapka jest tutaj kosztowa. Sto fraz sprawdzanych codziennie to trzy tysiące zapytań miesięcznie, a przy kilku klientach liczba rośnie liniowo. Częstotliwość warto różnicować: frazy transakcyjne codziennie, informacyjne raz na tydzień. Druga pułapka to scraping bezpośrednio z wyszukiwarki, który łamie regulamin i kończy się blokadą adresu IP serwera. Płatne API dostawców danych rozwiązuje jedno i drugie.
Scenariusz 3: wykrywanie zepsutych linków
Linki wewnętrzne psują się cicho. Ktoś zmienia slug, ktoś usuwa wpis, ktoś przenosi kategorię, a dwadzieścia artykułów prowadzi teraz w pustkę. Nikt tego nie zauważa, dopóki nie zrobi audytu.
Automatyzacja: węzeł Schedule raz w tygodniu, węzeł pobierający listę adresów z sitemapy XML, węzeł HTTP Request wykonujący żądanie na każdy adres z ustawionym niskim limitem czasu, węzeł Code zbierający wszystko, co zwróciło kod inny niż 200 lub 301. Wynik trafia do arkusza z datą i kodem odpowiedzi.
Warto dorzucić drugi poziom: pobranie treści każdej strony i wyciągnięcie z niej odnośników wewnętrznych, a następnie sprawdzenie ich osobno. Sitemapa pokazuje bowiem tylko to, co istnieje, a nie to, do czego prowadzą odnośniki w treści. Ten sam mechanizm przydaje się przy weryfikacji przejmowanych domen, gdzie kondycja profilu odnośników jest jednym z sygnałów opisanych w tekście o tym, jak wygląda analiza domeny przed zakupem.
Uwaga techniczna: część serwerów zwraca kod 200 również dla nieistniejących adresów, serwując stronę błędu w treści. Sam status HTTP wtedy nie wystarczy i trzeba dodatkowo sprawdzić, czy w odpowiedzi nie ma charakterystycznego fragmentu strony 404 albo czy długość treści nie jest podejrzanie mała.
Scenariusz 4: kontrola indeksacji nowych wpisów
Publikacja nie kończy pracy. Wpis, który nie został pobrany przez robota, nie istnieje, a przy serwisach z ograniczonym budżetem indeksowania dotyczy to sporej części nowych treści.
Przepływ: węzeł Schedule raz dziennie, pobranie z API systemu zarządzania treścią wpisów opublikowanych w ciągu ostatnich 14 dni, dla każdego z nich zapytanie do URL Inspection API o stan indeksacji, węzeł Code dzielący wynik na trzy kategorie: zaindeksowany, pobrany ale niezaindeksowany, nieznany wyszukiwarce. Raport idzie mailem raz w tygodniu, ale wpis starszy niż 10 dni ze statusem nieznanym generuje alert od razu.
Limit URL Inspection API wynosi 2000 zapytań dziennie na usługę, co przy monitorowaniu wyłącznie świeżych wpisów jest wartością nieosiągalną. Znaczenie ma natomiast opóźnienie samego API, które raportuje stan z 1–2 dni wstecz, więc zerowy wynik na wpisie opublikowanym wczoraj nie oznacza problemu. Szczegóły limitów i pól odpowiedzi opisuje dokumentacja Google Search Central.
Scenariusz 5: monitoring cytowań w AI
Widoczność przestała kończyć się na dziesięciu niebieskich linkach. Modele językowe odpowiadają na pytania, cytując konkretne źródła, a bycie jednym z nich generuje ruch i, co ważniejsze, buduje rozpoznawalność w kanale, którego klasyczne narzędzia rankingowe w ogóle nie widzą.
Automatyzacja polega na regularnym zadawaniu tego samego zestawu pytań przez API modelu i sprawdzaniu, czy w odpowiedzi pojawia się nasza domena albo nazwa marki. Węzeł Schedule raz w tygodniu, lista 20–50 pytań w arkuszu, węzeł HTTP Request wysyłający każde z nich do modelu z włączonym wyszukiwaniem, węzeł Code przeszukujący odpowiedź pod kątem domeny i domen konkurencji, zapis wyniku z datą.
Po kilku tygodniach powstaje z tego szereg czasowy pokazujący, czyje treści modele traktują jako źródło w danym temacie. Interpretacja tych danych i wnioski na temat tego, co odróżnia cytowane strony od niecytowanych, to osobny temat, który rozwija tekst o tym, jak wygląda analiza konkurencji pod AI.
Ograniczenie jest istotne: odpowiedzi modeli są niedeterministyczne, więc pojedynczy pomiar nic nie mówi. Sens ma dopiero trend liczony na wielu pytaniach i wielu tygodniach, najlepiej przy zadawaniu każdego pytania w kilku powtórzeniach.
Scenariusz 6: automatyczny raport miesięczny
Raport dla klienta to zwykle te same dane w tym samym układzie, przeklejane ręcznie przez dwie godziny. Kandydat na automatyzację numer jeden pod względem odzyskanego czasu.
Przepływ startuje pierwszego dnia miesiąca. Pobiera dane z Search Console za miesiąc poprzedni i za miesiąc go poprzedzający, dane sesji z analityki, zapisane pozycje ze scenariusza drugiego oraz listę opublikowanych w tym okresie treści. Węzeł Code składa z tego strukturę z wartościami, zmianami procentowymi i pięcioma największymi wzrostami oraz spadkami. Wynik trafia do szablonu dokumentu albo do arkusza, a stamtąd mailem do odbiorcy.
| Scenariusz | Częstotliwość | Odzyskany czas miesięcznie |
|---|---|---|
| Alert o spadku w GSC | codziennie | 2–3 h |
| Monitoring pozycji | codziennie | 1–2 h |
| Zepsute linki | tygodniowo | 1 h |
| Kontrola indeksacji | codziennie | 2 h |
| Cytowania w AI | tygodniowo | 3 h |
| Raport miesięczny | miesięcznie | 2–4 h |
Jedna zasada oszczędza tu sporo nerwów: automat składa liczby, człowiek pisze komentarz. Raport bez interpretacji jest zrzutem danych, za który nikt nie chce płacić.
Koszty i utrzymanie przepływów
Rachunek przy sześciu przepływach i jednym średnim serwisie wygląda mniej więcej tak: VPS pod n8n od 20 do 60 złotych miesięcznie, API danych SERP od 50 do 300 złotych zależnie od liczby fraz, API modelu językowego do monitoringu cytowań około 20 do 80 złotych. Search Console API i URL Inspection API są bezpłatne w ramach limitów. Razem zwykle mniej niż koszt jednej licencji na narzędzie rankingowe.
Utrzymanie jest realnym kosztem, którego nikt nie wycenia. Trzy rzeczy warto zrobić od razu.
- Włączyć w n8n powiadomienie o błędzie wykonania. Przepływ, który przestał działać w ciszy, jest gorszy niż jego brak.
- Dodać do każdego przepływu zapis znacznika czasu ostatniego udanego wykonania i osobny przepływ kontrolny, który raz w tygodniu sprawdza, czy któryś z nich nie milczy zbyt długo.
- Trzymać przepływy wyeksportowane do plików JSON w repozytorium. Odtworzenie dwudziestu automatyzacji z pamięci po awarii serwera zajmuje kilka dni.
Warto też wdrażać je pojedynczo. Najczęstszy błąd polega na zbudowaniu w jeden weekend wszystkich sześciu przepływów naraz, a potem na porzuceniu ich, bo żaden nie działa do końca poprawnie i nie wiadomo, od którego zacząć naprawę. Jeden przepływ, dwa tygodnie obserwacji, korekta progów, dopiero potem następny.
FAQ
Czy do zbudowania tych przepływów trzeba umieć programować?
Cztery z sześciu scenariuszy da się złożyć z gotowych węzłów bez ani jednej linii kodu. Alert o spadku w Search Console i monitoring cytowań w AI wymagają prostego JavaScriptu w węźle Code, na poziomie pętli i porównania dwóch liczb. To kilkanaście linii, które można napisać z pomocą modelu językowego.
n8n w chmurze czy na własnym serwerze?
Na start wersja chmurowa, bo pozwala sprawdzić pomysł bez konfiguracji serwera. Przy większej liczbie wykonań opłaca się przejście na self hosted, gdzie koszt przestaje zależeć od liczby operacji. Migracja polega na wyeksportowaniu przepływów do JSON i zaimportowaniu ich w nowej instancji, więc nie jest to decyzja nieodwracalna.
Jak często powinny się odpalać alerty z Search Console?
Raz dziennie wystarcza. Częstsze odpytywanie nie ma sensu, bo dane w Search Console aktualizują się z opóźnieniem 2–3 dni i w ciągu doby po prostu się nie zmieniają.
Czy automatyczne sprawdzanie pozycji jest zgodne z regulaminem wyszukiwarki?
Pobieranie wyników bezpośrednio ze strony wyszukiwarki nie jest. Korzystanie z płatnych API dostawców danych SERP przenosi ten problem na ich stronę i jest standardową praktyką rynkową. Dane z Search Console API są w pełni legalne, bo to własne dane serwisu.
Co zrobić, gdy przepływ przestanie działać po aktualizacji n8n?
Najczęstsza przyczyna to zmiana nazw pól w węźle albo wygasłe poświadczenia OAuth. Warto zaglądać do historii wykonań, gdzie widać dokładnie, na którym węźle przepływ się zatrzymał i jaki błąd zwrócił. Aktualizacje instancji self hosted lepiej robić ręcznie, po sprawdzeniu listy zmian, niż automatycznie.
