Agentic SEO – jak przygotować stronę na wyszukiwarki, w których agent AI nie tylko odpowiada, ale sam porównuje oferty i wykonuje zadania?

Agent AI nie wybierze sklepu dlatego, że karta produktu ma efektowną animację. Wybierze ofertę, której cenę, dostępność, termin dostawy, wariant, warunki zwrotu i dane sprzedawcy da się ustalić bez zgadywania. A gdy ma wykonać zadanie — dodać produkt do koszyka, obliczyć dostawę albo rozpocząć rezerwację — formularz nie może rozsypać się po pierwszym błędzie walidacji.

To właśnie oznacza Agentic SEO. Nie jest to nowy znacznik, osobny indeks ani oficjalny czynnik rankingowy. To praktyczna gotowość strony na wyszukiwarki, które wykonują serię zapytań, porównują wiele źródeł, odrzucają oferty niespełniające warunków, a następnie próbują przeprowadzić użytkownika przez kolejne kroki zadania. Google podkreśla, że dla funkcji AI nadal obowiązują podstawy klasycznego SEO: indeksowanie, jakość treści, dostępność danych i poprawna architektura strony. Nie istnieje specjalny schemat danych, który gwarantowałby widoczność w odpowiedziach generatywnych.

Zmiana jest jednak realna. Google AI Mode działa w Polsce od 8 października 2025 roku, a pierwsi użytkownicy formułują w nim zapytania dwa–trzy razy dłuższe niż w tradycyjnej wyszukiwarce. Nie pytają już wyłącznie o „dobry ekspres do kawy”, ale o „automatyczny ekspres do 2500 zł, nie szerszy niż 25 cm, z łatwym czyszczeniem i dostawą do piątku”. Agent musi rozłożyć takie polecenie na kilka wyszukiwań i sprawdzić każdy warunek.

Stan na 8 sierpnia 2026 roku nie uzasadnia jednak budowania kosztownego „checkoutu dla AI” przez każdy polski sklep. Zakupy w ChatGPT są nadal dostępne przede wszystkim w Stanach Zjednoczonych, a OpenAI przenosi ciężar z osobnego Instant Checkout na lepsze odkrywanie produktów i finalizowanie transakcji na stronie sprzedawcy. Dla firmy działającej wyłącznie w Polsce ważniejsze są dziś: poprawny feed, zgodność ceny i stanów magazynowych, dostępny formularz oraz odporność strony na ruch botów i agentów.

Od linku do decyzji: jak agent AI ocenia ofertę

Klasyczna wyszukiwarka zwykle prowadziła użytkownika do dokumentu. Agent ma doprowadzić go do wyniku. Różnica jest fundamentalna.

Przy zapytaniu „buty trekkingowe” można było walczyć o pozycję ogólnym poradnikiem i dobrze zoptymalizowaną kategorią. Przy poleceniu „znajdź wodoodporne buty trekkingowe męskie w rozmiarze 44, do 600 zł, z dostawą do Gdańska przed 14 sierpnia i możliwością bezpłatnego zwrotu” sama pozycja strony nie wystarczy.

Agent musi kolejno ustalić:

• czy produkt faktycznie występuje w rozmiarze 44,
• czy podana cena dotyczy tego wariantu,
• czy produkt jest dostępny teraz, a nie „na zamówienie”,
• ile kosztuje dostawa pod konkretny kod pocztowy,
• jaki jest przewidywany dzień doręczenia,
• czy zwrot jest bezpłatny i w jakim terminie,
• czy sprzedawca jest możliwy do zidentyfikowania,
• czy wybrany wariant można dodać do koszyka bez ręcznego obchodzenia przeszkód.

Google opisuje mechanizm query fan-out, czyli automatyczne wykonywanie wielu powiązanych wyszukiwań w celu zebrania informacji potrzebnych do odpowiedzi. Strona może więc zostać oceniona nie tylko na podstawie jednej frazy, lecz także na podstawie odpowiedzi na kilka pytań pomocniczych: o dostawę, parametry, opinie, kompatybilność lub warunki zakupu.

Cztery poziomy gotowości

Najlepiej podzielić prace na cztery poziomy. Nie są równie ważne.

Priorytet 0: strona musi być dostępna i zrozumiała

Agent powinien móc pobrać stronę, zobaczyć treść bez logowania oraz odczytać najważniejsze informacje w kodzie HTML. Cena znajdująca się wyłącznie na grafice, dostępność wyświetlana dopiero po uruchomieniu skryptu albo regulamin zwrotu ukryty w skanie PDF to nie drobne niedociągnięcia. To powód, dla którego oferta może wypaść z porównania.

Priorytet 1: informacje muszą być jednoznaczne i spójne

Ta sama cena powinna występować:

• na karcie produktu,
• w danych strukturalnych,
• w feedzie produktowym,
• w koszyku,
• po wybraniu dostawy.

Jeżeli strona pokazuje 399 zł, JSON-LD zawiera 379 zł, a koszyk nalicza 429 zł, agent nie ma bezpiecznego sposobu wyboru poprawnej wartości. Najgorszy przypadek to cena promocyjna bez daty obowiązywania oraz stan „dostępny”, który po wyborze koloru zmienia się na „wysyłka za 21 dni”.

Priorytet 2: interfejs musi umożliwiać wykonanie zadania

Agent powinien rozpoznać pole adresu, wybór wariantu, przycisk dodania do koszyka i komunikat błędu. Do tego potrzebne są semantyczny HTML, prawidłowe etykiety formularzy, logiczna kolejność fokusu oraz komunikaty, które da się odczytać bez analizy obrazu.

Priorytet 3: dopiero wtedy integracje agentowe i protokoły

Feed przekazywany bezpośrednio do platformy, interfejs API do rezerwacji czy integracja z Universal Commerce Protocol mogą skrócić drogę do transakcji. Nie naprawią jednak nieaktualnego magazynu, błędnej ceny ani sklepu, który blokuje boty kodem 403.

Agent potrzebuje danych decyzyjnych, nie kolejnych akapitów SEO

Wiele firm odpowiada na rozwój AI produkowaniem jeszcze większej liczby tekstów. To zwykle zły pierwszy ruch. Dodatkowy opis kategorii nie pomoże, gdy agent nie zna kosztu dostawy albo nie potrafi ustalić, czy produkt pasuje do konkretnego modelu urządzenia.

Dane decyzyjne różnią się zależnie od branży.

Dla sklepu z elektroniką będą to między innymi:

• dokładny numer modelu, GTIN/EAN, MPN i SKU,
• obsługiwane standardy i złącza,
• wymiary, masa i pobór energii,
• okres gwarancji,
• lista kompatybilnych urządzeń,
• cena konkretnego wariantu,
• stan magazynowy oraz data wysyłki.

Dla hotelu lub apartamentu:

• dostępność w konkretnych dniach,
• cena całego pobytu wraz z obowiązkowymi opłatami,
• liczba osób,
• zasady anulowania,
• godziny zameldowania,
• dostępność parkingu,
• warunki pobytu z dziećmi lub zwierzętami.

Dla kancelarii, kliniki albo firmy usługowej:

• zakres usługi,
• cena lub jasna metoda jej obliczania,
• czas realizacji,
• obszar obsługi,
• wymagane dokumenty,
• najbliższy dostępny termin,
• zasady odwołania wizyty,
• sytuacje, w których usługa nie może zostać wykonana.

Formuła „cena ustalana indywidualnie” nie zawsze jest możliwa do uniknięcia. Powinna jednak prowadzić do konkretnego procesu: formularza z określonym zestawem danych, deklarowanego czasu odpowiedzi i informacji, od czego zależy wycena. Agent nie porówna rzetelnie usługi, jeżeli jedyną informacją jest hasło „atrakcyjne ceny”.

Czego nie robić

Nie zaczynaj od pliku llms.txt. Google wprost informuje, że ignoruje ten plik i że jego obecność ani brak nie wpływają na widoczność w wyszukiwarce. Można go traktować jako dokument pomocniczy dla wybranych systemów, ale nie jako zamiennik mapy witryny, indeksowalnego HTML, feedu czy danych strukturalnych.

Nie twórz osobnych stron wyłącznie dla robotów AI. Ukryte instrukcje, niewidoczne bloki tekstu i znaczniki opisujące informacje, których użytkownik nie widzi na stronie, zwiększają ryzyko uznania treści za manipulacyjną. Dane strukturalne powinny odpowiadać zawartości dostępnej dla człowieka.

Nie kupuj obietnicy „pozycjonowania w ChatGPT w 14 dni”. Ani poprawne schema.org, ani feed, ani integracja protokołu zakupowego nie gwarantują polecenia produktu. Google wyraźnie zaznacza, że natywna integracja UCP nie poprawia rankingu oferty.

Dane i interfejs, które agent potrafi odczytać i obsłużyć

Przygotowanie strony trzeba zacząć od technicznego przejścia całej ścieżki: od pobrania dokumentu do potwierdzenia zadania. Sam audyt widoczności w Google Search Console nie wystarczy.

1. Sprawdź, czy roboty nie odbijają się od zabezpieczeń

OpenAI rozdziela roboty używane do różnych celów:

• OAI-SearchBot odpowiada za obecność stron w wynikach wyszukiwania ChatGPT,
• GPTBot służy do zbierania materiałów związanych z trenowaniem modeli,
• ChatGPT-User może odwiedzać stronę w wyniku konkretnego działania użytkownika.

Można pozwolić na wyszukiwanie, a jednocześnie zablokować wykorzystanie treści przez GPTBot:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Zmiana reguł może potrzebować około 24 godzin, zanim zacznie być respektowana. Trzeba też uwzględnić, że robot uruchamiany bezpośrednio przez użytkownika nie zawsze będzie zachowywał się tak samo jak automatyczny crawler. Plik robots.txt nie jest mechanizmem ochrony danych ani panelu klienta — prywatne zasoby należy zabezpieczać uwierzytelnianiem i kontrolą uprawnień.

Sam wpis w robots.txt nie rozwiązuje problemu. W logach serwera lub CDN trzeba sprawdzić, czy Googlebot i OAI-SearchBot otrzymują odpowiedzi 200, a nie:

• 403 po uznaniu ruchu za automatyczny,
• 429 po przekroczeniu limitu,
• stronę CAPTCHA zamiast produktu,
• pusty dokument wymagający uruchomienia JavaScriptu,
• przekierowanie do wyboru kraju lub języka.

Najwięcej problemów powodują agresywne ustawienia Cloudflare, Akamai i innych systemów WAF. Nie należy wyłączać zabezpieczeń globalnie. Lepsza jest kontrolowana reguła dla zweryfikowanego ruchu, monitorowanie adresów publikowanych przez operatora oraz ograniczenie testów CAPTCHA do działań naprawdę ryzykownych. OpenAI zaleca sprawdzanie blokad WAF, kodów 403 i 429 oraz wyzwań JavaScript, gdy crawler nie może pobrać strony.

2. Zbuduj jedno źródło prawdy o ofercie

Dane produktowe powinny pochodzić z jednego systemu nadrzędnego — zwykle ERP, PIM albo platformy e-commerce. Strona, JSON-LD i feed mają być różnymi reprezentacjami tych samych informacji, a nie trzema osobno edytowanymi bazami.

Na karcie produktu i w danych strukturalnych powinny znaleźć się przynajmniej:

• nazwa produktu i wariantu,
• identyfikator SKU,
• marka,
• GTIN/EAN lub MPN, jeśli producent je nadał,
• cena i waluta,
• dostępność,
• adres właściwej strony produktu,
• główne zdjęcie,
• koszt i warunki dostawy,
• zasady zwrotu.

Google obsługuje między innymi dane Product i Offer, a na poziomie organizacji również politykę zwrotów oraz informacje o dostawie. Dla produktów wariantowych można użyć ProductGroup, hasVariant, variesBy i wspólnego identyfikatora grupy. Samo dodanie znaczników nie daje gwarancji prezentacji rozszerzonego wyniku, ale ogranicza niejednoznaczność danych.

Feed produktowy powinien zawierać co najmniej pola takie jak:

• id,
• title,
• description,
• link,
• image_link,
• availability,
• price,
• brand.

Cena powinna być zapisana wraz z walutą, na przykład 299.00 PLN. Dla przedsprzedaży i produktów sprowadzanych na zamówienie trzeba przekazywać availability_date. GTIN albo MPN należy podawać, gdy rzeczywiście istnieją; generowanie fikcyjnego numeru jest gorsze niż uczciwe pozostawienie pola pustego zgodnie z regułami platformy.

W Polsce konfiguracja Google Merchant Center wymaga też poprawnych danych o dostawie dla bezpłatnych wyników produktowych i kampanii zakupowych. Podanie samego komunikatu „wysyłka od 0 zł” nie wystarcza, jeśli darmowa dostawa obowiązuje dopiero od określonej wartości koszyka lub tylko dla wybranych metod.

Dla sklepu ze stabilnym asortymentem pełny feed można generować raz na dobę. Przy częstych zmianach cen i zapasów potrzebne są aktualizacje śróddzienne przez API. Dokumentacja OpenAI dla feedów produktowych rekomenduje pełny plik przynajmniej raz dziennie, aktualizacje w ciągu dnia przez API oraz rozpoczęcie integracji od próbki około 100 produktów.

Dobre wewnętrzne progi operacyjne — nie wymagania Google ani OpenAI — to:

• mniej niż 0,5% rozbieżności ceny między stroną, feedem i koszykiem,
• opóźnienie stanu magazynowego do 15 minut dla szybko rotujących produktów,
• komplet danych dla co najmniej 98% najważniejszych kart produktowych,
• automatyczny alarm po wykryciu różnicy ceny większej niż 1 grosz,
• usunięcie niedostępnego wariantu z feedu najpóźniej w ciągu godziny.

Najbardziej irytująca awaria pojawia się przy wariantach. Produkt główny ma stan „dostępny”, lecz rozmiar 44 jest wyprzedany. Agent wybiera ofertę, przechodzi do karty, a dopiero selektor rozmiaru ujawnia brak towaru. Dlatego dostępność powinna być liczona na poziomie konkretnego wariantu, nie całej rodziny produktu.

3. Nie zmuszaj agenta do odgadywania interfejsu

Agent może analizować kod DOM, drzewo dostępności oraz obraz strony. Najpewniejsze pozostają jednak standardowe elementy HTML i poprawnie opisane formularze. OpenAI wskazuje, że role, etykiety i stany ARIA pomagają agentowi rozpoznawać elementy oraz wykonywać zadania w serwisie.

Formularz przygotowany na automatyczną obsługę powinien mieć:

• element <label> powiązany z każdym polem,
• prawdziwe przyciski <button>, a nie klikalne elementy <div>,
• jednoznaczne nazwy, np. „Dodaj rozmiar 44 do koszyka” zamiast „Wybierz”,
• obsługę klawiatury,
• widoczny fokus,
• komunikaty błędów zapisane tekstem,
• stabilną kolejność pól,
• potwierdzenie przed złożeniem zamówienia lub dokonaniem płatności.

Problematyczne są zwłaszcza:

• wybór wariantu dostępny wyłącznie po najechaniu kursorem,
• kalendarz rezerwacji bez możliwości wpisania daty,
• suwak ceny bez pola tekstowego,
• komunikat „Coś poszło nie tak” bez wskazania przyczyny,
• przycisk zmieniający nazwę i położenie podczas ładowania,
• baner zgody, który przechwytuje fokus i nie daje się zamknąć klawiaturą,
• CAPTCHA uruchamiana już przy otwarciu koszyka.

Polski Akt o Dostępności obejmuje od 28 czerwca 2025 roku między innymi usługi handlu elektronicznego. Przewidziano wyjątek dla usług świadczonych przez mikroprzedsiębiorców, ale nie należy traktować go jako argumentu za pozostawieniem niedostępnego checkoutu. Te same błędy, które utrudniają zakup osobom korzystającym z klawiatury, czytnika ekranu lub sterowania głosem, zatrzymują również agentów.

4. Przygotuj system na błędy i ponowienia

Agent nie powinien być traktowany jako zaufany użytkownik. Każda wartość — cena, kod rabatowy, ilość, wariant i koszt dostawy — musi być ponownie sprawdzana po stronie serwera.

Dla koszyka, rezerwacji lub zamówienia potrzebne są:

• ponowne obliczenie ceny przed zatwierdzeniem,
• sprawdzenie zapasu w czasie rzeczywistym,
• czytelny błąd out_of_stock,
• ochrona przed dwukrotnym złożeniem tego samego zamówienia,
• identyfikator żądania i dziennik zdarzeń,
• limit czasu rezerwacji,
• możliwość bezpiecznego wznowienia sesji,
• osobne potwierdzenie przed działaniem nieodwracalnym.

Przy integracji UCP sprzedawca odpowiada za kontrolę stanu magazynowego, obsługę dostawy, walidację zamówienia i zwracanie właściwych błędów. Google zaleca uwierzytelnianie przez OAuth i podpisy żądań zamiast polegania na blokowaniu całych krajów na podstawie adresu IP. Sprzedawca pozostaje również Merchant of Record, czyli stroną odpowiedzialną za transakcję i dane klienta.

5. Dane muszą odpowiadać polskim obowiązkom prawnym

Agent może porównać tylko te warunki, które sklep ujawnia. Brak informacji prawnych nie jest więc osobnym problemem działu compliance — wpływa na możliwość rekomendacji i przeprowadzenia zakupu.

Promocje. Przy komunikowaniu obniżki ceny trzeba pokazać najniższą cenę z 30 dni poprzedzających obniżkę. Nie należy wysyłać do feedu ceny promocyjnej, jeżeli karta produktu pokazuje wyłącznie przekreśloną „cenę katalogową”, która nie była rzeczywistą ceną sprzedaży. UOKiK może karać naruszenia zbiorowych interesów konsumentów kwotą sięgającą 10% obrotu przedsiębiorcy.

Zwroty. Przy standardowym zakupie internetowym konsument ma co do zasady 14 dni na odstąpienie od umowy. Są wyjątki, między innymi dla niektórych produktów wykonywanych na zamówienie i określonych treści cyfrowych. Jeżeli przedsiębiorca nie poinformuje prawidłowo o prawie odstąpienia, termin może przedłużyć się o dodatkowe 12 miesięcy.

Bezpieczeństwo produktów. Zgodnie z GPSR internetowa oferta powinna zawierać dane identyfikujące produkt, producenta albo osobę odpowiedzialną w Unii Europejskiej oraz wymagane ostrzeżenia i informacje dotyczące bezpieczeństwa. Dla producenta spoza UE szczególnie istotne są dane unijnej osoby odpowiedzialnej.

Własny chatbot lub asystent. Od 2 sierpnia 2026 roku zaczęły obowiązywać wymogi przejrzystości z art. 50 unijnego AI Act. Firma udostępniająca użytkownikom interaktywny system AI powinna poinformować, że rozmowa odbywa się z AI, chyba że jest to oczywiste z kontekstu. Obowiązek dotyczy własnego asystenta firmy, a nie samego faktu, że zewnętrzny agent odwiedza stronę.

Test, który można wykonać bez specjalistycznego laboratorium

Dla 20 najważniejszych produktów lub usług przygotuj scenariusze obejmujące cały proces:

1. Otwórz stronę w nowej sesji, bez zapisanych plików cookie.
2. Wyszukaj ofertę po parametrach, a nie po jej dokładnej nazwie.
3. Wybierz wariant i sprawdź dostępność.
4. Oblicz dostawę dla kodu 00-001 Warszawa.
5. Dodaj produkt do koszyka.
6. Przejdź do ostatniego kroku przed płatnością, nie składając zamówienia.
7. Powtórz test dla produktu niedostępnego, błędnego kodu pocztowego i wygasłej promocji.
8. Uruchom ten sam scenariusz klawiaturą oraz na ekranie mobilnym.
9. Porównaj cenę i stan na stronie, w JSON-LD, feedzie i koszyku.
10. Zapisz punkt, w którym potrzebna była ręczna interwencja.

Sensownym celem początkowym jest wykonanie bez pomocy człowieka przynajmniej 18 z 20 scenariuszy. Nie daje to gwarancji, że każdy zewnętrzny agent poradzi sobie ze stroną. Wykrywa jednak regresje, które dziś blokują zarówno automaty, jak i zwykłych klientów.

Plan wdrożenia w Polsce: priorytety, koszty i pomiar

Najdroższy błąd polega na rozpoczęciu od integracji z modnym protokołem. Najpierw trzeba naprawić dane i ścieżkę użytkownika. Dopiero później jest sens budować połączenie bezpośrednie.

Dni 1–14: audyt możliwości odczytu

Pierwszy etap powinien objąć:

• sprawdzenie robots.txt, noindex, nosnippet i tagów kanonicznych,
• analizę odpowiedzi serwera dla Googlebota i OAI-SearchBota,
• kontrolę kodów 403, 429 i przekierowań,
• sprawdzenie 20 najważniejszych szablonów stron,
• porównanie danych widocznych z JSON-LD i feedem,
• wskazanie systemu będącego źródłem ceny, zapasu i warunków dostawy.

W tym momencie nie trzeba poprawiać całego katalogu. Lepiej wybrać 50 najlepiej sprzedających się produktów albo 20 najważniejszych usług. Jeżeli firma nie potrafi utrzymać zgodnych danych dla tej próbki, skalowanie integracji na 20 tysięcy ofert tylko zwielokrotni błędy.

Dni 15–45: dane produktowe i polityki

Drugi etap to:

• uporządkowanie identyfikatorów produktów i wariantów,
• uzupełnienie Product, Offer i danych o wariantach,
• przebudowa feedu Merchant Center,
• dodanie rzeczywistych kosztów dostawy,
• publikacja jednoznacznych zasad zwrotu,
• synchronizacja ceny i stanów magazynowych,
• uzupełnienie informacji wymaganych przez GPSR,
• wdrożenie alertów dotyczących rozbieżności.

W sklepie z wieloma magazynami najwięcej czasu zabiera zwykle nie samo schema.org, lecz ustalenie, który stan jest stanem możliwym do sprzedaży. System ERP może pokazywać pięć sztuk, z czego dwie są zarezerwowane, jedna uszkodzona, a dwie znajdują się w magazynie z wysyłką za siedem dni. Feed nie powinien mechanicznie publikować liczby „5”.

Dni 46–75: ścieżka działania

Trzeci etap obejmuje:

• poprawę formularzy i etykiet,
• obsługę klawiatury,
• tekstowe komunikaty błędów,
• stabilny wybór wariantu,
• ponowną kontrolę ceny i dostępności po stronie serwera,
• zabezpieczenie przed podwójnym zamówieniem,
• testy 20 scenariuszy agentowych,
• monitoring nieudanych przejść między koszykiem a płatnością.

Dla firmy usługowej ten etap ma większy priorytet niż feed produktowy. Agentowi niewiele da perfekcyjnie opisany gabinet, jeśli kalendarz rezerwacji jest osadzonym widżetem bez etykiet, a wolny termin pojawia się dopiero po ręcznym przeklikaniu pięciu ekranów.

Po 75. dniu: feedy bezpośrednie i protokoły

Google rozwija Universal Commerce Protocol, który ma obsługiwać zakupy wykonywane bezpośrednio w AI Mode i Gemini. Wdrożenie wymaga jednak zgłoszenia, akceptacji Google, przygotowania profilu UCP, konfiguracji Google Pay oraz implementacji podstawowych endpointów REST do utworzenia, aktualizacji i zakończenia sesji zakupowej. Potrzebne są również mechanizmy informowania o statusie zamówienia. Standard nadal się rozwija i nie wszystkie elementy specyfikacji są dostępne w każdym wdrożeniu.

To nie jest pierwszy projekt dla małego sklepu działającego wyłącznie w Polsce. UCP ma sens, gdy firma:

• ma stabilny, przetestowany checkout,
• prowadzi sprzedaż na obsługiwanych rynkach,
• kontroluje zapasy w czasie zbliżonym do rzeczywistego,
• dysponuje zespołem utrzymującym API,
• otrzymała zgodę na integrację,
• potrafi obsługiwać zamówienia, zwroty i błędy bez ręcznego przepisywania danych.

OpenAI przyjmuje zgłoszenia sprzedawców zainteresowanych bezpośrednim przekazywaniem feedów. Na 8 sierpnia 2026 roku funkcje zakupowe są jednak dostępne głównie w USA, a firma deklaruje rozwój modelu, w którym klient kończy zakup na stronie lub w aplikacji sprzedawcy. OpenAI informuje również, że nie pobiera opłaty od zakupów rozpoczętych w ChatGPT.

Dla polskiego sklepu sprzedającego tylko w kraju kolejność jest więc prosta:

1. Google Merchant Center i zgodność danych.
2. Indeksowalne karty produktów.
3. Dostępny i odporny checkout.
4. Pomiar ruchu z wyszukiwarek AI.
5. Dopiero później bezpośredni feed OpenAI lub UCP, gdy rynek i dostępność usługi to uzasadnią.

Ile trzeba przeznaczyć na wdrożenie

Poniższe kwoty są budżetem planistycznym, a nie cennikiem Google lub OpenAI. Zakładają sklep z 1–10 tys. SKU, działający na popularnej platformie e-commerce, bez konieczności wymiany ERP. Do obliczeń przyjęto stawkę 220–350 zł netto za godzinę.

• Audyt robotów, WAF, indeksowania i szablonów: 8–16 godzin, czyli około 1,8–5,6 tys. zł netto.
• Uporządkowanie modelu danych, JSON-LD i feedu: 40–120 godzin, czyli około 8,8–42 tys. zł netto.
• Poprawa dostępności oraz scenariuszy koszykowych: 40–160 godzin, czyli około 8,8–56 tys. zł netto.
• Dedykowana integracja API lub UCP: 160–500 godzin, czyli około 35–175 tys. zł netto.

Sklep z własnym, kilkunastoletnim systemem, wieloma magazynami i osobnym modułem promocji może przekroczyć górną granicę. Z kolei firma na Shopify, WooCommerce lub PrestaShop, która ma uporządkowane warianty i jeden magazyn, może zamknąć podstawowe prace w dolnej części widełek.

Nie należy płacić kilkudziesięciu tysięcy złotych za integrację tylko po to, żeby „być pierwszym”. Natywna integracja nie daje automatycznego wzrostu pozycji, a platforma może zmienić wymagania techniczne. Wydatek ma uzasadnienie dopiero wtedy, gdy liczba potencjalnych transakcji pokrywa koszt budowy i późniejszego utrzymania.

Jak mierzyć efekt, skoro część decyzji zapada bez kliknięcia

Pomiar wyłącznie sesji organicznych będzie coraz mniej użyteczny. Agent może przeczytać ofertę, porównać ją z konkurencją i podać odpowiedź użytkownikowi, nie generując klasycznego wejścia na stronę. Z drugiej strony zadanie transakcyjne może doprowadzić użytkownika od razu do koszyka.

Od czerwca 2026 roku Google wdraża osobne raporty dotyczące wyników w generatywnej AI. Raport jest udostępniany stopniowo wybranym domenom i może pokazywać między innymi wyświetlenia, strony, kraje, urządzenia oraz daty. Trzeba go wykorzystać, jeśli pojawił się już w danym koncie Search Console, ale nie zakładać, że każda witryna ma do niego dostęp.

Ruch z ChatGPT można identyfikować między innymi przez parametr utm_source=chatgpt.com. W GA4 powinien otrzymać osobną grupę kanałów, zamiast trafiać do ogólnego referralu.

Miesięczny dashboard Agentic SEO powinien zawierać:

• liczbę wejść z wyszukiwarek i asystentów AI,
• liczbę wyświetleń w raportach generatywnych, jeśli są dostępne,
• przychód i konwersje wspomagane przez takie wejścia,
• odsetek odrzuconych produktów w Merchant Center,
• liczbę rozbieżności ceny i stanu,
• czas aktualizacji zapasu,
• skuteczność 20 scenariuszy testowych,
• liczbę odpowiedzi 403, 429 i 5xx dla robotów,
• błędy koszyka po wyborze dostawy lub wariantu,
• udział najważniejszych ofert z kompletnymi identyfikatorami.

Spadek liczby kliknięć nie musi oznaczać spadku widoczności. Jednocześnie wzrost „wzmianek w AI” bez zamówień nie jest sukcesem. Liczy się to, czy agent dociera do prawidłowej oferty, przekazuje poprawne warunki i nie traci użytkownika przed finalizacją zadania.

FAQ: najczęstsze pytania o Agentic SEO

Czy Agentic SEO zastępuje klasyczne SEO?
Nie. Indeksowanie, linkowanie wewnętrzne, dobra architektura, treść dostępna w HTML i reputacja domeny nadal stanowią podstawę. Agentic SEO dodaje do nich spójność danych oraz możliwość wykonania zadania.

Czy plik llms.txt jest konieczny?
Nie jako priorytet. Google deklaruje, że go ignoruje. Najpierw trzeba naprawić indeksowanie, dane strukturalne, feed, ceny, dostępność oraz formularze.

Czy mogę zablokować GPTBot, ale nadal pojawiać się w wyszukiwaniu ChatGPT?
Tak. GPTBot i OAI-SearchBot mają osobne reguły. Można zablokować robota treningowego i pozostawić dostęp robotowi wyszukiwarki.

Czy dane strukturalne gwarantują polecenie produktu przez AI?
Nie. Pomagają zidentyfikować ofertę, cenę, warianty, dostawę i zwroty, ale nie gwarantują widoczności ani rekomendacji. Dane muszą też odpowiadać temu, co użytkownik widzi na stronie.

Czy polski sklep powinien już budować integrację UCP albo dedykowany checkout dla ChatGPT?
Tylko po uzyskaniu dostępu i po wykazaniu biznesowego sensu. UCP wymaga akceptacji Google i pracy programistycznej, a zakupy w ChatGPT są obecnie skoncentrowane na rynku amerykańskim. Dla sklepu działającego wyłącznie w Polsce większy zwrot da uporządkowanie Merchant Center, danych produktowych i checkoutu.

Czy dostępność cyfrowa rzeczywiście pomaga agentom AI?
Tak. Etykiety formularzy, semantyczne przyciski, obsługa klawiatury i czytelne komunikaty błędów tworzą strukturę, którą wykorzystują zarówno technologie asystujące, jak i agenci analizujący drzewo dostępności strony.

Od czego zacząć pracę nad Agentic SEO?
Weź 50 najlepiej sprzedających się ofert i porównaj cenę, dostępność, wariant, dostawę oraz zwrot w pięciu miejscach: na stronie, w JSON-LD, feedzie, koszyku i systemie źródłowym. Najpierw usuń każdą rozbieżność. Dopiero później zamawiaj plik llms.txt, aplikację „AI-ready” albo kosztowną integrację z protokołem zakupowym.