Użytkownik wpisuje „kup ekspres do kawy z młynkiem” — zapytanie z jawną intencją zakupu. Google zwraca stronę produktową. Strona wygląda poprawnie: zdjęcia, opis, cena, specyfikacja. Ale przycisk „Dodaj do koszyka” jest nieaktywny, bo produkt jest niedostępny. Alternatywnie: przycisk działa, lecz prowadzi do formularza bez identyfikatora produktu. Albo: strona jest kategorią z listą wyników, a nie pojedynczym zasobem, na którym można wykonać akcję zakupu. W każdym z tych scenariuszy zapytanie transakcyjne trafia na stronę bez możliwej akcji.
Problem dotyczy dwóch warstw jednocześnie. Pierwsza to retrieval — czy system w ogóle wybiera właściwy URL dla zapytania transakcyjnego (zagadnienie opisujemy szerzej w badaniu retrieval na danych GSC). Druga to action readiness — czy wybrany URL faktycznie obsługuje akcję, której oczekuje użytkownik. Patent US12561387B2 (Google LLC, przyznany 2026-02-24) opisuje system indeksowania akcji obsługiwanych przez zasoby i dopasowywania typu akcji zapytania do zasobów z danymi akcji. W tym artykule sprawdzamy obie warstwy na danych z trzech polskich sklepów internetowych.
Dwie warstwy problemu: retrieval i action readiness
Tradycyjny audyt SEO skupia się na widoczności strony w wynikach wyszukiwania. Ale w kontekście zapytań transakcyjnych samo pojawienie się w SERP nie wystarczy. Użytkownik nie szuka informacji — szuka możliwości wykonania działania: kupienia, zamówienia, zarezerwowania, porównania lub zwrotu. Jeśli strona, na którą trafia, nie udostępnia tego działania w sposób jednoznaczny i kompletny, mamy do czynienia z luką między intencją zapytania a możliwościami strony.
Tę lukę można rozłożyć na dwa niezależne problemy.
Problem 1: retrieval wybiera niewłaściwy URL. Zapytanie transakcyjne trafia na stronę blogową, poradnik lub kategorię zamiast na kartę produktu z możliwością zakupu. W naszych testach z użyciem retrieval_candidate_select (element audytu widoczności w AI) zapytania transakcyjne dla trzech badanych sklepów zwróciły primary: null — żaden kandydat nie uzyskał wystarczającego wyniku retrieval. Główne przyczyny to: kara za niedostępność strony dla crawlerów (fetch_penalty: 48 punktów) i niskie dopasowanie intencji strony do intencji zapytania (intent_page_alignment: 16,3 dla stron produktowych i kategorii).
Problem 2: właściwy URL, ale brak akcji. Strona produktowa jest poprawnie zaindeksowana, ma treść, schema i pozycje w SERP — ale nie udostępnia akcji odpowiadającej intencji zapytania. Przycisk zakupu jest nieaktywny, formularz niekompletny albo ścieżka działania wymaga JavaScript, którego crawler nie wykonuje (to element rendering readiness).
Problem 3: akcja istnieje, ale parametry są niekompletne. Strona ma przycisk „Dodaj do koszyka”, ale brakuje identyfikatora produktu w URL-u docelowym, nie ma obsługi wariantów (rozmiar, kolor) albo endpoint nie jest stabilny.
Co mówi patent o indeksowaniu akcji
Patent US12561387B2 („Indexing actions for resources”, Google LLC) opisuje trzy niezależne roszczenia obejmujące metodę, system i nośnik danych. Mechanizm polega na: (1) indeksowaniu akcji obsługiwanych przez zasoby internetowe, (2) identyfikowaniu typu akcji w zapytaniu użytkownika, (3) dopasowywaniu zapytania do zasobów z zindeksowanymi akcjami odpowiedniego typu i (4) zastosowaniu premii rankingowej (ranking boost) dla zasobów z potwierdzonymi akcjami.
Patent nie jest dowodem wdrożenia mechanizmu w Google Search. Pokazuje jednak, że problem dopasowania zapytanie-akcja jest rozpoznany na poziomie architektury wyszukiwarki i że istnieją zdefiniowane metody jego rozwiązania. Na tej podstawie budujemy diagnostykę, a nie prognozę rankingową.
Patent nie jest potwierdzeniem używania rozwiązania w aktualnym algorytmie Google. Pokazuje problem techniczny, architekturę i klasę sygnałów, które można wykorzystać do zaprojektowania audytu. Wnioski w tym artykule wynikają z połączenia treści patentu z naszymi obserwacjami w GSC i danych stron.
Z perspektywy audytu kluczowe są cztery elementy, które patent wymienia jako dane indeksowane: typ akcji (np. zakup, rezerwacja, porównanie), cel akcji (URL endpointu), wymagane parametry (identyfikator produktu, ilość, wariant) i opcjonalne parametry (kolor, rozmiar, metoda płatności). Każdy z tych elementów można sprawdzić na stronie.
Audyt action readiness: trzy polskie sklepy
Zbadaliśmy trzy polskie sklepy internetowe z różnych branż przy użyciu ecom_resource_action_indexability_audit. Nazwy domen zostały zanonimizowane — prezentujemy wyłącznie zagregowane wyniki diagnostyczne.
| Sklep | Branża | Typ strony | Action score | Wykryte akcje | BuyAction | JSON-LD | Parametry (%) |
|---|---|---|---|---|---|---|---|
| Sklep A | Elektronika | Karta produktu (niedostępny) | 85 | porównaj, powiadom | Nie | Nie | 68% |
| Sklep B | Książki | Kategoria | 81 | kup (per kafelek), lista życzeń | Tak (per tile) | Nie | 68% |
| Sklep C | Moda | Kategoria | 83 | lista życzeń, zwrot, koszyk | Nie | Nie | 63% |
Co wynika z tych danych
Brak JSON-LD z akcjami we wszystkich trzech sklepach. Żaden z badanych sklepów nie implementuje potentialAction z typem BuyAction w danych strukturalnych. To nie jest wyjątek — według danych z AgentReadyHQ i WebsiteAIScore, BuyAction w schema implementuje mniej niż 100 domen na świecie. Brak JSON-LD oznacza, że akcja istnieje wyłącznie w warstwie HTML (przyciski, linki, formularze), ale nie w warstwie maszynowo czytelnej — problem zbieżny z niespójnością danych produktowych między DOM a schema.
Średnia kompletność parametrów: 66%. Nawet gdy akcja jest wykrywalna (przycisk istnieje i prowadzi do endpointu), jedna trzecia wymaganych parametrów jest niekompletna. Najczęstsze braki to: identyfikator wariantu produktu, ilość, metoda dostawy. W kontekście patentu US12561387B2, zasób z niekompletnymi parametrami nie kwalifikuje się do premii rankingowej nawet jeśli typ akcji jest poprawny.
Tylko 1 z 3 sklepów udostępnia akcję zakupu. Sklep B ma przyciski „Kup” na kafelkach kategorii — ale to linki do kart produktów, a nie bezpośrednie akcje zakupu. Sklep A ma produkt niedostępny, więc akcja zakupu jest fizycznie niemożliwa. Sklep C nie ma przycisku zakupu w ogóle — oferuje jedynie dodanie do listy życzeń i link do koszyka.
Warstwa retrieval: co system widzi przed wybraniem strony
Zanim użytkownik zobaczy stronę, system musi ją wybrać z puli kandydatów. Dla zapytań transakcyjnych testowaliśmy selekcję kandydatów przy użyciu retrieval_candidate_select — narzędzia, które symuluje proces wyboru dokumentu dla zapytania (metodę opisujemy szczegółowo w osobnym badaniu).
Wyniki były jednoznaczne: dla zapytań transakcyjnych skierowanych do trzech badanych sklepów żaden kandydat nie uzyskał wystarczającego wyniku, aby zostać wybranym jako źródło odpowiedzi (primary: null). Przyczyny rozłożyły się na dwa główne czynniki.
| Czynnik | Wynik | Co to oznacza |
|---|---|---|
| fetch_penalty | 48 pkt | Strony blokują automatyczne crawlery (CAPTCHA, WAF). Fetch reliability score: 5/100. |
| intent_page_alignment (produkt/kategoria) | 16,3 | Strony produktowe mają niskie dopasowanie do zapytań transakcyjnych w modelu retrieval. |
| intent_page_alignment (blog/poradnik) | 86 | Strony poradnikowe pasują lepiej, ale na intencję how_to, nie transakcyjną. |
To tworzy paradoks: strony, które powinny odpowiadać na zapytania transakcyjne (karty produktów), są niedostępne dla crawlerów lub mają niskie dopasowanie intencji. Strony, które mają wysokie dopasowanie (poradniki), odpowiadają na inną intencję. W efekcie zapytanie transakcyjne nie ma dobrego kandydata do odpowiedzi.
Trzy typy luk zapytanie-akcja
Na podstawie danych z audytów zidentyfikowaliśmy trzy typy luk, które występują niezależnie od siebie i wymagają różnych napraw.
Typ 1: retrieval wybiera niewłaściwy URL
Zapytanie „zamów buty do biegania 42″ trafia na stronę kategorii „buty sportowe” zamiast na kartę konkretnego produktu z rozmiarem 42. Problem leży w warstwie retrieval — system nie rozróżnia strony z listą produktów od strony z możliwością zakupu konkretnego produktu. Rozwiązanie wymaga poprawy extractability karty produktowej i jasnego sygnału intencji na poziomie URL i treści.
Typ 2: właściwy URL, brak akcji
Karta produktu jest poprawna, ale produkt jest niedostępny (Sklep A: przycisk „Powiadom o dostępności” zamiast „Kup”). Albo strona kategorii wyświetla produkty bez możliwości bezpośredniego zakupu (Sklep C: tylko „Dodaj do listy życzeń”). Z perspektywy patentu US12561387B2, zasób nie obsługuje akcji typu „zakup” — niezależnie od tego, jak dobrze jest zoptymalizowany pod SEO.
Typ 3: akcja istnieje, parametry niekompletne
Przycisk „Dodaj do koszyka” działa, ale link docelowy nie zawiera identyfikatora wariantu. Użytkownik musi wybrać rozmiar i kolor przed dodaniem do koszyka, ale te parametry nie są przekazywane w URL-u ani w danych strukturalnych. Średnia kompletność parametrów w naszej próbie wynosi 66% — co oznacza, że co trzeci wymagany parametr akcji jest niewidoczny dla systemu.
Dlaczego BuyAction jest prawie nieobecny
Google w listopadzie 2024 wycofał Sitelinks Search Box jako osobny rich result, ale potentialAction w schema.org pozostaje prawidłową konstrukcją. Problem polega na tym, że BuyAction — typ akcji dedykowany zakupom — jest implementowany przez znikomą liczbę domen. Według danych z AgentReadyHQ (maj 2026) mniej niż 100 stron na świecie implementuje BuyAction w swoich danych strukturalnych.
Przyczyny są praktyczne: brak widocznego efektu w SERP (Google nie generuje rich results na podstawie BuyAction), brak dokumentacji wdrożeniowej w oficjalnych przewodnikach Google i niepewność co do tego, czy implementacja wpłynie na ranking. W kontekście agentic commerce sytuacja może się zmienić — agenci AI potrzebują maszynowo czytelnych akcji, aby móc realizować zadania w imieniu użytkownika. Ale dziś BuyAction pozostaje raczej sygnałem gotowości niż wymogiem rankingowym.
Jak zbudować macierz zapytanie-strona-akcja
Praktyczny audyt wymaga połączenia trzech źródeł danych: zapytań z GSC, stron docelowych i wykrytych akcji. Poniżej opisujemy krok po kroku, jak to zrobić.
Krok 1: pobierz zapytania transakcyjne z GSC. Użyj filtrów na czasowniki akcji: kup, zamów, zarezerwuj, porównaj, pobierz, zwrot, kontakt. W polskim GSC szukaj wariantów: „kup”, „zamów”, „gdzie kupić”, „cena”, „sklep”, „dostawa”, „zwrot”. Pobierz pary zapytanie-strona z ostatnich 90 dni.
Krok 2: przypisz typ intencji akcji do każdego zapytania. Nie każde zapytanie transakcyjne wymaga tego samego typu akcji. „Kup ekspres” wymaga BuyAction. „Porównaj ekspresy” wymaga CompareAction. „Zwrot ekspresu” wymaga ReturnAction (patrz: dane strukturalne polityki zwrotów). Przypisanie typu akcji pozwala precyzyjnie sprawdzić, czy strona docelowa obsługuje właściwy typ.
Krok 3: audytuj stronę docelową pod kątem akcji. Dla każdej pary zapytanie-strona uruchom ecom_resource_action_indexability_audit. Narzędzie sprawdza: obecność przycisków i formularzy, cel akcji (URL endpointu), wymagane parametry, obecność JSON-LD z potentialAction i stabilność endpointu. Warto jednocześnie sprawdzić, czy nagłówek karty produktu odpowiada na intencję zapytania.
Krok 4: oznacz luki. Dla każdej pary zapytanie-strona zapisz wynik: (a) typ intencji zapytania, (b) wykryte akcje na stronie, (c) czy typ akcji pasuje, (d) kompletność parametrów. Luki P1 to przypadki, gdzie zapytanie ma dużo wyświetleń, ale strona nie obsługuje wymaganego typu akcji.
Krok 5: zweryfikuj ręcznie próbkę luk P1. Automatyczna detekcja może generować fałszywe alarmy — przycisk zakupu może być renderowany przez JavaScript, którego crawler nie wykonał. Ręczna weryfikacja eliminuje szum i pozwala potwierdzić rzeczywiste luki.
Priorytetyzacja: które luki naprawiać w pierwszej kolejności
Nie każda luka zapytanie-akcja jest równie ważna. Priorytetyzacja powinna uwzględniać trzy wymiary:
Wyświetlenia i kliknięcia w GSC. Zapytanie z 5000 wyświetleń miesięcznie i brakiem akcji na stronie docelowej to stracony potencjał. Zapytanie z 10 wyświetleniami można odłożyć.
Typ luki. Typ 2 (właściwy URL, brak akcji) jest zazwyczaj najłatwiejszy do naprawy — wystarczy dodać lub aktywować przycisk. Typ 1 (niewłaściwy URL) wymaga pracy nad architekturą informacji i architekturą kategorii. Typ 3 (niekompletne parametry) wymaga pracy z deweloperami nad endpoint-ami.
Wartość biznesowa. Zapytania zawierające nazwy konkretnych produktów, modeli lub SKU mają wyższą intencję zakupową niż zapytania generyczne. Priorytetyzuj konkretne zapytania z brakiem akcji nad ogólne z częściową obsługą.
Czego ten audyt nie twierdzi
Patent US12561387B2 opisuje możliwy mechanizm, a nie potwierdzony czynnik rankingowy. Nie twierdzimy, że dodanie BuyAction w JSON-LD poprawi pozycje w Google. Nie twierdzimy też, że wynik resource_action_indexability_score z naszego audytu odpowiada wewnętrznemu scoringowi Google.
Twierdzimy natomiast, że: (1) luka między intencją zapytania a możliwościami strony jest mierzalnym problemem, (2) problem ten można podzielić na warstwy retrieval i action readiness, (3) każda warstwa wymaga osobnej diagnostyki i naprawy, (4) próba trzech polskich sklepów pokazuje, że problem jest powszechny — żaden z nich nie implementuje pełnej ścieżki od zapytania transakcyjnego do kompletnej akcji z parametrami.
Audyt zapytanie-akcja jest nowym elementem diagnostyki, który uzupełnia audyt treści i audyt SEO o warstwę intencji działania. Wyniki z trzech sklepów traktujemy jako obserwacje na małej próbie, nie jako benchmark rynkowy. Jeśli chcesz sprawdzić, jak Twój sklep radzi sobie z zapytaniami transakcyjnymi, audyt action readiness jest dostępny jako element audytu e-commerce — skontaktuj się z nami przez konsultacje SEO, aby go uruchomić.
