SEO na wymagania – jak AI przetwarza zapytania z ograniczeniami i co to zmienia w optymalizacji produktów

Jeżeli Twój sklep traci widoczność w ChatGPT, Gemini i Perplexity na zapytania typu „laptop do montażu 4K do 6000 zł z min. 32GB RAM” – problem nie leży w SEO, lecz w brakujących atrybutach produktowych. AI nie dopasowuje słów kluczowych. Rozkłada zapytanie na ograniczenia (constrainty), filtruje katalog po każdym z nich i eliminuje produkty, które nie mają odpowiednich danych. Sklep z doskonałym SEO, ale bez ustrukturyzowanych atrybutów w feedzie i schema, jest dla AI niewidoczny.

W tym artykule znajdziesz: taksonomię 6 typów constraintów rozpoznawanych przez AI, framework CAM (Constraint-to-Attribute Mapping) do mapowania ograniczeń na pola w Google Merchant Center oraz Constraint Coverage Score (CCS) – autorski wskaźnik Semgence, który mierzy, jaki procent wymagań z zapytań użytkowników pokrywają Twoje dane produktowe. CCS powyżej 80% oznacza dobrą widoczność w AI; poniżej 50% – poważne luki.

O tym, jak AI zmienia wyszukiwanie zakupowe, pisałem szerzej w artykule o Google AI Mode w e-commerce – tutaj skupiam się na jednym konkretnym mechanizmie: przetwarzaniu zapytań z wieloma ograniczeniami.

Czym różni się zapytanie z ograniczeniami od zapytania ze słowem kluczowym?

Tradycyjne zapytanie zakupowe to jedno lub dwa słowa kluczowe: „laptop gamingowy”, „buty do biegania”, „robot sprzątający”. Wyszukiwarka dopasowuje je leksykalnie – szuka stron, które te frazy zawierają, i rankuje je według setek sygnałów. To model, na którym SEO opierało się przez dwie dekady.

Zapytanie z ograniczeniami (constraint query) to coś jakościowo innego: „laptop do montażu 4K, min. 32GB RAM, do 6000 zł, z Thunderbolt 4”. To nie jest dłuższe słowo kluczowe – to zestaw wymagań, które AI musi przetworzyć, zdekompnować i zweryfikować wzgledem danych produktowych. Roznica między tymi dwoma typami zapytań jest analogiczna do roznicy między wpisaniem hasla w encyklopedii a złozeniem zamowienia u doradcy: w pierwszym przypadku szukasz trafienia, w drugim oczekujesz filtrowania i rekomendacji.

Skala tego zjawiska rośnie. Według analizy ALM Corp, Google AI Overviews pojawiają się już na 14% zapytań zakupowych. W okresie Black Friday kategoria „Computers and Laptops” odnotowała wzrost obecności AI Overviews z 6% do 21% – ponad trójkrotny skok w kilka tygodni. Gemini 2.5 zostal specjalnie zoptymalizowany pod obsługę zapytań wielowarunkowych (multi-constraint queries), co oznacza, ze Google traktuje ten typ wyszukiwania jako priorytet rozwojowy.

Anatomia constraint query składa się z czterech elementów:

• Kategoria produktowa: laptop, buty, wozek dziecięcy
• Zastosowanie (use case): do montażu wideo, do biegania po asfalcie, do bliźniąt
• Ograniczenie (constraint): do 6000 zł, min. 32GB RAM, z amortyzacja
• Kontekst: z Thunderbolt 4, w kolorze czarnym, z dostawa do piatku

W jednym zapytaniu konwersacyjnym moga pojawić się wszystkie cztery elementy jednocześnie. Jak opisuje to dokumentacja Gemini: „Size constraints, style preferences, budget limits, and use case all come through in a single conversational turn.” To fundamentalna zmiana – użytkownik nie wpisuje już jednej frazy, która pozniej zawęża filtrami na stronie sklepu. Podaje pełną specyfikacje od razu i oczekuje, ze AI zrobi reszte.

Dla SEO konsekwencja jest jednoznaczna: optymalizacja pod słowa kluczowe nie wystarczy. Pisałem o tym szerzej w artykule o słowach kluczowych w erze AI – keyword research nie znika, ale musi zostac rozszerzony o mapowanie constraintów. Jeżeli Twoja strona jest zoptymalizowana pod „laptop gamingowy”, ale nie zawiera danych o ilości RAM, portach Thunderbolt i zakresie cenowym w ustrukturyzowanej formie – AI nie ma czego dopasować do zapytania z ograniczeniami.

Jak AI rozkłada zapytanie wielowarunkowe na podzapytania?

Gemini, ChatGPT i inne modele AI nie przetwarzają zapytania z ograniczeniami jako jednego ciagu tekstu. Stosuja dekompozycję – rozkładają zapytanie na części skladowe i przetwarzają każda z nich równolegle.

Proces wyglada następująco. AI parsuje zapytanie, identyfikując trzy warstwy: encje (obiekty, o które pyta użytkownik), ograniczenia (warunki, które musza byc spełnione) i intencje (co użytkownik chce osiagnac – kupic, porownac, zrozumiec). Nastepnie dekomponuje zapytanie na sub-queries, które uruchamia jednocześnie. Dla zapytania „wozek dziecięcy do bliźniąt, składany, do 3000 zł, z gondolą” podzapytania moga wygladac tak:

1. Znajdź wozki dzieciece dla bliźniąt (filtr kategorii + typ)
2. Ogranicz do składanych (filtr cechy fizycznej)
3. Ogranicz do ceny poniżej 3000 zł (filtr budżetu)
4. Ogranicz do modeli z gondolą (filtr akcesoriów/kompatybilności)

Każde podzapytanie sprawdza inny atrybut w danych produktowych. Jeżeli Twoj wozek kosztuje 2800 zł, jest składany i ma gondolę w zestawie, ale nigdzie w danych nie jest oznaczony jako „dla bliźniąt” – nie przejdzie pierwszego filtra i nie trafi do wyników.

Ten mechanizm nie jest nowy w systemach Google. Patent US9672552B2 („Methods of augmenting search engines for ecommerce information retrieval”) opisuje system, który odbiera zapytanie użytkownika, porownuje je z zapisanymi regulami i augmentuje zapytanie za pomoca pasujacych regul. System wspiera dynamiczna nawigację umożliwiającą inteligentne filtrowanie – dokładnie to, co obserwujemy dzis w AI Mode. Patent mowi o „query augmentation” – wzbogacaniu zapytania o dodatkowe parametry, które system rozpoznaje jako istotne dla danej kategorii produktowej.

Drugi istotny patent to US7461058B1 („Optimized rule based constraints for collaborative filtering systems”). Opisuje serwer rekomendacji, który odbiera zapytanie i aplikuje dwa typy filtrów: filtr ograniczeń (constraint filter) i filtr rekomendacji (recommendation filter). Filtr ograniczeń eliminuje produkty, które nie spełniają twardych wymagań (cena, kompatybilność). Filtr rekomendacji rankuje pozostale produkty według dopasowania do preferencji. To dwuetapowy proces: najpierw odsiewanie, potem rankowanie.

W praktyce oznacza to, ze constraint query przechodzi przez potok przetwarzania, w którym każdy etap może wyeliminowac Twoj produkt. Nie wystarczy byc „dobrym” ogólnie – trzeba spełniać każdy constraint z osobna. Jeżeli Twoj produkt nie przejdzie choćby jednego filtra, cały potok go pomija, niezależnie od tego, jak dobrze radzi sobie z pozostalymi ograniczeniami.

Wazne jest też to, ze dekompozycja nie jest statyczna. AI uczy się, które constrainty sa najistotniejsze w danej kategorii i dynamicznie dostosowuje hierarchie filtrowania. Dla zapytań o laptopy cena i parametry techniczne sa filtrowane jako pierwsze. Dla zapytań o ubrania rozmiar i styl sa ważniejsze niz specyfikacja materiału. To oznacza, ze kolejność eliminacji produktów zalezy od kategorii – i od tego, jakie wzorce AI zaobserwował w poprzednich zapytaniach.

Dodatkowy aspekt to refinement – użytkownik w konwersacji z AI zawęża wyniki krok po kroku. Po pierwszej odpowiedzi może dodać: „Tylko w czarnym”, „Pokaż tansze”, „Coś dobrego na nierownemu chodnikowi?”. Każde uściślenie dodaje nowy constraint do już istniejacego zestawu. AI musi miec atrybuty, zeby odpowiedziec na każdy z tych refinementow – jeżeli Twoj produkt nie ma podanego koloru w danych strukturalnych, odpada po „tylko w czarnym”, nawet jeżeli faktycznie jest dostępny w czarnym.

Jakie typy constraintów rozpoznaje AI w zapytaniach zakupowych?

Na podstawie analizy zapytań zakupowych w AI Mode, ChatGPT Shopping i Perplexity wyodrębniliśmy szesc typów constraintów, które AI rozpoznaje i przetwarza. Taksonomia ta jest autorskim narzedziem Semgence – powstala na bazie analizy kilkuset realnych zapytań i sposobu, w jaki modele AI na nie odpowiadają.

1. Constrainty budżetowe (price cap / floor / range)

Najczęstszy typ ograniczenia. Uzytkownik podaje górny limit („do 2000 zł”), dolny limit („powyżej 500 zł”) lub przedzial („od 1000 do 3000 zł”). AI filtruje katalog po cenie – to hard constraint, który nie podlega negocjacji. Jeżeli cena produktu nie jest dostępna w danych strukturalnych, AI nie może go nawet ocenic.

2. Constrainty funkcjonalne (zastosowanie, use case)

Określają, do czego produkt ma służyć: „do biegania”, „do montażu wideo”, „do malego mieszkania”. AI szuka atrybutów opisujacych przeznaczenie produktu – pola typu „best for”, „recommended use”, „designed for”. To constraint, który wymaga atrybutów Tier 3, opisywanych w naszym artykule o Product Comparability Score.

3. Constrainty techniczne (specyfikacja, parametry)

Konkretne wymagania parametryczne: „min. 32GB RAM”, „rozdzielczość 4K”, „moc ssania powyżej 2500 Pa”. AI porownuje wartość z zapytania z wartością atrybutu w danych produktowych. Tu kluczowa jest precyzja – wartość „dużo RAM” nie pozwala AI zweryfikować constraintu „min. 32GB”.

4. Constrainty kompatybilności

Określają, z czym produkt ma wspolpracac: „kompatybilny z iPhone 15”, „do systemu Bosch Professional 18V”, „pasujący do ramy 29 cali”. To jeden z najtrudniejszych typów – wymaga jawnych danych o kompatybilności w feedzie lub schema, a wiele sklepow ich nie posiada.

5. Constrainty fizyczne (wymiary, waga, kolor)

Ograniczenia dotyczące fizycznych cech: „waga do 1.5 kg”, „szerokość max. 60 cm”, „w kolorze czarnym”. AI weryfikuje je bezpośrednio w atrybutach – wymiary, waga i kolor to pola, które powinny byc w każdym feedzie produktowym, a często sa puste lub nieprecyzyjne.

6. Constrainty temporalne (dostępność, czas dostawy)

Dotycza czasu: „z dostawa do piatku”, „dostępny od reki”, „na zamowienie do 3 dni”. AI sprawdza atrybuty dostępności i dostawy – shipping information, availability status, delivery time. Jak podkresla SearchEngineLand: „If your product feed has incomplete attributes, vague shipping information, or missing compatibility details, the AI will skip you.”

Poniżej tabela mapująca typy constraintów na przykladowe zapytania i wymagane atrybuty:

Typ constraintu	Przyklad zapytania	Wymagany atrybut w feedzie / schema
Budżetowy	„do 2000 zł”	price, sale_price
Funkcjonalny	„do biegania po asfalcie”	product_highlight, additionalProperty: intended_use
Techniczny	„min. 32GB RAM”	additionalProperty: ram_size (wartość numeryczna)
Kompatybilnośći	„do iPhone 15 Pro”	compatible_with, additionalProperty: compatibility
Fizyczny	„waga do 1.5 kg”	shipping_weight, additionalProperty: weight
Temporalny	„z dostawa do piatku”	shipping_label, transit_time, availability

Każdy brakujący atrybut to potencjalny punkt eliminacji. AI nie zgaduje – jeżeli danych nie ma, produkt nie przechodzi filtra.

Warto zauwazyc, ze rozkłady constraintów różnią się między branżami. W elektronice dominują constrainty techniczne (procesor, RAM, pojemność) i budżetowe. W fashion dominują fizyczne (rozmiar, kolor, materiał) i funkcjonalne (na jaka okazje). W kategorii dom i ogrod najczestsze sa fizyczne (wymiary, waga) i kompatybilności (do jakiego systemu, do jakiego metrazu). Znajomosc rozkładu constraintów w Twojej branży pozwala priorytetyzować uzupełnianie atrybutów – zacznij od typów constraintów, które pojawiają się najczęściej w zapytaniach Twoich klientow.

Dlaczego brakujące atrybuty eliminuja produkt z rekomendacji AI?

Mechanizm jest prosty i bezwzględny: jeżeli dane produktowe nie zawierają atrybutu, o który pyta użytkownik, AI nie może Cie polecic. To nie jest kwestia rankingu czy pozycji – to kwestia obecności. Produkt bez wymaganego atrybutu nie jest gorzej oceniany, jest całkowicie pomijany.

Dane potwierdzaja to jednoznacznie. AI crawlery wyciągają z danych produktowych surowe atrybuty: rozmiar, kolor, materiał, cene, dostępność. Schema markup umozliwia AI ekstrakcje dodatkowych danych: kompatybilność, oceny klientow, warianty. Jeżeli te pola sa puste, AI przechodzi do konkurenta, który je wypelnil. Jak ujal to Productrise: „The more structured, specific, and accurate the data you submit, the easier it is for Google to match your products to queries it has never seen before.”

Kluczowe jest rozróżnienie między hard constraints i soft constraints.

Hard constraints to ograniczenia, których AI nie może złuzować: cena, kompatybilność, podstawowa funkcjonalność. Jeżeli użytkownik szuka wozka „do 2000 zł”, produkt za 2100 zł nie wejdzie do wyników. Jeżeli szuka etui „na iPhone 15”, etui bez podanej kompatybilności jest niewidoczne.

Soft constraints to preferencje, które AI może potraktowac elastycznie: kolor, marka, konkretny materiał. Jeżeli użytkownik pyta o „czarny plecak turystyczny”, a w wynikach nie ma czarnych plecakow spełniających inne constrainty, AI może zaproponować grafitowy z adnotacja „closest match”. Ale zeby to zrobic, musi znac kolor każdego plecaka w katalogu.

Constraint relaxation – luzowanie ograniczeń – to mechanizm, który AI stosuje, gdy nie ma idealnego dopasowania. AI hierarchizuje constrainty: najpierw eliminuje po hard constraints, potem szuka najlepszego dopasowania w soft constraints. Jeżeli zaden produkt nie spełnia wszystkich wymagań, AI może złuzować najmniej istotne ograniczenie i poinformować o tym użytkownika: „Nie znalazłem czarnego plecaka z tymi parametrami, ale ten grafitowy jest bardzo zbliżony.”

Problem polega na tym, ze constraint relaxation działa tylko wtedy, gdy AI zna wartość atrybutu. Jeżeli Twoj plecak jest czarny, ale kolor nie jest podany w danych – AI nie wie, ze może go zaproponować jako dopasowanie. Produkt z pustym polem koloru jest gorszy od produktu z polem „grafitowy”, bo grafitowy przynajmniej wchodzi do constraint relaxation, a pusty jest ignorowany całkowicie.

To prowadzi do paradoksu: produkt obiektywnie lepszy może byc niewidoczny w AI, jeżeli ma gorsze dane. Robot sprzątający z najlepsza moca ssania na rynku, ale bez podanej wartości w atrybucie „suction_power”, przegra z gorszym robotem, który ma wpisane „2500 Pa”. AI nie czyta recenzji, nie oglada filmow na YouTube – przetwarza atrybuty. Jeżeli atrybutu nie ma, produktu też nie ma.

Jak zmapować constrainty na atrybuty w Google Merchant Center?

Wiedza o typach constraintów jest bezużyteczna bez metody mapowania ich na konkretne pola w feedzie produktowym i schema. Przedstawiam framework Constraint-to-Attribute Mapping (CAM) – systematyczne podejście do identyfikowania luk między tym, czego szukają użytkownicy, a tym, co zawierają Twoje dane.

Krok 1: Identyfikacja constraintów z trzech źródeł

Constrainty nie sa abstrakcyjnymi kategoriami – to konkretne wymagania, które użytkownicy wpisuja w zapytaniach. Trzy źródła, z których je pozyskasz:

• Google Search Console: przeanalizuj zapytania zawierające modyfikatory: „do”, „pod”, „z”, „bez”, „min.”, „max.”, „od… do…”, „kompatybilny z”, „dla”. Każdy taki modyfikator wskazuje constraint.
• People Also Ask: pytania PAA często zawierają jawne constrainty: „jaki laptop do montażu wideo do 5000 zł”, „który telefon ma najlepsza baterie do 2000 zł”.
• Testy promptow AI: wpisz 10-15 zapytań z constraintami w ChatGPT, Gemini i Perplexity. Przeanalizuj, jakie atrybuty AI wykorzystuje w odpowiedziach – to Twoj benchmark wymagań.

Krok 2: Mapowanie na pola feed + schema

Każdy zidentyfikowany constraint mapujesz na trzy warstwy danych:

Constraint z zapytania	Atrybut w Google Merchant Center	Pole schema.org
„do 3000 zł”	price	schema:Product > offers > price
„do biegania”	product_highlight, product_type	schema:Product > additionalProperty (intended_use)
„min. 32GB RAM”	custom_label, product_detail	schema:Product > additionalProperty (ram_size)
„kompatybilny z iPhone 15”	– (brak natywnego pola)	schema:Product > isAccessoryOrSparePartFor
„waga do 1.5 kg”	shipping_weight	schema:Product > weight
„dostępny od reki”	availability	schema:Product > offers > availability

Pisałem o nowych polach atrybutowych w Google Merchant Center szczegolowo w artykule o conversational attributes – to właśnie te pola, które Google wprowadza z mysla o AI. Short description, product highlight, lifestyle imagery – każde z nich pozwala opisac produkt w sposób, który AI może dopasować do constraintów użytkownika.

Krok 3: Uzupelnienie luk

Po zmapowaniu constraintów na atrybuty zobaczysz luki – constrainty, na które Twoje dane nie odpowiadają. Te luki to bezpośrednia przyczyna niewidoczności w AI. Uzupelnienie ich nie wymaga rewolucji – często wystarczy dodać jedno pole w feedzie lub jeden PropertyValue w schema.

Przyklad: sklep z rowerami analizuje zapytania GSC i znajduje constraint „do jazdy po miescie”. W feedzie nie ma zadnego atrybutu opisujacego przeznaczenie roweru – jest tylko kategoria „rowery” i podkategoria „rowery miejskie”. Ale AI szukające odpowiedzi na „rower do jazdy po miescie do 3000 zł z koszem” potrzebuje jawnego atrybutu „intended_use: jazda miejska”. Dodanie product_highlight: „rower zaprojektowany do codziennej jazdy po miescie” i additionalProperty: intended_use = „commuting, city riding” pokrywa ten constraint.

Framework CAM łączy się bezpośrednio z podejsciem do personalizacji rekomendacji AI – constraint to jawnie wyrazona preferencja użytkownika, a atrybut to odpowiedź na te preferencje w danych produktowych.

Czym jest Constraint Coverage Score i jak go mierzyc?

Constraint Coverage Score (CCS) to autorski wskaźnik Semgence, który mierzy, jaki procent constraintów z zapytań użytkowników jest pokryty atrybutami w Twoich danych produktowych. CCS uzupełnia Product Comparability Score (PCS) – podczas gdy PCS mierzy ogólną gotowość danych do porównań AI, CCS skupia się konkretnie na pokryciu wymagań z zapytań wielowarunkowych.

Wzor:

CCS = (liczba constraintów pokrytych atrybutami / łączna liczba constraintów w zapytaniach) x 100

CCS obliczasz per kategoria produktowa, bo różne kategorie maja różne constrainty.

Jak przeprowadzić audyt CCS:

Krok 1: Wybierz 3 kluczowe kategorie produktowe (według przychodu).

Krok 2: Dla każdej kategorii zbierz top 20 zapytań z constraintami – z GSC, PAA i testow promptow AI.

Krok 3: Wyodrebnij unikalne constrainty z tych zapytań. Typowo otrzymasz 15-25 unikalnych constraintów per kategoria.

Krok 4: Dla każdego constraintu sprawdź, czy odpowiadający mu atrybut istnieje w feedzie produktowym i/lub schema na PDP.

Krok 5: Oblicz CCS.

Przyklad audytu dla kategorii „laptopy”:

Constraint z zapytań	Atrybut w feedzie?	Atrybut w schema?	Pokryty?
Cena do X zł	Tak (price)	Tak (offers > price)	Tak
Min. RAM	Nie (brak pola)	Nie	Nie
Rozmiar ekranu	Tak (product_detail)	Czesciowo (brak PropertyValue)	Czesciowo
Do montażu wideo	Nie	Nie	Nie
Z Thunderbolt	Nie	Nie	Nie
Waga do X kg	Tak (shipping_weight)	Nie	Czesciowo
Czas pracy baterii	Nie	Nie	Nie
Procesor (typ)	Tak (product_detail)	Nie	Czesciowo

W tym przykladzie na 8 constraintów: 1 jest w pełni pokryty, 3 częściowo, 4 niepokryte. Liczac czesciowe jako 0.5, CCS = (1 + 1.5) / 8 x 100 = 31.25%.

CCS poniżej 50% to sygnalizacja, ze większość zapytań z ograniczeniami nie ma szans na dopasowanie Twoich produktów. Oznacza to, ze użytkownik może wpisac w ChatGPT „laptop do montażu wideo do 6000 zł z min. 32GB RAM” i Twoj laptop za 5500 zł z 64GB RAM nie pojawi się w odpowiedzi, bo AI nie zna wartości jego RAM-u ani przeznaczenia.

Interpretacja CCS:

• 80-100%: Doskonale pokrycie – Twoje dane odpowiadają na większość constraintów, produkty regularnie pojawiają się w odpowiedziach AI na zapytania wielowarunkowe
• 60-79%: Dobre pokrycie z lukami – produkty pojawiają się w odpowiedziach, ale tracisz widoczność na części zapytań; priorytetowe uzupełnienie brakujących atrybutów
• 40-59%: Srednie pokrycie – produkty sporadycznie dopasowuja się do zapytań z ograniczeniami; potrzebna systematyczna praca nad danymi
• 0-39%: Slabe pokrycie – dane produktowe nie odpowiadają na większość constraintów; konieczny audyt i przebudowa struktury atrybutów

Roznica między CCS a PCS: PCS mierzy ogólną jakość i kompletność danych produktowych w kontekscie porównań AI. CCS mierzy konkretnie pokrycie constraintów z realnych zapytań użytkowników. Sklep może miec wysoki PCS (dobrze wypelniony feed, poprawna schema), ale niski CCS (atrybuty nie odpowiadają na to, czego szukają użytkownicy). Dlatego oba wskazniki sa komplementarne.

Jak optymalizowac opisy produktowe pod zapytania z ograniczeniami?

Optymalizacja pod constraint-based search wymaga pracy na trzech warstwach: structured data (schema), feed produktowy (Google Merchant Center) i strona PDP (treść wizualna). Każda warstwa służy innemu celowi i dociera do AI przez inny kanal.

Warstwa 1: Schema.org Product + additionalProperty

Schema to podstawa. Każdy atrybut, który może byc constraintem w zapytaniu, powinien byc zakodowany jako PropertyValue w additionalProperty. Przyklad dla laptopa:

{
  "@type": "Product",
  "name": "Laptop ProX 16",
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "RAM",
      "value": "32",
      "unitCode": "GB"
    },
    {
      "@type": "PropertyValue",
      "name": "intended_use",
      "value": "montaz wideo, obrobka graficzna"
    },
    {
      "@type": "PropertyValue",
      "name": "port_thunderbolt",
      "value": "2x Thunderbolt 4"
    }
  ]
}

Każdy PropertyValue to jawna odpowiedź na potencjalny constraint. AI nie musi „wyciągać” informacji z opisu – ma ja gotowa w formacie maszynowym.

Warstwa 2: Feed produktowy z conversational attributes

Google Merchant Center wspiera pola, które bezpośrednio odpowiadają na constrainty: product_highlight (krótkie frazy opisujące kluczowe cechy), short_description (zwięzły opis z faktami), product_detail (dodatkowe atrybuty w parach nazwa-wartość). Im więcej tych pol wypelnisz, tym więcej constraintów AI może zweryfikować. Wiecej o tych polach i strategii ich wypelniania opisuje artykul o conversational attributes w Merchant Center.

Warstwa 3: Sekcje na PDP

Strona produktowa powinna zawierac dedykowane sekcje odpowiadające na najpopularniejsze constrainty w danej kategorii:

• „Kompatybilność” – lista urządzeń, systemow i akcesoriów, z ktorymi produkt współpracuje
• „Zastosowanie” – jawnie opisane use case’y z konkretnymi scenariuszami uzycia
• „Specyfikacja techniczna” – tabela z precyzyjnymi wartosciami numerycznymi
• „Dostępność i dostawa” – informacje o czasie dostawy, stanach magazynowych, wariantach

Każda z tych sekcji to punkt ekstrakcji dla AI. Perplexity scrapuje strony bezpośrednio – jeżeli informacja o kompatybilności jest na PDP, Perplexity może ja wyekstrahować i użyć w odpowiedzi. ChatGPT coraz częściej korzysta z feedow produktowych, ale gdy feed nie zawiera danego atrybutu, siega po dane z PDP. Google AI Mode łączy dane z Merchant Center, schema i indeksu – im więcej warstw pokrywasz, tym wieksza szansa na widoczność.

Kluczowa zasada: każdy constraint, który zidentyfikujesz w analizie CAM, powinien miec odpowiedź w co najmniej dwóch z trzech warstw. Jeżeli constraint „do biegania” jest pokryty w schema (additionalProperty: intended_use = „running”) i w feedzie (product_highlight: „zaprojektowany do biegania”), ale nie na PDP – to i tak dobra pozycja wyjściowa. Jeżeli jest tylko na PDP w opisie marketingowym („idealne do porannego joggingu”) – AI może go nie wyekstrahować poprawnie.

Jak przetestowac widoczność produktu na zapytania constraint-based?

Testowanie widoczności na zapytania z ograniczeniami to proces, który możesz przeprowadzić samodzielnie. Poniżej metodologia, która stosujemy w Semgence w ramach audytu widoczności w AI.

Metodologia testowania:

1. Przygotuj 10 zapytań z constraintami dla każdej kluczowej kategorii. Zapytania powinny zawierac 2-4 constrainty i odpowiadać realnym scenariuszom zakupowym.

1. Wpisz każde zapytanie w trzech systemach AI: ChatGPT, Google AI Mode (lub Gemini), Perplexity.

1. Powtórz każde zapytanie 3 razy (AI generuje różne odpowiedzi za każdym razem).

1. Dla każdej odpowiedzi odnotuj trzy metryki:

– Presence rate: czy Twoj produkt pojawił się w odpowiedzi (tak/nie) – Position: jeżeli tak, na którym miejscu w liscie rekomendacji – Constraint match accuracy: ile constraintów z zapytania AI poprawnie dopasowało do Twojego produktu

Przyklad arkusza testowego:

Zapytanie	System	Powtorzenie	Obecnosc	Pozycja	Constrainty dopasowane
Laptop do montażu 4K do 6000 zł min. 32GB RAM	ChatGPT	1	Nie	–	0/3
Laptop do montażu 4K do 6000 zł min. 32GB RAM	ChatGPT	2	Nie	–	0/3
Laptop do montażu 4K do 6000 zł min. 32GB RAM	Gemini	1	Tak	3	2/3 (cena, RAM)

Interpretacja wyników:

Jeżeli presence rate jest poniżej 30% na zapytania, na które Twoj produkt obiektywnie powinien odpowiadać – masz problem z danymi, nie z produktem. Porównaj atrybuty Twojego produktu z atrybutami produktów, które AI rekomenduje. Roznica niemal zawsze lezy w kompletności i strukturze danych.

Porownanie: przed i po dodaniu brakujących atrybutów

Rekomendujemy przeprowadzenie testu dwukrotnie: raz przed optymalizacja danych, raz 2-3 tygodnie po wdrożeniu zmian. Roznica w presence rate to najlepsza miara skuteczności optymalizacji pod constraint-based search. Realistyczny cel to wzrost presence rate o 20-40 punktow procentowych po uzupelnieniu brakujących atrybutów.

Warto też monitorować, jakie constrainty AI dopasowuje poprawnie, a jakie pomija. Jeżeli Twoj produkt pojawia się w odpowiedzi, ale AI nie rozpoznaje jednego z constraintów (np. pokazuje produkt na zapytanie „do biegania”, ale nie wspomina o wodoodporności, która też byla w zapytaniu) – to sygnal, ze dany atrybut jest niewystarczająco wyraźny w danych. Moze jest w opisie marketingowym, ale nie w schema ani w feedzie. Moze wartość jest opisowa („wytrzymały na deszcz”) zamiast maszynowej („IPX7”). Takie szczegoly robią różnice między czesciowym a pełnym dopasowaniem do zapytania.

Checklista wdrożeniowa – 14 dni:

Dni 1-3: Audyt

• Przeprowadź audyt CCS dla 3 top kategorii
• Zidentyfikuj 10-15 najczęstszych constraintów per kategoria
• Zmapuj constrainty na atrybuty (framework CAM)
• Wykonaj bazowy test widoczności (10 zapytań x 3 systemy x 3 powtórzenia)

Dni 4-7: Implementacja warstwy danych

• Uzupełnij brakujące atrybuty w feedzie Google Merchant Center
• Dodaj PropertyValue do schema na PDP dla top 50 produktów
• Znormalizuj wartości atrybutów (opisowe na numeryczne)

Dni 8-10: Implementacja warstwy treści

• Dodaj sekcje „Kompatybilność” i „Zastosowanie” na PDP
• Rozbuduj tabele specyfikacji o atrybuty odpowiadające constraintom
• Dodaj product_highlight i short_description do feedu

Dni 11-14: Weryfikacja

• Poczekaj na reindeksację (ChatGPT: kilka dni, Google: cykl crawlowania, Perplexity: natychmiast)
• Powtórz test widoczności z tymi samymi zapytaniami
• Porównaj presence rate przed i po
• Oblicz CCS po zmianach

Jeżeli potrzebujesz wsparcia w tym procesie – od audytu przez implementację po monitoring – sprawdź nasze pozycjonowanie sklepu internetowego. Łączymy klasyczne SEO e-commerce z optymalizacja danych produktowych pod AI.