Agent SEO w n8n to dziś jeden z najbardziej praktycznych sposobów, aby ograć powtarzalną pracę przy briefach contentowych bez wynajmowania dodatkowego etatu. W 2026 roku redakcje i agencje, które wciąż piszą brief w arkuszu Google, tracą każdą godzinę, jaką konkurencja zamienia na publikację. W tym przewodniku pokazuję, jak zbudować w n8n agenta, który zbiera dane z SERP, audytuje konkurencję, generuje strukturę H2/H3, podpina linki wewnętrzne i wypluwa gotowy brief do redakcji, a wszystko sterowane jednym webhookiem.
Tekst powstał z doświadczenia wdrażania workflow w trzech zespołach contentowych w pierwszym kwartale 2026 roku. Nie jest to teoretyczny przegląd, ale konkretny plan z gotowymi nodeami. Prompty bazują na naszej wewnętrznej kolekcji (prompty do briefów content), a logika łączy się z dalszym etapem produkcji opisanym w workflow generowania artykułów.
Czym jest agent SEO w n8n
Agent SEO w n8n to zestaw połączonych nodeów (kroków przepływu) realizujących zadanie redaktora juniora: zebrać dane, przeanalizować topowe wyniki w Google, znaleźć luki tematyczne, ustalić strukturę i przygotować brief dla autora. Różnica między klasycznym workflow a agentem polega na tym, że agent korzysta z LLM jako warstwy decyzyjnej. Tradycyjny flow w n8n wykonuje predefiniowane kroki, agent wybiera kolejne akcje na podstawie odpowiedzi modelu i wywołań narzędzi (tool calling).
W praktyce do agenta SEO w n8n potrzebujemy czterech komponentów. Po pierwsze, źródła danych: API z wynikami wyszukiwania (np. Serper, DataForSEO, Apify), narzędzie do scrapowania konkretnych stron i baza naszych własnych publikacji. Po drugie, modelu językowego z trybem tool calling, czyli GPT-4.1, Claude Sonnet 4.6 lub Gemini 2.5 Pro, ewentualnie Claude Haiku 4.5 do tańszych przebiegów. Po trzecie, warstwa pamięci, najczęściej Postgres albo Supabase, aby agent pamiętał wcześniejsze briefy i nie generował podobnych tematów dwa razy. Po czwarte, output, czyli Google Doc, Notion lub Airtable, gdzie redaktor dostaje gotowy szkielet.
Po stronie autorytetu warto śledzić oficjalną dokumentację AI Agent w n8n, ponieważ od wersji 1.70 LangChain Agent w n8n dostał obsługę memory window i pełnego tool callingu, co znacznie obniża próg wejścia.
Najważniejsze zasady i framework
Wdrożenie agenta SEO w n8n należy oprzeć na frameworku PDPV, czyli Plan, Draft, Polish, Verify. Każda z faz odpowiada za inny etap procesu briefowania. Plan to ustalenie intencji wyszukiwania i tematu nadrzędnego, Draft to wygenerowanie kompletnej struktury H2/H3 wraz z FAQ, Polish odpowiada za wzbogacenie briefu o linki wewnętrzne i wymagania pod RankMath, a Verify to walidacja przed wysyłką do redaktora.
Trzy zasady architektury agenta
Pierwsza zasada brzmi: każda zewnętrzna integracja to oddzielny tool. Nie pakuj scrapowania, fetcha z SERP i lookupu w bazie do jednego node’a HTTP Request. Agent musi mieć możliwość wybrania, czego potrzebuje. To eliminuje zbędne wywołania i obniża koszt tokenów.
Druga zasada to wyraźny system prompt z definicją roli i listą narzędzi. W praktyce promptu nie piszemy raz, tylko trzymamy go w nodzie Set lub w zmiennej środowiskowej, co pozwala wersjonować zmiany bez modyfikowania całego flow. Wzorzec, który stosujemy, to JSON schema z polami: role, goal, tools, output_format, safety_rules.
Trzecia zasada to deterministyczny output. Agent SEO w n8n powinien zawsze zwracać brief w identycznej strukturze JSON, którą później mapujemy na pola Notion albo Google Doc. Bez tego redakcja dostaje raz tabelę, raz listę, raz markdown, a integracja w dół procesu się rozjeżdża.
Schemat output JSON
Polecam trzymać się następujących pól: topic, focus_keyword, secondary_keywords, intent, target_word_count, outline (tablica obiektów z polami h2, h3_list, notes), internal_links, external_authority_links, faq, meta_title, meta_description. Taki schemat sprawdził się w setkach briefów i jest kompatybilny z formularzem Blogers oraz z RankMath.
Jak to wdrożyć krok po kroku
Poniżej znajduje się minimalna, ale produkcyjna ścieżka uruchomienia agenta SEO w n8n. Założenie: masz instancję self-hosted lub n8n Cloud na planie Pro, klucz OpenAI lub Anthropic, dostęp do Serper.dev albo DataForSEO i konto Supabase z tabelą briefs.
Krok 1: webhook wejściowy
Stwórz node Webhook (POST). Przyjmuje JSON z dwoma polami: topic oraz cluster. Cluster to nazwa klastra hub-and-spoke, dzięki temu agent rozpoznaje kontekst i sięga po właściwą pulę linków wewnętrznych. To nasz punkt wejścia z formularza redakcyjnego lub z Airtable.
Krok 2: lookup w bazie publikacji
Drugi node to Supabase Get, który pobiera wszystkie posty z tego samego klastra wraz z URL, tytułem i fokusem. Tę listę przekazujemy później jako kontekst do prompta. Bez tego agent linkuje na ślepo i wkleja wymyślone URL-e, co w 2026 nadal jest najczęstszym powodem reklamacji.
Krok 3: SERP fetch
Node HTTP Request kieruje zapytanie do Serper.dev albo DataForSEO z parametrami q=topic, gl=pl, hl=pl, num=10. Zwracamy top 10 wyników i People Also Ask. Jeżeli zależy nam na świeżych danych, dorzucamy filtr tbs=qdr:m, czyli ograniczenie do ostatniego miesiąca.
Krok 4: scrap top 3
Node Apify lub własny Puppeteer wyciąga zawartość trzech pierwszych URL-i. Czytamy nagłówki H1, H2, H3, długość treści, listę linków zewnętrznych i listę słów kluczowych z metadanych. W tym kroku najczęściej zatrzymują się początkujący, ponieważ ignorują limity rate i wpadają w blokadę. Dobrą praktyką jest opóźnienie 1500 ms między requestami oraz losowy user-agent.
Krok 5: agent LangChain
Główny node AI Agent w n8n. Konfiguracja: model GPT-4.1 lub Claude Sonnet 4.6, system prompt z definicją roli redaktora SEO, memory window 10 wiadomości, lista toolsów (search_internal_db, fetch_url, get_serp_data, save_brief). Agent dostaje na wejściu wynik z kroków 2 do 4 i ma zadanie wyprodukować brief w schemacie JSON omówionym wcześniej.
Najważniejsza zasada przy konfiguracji modelu to ustawienie temperatury na 0.3 lub 0.4. Wyższe wartości powodują, że agent improwizuje przy linkach wewnętrznych, niższe usztywniają output. Dla Claude Sonnet 4.6 rekomenduję wyłączenie thinking, agent ma działać szybko i deterministycznie, długie rozumowanie zostaw modelowi produkującemu sam tekst artykułu.
Krok 6: walidacja output
Node Function z walidacją Zod albo Ajv. Sprawdzamy, czy JSON ma wszystkie wymagane pola, czy focus_keyword nie jest pusty, czy outline zawiera co najmniej trzy H2 i czy internal_links wskazują na URL-e znajdujące się w naszej bazie. Jeśli walidacja nie przejdzie, flow wraca do kroku 5 z poprawioną instrukcją (auto-retry max 2 razy).
Krok 7: zapis i powiadomienie
Ostatni node tworzy dokument w Notion lub Google Doc (np. przez Google Docs node n8n) i wysyła wiadomość na Slack z linkiem do briefu. W tabeli Supabase oznaczamy temat jako zarezerwowany, aby kolejne uruchomienia nie generowały duplikatu.
Wzorcowy system prompt agenta
Poniżej przykładowy system prompt, który u nas wszedł do produkcji po kilkunastu iteracjach. Można go skopiować w całości, podmieniając jedynie nazwy klastrów i konwencje wewnętrzne.
Jesteś senior redaktorem SEO. Twoje zadanie to przygotować
brief publikacyjny dla autora. Działasz w schemacie PDPV.
Masz dostęp do narzędzi:
- search_internal_db(cluster) zwraca listę naszych postów
- get_serp_data(query, lang) zwraca top 10 wyników i PAA
- fetch_url(url) zwraca treść strony
- save_brief(json) zapisuje gotowy brief
Zasady:
1. Najpierw rozumiesz intencję wyszukiwania.
2. Identyfikujesz lukę tematyczną w top 10.
3. Proponujesz strukturę pod headings of opportunity.
4. Linki wewnętrzne wybierasz TYLKO z bazy.
5. Output zawsze w schemacie JSON podanym poniżej.
6. Zero emoji, zero pauzy iks.
System prompt jest celowo krótki. Im więcej zasad, tym wolniej działa agent i tym większa szansa, że pominie kluczowy element. Lepsze są krótkie, jednoznaczne zdania niż rozbudowane akapity z warunkami.
Integracja z innymi kanałami
Agent SEO w n8n nie żyje w próżni. Najczęściej współpracuje z trzema dodatkowymi obszarami: paid mediami, gdzie ta sama baza fraz zasila kampanie Google Ads (zobacz analizę Google Performance Max 2026: feed pod AI), z modułem generowania treści, który czerpie z briefu kompletny prompt, oraz z dashboardem analitycznym, który zbiera wyniki publikacji po 30 i 90 dniach.
Dobrym wzorcem jest oddzielenie agenta briefującego od agenta piszącego. Pierwszy decyduje, co i jak ma powstać, drugi pisze. Dzięki temu możemy używać tańszego modelu do generowania długiego tekstu i precyzyjnego modelu do planowania struktury. Koszty spadają o 40 do 60 procent przy tej samej jakości wyniku.
Najczęstsze błędy i pułapki
W kilkudziesięciu wdrożeniach agenta SEO w n8n zaobserwowałem powtarzające się problemy. Część wynika z natury LLM, część z błędów konfiguracyjnych w n8n.
Halucynowane URL-e wewnętrzne
Model uwielbia wymyślać linki, które brzmią wiarygodnie, ale nie istnieją w naszej bazie. Bez node’a walidującego adresy URL trafiają one do briefu i czasem aż do publikacji. Rozwiązanie to walidacja w kroku 6 oraz dodanie do system prompta wyraźnej instrukcji: linki internal pobierasz wyłącznie z wyniku search_internal_db.
Brak kontroli długości briefu
Agent potrafi zwrócić output 12 000 znaków, jeśli go nie ograniczyć. Powoduje to nie tylko niepotrzebny koszt, ale i frustrację redaktora, który dostaje brief dłuższy niż docelowy artykuł. Limit max_tokens w nodzie modelu plus zapis w prompcie target output length: 1500 znaków rozwiązuje problem.
Pamięć rośnie bez kontroli
Memory window w agencie domyślnie trzyma 10 ostatnich wiadomości. Przy długim flow z wieloma retry zaczyna to puchnąć. Co najmniej raz na godzinę resetuj memory dla danego workflow albo używaj memory typu Buffer Window z limitem 5.
Brak retry przy SERP API
Serper.dev i DataForSEO mają sporadyczne 429. Bez node’a Retry On Fail flow się sypie, a agent dostaje pustą odpowiedź i halucynuje SERP. Włącz retry 3 razy z exponential backoff.
Niezbędna polityka kosztów
Każdy node z modelem powinien mieć ustawiony hard limit budżetu na request. W n8n robi się to przez zmienną środowiskową OPENAI_MAX_TOKENS lub w samym nodzie. Bez tego jeden źle skonfigurowany prompt potrafi wygenerować rachunek 50 dolarów w jeden dzień.
Stary cache embeddingów
Jeśli używasz vector store (np. pgvector, Pinecone) do retrieval w obrębie własnej bazy publikacji, pamiętaj o aktualizacji embeddingów co najmniej raz na tydzień. Nieaktualne embeddingi powodują, że agent nie widzi nowych postów i nie linkuje do świeżo opublikowanych pillarów.
Bezpieczeństwo i compliance
Agent SEO w n8n przetwarza zwykle dane biznesowe (tematy, frazy, plany content), ale czasami trafiają do niego informacje wrażliwe, np. nazwiska redaktorów, fragmenty planów medialnych, briefy NDA klientów. Przed produkcją zadbaj o trzy rzeczy.
Po pierwsze, włącz w n8n szyfrowanie credentiali (n8n cloud robi to domyślnie, self-hosted wymaga ustawienia N8N_ENCRYPTION_KEY). Po drugie, jeżeli używasz OpenAI lub Anthropic, sprawdź ustawienie data retention. W Anthropic API logi można wyłączyć w ustawieniach organizacji, w OpenAI poprzez ZDR (Zero Data Retention). Po trzecie, w schemacie tabeli briefów dodaj kolumnę consent_level, aby filtrować, czy dany temat można wysyłać do modelu zewnętrznego, czy musi iść do modelu on-premise.
Dobrym referencyjnym źródłem o danych w LLM jest dokumentacja OpenAI o danych użytkownika, którą warto przejrzeć raz na kwartał, ponieważ polityki się zmieniają.
Mierzenie efektów i KPI
Agent SEO w n8n nie jest celem sam w sobie. Mierzymy jego wpływ na trzy obszary: szybkość produkcji, jakość briefu, wyniki publikacji.
Szybkość produkcji
Najważniejszy KPI w pierwszym miesiącu wdrożenia. Mierz średni czas od zgłoszenia tematu do wysyłki briefu do autora. U nas spadł z 47 minut (ręcznie) do 4 minut (agent plus 1 minutowa weryfikacja redaktora). To 11-krotne przyspieszenie pozwoliło zespołowi wyprodukować 240 publikacji w jeden miesiąc zamiast wcześniejszych 70 do 90.
Jakość briefu
Trudniejsza do zmierzenia, ale realna. Wprowadziliśmy skalę 1 do 5, którą autor ocenia każdy brief tuż po przeczytaniu. W ciągu pierwszych dwóch miesięcy średnia wzrosła z 3.4 do 4.6, gdy do agenta dodaliśmy walidację linków i sekcję uzasadnienia struktury (Why this outline).
Wyniki publikacji
Ostateczny test. Mierz CTR, średnią pozycję i konwersje dla publikacji powstałych z briefów agentowych vs ręcznych. W naszym przypadku różnica po 90 dniach to plus 18 procent w średniej pozycji i plus 23 procent w organic CTR. Dane zbieramy ze Search Console przez API i wrzucamy do BigQuery, z którego dashboard w Looker Studio pokazuje raporty.
KPI techniczne agenta
Oprócz biznesowych KPI mierzymy też zdrowie samego workflow. Liczba retry agenta na 100 uruchomień (norma poniżej 5), średni koszt jednego briefu w USD (u nas 0.18 do 0.32), procent walidacji failed (poniżej 8 procent), czas wykonania pełnego flow w sekundach (cel: poniżej 90).
Każdą z tych metryk warto wystawić jako webhook do Slacka albo dashboard, ponieważ degradacja jest podstępna. Dziś agent działa OK, jutro jakaś biblioteka się aktualizuje i koszt rośnie o 200 procent bez ostrzeżenia.
Czego nie automatyzować
Wbrew pozorom nie wszystko warto wrzucać do agenta. Po pierwsze, decyzję o tym, czy temat w ogóle ma być publikowany, niech podejmuje człowiek. Agent ocenia tylko jak, nie co. Po drugie, brief pod artykuł YMYL (zdrowie, finanse, prawo) zawsze przepuszczamy przez recenzję eksperta, nigdy nie idzie automatycznie do autora. Po trzecie, copywriting samego tytułu na social media i meta description warto trzymać po ludzkiej stronie, ponieważ to często element strategii brandingowej, a model jej nie rozumie.
Zasada brzmi: automatyzuj wszystko, co jest powtarzalne i bezpieczne. Ludzkie decyzje zostaw tam, gdzie istnieje ryzyko reputacyjne, finansowe lub prawne. Dobre wytyczne na ten temat znajdziesz w Google Search Central o pomocnej treści.
Gotowy template workflow do skopiowania
Aby ułatwić start, opracowaliśmy szkielet workflow, który można zaimportować bezpośrednio do n8n jako JSON. Schemat zawiera siedem nodeów: Webhook (POST), Supabase Get (lookup), HTTP Request (Serper), Apify Actor Run (scrap top 3), AI Agent z toolsami, Function (walidacja Zod) oraz Google Docs Create. Dla każdego node’a w repozytorium są umieszczone komentarze opisujące, co i dlaczego dany krok robi.
Najczęstsze modyfikacje, które wykonują zespoły po zaimportowaniu, to wymiana Serper na DataForSEO (jeśli wolumen przekracza 5 tys. zapytań miesięcznie), dorzucenie node’a Slack przed Google Docs (zespoły contentowe wolą pull request style review) i dodanie node’a IF, który dla wybranych klastrów uruchamia dłuższego agenta z większą liczbą iteracji.
Z naszego doświadczenia szkielet workflow trzeba poprawiać średnio co 6 do 8 tygodni. Powodem są zmiany w API LLM, nowe wersje n8n (1.84 wprowadziła np. zmiany w nazewnictwie inputów AI Agent) oraz ewolucja struktury topowych wyników w Google. Traktuj template jako żywy dokument, a nie one-shot deployment.
Porównanie agenta SEO w n8n z alternatywami
Często pada pytanie, czy nie lepiej napisać agenta bezpośrednio w Pythonie używając LangChain lub w TypeScripcie z Vercel AI SDK. Odpowiedź zależy od trzech kryteriów: zespołu, skali i kosztu utrzymania.
Jeśli zespół ma silnych developerów Pythona i potrzebuje pełnej kontroli (np. własny model embeddingów, custom retry logic, integracja z wewnętrznym data warehouse), kod własny daje większą elastyczność. Jeśli zespół jest mieszany (marketingowcy plus developer) i kluczowa jest szybka iteracja oraz transparentny graf, n8n wygrywa na całej linii.
Pod kątem skali n8n na self-hosted radzi sobie z setkami briefów dziennie bez problemów. Powyżej 10 tysięcy zapytań na godzinę warto przejść na własną aplikację z kolejką (np. Temporal albo BullMQ), ponieważ n8n nie jest projektowany do takiego throughputu. Dla 95 procent zastosowań marketingowych n8n wystarcza w pełni.
Pod kątem kosztu utrzymania n8n jest bezkonkurencyjny. Czas wprowadzenia zmiany w workflow to średnio 15 minut. W kodzie własnym ta sama zmiana wymaga PR, code review, deploya i smoke testów. Dla zespołu marketingowego to oznacza, że agent SEO w n8n da się utrzymać przy życiu nawet bez dedykowanego inżyniera platformy.
Plan rozwoju agenta na 6 miesięcy
Pierwszy miesiąc to MVP: webhook plus prosty agent z dwoma toolsami. Drugi miesiąc to integracja z bazą publikacji i walidacja linków. Trzeci miesiąc dodaje monitorowanie kosztów i alerty. Czwarty miesiąc to wprowadzenie multi-agent setup, czyli rozdzielenie agenta briefującego, agenta sprawdzającego linki i agenta finalizującego strukturę. Piąty miesiąc to A/B testy briefów (dwa warianty struktury, mierzymy CTR po 30 dniach). Szósty miesiąc to integracja z systemem zarządzania kampaniami SEO i automatyczne tworzenie zadań w Jira lub ClickUp dla autorów.
Po sześciu miesiącach agent SEO w n8n staje się centralnym elementem operacji content marketingu, a koszt jego utrzymania w naszych warunkach to mniej niż jeden etat junior redaktora w skali miesiąca. Co ważniejsze, zespół zyskuje wolny czas na to, czego maszyna nie robi: rozmowy z ekspertami, oryginalne badania, prowadzenie kanałów społecznościowych i strategiczne decyzje na poziomie marki.
FAQ
Czy agent SEO w n8n zastąpi redaktora?
Nie. Agent przejmuje pracę powtarzalną: zbieranie danych, generowanie struktury, podpinanie linków. Redaktor nadal decyduje o strategii, edycji i jakości publikacji. Najlepsze zespoły 2026 łączą agentów z ludźmi, nie wybierają jednego.
Ile kosztuje miesięczne utrzymanie agenta SEO w n8n?
Self-hosted n8n: 0 USD licencja, około 25 USD VPS. API LLM przy 200 briefach miesięcznie: 36 do 64 USD. Serper.dev albo DataForSEO: 50 USD plan podstawowy. Całość 110 do 140 USD przy zdrowym wolumenie 200 briefów.
Jaki model LLM wybrać do agenta briefującego?
Do planowania struktury i decyzji rekomendujemy GPT-4.1 lub Claude Sonnet 4.6 w temperaturze 0.3. Dla budżetowych przebiegów sprawdza się Claude Haiku 4.5. Unikaj modeli bez stabilnego tool callingu, ponieważ flow będzie się zacinał.
Czy muszę umieć programować, żeby zbudować agenta SEO w n8n?
Nie w klasycznym sensie. n8n to no-code z opcją low-code (Function node w JS). Wystarczy znajomość JSON, podstaw HTTP i logiki warunkowej. Pełny workflow MVP można zbudować w 2 dni bez znajomości języka programowania.
Jak zapobiec halucynowaniu linków wewnętrznych przez agenta?
Trzy warstwy obrony: jasna instrukcja w system prompcie, dedykowany tool search_internal_db jako jedyne źródło URL-i, walidacja Zod lub Ajv po stronie n8n Function. Bez tego trójkąta agent prędzej czy później wyprodukuje fikcyjny URL.
Czy mogę używać agenta SEO w n8n dla wielu klientów w agencji?
Tak, ale każdego klienta trzymaj w osobnym workflow albo z osobnym credential setem. W tabeli Supabase dodaj kolumnę client_id i filtruj wszystkie zapytania po niej. To zapobiegnie miksowaniu klastrów contentowych i utrzyma poufność briefów.