Wokół agentów AI narosło sporo obietnic, które nie wytrzymują kontaktu z realnym projektem SEO. Agent nie zastąpi stratega ani nie napisze sam strategii linkowania dla serwisu z kilkuset podstronami. Potrafi natomiast przejąć powtarzalną, dobrze zdefiniowaną pracę operacyjną, która dziś zjada większość godzin w zespole. Ten tekst jest próbą uczciwego podziału: co agent robi wiarygodnie, czego nie warto mu oddawać i jak zbudować pierwszy proces, który przetrwa dłużej niż tydzień entuzjazmu.
Czym różni się agent od zwykłego promptu
Prompt to pojedyncze zapytanie z pojedynczą odpowiedzią. Wysyłasz kontekst, dostajesz tekst, kopiujesz go dalej ręcznie. Agent działa inaczej: dostaje cel, ma dostęp do narzędzi (API, baza, arkusz, przeglądarka) i sam decyduje, w jakiej kolejności ich użyć, żeby ten cel osiągnąć. Między jednym a drugim leży różnica, która w praktyce zmienia wszystko: agent wykonuje pętlę, sprawdza wynik własnego działania i podejmuje kolejny krok na jego podstawie.
Dla SEO oznacza to konkret. Prompt odpowie na pytanie „jakie nagłówki dodać do tego artykułu”. Agent pobierze artykuł z API, pobierze dane z Search Console, porówna zapytania z aktualną strukturą nagłówków, wskaże lukę i zapisze rekomendację w arkuszu, do którego rano zaglądasz. Pierwsze jest pomocą przy jednej stronie. Drugie skaluje się na dwieście.
Warto też nazwać trzeci poziom, bo bywa mylony z agentem: automatyzacja przepływowa, czyli klasyczny workflow w narzędziu typu n8n czy Make. Tam kolejność kroków jest zdefiniowana z góry przez człowieka, model jest tylko jednym z bloków. To rozwiązanie tańsze, bardziej przewidywalne i w wielu zadaniach SEO nadal lepsze niż agent. Jeśli proces da się opisać jako sztywny schemat, opisz go jako sztywny schemat: różnice między dostępnymi platformami rozbieramy w tekście o automatyzacjach SEO w n8n, Make i Zapier. Agenta rezerwuj na sytuacje, w których liczba wariantów jest zbyt duża, żeby wypisać je wszystkie w graf.
Zadania, w których agent jest dziś wiarygodny
Wspólny mianownik zadań, które wychodzą dobrze, jest prosty: wynik da się zweryfikować maszynowo albo w kilkanaście sekund oczami. Poniżej lista procesów, które w naszej praktyce działają stabilnie w produkcji.
- Audyt techniczny w pętli. Agent przechodzi listę adresów, sprawdza status HTTP, kanoniczne, tytuły, opisy, nagłówki H1 i obecność danych strukturalnych, a następnie zwraca tabelę wyjątków. Kryterium poprawności jest binarne, więc halucynacja nie ma się gdzie ukryć.
- Klasyfikacja zapytań z Search Console. Przypisanie tysiąca fraz do intencji, etapu ścieżki i klastra tematycznego to praca, w której model jest szybki, a błąd na pojedynczym wierszu nie wywraca wniosków.
- Wykrywanie kanibalizacji. Agent pobiera pary strona plus zapytanie, szuka fraz obsługiwanych przez więcej niż jeden adres i sprawdza, czy pozycje się przeplatają w czasie.
- Monitoring cytowań w odpowiedziach AI. Odpytywanie modeli o zestaw pytań z branży i zapisywanie, które domeny zostały wskazane, to zadanie czysto mechaniczne. Sposób na zbudowanie takiego pomiaru opisujemy w artykule o automatycznym raportowaniu cytowań AIO.
- Streszczanie i porządkowanie danych wejściowych. Notatki z rozmowy z klientem, dokumentacja produktu, transkrypcje webinarów: agent wyciąga z tego fakty i encje, które potem zasilają brief.
- Przygotowanie briefu redakcyjnego. Nie gotowego tekstu, lecz szkieletu: pytania użytkowników, zakres tematyczny, lista encji do pokrycia, propozycje linków wewnętrznych.
Zwróć uwagę, że w każdym z tych przypadków agent produkuje dane do decyzji, a nie samą decyzję. To nie przypadek, tylko warunek, przy którym automatyzacja zostaje w firmie na dłużej.
Zadania, których nie warto mu oddawać
Lista rzeczy, które kuszą, ale kosztują więcej niż dają, jest równie ważna.
Publikacja tekstu bez czytania przez człowieka. Model potrafi napisać poprawne zdania o czymś, czego nie ma. W tekstach eksperckich pojawiają się nieistniejące badania, zmyślone liczby i linki do stron, które nigdy nie powstały. Jeden taki akapit na stronie doradczej kosztuje więcej niż oszczędność z pięćdziesięciu wygenerowanych artykułów.
Decyzje o architekturze serwisu. Scalanie kategorii, przekierowania, wybór adresu kanonicznego dla klastra: to decyzje, których skutki widać po miesiącach i które trudno cofnąć. Agent może przygotować analizę, ale podpis zostaje po stronie człowieka.
Ocena jakości własnej pracy. Model poproszony o ocenę tekstu, który sam napisał, niemal zawsze ocenia go wysoko. Jeśli chcesz oceny, potrzebujesz niezależnego kryterium: danych z narzędzia, drugiego modelu z inną instrukcją albo po prostu redaktora.
Kontakt z zewnętrznymi podmiotami. Mailing do wydawców, odpowiedzi w komentarzach, zgłoszenia do katalogów. Ryzyko reputacyjne jest nieproporcjonalne do zysku czasowego.
Interpretacja wytycznych wyszukiwarki. Modele mieszają stan z 2019 roku ze stanem obecnym. Wytyczne czyta się u źródła, na przykład w dokumentacji Google Search Central, a nie w parafrazie wygenerowanej w locie.
Dostęp do danych: API, MCP i arkusze
Agent bez dostępu do danych jest generatorem prawdopodobnych zdań. Cała wartość pojawia się dopiero wtedy, gdy w pętli krąży prawdziwy wiersz z prawdziwego raportu. Masz trzy praktyczne drogi, różniące się progiem wejścia.
Arkusz jako warstwa pośrednia. Najprostszy start. Eksportujesz dane z Search Console i Analytics do arkusza, agent czyta arkusz i dopisuje kolumny z wnioskami. Zaletą jest pełna przejrzystość: widzisz dokładnie te same liczby co model. Wadą ręczny eksport i opóźnienie danych.
Bezpośrednie API. Search Console, Analytics, CMS i narzędzie do monitoringu pozycji mają własne interfejsy. Agent dostaje klucz z minimalnym zakresem uprawnień i pobiera dane sam. To wariant docelowy dla procesów, które mają działać codziennie bez udziału człowieka.
MCP jako wspólny protokół. Model Context Protocol standaryzuje sposób, w jaki model sięga po zewnętrzne źródła i narzędzia, dzięki czemu nie piszesz osobnej integracji dla każdego asystenta. Specyfikacja jest otwarta i opisana w dokumentacji Model Context Protocol. W praktyce MCP najbardziej opłaca się wtedy, gdy to samo źródło danych ma obsługiwać kilka różnych narzędzi.
Niezależnie od wybranej drogi obowiązuje jedna zasada: dostęp tylko do odczytu, dopóki proces nie przejdzie kilku tygodni obserwacji. Uprawnienia do zapisu w CMS dopisujesz na końcu, nie na początku.
Kontrola jakości i punkty zatwierdzania
Największy błąd przy wdrażaniu agentów polega na projektowaniu procesu bez miejsc, w których człowiek mówi „tak”. Bez nich nie da się odróżnić sytuacji, w której proces działa, od tej, w której od dwóch tygodni produkuje śmieci.
Dobrze zaprojektowany proces ma trzy rodzaje bramek. Pierwsza to walidacja formatu, wykonywana maszynowo tuż po odpowiedzi modelu: czy wynik jest poprawnym JSON, czy wszystkie wymagane pola istnieją, czy liczby mieszczą się w oczekiwanym zakresie. Druga to walidacja faktu: każdy adres URL podany przez agenta sprawdzasz zapytaniem HEAD, każdą liczbę porównujesz ze źródłem. Trzecia to akceptacja merytoryczna przez człowieka, zawsze przed publikacją czegokolwiek widocznego dla użytkownika.
Przydatny jest też rejestr działań. Jeśli agent zapisuje, co zrobił, jakich danych użył i jaki był koszt kroku, to po miesiącu masz materiał do optymalizacji i dowód, gdy coś pójdzie nie tak. Log traktuj jak część systemu, a nie dodatek.
| Bramka | Kto wykonuje | Co blokuje |
|---|---|---|
| Walidacja formatu | skrypt | uszkodzone odpowiedzi, brakujące pola |
| Walidacja faktu | skrypt | zmyślone adresy i liczby |
| Akceptacja merytoryczna | człowiek | treści sprzeczne ze strategią |
Koszty: tokeny, limity i czas pracy
Koszt agenta rozkłada się na trzy składniki i tylko jeden z nich widać na fakturze. Pierwszy to tokeny. Agent zużywa ich wielokrotnie więcej niż pojedynczy prompt, bo każdy krok pętli niesie ze sobą całą dotychczasową historię. Proces, który w wersji jednorazowej kosztuje grosze, w wersji agentowej potrafi kosztować kilkadziesiąt razy więcej.
Drugi składnik to limity po stronie źródeł danych. Search Console, Analytics i większość narzędzi SEO mają dzienne kwoty zapytań. Agent, który w pętli odpytuje API bez pamięci podręcznej, wyczerpie kwotę zespołu przed południem. Warstwa cache na poziomie doby rozwiązuje ten problem prawie w całości.
Trzeci, najczęściej pomijany, to czas ludzi. Napisanie instrukcji, przetestowanie jej na dwudziestu przypadkach i utrzymanie po zmianie modelu to realne godziny. Rozsądny próg wygląda tak: automatyzuj zadanie, które wykonujesz co najmniej raz w tygodniu i które zajmuje co najmniej dwadzieścia minut. Poniżej tego progu ręczna robota jest po prostu tańsza.
Praktyczne sposoby na ograniczenie rachunku: skracaj kontekst do tego, co faktycznie potrzebne w danym kroku, dziel duże zadania na mniejsze wywołania zamiast jednej długiej pętli, ustawiaj twardy limit kroków, a do zadań klasyfikacyjnych używaj mniejszych modeli. Różnice w kosztach i możliwościach poszczególnych platform zebraliśmy w scorecardzie dwunastu narzędzi AIO.
Pierwszy proces do wdrożenia w tydzień
Zamiast budować uniwersalnego asystenta, wdroż jeden wąski proces i doprowadź go do stanu, w którym działa bez nadzoru. Dobry kandydat: cotygodniowy raport stron tracących widoczność.
- Dzień pierwszy. Zdefiniuj wejście i wyjście. Wejście: eksport zapytań i stron z Search Console za ostatnie 28 dni i za poprzednie 28 dni. Wyjście: tabela stron ze spadkiem kliknięć powyżej progu, z przypisaną prawdopodobną przyczyną.
- Dzień drugi. Przygotuj dane ręcznie i przepuść je przez model jeden raz. Bez automatyzacji, bez pętli. Sprawdzasz tylko, czy odpowiedź ma sens i czy format jest użyteczny.
- Dzień trzeci. Ustal instrukcję i schemat odpowiedzi. Wymuś JSON z polami: adres, zmiana kliknięć, zmiana pozycji, hipoteza, sugerowane działanie. Odrzucaj odpowiedzi niezgodne ze schematem.
- Dzień czwarty. Podłącz źródło danych automatycznie i dodaj walidację faktów: każdy adres w odpowiedzi musi istnieć w eksporcie i zwracać status 200.
- Dzień piąty. Uruchom na pełnym zbiorze, przejrzyj dwadzieścia losowych wierszy i policz odsetek trafnych hipotez. Poniżej siedemdziesięciu procent wracasz do instrukcji.
- Dzień szósty. Dodaj harmonogram, powiadomienie i log. Raport ma trafiać w to samo miejsce o tej samej porze.
- Dzień siódmy. Opisz proces w dwóch akapitach: co robi, czego nie robi, kto go naprawia. Bez tego opisu proces umiera przy pierwszej zmianie w zespole.
Po dwóch pełnych cyklach będziesz wiedział, czy to zadanie w ogóle warto było automatyzować. Dopiero wtedy dokładaj drugi proces.
Ryzyka i zabezpieczenia
Najpoważniejsze ryzyko to nie halucynacja, lecz cicha degradacja. Agent działa, raporty przychodzą, nikt ich nie czyta uważnie, a jakość wniosków spada powoli przez trzy miesiące. Zabezpieczenie jest nudne i skuteczne: raz w miesiącu ktoś ręcznie weryfikuje dziesięć losowych wyników i zapisuje odsetek trafień.
Drugie ryzyko to wstrzyknięcie instrukcji przez treść. Agent czytający cudze strony może natrafić na tekst, który udaje polecenie systemowe. Jeśli ten sam agent ma uprawnienia do zapisu w CMS, konsekwencje wykraczają poza błędny raport. Rozdzielaj role: proces czytający zewnętrzne treści nie powinien mieć żadnych uprawnień zapisu.
Trzecie to wyciek danych. Dane klienta trafiające do zewnętrznego modelu wymagają zapisu w umowie i świadomej decyzji, a nie milczącej zgody. Sprawdź politykę retencji dostawcy i wyłącz uczenie na danych, jeśli jest taka opcja.
Czwarte to zależność od jednego dostawcy. Zmiana modelu potrafi zmienić zachowanie procesu z dnia na dzień. Trzymaj instrukcje w repozytorium, wersjonuj je i utrzymuj zestaw testowy dwudziestu przypadków, który przepuszczasz przy każdej zmianie modelu. To dziesięć minut pracy, które ratują tydzień diagnozy.
Podsumowując: agent AI jest dziś dobrym pracownikiem operacyjnym i złym decydentem. Traktuj go jak młodszego analityka, któremu dajesz wąski zakres, jasne kryterium poprawności i regularną kontrolę. W tej roli realnie oddaje kilkanaście godzin miesięcznie. W każdej innej generuje pracę zamiast ją zabierać.
FAQ
Czy agent AI zastąpi specjalistę SEO?
Nie w obecnym stanie technologii. Agent przejmuje pracę operacyjną, którą da się zweryfikować maszynowo: audyty, klasyfikacje, monitoring, przygotowanie danych. Decyzje strategiczne, ocena jakości treści i odpowiedzialność za skutki zostają po stronie człowieka. Realny efekt to przesunięcie proporcji czasu, a nie likwidacja roli.
Od jakiego zadania najlepiej zacząć?
Od cotygodniowego raportu stron tracących widoczność albo od audytu technicznego listy adresów. Oba mają jasne kryterium poprawności, powtarzają się regularnie i nie publikują niczego widocznego dla użytkownika, więc błąd jest tani.
Czy potrzebuję umiejętności programowania?
Do pierwszego procesu nie. Wystarczy narzędzie typu n8n lub Make oraz arkusz jako warstwa danych. Programowanie zaczyna się opłacać przy trzecim czy czwartym procesie, gdy koszt utrzymania klikanych przepływów przekracza koszt napisania skryptu.
Ile kosztuje utrzymanie takiego procesu?
Rachunek za tokeny w prostym raporcie tygodniowym dla średniego serwisu mieści się zwykle w kilkunastu złotych miesięcznie. Istotniejszy jest koszt ludzki: licz od 2 do 4 godzin miesięcznie na kontrolę jakości i poprawki po zmianach modelu.
Jak sprawdzić, czy agent nie zmyśla?
Wymuś format odpowiedzi ze schematem, a następnie zweryfikuj każdy element maszynowo: adresy zapytaniem HEAD, liczby przez porównanie ze źródłem, nazwy encji przez dopasowanie do listy. Wszystko, czego nie da się sprawdzić automatycznie, musi przeczytać człowiek przed publikacją.
Czy MCP jest konieczne do pracy z agentami?
Nie. MCP upraszcza podłączanie źródeł danych do wielu narzędzi naraz, ale pojedynczy proces obsłużysz zwykłym wywołaniem API albo eksportem do arkusza. Po MCP sięgaj wtedy, gdy te same dane mają zasilać kilka różnych asystentów.