Karta produktu pod lupą algorytmów – co patenty Google mówią o Twoim sklepie?

Google analizuje karty produktów w polskich sklepach internetowych przez pryzmat co najmniej 8 opatentowanych algorytmów – od ekstrakcji Entity-Attribute-Value (US9110852B1) po predykcję jakości witryny (US20140280011A1). Przeprowadziliśmy audyt 2 polskich sklepów ze świecami zapachowymi – swiecoholik.pl i domkove.pl – z pełną weryfikacją kodu źródłowego. Wynik? Oba mają dane produktowe w schema – ale w różnych formatach. I właśnie ten wybór formatu decyduje o widoczności w AI Search. A wystarczy ta sama świeca Yankee Candle, żeby zobaczyć, jak ogromna jest różnica w widoczności.

Dlaczego Google patentuje sposoby analizy kart produktów?

Google składa rocznie setki patentów związanych z wyszukiwaniem, a sam algorytm przechodzi średnio 7 potwierdzonych aktualizacji rocznie (dane za lata 2021-2025), a znaczna część z nich dotyczy sposobu, w jaki algorytmy rozumieją i oceniają strony produktowe. Nie chodzi tu o abstrakcyjne pomysły – każdy patent opisuje konkretny mechanizm, który może być (i prawdopodobnie jest) wdrożony w systemie rankingowym. Z perspektywy właściciela sklepu internetowego znajomość tych patentów to przewaga konkurencyjna – pozwala zrozumieć, czego algorytm szuka na karcie produktu i dlaczego niektóre sklepy rankują wyżej od innych mimo podobnej oferty.

Ten artykuł powstał na podstawie analizy publicznie dostępnych patentów Google, audytu danych strukturalnych w polskich sklepach oraz doświadczeń z ponad 50 audytów kart produktowych, które Semgence przeprowadziło w ramach usługi pozycjonowania sklepów internetowych. Każdy opisany patent zawiera numer referencyjny, dzięki czemu można samodzielnie zweryfikować jego treść na patents.google.com. Warto dodać, że dane strukturalne zyskują na znaczeniu także w kontekście AI Search – jak podkreślił Fabrice Canel z Microsoft Bing na konferencji SMX Munich 2025, schema markup pomaga LLM-om zrozumieć treść strony.

Przeanalizowaliśmy 8 kluczowych patentów Google, które bezpośrednio wpływają na ocenę kart produktowych. Każdy z nich odpowiada za inny aspekt – od sposobu wyciągania faktów z opisu, przez ocenę wiarygodności danych, aż po analizę zachowań użytkowników na stronie.

Jak Google wyciąga fakty z opisu produktu?

Patent US9110852B1 (Entity-Attribute-Value extraction) opisuje mechanizm, który zmienia sposób, w jaki algorytm czyta kartę produktu. Zamiast traktować tekst jako ciągły blok, system parsuje go do trójek: encja (nazwa produktu) – atrybut (np. RAM, waga, rozdzielczość) – wartość (np. 12 GB, 234 g, 200 MP). To kluczowe rozróżnienie, bo oznacza, że algorytm nie szuka „ładnego opisu” – szuka strukturalnych faktów.

Z praktycznego punktu widzenia oznacza to, że karta produktu, na której specyfikacja techniczna jest zakodowana w tabeli HTML (element TABLE) lub w liście definicyjnej (DL/DT/DD), jest wielokrotnie łatwiejsza do przetworzenia niż ta sama informacja ukryta w akapitach tekstu ciągłego. Więcej o tym, jak algorytmy wyciągają dane z kart produktowych, pisaliśmy w artykule o extractability score karty produktowej. Google wprost preferuje formaty klucz-wartość, bo odpowiadają one trójkom EAV opisanym w patencie.

Warto podkreślić, że patent US9110852B1 opisuje również mechanizm walidacji wyekstrahowanych faktów – system porównuje nowo wyciągnięte trójki z już znanymi faktami w bazie wiedzy i ocenia ich wiarygodność (fact validation ratio). Na karcie produktu oznacza to, że dane techniczne, które są spójne z oficjalną specyfikacją producenta (np. z Samsung.com), otrzymują wyższy wskaźnik zaufania niż dane podane bez potwierdzenia. Dlatego tak ważne jest, aby specyfikacja na karcie produktu była nie tylko kompletna, ale również dokładna – błędna wartość RAM czy pojemności baterii obniża wskaźnik walidacji dla całej strony.

Czym jest Fact Density i dlaczego polskie opisy produktów mają z tym problem?

Patent US9672251B1 wprowadza pojęcie gęstości faktów (Fact Density) – algorytm dzieli stronę na sekcje i liczy, ile weryfikowalnych faktów zawiera każda z nich. Sekcja z najwyższą gęstością faktów staje się wyznacznikiem jakości całego dokumentu. W kontekście karty produktu oznacza to, że sekcja specyfikacji technicznej z 20 konkretnymi parametrami (rozdzielczość ekranu: 3120 x 1440 pikseli, jasność: 2600 nitów, procesor: Snapdragon 8 Gen 3) wygeneruje znacznie wyższy wynik niż 3 akapity marketingowego opisu producenta.

Problem polskich sklepów internetowych polega na tym, że większość z nich kopiuje opisy producenta – identyczne teksty marketingowe pojawiają się na kartach produktów w dziesiątkach sklepów jednocześnie. Z perspektywy patentu US9672251B1 takie opisy mają niską gęstość faktów (dużo słów, mało weryfikowalnych danych) i zerowy information gain (bo ten sam tekst jest dostępny wszędzie). Sklep, który doda własne testy, pomiary lub porównania, automatycznie zwiększa zarówno Fact Density, jak i unikalność treści. Wyobraź sobie użytkownika, który wpisuje w Google „prezent dla Kasi” – algorytm musi zrozumieć, że świeca zapachowa może być odpowiedzią na to zapytanie. Ale żeby to zrobić, potrzebuje faktów: że to produkt prezentowy, że ma eleganckie opakowanie, że pachnie wanilią (bo Kasia lubi wanilię). Bez tych faktów na karcie produktu – ani w tekście, ani w schema – algorytm nie ma podstaw do dopasowania intencji. Temat unikalnych opisów produktów omówiliśmy szczegółowo w poradniku jak tworzyć opisy w sklepie internetowym.

JSON-LD vs Microdata – jak dwa polskie sklepy ze świecami podeszły do schema Product?

Przeprowadziliśmy audyt danych strukturalnych na kartach produktów w dwóch polskich sklepach ze świecami zapachowymi: swiecoholik.pl (reseller Yankee Candle) i domkove.pl (producent świec sojowych). Oba serwują pełny HTML po stronie serwera – żaden nie ukrywa treści za JavaScript. Oba mają schema Product. Ale implementują ją w kompletnie różnych formatach – i ta różnica ma realne konsekwencje.

Swiecoholik.pl uzyskał wynik 85/100 w schema coverage dzięki pełnej implementacji Product JSON-LD z name, description, brand, sku, gtin13 (EAN), category oraz Offer z ceną i availability. Weryfikacja kodu źródłowego potwierdza – cały JSON-LD jest widoczny w surowym HTML bez renderowania JavaScript. Sklep działa na platformie Shoper i korzysta z wbudowanego generatora schema (zgodnie z dokumentacją Google Search Central). Domkove.pl (producent sojowych świec zapachowych z Warszawy) ma pełną implementację schema Product – ale w formacie Microdata, nie JSON-LD. Ręczna weryfikacja kodu źródłowego ujawniła Product z name, description, brand, sku, image, Offer z ceną i availability, a nawet 17 recenzji z AggregateRating (ocena 4.9). To więcej danych niż u swiecoholik.pl! Problem polega na tym, że Microdata jest wpleciona w strukturę HTML (atrybuty itemprop, itemscope, itemtype) – co oznacza, że systemy AI muszą renderować i parsować DOM, żeby do niej dotrzeć. Brakuje natomiast GTIN/EAN, co utrudnia jednoznaczną identyfikację produktu.

Kluczowa metryka to Attribute Richness Score – swiecoholik.pl uzyskał 29/100 (JSON-LD bez atrybutów fizycznych), a domkove.pl ma bogatsze dane w Microdata (review, rating), ale w formacie trudniejszym do ekstrakcji przez AI. Żaden z dwóch sklepów nie podaje w schema atrybutów typowych dla świec: materiału (wosk sojowy vs parafina), wagi, czasu palenia, nut zapachowych ani koloru. Z perspektywy patentu US9110852B1 (EAV extraction) każdy brakujący atrybut to utracona trójka faktów, którą Google mógłby wykorzystać do rankowania i wyświetlania w rich snippets. A dla zapytań typu „prezent dla Kasi” – gdzie Google musi dopasować intencję do konkretnych atrybutów produktu – brak tych danych oznacza brak szansy na pojawienie się w wynikach.

Istotne zastrzeżenie dotyczące renderowania: Ręczna weryfikacja kodu źródłowego (curl + Python) ujawniła kluczową różnicę formatów. Swiecoholik.pl (465 KB) serwuje Product schema jako oddzielny blok JSON-LD w sekcji head – czytelny dla każdego crawlera i systemu AI bez renderowania DOM. Domkove.pl (234 KB) serwuje te same dane jako Microdata – atrybuty itemprop rozproszone po elementach HTML. Google odczyta oba formaty. Ale systemy AI (ChatGPT, Perplexity, Gemini), które indeksują treść bez pełnego renderowania przeglądarki, znacznie łatwiej parsują JSON-LD niż wyciągają itemprop z zagnieżdżonego HTML.

Czy Google sprawdza spójność danych między HTML a JSON-LD?

Patent US9785686B2 (Fact Corroboration) opisuje mechanizm porównywania faktów z wielu źródeł. W kontekście karty produktu oznacza to, że algorytm porównuje cenę widoczną na stronie z ceną w JSON-LD, cenę w JSON-LD z ceną w Google Merchant Center, a dane producenta z informacjami na stronie sklepu. Każda rozbieżność obniża wskaźnik zaufania (source confidence).

W praktyce widzimy to regularnie w polskich sklepach – cena na stronie zawiera „brutto” lub „netto”, a w schema Product jest sama liczba bez kontekstu. Albo stan magazynowy mówi „dostępny”, a schema nie zawiera pola availability. Patent US9785686B2 jasno wskazuje, że takie rozbieżności nie są neutralne – aktywnie obniżają ocenę wiarygodności źródła.

Co patent o jakości witryny mówi o sklepach internetowych?

Dwa powiązane patenty – US9031929B1 (Site Quality Score) i US20140280011A1 (Predictive Site Quality) – opisują mechanizmy oceny jakości na poziomie całej domeny, nie pojedynczej strony. Patent US9031929B1 liczy, ile unikalnych zapytań brandowych (np. „swiecoholik opinie”, „domkove swiece”) prowadzi do danej witryny. Im więcej użytkowników szuka sklepu po nazwie, tym wyższy Brand Demand Score i wyższa ogólna ocena jakości.

Patent US20140280011A1 idzie dalej – buduje model predykcyjny jakości na podstawie częstotliwości fraz w treści witryny. Jeśli strona używa fraz typowych dla witryn wysokiej jakości (szczegółowe specyfikacje, recenzje eksperckie, porównania), algorytm przewiduje wysoką jakość. Jeśli dominują frazy typowe dla witryn niskiej jakości (sztuczne powtórzenia słów kluczowych, generyczne opisy), wynik spada.

Dla polskich sklepów internetowych oznacza to, że indywidualnie napisane opisy produktów, unikalne sekcje recenzji i oryginalne treści poradnikowe budują sygnały jakości na poziomie całej domeny. O budowaniu encji, którą algorytmy AI rozpoznają i cytują, pisaliśmy w artykule o entity-citability – a nie tylko pojedynczej karty produktu.

Jak phrase-based indexing wpływa na ranking kart produktowych?

Patent US6823333B1 (Phrase-based Indexing) opisuje system analizy współwystępowania fraz na stronie. Algorytm nie patrzy na pojedyncze słowa kluczowe – analizuje, czy na stronie pojawiają się frazy, które normalnie występują razem w treściach wysokiej jakości o danym temacie. Na karcie smartfona algorytm oczekuje współwystępowania fraz takich jak „rozdzielczość aparatu”, „pojemność baterii”, „częstotliwość odświeżania ekranu”, „pamięć operacyjna” i „certyfikat IP68”.

Jeśli karta produktu zawiera jedynie nazwę, cenę i skopiowany opis producenta, brakuje jej naturalnych ko-występowań fraz, które algorytm znajduje na najlepiej rankujących stronach. Własna sekcja „dla kogo jest ten produkt”, porównanie z konkurencyjnym modelem lub odpowiedzi na najczęstsze pytania kupujących to elementy, które budują bogatszą sieć powiązanych fraz i sygnalizują algorytmowi eksperckość treści.

Czy Google mierzy, jak użytkownicy zachowują się na karcie produktu?

Patent US8661029B1 (Search Satisfaction) opisuje mechanizm pomiaru satysfakcji użytkownika po kliknięciu w wynik wyszukiwania. Algorytm analizuje, czy użytkownik wrócił szybko do wyników (pogo-sticking – sygnał niskiej satysfakcji), czy spędził czas na stronie i podjął dalsze akcje (sygnał wysokiej satysfakcji).

Na karcie produktu pogo-sticking najczęściej występuje, gdy użytkownik nie znajduje informacji, której szukał – brak ceny, brak stanu magazynowego, brak szczegółowej specyfikacji lub brak odpowiedzi na kluczowe pytanie (np. „czy pasuje do mojego modelu”). Każdy element, który zatrzymuje użytkownika na stronie i pomaga mu podjąć decyzję – tabela porównawcza, sekcja FAQ, informacja o kompatybilności – to bezpośredni sygnał satysfakcji z perspektywy tego patentu.

Jak Google identyfikuje atrybuty encji produktowych?

Patent US9864795B1 (Identifying Entity Attributes) opisuje system, który uczy się, jakie atrybuty są istotne dla danej klasy encji. Dla klasy „smartfon” algorytm wie, że kluczowe atrybuty to RAM, pamięć wewnętrzna, rozdzielczość aparatu, pojemność baterii i rozmiar ekranu – bo miliony zapytań użytkowników i tekstów na stronach internetowych konsekwentnie łączą te atrybuty ze smartfonami. Patent określa to jako „schema-level attributes” – nie wartości konkretnych produktów, ale typy informacji, które ludzie uważają za istotne dla danej kategorii.

Z perspektywy karty produktu oznacza to, że algorytm wie, czego szukać – i potrafi ocenić, czy karta produktu zawiera komplet oczekiwanych atrybutów. Karta smartfona bez informacji o baterii, karta laptopa bez informacji o procesorze, karta telewizora bez rozdzielczości – to sygnały niekompletności, które wpływają na ocenę entity attribute completeness. Narzędzia audytowe Semgence mierzą ten wskaźnik automatycznie – w naszym audycie x-kom.pl uzyskał entity attribute completeness na poziomie zaledwie 15/100 (bo crawler trafił na stronę 404), a na działającej karcie swiecoholik.pl wynik attribute richness wyniósł zaledwie 29/100.

Czy format danych strukturalnych ma znaczenie dla AI Search?

To kluczowe pytanie, które wyłania się z porównania swiecoholik.pl i domkove.pl. Google oficjalnie wspiera trzy formaty danych strukturalnych: JSON-LD, Microdata i RDFa. Jednak w praktyce rekomenduje wyłącznie JSON-LD – i ma ku temu konkretne powody, które nabierają znaczenia w erze AI Search.

JSON-LD to oddzielny blok kodu JavaScript umieszczony w sekcji head lub body strony. Zawiera kompletny obiekt danych produktu jako samodzielną strukturę – niezależną od HTML. Crawler Google, system AI Overviews, czy LLM indeksujący treść (ChatGPT, Perplexity, Gemini) może odczytać ten blok bez renderowania całej strony. To jak osobna kartoteka produktu dołączona do strony.

Microdata to atrybuty (itemprop, itemscope, itemtype) wplecione bezpośrednio w elementy HTML. Żeby je odczytać, system musi przejść po drzewie DOM i zrekonstruować obiekt danych z rozproszonych fragmentów. Google to potrafi – ale systemy AI, które skanują treść stron na potrzeby AI visibility, często parsują tekst i JSON, pomijając atrybuty HTML. W efekcie sklep z Microdata może być niewidoczny dla AI, mimo że Google widzi jego schema Product prawidłowo.

Z perspektywy patentu US9110852B1 (EAV extraction) oba formaty dostarczają te same trójki faktów. Ale z perspektywy extractability score – czyli tego, jak łatwo system AI wyciągnie dane z Twojej strony – JSON-LD wygrywa bezapelacyjnie. Dlatego Google od lat rekomenduje ten format jako jedyny do nowych wdrożeń, a Microsoft Bing wprost stwierdził na konferencji SMX Munich 2025, że schema markup pomaga LLM-om zrozumieć treść strony.

Jakie konkretne zmiany powinny wprowadzić polskie sklepy na kartach produktów?

Na podstawie analizy 8 patentów i audytu 3 polskich sklepów przygotowaliśmy listę priorytetowych zmian, uszeregowaną według wpływu na widoczność w Google:

Priorytet P0 (krytyczne): Wdrożenie pełnego JSON-LD Product z polami name, description, brand, sku, gtin, image, offers (price, priceCurrency, availability, itemCondition). Dodanie availability do Offer – bez tego Google nie wie, czy produkt jest w ogóle do kupienia. Implementacja specyfikacji technicznej w formacie HTML TABLE lub DL/DT/DD zamiast tekstu ciągłego – algorytm EAV (US9110852B1) wyciągnie z tabeli 10x więcej trójek faktów niż z akapitu.

Priorytet P1 (wysoki wpływ): Dodanie merchant-listing” target=”_blank” rel=”noopener”>OfferShippingDetails i MerchantReturnPolicy do schema – Google wspiera te typy od 2023 roku, a swiecoholik.pl ma już solidną bazę JSON-LD, domkove.pl zaś pełną Microdata z recenzjami. Napisanie unikalnych opisów produktów (minimum 150-200 słów), które zawierają frazy typowe dla danej kategorii produktowej (phrase-based indexing US6823333B1). Dodanie sekcji FAQ z odpowiedziami na najczęstsze pytania kupujących – redukuje pogo-sticking i zwiększa Fact Density.

Priorytet P2 (budowanie przewagi): Wdrożenie ProductGroup + hasVariant dla wariantów kolorystycznych i pojemnościowych (Google dodał wsparcie w lutym 2024). Dodanie własnych testów, zdjęć i pomiarów jako information gain (US20140280011A1). Implementacja schema Review/AggregateRating z realnymi opiniami klientów. Spójność ceny, nazwy i dostępności między HTML, JSON-LD i Google Merchant Center (fact corroboration US9785686B2). O tym, jak dane z feedu produktowego wpływają na widoczność, pisaliśmy w artykule Product feed a AI visibility.

Jak Semgence wykorzystuje patenty Google do audytów e-commerce?

Semgence opracowało metodologię audytu kart produktowych opartą na analizie patentów Google. Agencja Semgence, założona w 2018 roku przez Pawła Gontarka z ponad 20-letnim doświadczeniem w SEO, wykorzystuje autorskie narzędzia MCP (Model Context Protocol), które automatycznie analizują Entity-Attribute-Value extraction, Fact Density, schema coverage i spójność danych na kartach produktów. Semgence przeprowadziło audyty Product Schema dla sklepów z branży elektronicznej, modowej i FMCG – w każdym przypadku identyfikując braki w implementacji danych strukturalnych, które bezpośrednio przekładały się na utratę widoczności w Google Shopping i rich snippets.

Narzędzia Topical Intelligence i AI Monitor, rozwijane przez Semgence, pozwalają na bieżąco monitorować, jak zmiany na kartach produktów wpływają na widoczność w wynikach organicznych, AI Overviews i Google AI Mode. Audyt patentowy karty produktu to element szerszej usługi audytu SEO i pozycjonowania sklepów internetowych, którą Semgence realizuje dla klientów e-commerce na rynku polskim.

Najczęściej zadawane pytania

Pelna analiza 10 warstw SEO e-commerce – od feedu przez duplikacje, visual search i merchant trust az po AI Search – jest w artykule spinajacym cykl 74 patentow Google. Osobno sprawdzamy, czym poprzeć twierdzenia z karty produktu, żeby były weryfikowalne: dowody twierdzeń produktowych dla AI i prawa UE.