Sklep z wyposażeniem kuchni miał ponad 2 tysiące produktów, przyzwoite pozycje w Google na frazy produktowe i praktycznie zerową obecność w odpowiedziach ChatGPT. Gdy ktoś pytał model o „dobry nóż szefa kuchni do 300 zł” albo „patelnię stalową na indukcję z darmowym zwrotem”, w rekomendacjach pojawiały się marketplace’y i dwa konkurencyjne sklepy. Ten case pokazuje, co zmieniliśmy i jak to mierzyliśmy. To case modelowy: łączy przebieg kilku podobnych wdrożeń w sklepach średniej wielkości, a liczby są zaokrąglone i mają pokazać skalę zjawisk, nie obiecywać konkretnego wyniku.
Punkt wyjścia był typowy. Produkty istniały, opisy były poprawne, ale najważniejsze fakty (cena, dostępność, warunki zwrotu, parametry techniczne) żyły w skryptach JavaScript, w widżetach ładowanych po czasie i w plikach PDF. Dla człowieka w przeglądarce wszystko było widoczne. Dla systemu, który pobiera stronę i składa z niej odpowiedź, połowa informacji nie istniała.
Diagnoza: co model widział, a czego nie
Zaczęliśmy od prostego testu: pobraliśmy surowy HTML 50 losowych kart produktowych bez wykonywania JavaScriptu, czyli tak, jak robi to większość crawlerów używanych przez systemy AI. Wynik był jednoznaczny. Cena była w kodzie źródłowym tylko w 18 z 50 kart, informacja o dostępności w żadnej, a tabela parametrów w 31. Polityka zwrotów była podlinkowana w stopce, ale prowadziła do PDF bez wersji HTML.
Drugi test polegał na zadaniu ChatGPT z włączonym wyszukiwaniem 40 pytań zakupowych z kategorii, w których sklep miał najmocniejszy asortyment. Sklep pojawił się w 2 odpowiedziach na 40, i w obu przypadkach model cytował stary wpis blogowy, a nie kartę produktu. Tam, gdzie model polecał konkurencję, w odpowiedzi padały konkretne fakty: cena, materiał, gwarancja. Model wybierał źródła, z których mógł te fakty wyciągnąć bez zgadywania.
Audyt danych produktowych i znaczników
Audyt podzieliliśmy na trzy warstwy: treść widoczną w HTML, dane strukturalne oraz spójność danych między stroną, feedem produktowym i stronami informacyjnymi.
- Treść w HTML: brak ceny i dostępności w kodzie serwowanym przez serwer, parametry w zakładkach ładowanych dynamicznie, opisy częściowo skopiowane od producentów.
- Dane strukturalne: znacznik Product istniał, ale bez
offers, bezbrandi z ceną zapisaną jako tekst z walutą w jednym polu. - Spójność: feed w Merchant Center miał inne ceny niż strona w około 7% produktów, a czas dostawy w regulaminie różnił się od tego na kartach.
Jako punkt odniesienia dla znaczników przyjęliśmy dokumentację danych strukturalnych produktów w Google Search Central oraz definicję typu Product na schema.org. Modele językowe nie czytają schema.org tak jak Google, ale porządne znaczniki wymuszają porządek w samych danych, a to przekłada się na treść widoczną na stronie.
Zmiany w HTML kart produktowych
Najważniejsza zmiana była techniczna i mało efektowna: cena, dostępność, czas wysyłki i kluczowe parametry trafiły do HTML renderowanego po stronie serwera. Zakładki zostały, ale ich zawartość jest w kodzie od początku, a JavaScript tylko ją pokazuje i ukrywa.
Każda karta dostała krótki blok faktów nad opisem: materiał, wymiary, waga, kompatybilność (na przykład typ płyty grzewczej), gwarancja i kraj produkcji. Zapisaliśmy go jako tabelę, bo jak pokazujemy w tekście o tym, który format treści modele cytują najchętniej, pary „cecha: wartość” są dla modelu najłatwiejsze do wyciągnięcia i przytoczenia bez przekłamań.
Opisy skopiowane od producentów przepisaliśmy w pierwszej kolejności dla 300 produktów z największą sprzedażą. Nie chodziło o długość, tylko o informacje, których nie ma nigdzie indziej: do czego produkt się nadaje, a do czego nie, z czym bywa mylony, jak go pielęgnować.
Uporządkowanie cen, dostępności i zwrotów
Rozbieżności między feedem a stroną usunęliśmy u źródła: obie wersje zaczęły czerpać cenę z jednego pola w systemie sklepu, z jednym harmonogramem aktualizacji. Znacznik offers dostał osobno price, priceCurrency, availability oraz informacje o wysyłce i zwrotach.
Politykę zwrotów przenieśliśmy z PDF na zwykłą stronę HTML z jasnymi odpowiedziami: ile dni, kto płaci za odesłanie, czy zwrot obejmuje produkty używane. To jedna z tych stron, które w pytaniach zakupowych modele cytują zaskakująco często, bo użytkownicy dopytują o warunki zakupu, a nie tylko o sam produkt. Jeśli sklep ma ambicję trafiać do odpowiedzi zakupowych, warto też przejść przez warunki opisane w tekście o tym, jak sklep trafia do wyników zakupowych ChatGPT.
Strony porównań i zestawień jako wsparcie
Same karty produktów odpowiadają na pytanie „co to jest”, ale rzadko na pytanie „co wybrać”. Tymczasem większość zapytań w testowym zestawie miała właśnie charakter porównawczy. Przygotowaliśmy więc 12 stron zestawień: na przykład patelnie stalowe kontra żeliwne na indukcję czy noże japońskie kontra niemieckie w różnych przedziałach cenowych.
Każde zestawienie miało jawne kryteria, tabelę porównawczą z linkami do konkretnych kart i podpis autora z opisem doświadczenia. Autorem był pracownik sklepu, który od lat doradza klientom w sklepie stacjonarnym. Taka strona autora ma realne znaczenie dla wiarygodności, a sposób jej budowania opisujemy w osobnym materiale z klastra o cytowaniach i E-E-A-T.
Jak mierzyliśmy obecność w odpowiedziach
Bez pomiaru każda zmiana w AIO jest wróżeniem. Zbudowaliśmy stały zestaw 120 pytań w trzech grupach: pytania o konkretny typ produktu, pytania porównawcze i pytania o warunki zakupu. Każde pytanie zadawaliśmy co tydzień w ChatGPT z wyszukiwaniem, w nowej sesji, bez historii i bez personalizacji.
Zapisywaliśmy trzy rzeczy: czy sklep pojawił się w odpowiedzi, czy był podlinkowany jako źródło oraz który adres został zacytowany. Ponieważ odpowiedzi modeli są niedeterministyczne, każde pytanie zadawaliśmy trzy razy i liczyliśmy obecność jako odsetek prób. Podobną metodykę, w wersji gotowej do wdrożenia u siebie, opisujemy w poradniku o tym, jak zbudować własny tracker widoczności w ChatGPT.
Grupa kontrolna
Żeby oddzielić efekt naszych zmian od ogólnych wahań modelu, 30 pytań dotyczyło kategorii, których nie ruszaliśmy. Gdyby obecność rosła tak samo w obu grupach, wniosek byłby prosty: to model się zmienił, nie sklep.
Wyniki po trzech miesiącach
Po 12 tygodniach obraz wyglądał tak:
| Wskaźnik | Przed zmianami | Po 12 tygodniach |
|---|---|---|
| Obecność w odpowiedziach (kategorie zmienione) | ok. 4% | ok. 27% |
| Obecność w odpowiedziach (grupa kontrolna) | ok. 3% | ok. 6% |
| Cytowania karty produktu jako źródła | prawie zero | ok. 40% wszystkich cytowań sklepu |
| Cytowania stron zestawień | brak stron | ok. 35% wszystkich cytowań sklepu |
Najszybciej rosła obecność w pytaniach o warunki zakupu, co ma sens: strona zwrotów w HTML zaczęła być cytowana już po trzech tygodniach. Pytania porównawcze ruszyły dopiero po publikacji zestawień. Ruch z ChatGPT w analityce był niewielki w liczbach bezwzględnych, ale współczynnik konwersji tych wizyt był wyraźnie wyższy niż średnia sklepu, bo użytkownik przychodził z gotową decyzją.
Co okazało się nieistotne
Kilka rzeczy, na które poświęciliśmy czas, nie dało mierzalnego efektu:
- Plik llms.txt: wdrożony, ale w logach serwera nie odnotowaliśmy, żeby którykolwiek crawler AI go pobierał w okresie testu.
- Wydłużanie opisów: karty, które urosły z 300 do 900 słów bez nowych faktów, nie zyskały na obecności w odpowiedziach.
- Dodatkowe typy schema: rozbudowa o rzadko używane właściwości nie zmieniła niczego, w przeciwieństwie do poprawienia podstawowych pól
offers.
Wniosek jest podobny do tego z case’u młodej domeny i pierwszych 1000 wejść z Google: największy efekt dają nudne, porządkowe zmiany w fundamentach, a nie modne dodatki. W AIO tym fundamentem są dane produktowe dostępne w HTML, spójne między kanałami i zapisane w formie, którą da się zacytować.
FAQ
Czy ChatGPT czyta dane strukturalne schema.org?
Nie ma publicznego potwierdzenia, że modele korzystają ze schema.org bezpośrednio. W praktyce ważniejsze jest to, że te same fakty są widoczne w HTML strony. Porządne znaczniki pomagają głównie dlatego, że wymuszają porządek w danych, a przy okazji wspierają wyniki rozszerzone w Google.
Ile czasu trzeba, żeby zobaczyć efekty w odpowiedziach modeli?
W opisanym przypadku pierwsze cytowania strony zwrotów pojawiły się po około trzech tygodniach, a wyraźny wzrost w pytaniach porównawczych po 8–10 tygodniach. Tempo zależy od tego, jak często crawlery odwiedzają sklep.
Czy sklep musi mieć feed w Merchant Center, żeby trafić do rekomendacji ChatGPT?
Do zwykłych odpowiedzi z cytowaniem nie, wystarczy dobrze zbudowana strona. Feed ma znaczenie dla wyników zakupowych i integracji produktowych, a jego spójność ze stroną eliminuje sprzeczne sygnały o cenie i dostępności.
Jak mierzyć obecność sklepu w odpowiedziach AI bez drogich narzędzi?
Wystarczy stały zestaw pytań, zadawanych regularnie w nowych sesjach, kilka powtórzeń każdego pytania i arkusz z wynikami. Kluczowa jest grupa kontrolna, która pozwala odróżnić efekt własnych zmian od zmian w samym modelu.
Co poprawić w pierwszej kolejności przy ograniczonym budżecie?
Cenę, dostępność i parametry w HTML renderowanym po stronie serwera, a potem stronę z warunkami zwrotów i dostawy. To zmiany o najniższym koszcie i najszybszym efekcie w opisanym wdrożeniu.