Feed produktowy, karta produktu i dane strukturalne – gdzie Google szuka prawdy o produkcie?

Sklep internetowy komunikuje dane o produkcie w co najmniej trzech warstwach: feed produktowy (Google Merchant Center), karta produktu (HTML strony) i dane strukturalne (Product schema w JSON-LD). Google nie musi polegać na żadnej z nich pojedynczo. Patenty Google opisują mechanizmy, które pozwalają porównywać te warstwy, wyciągać dane bezpośrednio z HTML karty produktu, tworzyć „sygnaturę merchanta” na podstawie wzorców w feedzie i automatycznie klasyfikować produkty na bazie metadanych tekstowych. Gdy feed mówi jedno, schema drugie, a strona trzecie – produkt może zostać błędnie sklasyfikowany, odrzucony lub pominięty w wynikach zakupowych.

W tym artykule analizuję cztery rodziny patentów, które pokazują, jak Google może traktować dane produktowe jako system wzajemnie weryfikujących się źródeł. To pierwszy tekst z cyklu „SEO e-commerce w świetle patentów Google.”

Dlaczego produkt w Google to nie jedna strona, tylko zestaw danych?

Tradycyjne podejście do SEO e-commerce traktuje kartę produktu jako stronę do optymalizacji (pisaliśmy o tym szerzej w artykule co algorytmy Google sprawdzają na karcie produktu) – tytuł, opis, nagłówki, frazy kluczowe. Tymczasem z perspektywy wyszukiwarki produkt to byt danych, który może istnieć jednocześnie w wielu źródłach:

• feed produktowy przesyłany do Google Merchant Center,
• karta produktu (strona HTML dostępna pod URL-em),
• dane strukturalne osadzone w kodzie strony (JSON-LD Product schema),
• wyniki ekstrakcji – dane, które Google sam wyciąga z HTML,
• dane od użytkowników – opinie, oceny, zdjęcia,
• dane zewnętrzne – porównywarki, marketplace’y, katalogi producentów.

Żadne z tych źródeł nie jest jedyną „prawdą” o produkcie. Patenty Google opisują systemy, które mogą te źródła porównywać, weryfikować i na ich podstawie podejmować decyzje o widoczności produktu w wynikach.

To nie jest hipoteza. Dokumentacja Google Merchant Center wprost mówi, że system porównuje dane z feedu z danymi na stronie docelowej. Według oficjalnej specyfikacji Google z kwietnia 2026, niespójność ceny lub dostępności między feedem a stroną może prowadzić do odrzucenia produktu.

Patenty, które analizuję poniżej, pokazują, jak te mechanizmy mogą działać na poziomie technicznym.

Patent nie jest dowodem, że dany mechanizm działa dokładnie tak w bieżącym algorytmie Google. Patent jest modelem analitycznym – pokazuje problem, który inżynierowie próbowali rozwiązać, i pozwala zbudować praktyczną checklistę dla sklepu internetowego. To zastrzeżenie powtórzę w każdym artykule tego cyklu.

Czym jest merchant signature i dlaczego feed produktowy to nie tylko lista ofert?

Patent US8396935B1 – Discovering spam merchants using product feed similarity

• Numer patentu: US8396935B1
• Tytuł: Discovering spam merchants using product feed similarity
• Assignee: Google LLC
• Wynalazcy: Mircea Gabriel Ciurumelea, Stefan Christoph
• Data zgłoszenia: 10 kwietnia 2012
• Data publikacji: 12 marca 2013
• Rodzina patentowa: CA2869888C (Kanada), EP2686821A4 (Europa), KR101565957B1 (Korea), JP5728628B1 (Japonia), WO2013155022A1 (PCT)
• Status: Expired – Fee Related
• Pełny tekst: patents.google.com/patent/US8396935

Jaki problem rozwiązuje ten patent?

Patent opisuje system wykrywania spamowych sprzedawców (spam merchants) w serwisach porównywania produktów. Problem jest konkretny: po zidentyfikowaniu i usunięciu spamowego merchanta, ten sam sprzedawca otwiera nowe konto, zmienia adres strony, modyfikuje wygląd witryny lub wprowadza drobne zmiany w feedzie – i wraca do systemu.

Rozwiązanie polega na obliczaniu tzw. merchant signature – unikalnego odcisku palca sprzedawcy na podstawie wzorców w jego feedzie produktowym.

Jak działa mechanizm merchant signature?

Zgodnie z opisem patentu (sekcja Detailed Description), system przetwarza feed w następujących krokach:

1. Odbiór feedu – merchant przesyła plik z ofertami (XML lub inny format) do systemu porównywania produktów. Plik zawiera dane ofertowe dla jednego lub wielu produktów.

2. Walidacja pól – system sprawdza, czy feed zawiera wymagane pola danych. Jeśli brakuje obowiązkowych pól (np. tytułu produktu), plik jest odrzucany. Patent wymienia przykładowe pola: tytuł produktu (product title), opis produktu (product description), cena (price), zdjęcie (photo).

3. Parsowanie na oferty składowe – jeśli plik przechodzi walidację, system dzieli go na pojedyncze oferty (component offers). Każda oferta dotyczy jednego produktu.

4. Ekstrakcja cechy wspólnej – system wybiera predefiniowaną cechę wspólną dla wszystkich ofert (specific feature common to all offers). Może to być tytuł, opis, cena lub zdjęcie.

5. Przypisanie wartości numerycznych – każdej wyekstrahowanej cesze przypisywana jest wartość numeryczna (data value). Patent precyzuje, że do generowania wartości numerycznej może być używana funkcja haszująca (hash function).

6. Generowanie ciągu wartości – wartości numeryczne są łączone w ciąg (string of assigned data values).

7. Obliczanie sygnatury – na ciągu wartości wykonywany jest algorytm haszujący, którego wynikiem jest merchant signature.

8. Porównanie z bazą – sygnatura jest porównywana z sygnaturami znanych spamowych merchantów. Jeśli nowa sygnatura mieści się w predefiniowanym progu podobieństwa (predefined threshold), merchant jest odrzucany.

Sygnatura może być wielowymiarowa

Patent opisuje wariant, w którym system przypisuje wartości do dwóch lub więcej cech (two or more specific features) i generuje osobne ciągi wartości dla każdej cechy. To pozwala na tworzenie wielowymiarowej sygnatury – np. osobnej dla tytułów, osobnej dla cen, osobnej dla opisów.

Oznacza to, że zmiana jednej warstwy feedu (np. przepisanie tytułów) nie musi wystarczyć do uniknięcia wykrycia, jeśli pozostałe wzorce (ceny, opisy, struktury) pozostają te same.

Jakie wnioski można wyciągnąć dla SEO e-commerce?

Patent nie mówi wprost o rankingu organicznym – dotyczy wykrywania spamu w serwisie porównywania produktów (takim jak Google Shopping). Ale mechanizm merchant signature ujawnia ważną zasadę: Google może analizować feed nie tylko na poziomie pojedynczego produktu, ale jako całościowy wzorzec danych sprzedawcy.

• Feed, który wygląda jak masowo wygenerowana kopia (identyczne struktury tytułów, szablonowe opisy, powtarzające się wzorce cen), może wyglądać podejrzanie na poziomie sygnatury.
• Zmiana adresu domeny lub wyglądu strony nie zmienia sygnatury feedu – wzorce danych pozostają te same.
• Unikalne, rzetelne opisy produktów w feedzie nie są tylko „dobrą praktyką” – mogą wpływać na to, jak sygnatura merchanta jest postrzegana przez system.

Czy Google może wyciągać dane produktowe bezpośrednio z HTML karty produktu?

Patent US8438080B1 – Learning characteristics for extraction of information from web pages

• Numer patentu: US8438080B1 (kontynuacja: US9443250B1)
• Tytuł: Learning characteristics for extraction of information from web pages
• Assignee: Google LLC
• Wynalazcy: Fei Xiao, Cristos Goodrow
• Data zgłoszenia: 28 maja 2010
• Data publikacji: 7 maja 2013
• Status: Active (wygasa 17 stycznia 2031)
• Pełny tekst: patents.google.com/patent/US8438080

Jaki problem rozwiązuje ten patent?

Patent adresuje fundamentalny problem: feedy produktowe są często nieaktualne, niekompletne lub niedokładne. Opis patentu wymienia konkretne scenariusze:

• Aktualizacje feedu są zbyt rzadkie, żeby odzwierciedlać zmiany cen w czasie rzeczywistym.
• Produkty niedostępne mogą być błędnie raportowane jako dostępne (i odwrotnie).
• Feedy mogą być generowane ręcznie przez pracowników merchantów, co prowadzi do nieumyślnych (lub celowych) nieścisłości.
• Merchanty często dostarczają dane tylko dla części swoich produktów.

Rozwiązaniem jest system uczący się, który automatycznie uczy się rozpoznawać, gdzie na stronie HTML merchanta znajdują się dane produktowe (cena, dostępność, tytuł, wariant), i potrafi je wyekstrahować bezpośrednio – bez polegania na feedzie (mechanizm, który opisywaliśmy też w kontekście extractability score karty produktowej).

Jak działa mechanizm ekstrakcji?

System składa się z trzech modułów:

Learning module (moduł uczący) – uczy się charakterystyk identyfikujących zmienne produktowe (product variables) na stronach merchantów. Feed pełni rolę „ground truth” – prawdy bazowej. System wykorzystuje wartości z feedu jako punkt odniesienia, żeby zidentyfikować, gdzie na stronie HTML znajdują się odpowiadające im dane.

Extraction module (moduł ekstrakcji) – stosuje wyuczone charakterystyki do wyciągania wartości zmiennych produktowych z dowolnych stron danego merchanta.

Search module (moduł wyszukiwania) – wykorzystuje wyekstrahowane dane w wynikach wyszukiwania.

Proces uczenia krok po kroku

Proces (opisany w FIG. 5 i 6 patentu):

System otrzymuje feed produktowy z wartością zmiennej produktowej (np. ceną „199,99 zł”), pobiera stronę HTML produktu od tego samego merchanta i tworzy model strony w postaci drzewa DOM (Document Object Model) – zbioru węzłów (nodes) reprezentujących fragmenty danych na stronie.

Następnie identyfikuje węzły kandydujące (candidate nodes) – te, które zawierają wartość zgodną z wartością z feedu. Z węzłów kandydujących wyciąga charakterystyki – właściwości tekstu, typu tagu HTML, atrybutów tagu. System oblicza wagi (weights) dla różnych wartości właściwości, agregując wyniki ze wszystkich przeanalizowanych stron danego merchanta. Na podstawie wag identyfikuje najlepszego kandydata.

Patent wymienia wprost trzy kluczowe zmienne produktowe: product title (tytuł produktu), product price (cena produktu) i product availability (dostępność produktu). Ale mechanizm nie jest ograniczony do tych trzech – może służyć do ekstrakcji dowolnych zmiennych produktowych.

Kluczowy wniosek z Claim 1

Claim 1 US8438080B1 definiuje metodę uczenia się charakterystyk zmiennych produktowych „within web pages of a merchant.” Ważne sformułowanie: system „extracting a value for the product variable from a new web page of the merchant, at least in part using the learned product variable characteristics.”

To oznacza, że po nauczeniu się wzorców na kilku stronach, system może automatycznie wyciągać dane z nowych stron tego samego merchanta – nawet jeśli te strony nie mają odpowiadającego im wpisu w feedzie.

Co to oznacza dla sklepów?

• Google nie musi polegać wyłącznie na feedzie. Może porównywać dane z feedu z danymi wyekstrahowanymi bezpośrednio z HTML. Jeśli cena w feedzie to 199 zł, a na stronie 249 zł – system to widzi.
• Spójność danych staje się mierzalna. Patent opisuje mechanizm, który może automatycznie weryfikować, czy feed mówi to samo co strona.
• Struktura HTML ma znaczenie. System uczy się na podstawie drzewa DOM – pozycji elementów w strukturze strony, typów tagów, atrybutów. W praktyce to Googlebot pobiera i renderuje stronę, tworząc drzewo DOM, z którego system wyciąga dane. Jeśli cena jest ukryta w niestandardowym elemencie, renderowana dynamicznie przez JavaScript lub zablokowana dla crawlera – ekstrakcja może być trudniejsza lub niemożliwa.
• Dane strukturalne (schema) mogą ułatwiać ten proces. Choć patent nie mówi wprost o schema.org, dane strukturalne Product w JSON-LD to jawna deklaracja zmiennych produktowych w formacie ustandaryzowanym przez schema.org – otwarty standard wspierany przez Google, Microsoft, Yahoo i Yandex.

Czy Google może automatycznie klasyfikować produkty na podstawie tekstu w feedzie?

Patent US20140172652A1 / US10528907B2 – Automated categorization of products in a merchant catalog

• Numer patentu: US10528907B2 (granted), US20140172652A1 (application)
• Tytuł: Automated categorization of products in a merchant catalog
• Assignee: Yahoo AD Tech LLC (dawniej Oath Inc, dawniej Yahoo! Inc.)
• Wynalazcy: Nageswara R. Pobbathi, Anlei Dong, Yi Chang
• Data zgłoszenia: 19 grudnia 2012
• Uwaga: Ten patent został zgłoszony przez Yahoo!, nie przez Google. Analizuję go jako przykład podejścia do automatycznej kategoryzacji produktów, które jest istotne niezależnie od właściciela patentu.

Patent opisuje system automatycznej kategoryzacji produktów na dużą skalę. System otrzymuje informacje o produktach (w tym tekstowe pola metadanych), otrzymuje zestaw kategorii i automatycznie przypisuje każdy produkt do jednej lub więcej kategorii na podstawie pól metadanych.

Do automatycznego przypisywania kategorii może być użyty klasyfikator uczenia maszynowego (machine learning classifier), który operuje na wektorze cech (feature vector) wyprowadzonym z tekstowych pól opisu produktu i jest trenowany na zbiorze wstępnie skategoryzowanych opisów produktów.

Dlaczego ten patent ma znaczenie mimo że nie jest patentem Google?

Dokumentacja Google Merchant Center wprost mówi, że jeśli merchant nie poda kategorii (google_product_category), Google będzie próbował automatycznie skategoryzować produkt – ale wyniki mogą być niedokładne.

Patent Yahoo opisuje jeden z możliwych mechanizmów takiej automatycznej kategoryzacji. Wniosek jest jasny niezależnie od właściciela patentu: jeśli tytuł, opis i atrybuty produktu w feedzie są nieprecyzyjne, system automatycznej klasyfikacji może przypisać produkt do złej kategorii.

• Tytuł produktu w feedzie powinien jednoznacznie wskazywać kategorię. „Buty Nike Air Max 90 czarne” jest lepsze niż „Super obuwie sportowe.”
• Opis produktu powinien zawierać atrybuty klasyfikacyjne: typ produktu, materiał, przeznaczenie, sezon, płeć, rozmiarówka.
• Niezgodność kategorii w feedzie z kategorią na stronie może prowadzić do konfliktu sygnałów.
• Ręczne ustawienie google_product_category jest znacznie bezpieczniejsze niż poleganie na autoklasyfikacji.

Jak dane strukturalne mogą pomagać w deduplikacji wyników zakupowych?

Patent US9342849B2 / US9607331B2 – Near-duplicate filtering in search engine result page of an online shopping system

• Numer patentu: US9342849B2 (granted), US9607331B2 (kontynuacja)
• Tytuł: Near-duplicate filtering in search engine result page of an online shopping system
• Assignee: Google LLC
• Wynalazcy: Liang Hu, Lijie Chen, Hao Zhang
• Data priorytetowa: 1 sierpnia 2013 (z PCT/CN2013/080631)
• Pełny tekst: patents.google.com/patent/US9342849

Temat duplikacji treści omawialiśmy w osobnym poradniku – tutaj skupiamy się na deduplikacji produktowej. Patent dotyczy filtrowania near-duplicate entries w wynikach wyszukiwania zakupowego (online shopping SERP) – czyli w interfejsie Google Shopping i na karcie Shopping w wynikach Google. Problem: w wynikach zakupowych mogą pojawiać się wpisy, które nie są identyczne tekstowo, ale są prawie identyczne jako oferty produktowe.

System działa następująco: każdy wpis produktowy jest opisany zestawem atrybutów (set of attributes). Dla każdej pary wpisów obliczana jest odległość (distance) – miara podobieństwa. Wpisy zbyt bliskie (poniżej progu odległości) są grupowane w klastry (clusters). Z każdego klastra wybierany jest reprezentant – najlepsza oferta, która trafia do wyników.

Problem e-commerce z wariantami URL

W typowym sklepie internetowym ten sam zestaw produktów może być dostępny pod wieloma adresami (ten problem opisujemy szczegółowo w artykule o faceted navigation i crawl budget): /kategoria/aparaty?sort=price-asc, /kategoria/aparaty?sort=popular, /kategoria/aparaty?view=list, /kategoria/aparaty?color=czarny. Jeśli te adresy nie są kontrolowane (przez canonical, noindex lub robots.txt), wyszukiwarka widzi wiele „stron” pokazujących prawie te same produkty. Patent opisuje mechanizm, który może te strony zidentyfikować jako near-duplicates i wybrać jedną.

Rola danych strukturalnych w deduplikacji

Dane strukturalne Product schema zawierają identyfikator produktu (sku, gtin, mpn), cenę (offers.price), dostępność (offers.availability), markę (brand.name) i wariant (kolor, rozmiar). Te pola pozwalają systemowi porównać dwie strony i stwierdzić, że pokazują ten sam produkt – nawet jeśli ich treść HTML różni się.

• Dane strukturalne Product schema nie służą wyłącznie do rich results (więcej o roli schema w widoczności AI pisaliśmy w artykule schema markup a widoczność w AI). Mogą pełnić funkcję w deduplikacji wyników zakupowych.
• Identyfikatory produktów (GTIN, MPN, SKU) mogą być kluczowe dla poprawnej deduplikacji. Produkt bez GTIN-u jest trudniejszy do jednoznacznego zidentyfikowania.
• Warianty produktu z identycznym zestawem atrybutów w schema mogą zostać potraktowane jako near-duplicates.
• Canonical URL powinien być spójny z danymi strukturalnymi – jeśli canonical wskazuje na /produkt-x/, to schema na wszystkich wariantach URL powinna zawierać url: /produkt-x/.

Co się dzieje, gdy feed, schema i karta produktu mówią coś innego?

Połączenie wszystkich czterech opisanych mechanizmów tworzy system, w którym produkt jest weryfikowany z wielu stron jednocześnie.

Warstwa danych	Co zawiera	Jak Google może ją czytać
Feed produktowy (Merchant Center)	Tytuł, cena, dostępność, GTIN, kategoria, zdjęcie	Bezpośredni odczyt + merchant signature (US8396935B1)
Karta produktu (HTML)	Treść strony, cena w DOM, zdjęcia, opis	Ekstrakcja z DOM (US8438080B1)
Dane strukturalne (JSON-LD)	Product schema: name, price, availability, brand, sku	Bezpośredni odczyt ustandaryzowanego formatu
Dane z wyników / index	Tytuł w SERP, snippet, cena w rich result	Synteza wielu źródeł

Scenariusze niespójności

Scenariusz 1: Cena w feedzie inna niż na stronie. Feed mówi: 199 zł. Karta produktu pokazuje: 249 zł (bo promocja się skończyła i cena wróciła do pełnej kwoty, ale feed wciąż ma starą cenę promocyjną). Schema mówi: 249 zł (bo generuje się dynamicznie z aktualnej ceny). Wynik: Google Merchant Center może odrzucić produkt z powodu price mismatch. System ekstrakcji (US8438080B1) widzi cenę 249 zł na stronie, a feed mówi 199 zł. Rozbieżność jest wykrywalna.

Scenariusz 2: Dostępność w feedzie „in stock”, na stronie „brak”. Feed mówi: InStock. Karta produktu wyświetla: „Produkt niedostępny”. Schema mówi: OutOfStock (bo generuje się z systemu magazynowego). Wynik: System ekstrakcji może wyciągnąć ze strony informację o niedostępności. Rozbieżność między feedem a stroną/schema jest jednym z najczęstszych powodów odrzucenia w Merchant Center.

Scenariusz 3: Nazwa produktu inna w feedzie i na stronie. Feed mówi: „Buty sportowe Nike Air Max 90 białe 42”. Karta produktu H1: „Nike Air Max 90”. Schema name: „Air Max 90 White”. Trzy różne nazwy tego samego produktu. System kategoryzacji może przypisać różne wektory cech do każdej nazwy.

Scenariusz 4: GTIN w feedzie, brak GTIN w schema. Feed zawiera GTIN. Schema Product nie zawiera pola gtin. Karta produktu nie wyświetla GTIN-u. Feed jest jedynym źródłem identyfikatora produktu. Deduplikacja musi polegać wyłącznie na danych z feedu.

Jak Google Merchant Center weryfikuje spójność danych w praktyce?

Oficjalna dokumentacja Google Merchant Center (aktualizacja z 14 kwietnia 2026) wymienia konkretne wymagania dotyczące spójności:

• Cena musi zgadzać się między feedem a stroną docelową (landing page). Rozbieżność prowadzi do odrzucenia produktu.
• Dostępność musi być spójna. Produkt oznaczony jako „in stock” w feedzie musi być dostępny do zakupu na stronie.
• Tytuł powinien być opisowy i zawierać kluczowe atrybuty (markę, model, kolor, rozmiar).
• GTIN (Global Trade Item Number) jest wymagany dla większości markowych produktów.
• Kategoria (google_product_category) powinna być ustawiona ręcznie. Automatyczna kategoryzacja jest podatna na błędy.

Aktualizacja specyfikacji z kwietnia 2026 wprowadziła dodatkowe wymagania: nowe atrybuty dostawy na poziomie produktu, opcjonalny atrybut video_link (walidacja jakości od 30 czerwca 2026) oraz podwyższenie minimalnej rozdzielczości zdjęć do 500×500 pikseli (egzekwowane od 31 stycznia 2027).

Dokumentacja Google Search Central dotycząca Product schema potwierdza: „Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data.”

Dane z badania: jak polskie sklepy internetowe radzą sobie ze spójnością danych produktowych?

W ramach badania „AI Readiness w polskim e-commerce 2026” przeanalizowaliśmy 85 polskich sklepów internetowych z 10 nisz (kosmetyki naturalne, kawa/herbata specialty, świece zapachowe, zoologiczne, ceramika/dekoracje, biżuteria, suplementy, zabawki drewniane, ogród/rośliny, odzież dziecięca). Crawl objął 88 stron głównych i 187 kart produktów/kategorii z ekstrakcją obu formatów danych strukturalnych – JSON-LD (rekomendowany przez Google, osadzany w tagu script) i Microdata (starszy format wbudowany bezpośrednio w atrybuty HTML) – oraz ręczną weryfikacją kodu źródłowego.

Wyniki (opublikowane w artykule Dane strukturalne w polskim e-commerce) potwierdzają, że problem spójności danych produktowych nie jest teoretyczny:

Product schema – stan wdrożenia

• Tylko 20 z 85 sklepów (24%) miało Product schema na kartach produktów.
• 76% przebadanych sklepów (65 z 85) nie miało żadnego Product schema – ani JSON-LD, ani Microdata.
• Najlepsza implementacja: sklep z branży kosmetycznej z 13 polami w Product JSON-LD (name, brand, sku, gtin, price, availability, image, description, aggregateRating, review, offers, url, category).
• Cała nisza zoologiczna: 0% Product JSON-LD. Żaden z przebadanych sklepów z karmą i akcesoriami dla zwierząt nie wdrożył danych strukturalnych Product w formacie JSON-LD.

Brakujące pola w schema – nawet u liderów

Nawet wśród sklepów, które miały Product schema, kluczowe pola były pomijane:

• Żaden sklep w próbie nie miał w schema pól: material, weight, color – czyli atrybutów, które mogą wspierać klasyfikację produktu i odpowiadanie na zapytania atrybutowe („buty skórzane białe”, „plecak lekki 500g”).
• GTIN był obecny w schema u mniej niż 30% sklepów, które w ogóle miały Product schema. Pozostałe polegały wyłącznie na feedzie jako źródle identyfikatora produktu.
• availability (dostępność) – wiele sklepów miało to pole w feedzie Merchant Center, ale nie w schema na stronie. To klasyczny scenariusz niespójności opisany wcześniej w tym artykule.

Co to oznacza w kontekście patentów?

Jeśli 76% sklepów nie ma Product schema, to system ekstrakcji opisany w patencie US8438080B1 musi polegać wyłącznie na uczeniu się wzorców z HTML strony – bez dodatkowego „ground truth” ze strony danych strukturalnych. To sprawia, że ekstrakcja ceny, dostępności i nazwy produktu jest mniej pewna.

Sklepy z pełnym Product schema (JSON-LD z ceną, dostępnością, GTIN-em i marką) dostarczają Google trzy spójne źródła danych: feed + schema + HTML. Sklepy bez schema dostarczają co najwyżej dwa: feed + HTML. A jeśli feed jest nieaktualny – jedno.

W kontekście patentu US9342849B2 (deduplikacja): sklepy bez GTIN-u w schema tracą najsilniejszy identyfikator do jednoznacznego rozpoznania produktu. System musi polegać na porównaniu tytułów i opisów – które, jak pokazuje scenariusz 3, mogą się różnić między feedem a stroną.

W kontekście merchant signature (US8396935B1): sklepy z jednej niszy, które korzystają z tego samego dostawcy feedów lub tej samej platformy e-commerce z domyślnymi ustawieniami, mogą generować bardzo podobne sygnatury – szablonowe tytuły, identyczne struktury opisów, powtarzalne wzorce cenowe. To nie oznacza, że zostaną potraktowane jako spam, ale oznacza, że ich feedy nie wyróżniają się na tle konkurencji.

Jak audytować spójność danych produktowych w sklepie?

Spójność feed-strona-schema

• Czy nazwa produktu w feedzie jest taka sama jak H1 na karcie produktu i name w schema Product?
• Czy cena w feedzie zgadza się z ceną widoczną na stronie i offers.price w schema?
• Czy dostępność w feedzie (availability) zgadza się z informacją na stronie i offers.availability w schema?
• Czy marka (brand) jest podana w feedzie, w schema i widoczna na karcie produktu?
• Czy GTIN / MPN jest uzupełniony w feedzie i obecny w schema?
• Czy kategoria w feedzie (google_product_category) odpowiada kategorii na stronie (breadcrumbs)?

Jakość feedu jako całości

• Czy opisy produktów w feedzie nie są szablonowe (masowo wygenerowane z jednego wzorca)?
• Czy tytuły produktów w feedzie zawierają markę, model, kluczowe atrybuty?
• Czy feed nie zawiera sztucznych wariantów (tworzonych tylko po to, żeby mnożyć oferty)?
• Czy feed jest aktualizowany z częstotliwością odpowiadającą zmianom cen i dostępności?

Struktura HTML karty produktu

• Czy cena jest widoczna w czytelnym elemencie DOM (nie ukryta w zagnieżdżonym JavaScript)?
• Czy dostępność jest komunikowana jasno (nie tylko kolorem przycisku, ale tekstem)?
• Czy dane techniczne / atrybuty produktu są dostępne w strukturze HTML (tabela, lista dt/dd)?
• Czy karta produktu zawiera JSON-LD Product schema z pełnym zestawem wymaganych pól?

Identyfikatory produktów

• Czy każdy produkt markowy ma GTIN (EAN/UPC)?
• Czy produkty bez GTIN mają MPN + brand?
• Czy identyfikatory są spójne między feedem, schema i stroną?
• Czy warianty produktu mają osobne identyfikatory lub item_group_id?

Jak Product schema może wspierać ekstrakcję i deduplikację?

Dane strukturalne Product w JSON-LD to jawna deklaracja zmiennych produktowych. W kontekście analizowanych patentów schema pełni kilka funkcji:

• Ułatwia ekstrakcję (w kontekście US8438080B1) – zamiast uczyć się, gdzie na stronie jest cena, system może ją odczytać bezpośrednio z JSON-LD.
• Wspiera deduplikację (w kontekście US9342849B2) – identyfikatory w schema (gtin, sku, mpn) pozwalają jednoznacznie zidentyfikować produkt na różnych stronach.
• Umożliwia weryfikację – wartości w schema można porównać z wartościami w feedzie i na stronie HTML. Trzy źródła mówiące to samo to silny sygnał spójności.
• Może wspierać kategoryzację – pola takie jak brand, category, productID dostarczają dodatkowych cech do klasyfikacji produktu.

Na podstawie analizy patentów i dokumentacji Google, minimalny zestaw Product schema, który wspiera ekstrakcję, weryfikację i deduplikację:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Air Max 90 białe męskie",
  "brand": {
    "@type": "Brand",
    "name": "Nike"
  },
  "sku": "NIKE-AM90-WHT-42",
  "gtin13": "0123456789012",
  "description": "Buty sportowe Nike Air Max 90...",
  "image": "https://sklep.pl/img/nike-air-max-90-white.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://sklep.pl/nike-air-max-90-white/",
    "priceCurrency": "PLN",
    "price": "549.00",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@type": "Organization",
      "name": "Nazwa Sklepu"
    }
  }
}

Każde pole w tej schema powinno odpowiadać dokładnie temu, co jest w feedzie Merchant Center (te same wartości), jest widoczne na stronie (ta sama cena, ta sama dostępność) i jest w tytule/H1 produktu (ta sama nazwa).

Wnioski dla SEO e-commerce

Analizowane patenty – niezależnie od tego, czy są wdrożone dokładnie tak jak opisane – ujawniają spójny model myślenia o danych produktowych:

1. Produkt nie jest stroną. Produkt jest bytem danych. Google może widzieć produkt przez wiele warstw: feed, HTML, schema, a nawet dane od użytkowników. Spójność tych warstw nie jest opcjonalna.

2. Feed produktowy to nie tylko narzędzie do Google Shopping. Feed tworzy „sygnaturę” merchanta. Masowo generowane, szablonowe feedy mogą wyglądać podobnie do wzorców spamowych.

3. Google nie musi polegać na feedzie. Może wyciągać dane bezpośrednio z HTML karty produktu i porównywać je z feedem. Niespójności są wykrywalne.

4. Dane strukturalne Product schema to dodatkowa warstwa weryfikacji. Schema nie jest „nice to have” – to jawna deklaracja danych produktowych w ustandaryzowanym formacie, który ułatwia ekstrakcję, weryfikację i deduplikację.

5. Precyzyjne metadane tekstowe wpływają na klasyfikację. Jeśli tytuł, opis i atrybuty nie komunikują jednoznacznie, czym jest produkt, system automatycznej kategoryzacji może go przypisać do złej kategorii.

Ten artykul jest czescia cyklu „SEO e-commerce w swietle patentow Google.” Pelna mape 74 patentow, dane z audytow 6 sklepow i checklisty do pobrania znajdziesz w kompletnej mapie 10 warstw SEO e-commerce.

To jest pierwszy artykuł z cyklu „SEO e-commerce w świetle patentów Google.” Jeśli szukasz wsparcia w pozycjonowaniu sklepu internetowego lub potrzebujesz audytu SEO uwzględniającego dane produktowe i patenty Google – skontaktuj się z nami. W następnym tekście pokażę, jak Google może traktować dane strukturalne Product schema nie tylko jako minimum techniczne, ale jako pełną warstwę semantyczną produktu.

Źródła

Patenty

1. US8396935B1 – „Discovering spam merchants using product feed similarity.” Google LLC. Wynalazcy: Mircea Gabriel Ciurumelea, Stefan Christoph. 2013. patents.google.com/patent/US8396935

2. CA2869888C – Kanadyjski odpowiednik US8396935B1. Google LLC. patents.google.com/patent/CA2869888C

3. US8438080B1 – „Learning characteristics for extraction of information from web pages.” Google LLC. Wynalazcy: Fei Xiao, Cristos Goodrow. 2013. patents.google.com/patent/US8438080

4. US9443250B1 – Kontynuacja US8438080B1. Google LLC. patents.google.com/patent/US9443250

5. US10528907B2 / US20140172652A1 – „Automated categorization of products in a merchant catalog.” Yahoo AD Tech LLC. Wynalazcy: Nageswara R. Pobbathi, Anlei Dong, Yi Chang. 2020. patents.google.com/patent/US10528907

6. US9342849B2 – „Near-duplicate filtering in search engine result page of an online shopping system.” Google LLC. Wynalazcy: Liang Hu, Lijie Chen, Hao Zhang. patents.google.com/patent/US9342849

7. US9607331B2 – Kontynuacja US9342849B2. Google LLC. patents.google.com/patent/US9607331

Dokumentacja Google

8. Google Merchant Center – Product data specification. Aktualizacja 14 kwietnia 2026. support.google.com/merchants/answer/7052112

9. Google Merchant Center – Product data specification update 2026. support.google.com/merchants/answer/16989427

10. Google Search Central – Intro to Product Structured Data. developers.google.com/search/docs/appearance/structured-data/product

11. Google Search Central – Product Variant Structured Data. Aktualizacja 20 maja 2026. developers.google.com/search/docs/appearance/structured-data/product-variants

Analizy zewnętrzne

12. ALM Corp – „Google Merchant Center Product Data Specification Update 2026.” 17 kwietnia 2026. almcorp.com

13. WebAppick – „Google Product Feed Specification Requirements (2026).” 15 maja 2026. webappick.com

14. eFulfillment Service – „The Complete Product Data Optimization Guide for Google’s AI Shopping (2026).” 27 marca 2026. efulfillmentservice.com