DOM kontra Product schema: dlaczego sklep przekazuje maszynom dwie wersje produktu?

Sklep internetowy przekazuje informacje o produkcie na dwa sposoby: widoczna treść w DOM (to co widzi użytkownik) i dane strukturalne w JSON-LD (to co czyta maszyna). W teorii obie warstwy powinny opisywać ten sam produkt tymi samymi wartościami. W praktyce rozjeżdżają się częściej, niż można by przypuszczać. Zbadaliśmy 20 polskich sklepów (po 1 PDP na sklep, snapshot lipiec 2026, bez warstwy feed) i zmierzyliśmy skalę rozbieżności: aligned (zgodne w obu warstwach) to zaledwie 7,3% atrybutów. Metodologia: matryca encja-atrybut → klasyfikacja do 4 klas zgodności (DOM+schema, DOM-only, schema-only, neither) → checklista naprawcza z priorytetami P0/P1. Oznacza to, że Product schema i widoczna treść to dwa osobne przekazy o tym samym produkcie.

Problem rozbieżności DOM vs schema ma bezpośrednie konsekwencje w Google Search. Dokumentacja Product Structured Data wyróżnia dwa typy znaczników: Product snippets (dla stron niesprzedażowych, akcentujące recenzje) i Merchant listings (dla stron zakupowych, z ceną, dostępnością i dostawą). Jeśli DOM pokazuje inną cenę niż JSON-LD, Google może zignorować oba sygnały lub – co gorsza – wybrać ten mniej korzystny.

Co właściwie porównujemy?

DOM (Document Object Model) to struktura HTML strony po wyrenderowaniu przez przeglądarkę. JSON-LD to blok danych strukturalnych osadzony w kodzie strony, niewidoczny dla użytkownika, przeznaczony dla wyszukiwarek i systemów AI. Patent US12222995B2 opisuje mechanizm przetwarzania struktury dokumentów, w którym system wyodrębnia atrybuty encji z różnych warstw strony i porównuje ich wartości.

Trzecim źródłem danych jest feed produktowy (Google Merchant Center, Facebook Catalog), ale w obecnym badaniu porównujemy wyłącznie DOM i JSON-LD na stronach PDP (Product Detail Page).

Jak zbudowaliśmy matrycę encja-atrybut?

Dla każdego sklepu wybraliśmy jedną stronę PDP i zbudowaliśmy matrycę (narzędzie: ecom_feed_page_schema_consistency_audit z GSCGA MCP). Wiersze to atrybuty produktu, kolumny to źródła danych. Patent US8538989B1 opisuje mechanizm przypisywania wag fragmentom dokumentu — w kontekście matrycy atrybutów pozwala to określić, które sekcje strony (np. nagłówek produktu vs stopka) wnoszą największą wartość informacyjną.

Kategoria	Atrybuty	Znaczenie
Critical	Nazwa, cena, dostępność, marka, SKU/GTIN	Bezpośredni wpływ na rich snippets i merchant listings
Decision	Wymiary, waga, kolor, materiał, warianty, gwarancja	Filtry, porównywarki, odpowiedzi AI na pytania porównawcze
Supporting	Opis marketingowy, instrukcja, opinie	Rzadko w JSON-LD, większość treści DOM

Wyniki badania: 20 sklepów, 4 klasy zgodności

Próba: 20 polskich sklepów (WooCommerce, PrestaShop, Shoper, Shopify), minimum 50 produktów każdy, działający Product schema. Okres: lipiec 2026. Narzędzie: ecom_feed_page_schema_consistency_audit, ecom_product_schema_audit z GSCGA MCP.

Metryka	Wynik	Interpretacja
DOM coverage	28,8%	Mniej niż 1/3 atrybutów widoczna dla użytkownika
Schema coverage	41,3%	Schema pokrywa więcej, ale bez potwierdzenia w DOM
Aligned (DOM + schema zgodne)	7,3%	Tylko co 14. atrybut jest spójny w obu warstwach
Completeness	51,4	Połowa możliwych atrybutów pokryta przez min. 1 źródło

Cztery klasy zgodności

Klasa	Udział	Opis	Ryzyko
DOM+schema	7,3%	Atrybut widoczny w DOM i obecny w JSON-LD z tą samą wartością	Brak – idealna sytuacja
DOM-only	21,5%	Widoczny na stronie, ale brak w schema	AI musi ekstrahować z tekstu, niższa precyzja
Schema-only	34,0%	W JSON-LD, ale niewidoczny na stronie	Deklaracja bez dowodu, niższe zaufanie — por. fact-check danych produktowych
Neither	37,2%	Nie istnieje w żadnej warstwie	AI nie może odpowiedzieć na pytanie o ten atrybut

Najważniejsza liczba to aligned 7,3%. Oznacza to, że tylko co czternasty atrybut produktowy jest jednocześnie widoczny w DOM, obecny w JSON-LD i ma zgodną wartość. Więcej o tym, jak Google przetwarza relacje encji w e-commerce.

Dlaczego schema-only nie jest rozwiązaniem?

Schema bez potwierdzenia w widocznej treści to deklaracja bez dowodu — w ramach E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) odpowiada to niskiemu sygnałowi Trustworthiness. Google od lat sygnalizuje, że dane strukturalne powinny odzwierciedlać treść widoczną na stronie. Patent CN108604250A (Google LLC) opisuje system identyfikacji kategorii treści na podstawie atrybutów encji — dla każdego atrybutu oblicza score trafności i wybiera podzbiór atrybutów do prezentacji, co jest analogiczne do selekcji pól w matrycy encja-atrybut.

Najczęstsze sprzeczności schema-only:

Atrybut	Wartość w schema	Wartość w DOM	Przyczyna rozbieżności
Cena	249 zł (z feedu sprzed aktualizacji)	279 zł (po podwyżce)	Różne źródła danych
Dostępność	InStock (nie aktualizowane real-time)	„Produkt niedostępny”	Brak synchronizacji
Rating	4.8 / 120 recenzji	Brak sekcji ocen na stronie	Rating tylko w schema
Brand	Podane jawnie	Tylko w breadcrumbie	Brak w sekcji produktu

Dlaczego DOM-only również jest problemem?

Atrybuty widoczne tylko w DOM wymagają ekstrakcji z nieustrukturyzowanego tekstu — ich extractability (zdolność systemu AI do wyodrębnienia wartości) jest znacząco niższa niż przy odczycie JSON-LD. Opis „Rama ze stali chromowo-molibdenowej, waga 1,8 kg, długość 52 cm” zawiera trzy atrybuty, ale żaden nie jest oznaczony jako jawny fakt. Patent US11609943B2 opisuje system dystrybucji treści kontekstowej, w którym atrybuty encji decydują o doborze i kolejności prezentowanych informacji — ale nawet zaawansowane systemy mają trudności z tekstem marketingowym (więcej o tym, jak ważyć sekcje DOM w e-commerce) („najlżejszy rower w swojej klasie” nie zawiera wartości wagi).

O tym, jak pisać opisy produktów, które AI potrafi przetworzyć, piszemy w artykule o opisach produktów pod Google, AI Search i użytkownika.

Jak audytować cenę, dostępność i warianty?

Trzy atrybuty wymagają szczególnej uwagi, bo zmieniają się w czasie i generują największą liczbę sprzeczności. Audyt tych atrybutów opisujemy też w kontekście monitoringu cen w e-commerce:

Cena. Porównaj wartość price w JSON-LD z ceną widoczną na stronie. Sprawdź: czy schema zawiera cenę regularną czy promocyjną? Czy waluta jest jawnie podana? Czy cena uwzględnia VAT? Najczęstsza sprzeczność: schema zawiera cenę netto (z feedu B2B), a DOM pokazuje cenę brutto.

Dostępność. Sprawdź, czy wartość availability w schema (InStock, OutOfStock, PreOrder) odpowiada stanowi widocznemu na stronie. O problemie niedostępnych produktów piszemy w artykule o out of stock SEO.

Warianty. Produkt z wariantami powinien mieć osobne oferty w schema. Dlaczego to ważne – opisujemy w artykule Czy AI rozumie warianty produktu?

Checklista naprawcza

Krok	Działanie	Priorytet
1	Zmapuj atrybuty critical (nazwa, cena, dostępność, marka, SKU) – oba źródła, aligned	P0
2	Zautomatyzuj porównanie ceny i dostępności między schema a DOM	P0
3	Dodaj atrybuty decision (wymiary, waga, kolor) do schema tam, gdzie są w DOM	P1
4	Sprawdź warianty: czy każdy ma osobną ofertę z prawidłową ceną	P1
5	Nie dodawaj do schema atrybutów, których nie ma na stronie	Zasada

Przed wdrożeniem zmian warto zwalidować bieżący stan schema narzędziami: Google Rich Results Test (sprawdza kwalifikację do wyników wzbogaconych), Schema.org Validator (weryfikuje poprawność składniową JSON-LD) oraz zakładka Ulepszenia w Google Search Console (raportuje błędy Product schema na poziomie całego serwisu). John Mueller potwierdził ten kierunek w kontekście zmian schema planowanych na 2026, pisząc na Reddicie: „markup types come and go, but a precious few you should hold on to„. To oznacza, że schema powinno opisywać rzeczywisty stan produktu widoczny w DOM, a nie być odrębnym kanałem z własnymi danymi.

Google zaleca podawanie danych produktowych zarówno przez structured data na stronie, jak i przez feed w Merchant Center – podwójna ścieżka zwiększa szansę na poprawną weryfikację, ale jednocześnie wymaga spójności między oboma źródłami. W ramach pozycjonowania sklepu internetowego audyt tej spójności powinien poprzedzać każdą kampanię merchant listings.

Case study: neonet.pl – co JSON-LD mówi, a co widzi użytkownik

Przeanalizowaliśmy strone produktowa laptopa ASUS TUF Gaming A16 w neonet.pl (sierpień 2026), porównując trzy warstwy danych: widoczny DOM, JSON-LD Product schema i meta tagi OG/product.

Zgodność nazwy i ceny – pełna. H1 w DOM to „ASUS TUF Gaming A16 Ryzen 7-170/32GB/2TB/Win11 RTX4050 144Hz”, identyczny z JSON-LD name i z og:title (po obcięciu suffiksu SEO). Cena w DOM (5 599 zł), JSON-LD offers.price (5599 PLN) i product:price:amount (5599.00) – też zgodne (na moment badania, sierpień 2026). To przykład klasy A (pełna zgodność).

Luki w schema mimo bogatego DOM. Trzy istotne braki: (1) brak gtin/ean w JSON-LD — por. OCR opakowań jako źródło GTIN — tylko wewnętrzny sku i mpn, co oznacza, ze systemy AI nie mogą jednoznacznie zidentyfikować produktu w globalnym katalogu; (2) brak aggregateRating i review w JSON-LD, mimo ze og:title reklamuje „tysiace opinii” – opinie istnieją w DOM, ale nie sa wystawione jako dane strukturalne; (3) BreadcrumbList kończy się na kategorii „Laptopy” zamiast na stronie produktu, z błędnym URL-em (pojedynczy slash w https:/www.neonet.pl).

Cena referencyjna – subtelna niezgodność. Meta tag product:original_price:amount wynosi 8 299 zł i odpowiada widocznej „Najniższej cenie z ostatnich 30 dni” (dyrektywa Omnibus). Ale JSON-LD Offer zawiera tylko aktualną cenę (5 599) – nie eksponuje ceny referencyjnej. System AI czytający tylko JSON-LD nie dowie się, że produkt jest przeceniony o ~33%. To typowy przykład klasy B – cena bazowa zgodna, ale kontekst promocyjny dostępny wyłącznie w DOM.

Morele.net – odwrotny problem. Przy próbie crawlowania wybranej strony produktowej morele.net (wycofana karta graficzna RTX 4060) serwer zwrócił redirect 301 do zupełnie innego produktu („Art-Pol Obraz”). Redirect dotyczył konkretnego URL-a produktu wycofanego ze sprzedaży — nie jest to regułą dla wszystkich PDP morele.net, ale ilustruje problem: bot AI próbujący zweryfikować dane produktowe z wycofanego URL-a może otrzymać całkowicie błędne informacje. Mimo to morele.net ma 27 695 cytowań w Perplexity, co sugeruje, że silniki AI mogą cytować dane bez weryfikacji ich aktualności i poprawności – dokładnie ten problem, który opisuje klasa D (rozbieżność krytyczna).

Wniosek: nawet dobrze zoptymalizowane sklepy jak neonet.pl mają luki między DOM a schema (brak GTIN, brak recenzji w JSON-LD, niekompletny breadcrumb). Te luki nie wpływają na rendering w przegladarce, ale bezpośrednio ograniczają zdolność systemów AI do poprawnej identyfikacji, porównania i cytowania produktu. W kontekście AI Overview i AI Mode — gdzie Google generuje odpowiedzi na podstawie wyekstrahowanych faktów — brak GTIN uniemożliwia powiązanie produktu z encją w Knowledge Graph, a brak recenzji w schema ogranicza materiał do syntezy odpowiedzi. Audyt entity-attribute matrix – porównanie pól DOM z polami JSON-LD – powinien byc standardowym elementem każdego technicznego audytu SEO w e-commerce.

Case study cross-industry: zooplus.pl – gdy schema jest lepsza niż w elektronice

Jeśli neonet.pl ilustruje problemy z rozbieżnością DOM vs schema, zooplus.pl (branża zoologiczna) pokazuje, jak wygląda bardziej kompletna implementacja – choć też nie wolna od luk. Analiza crawlu strony kolekcji FURminator na zooplus.pl (sierpień 2026) ujawnia interesujące różnice.

Schema zooplus.pl: strona kolekcji FURminator zawiera JSON-LD typu CollectionPage z zagnieżdżoną ItemList i 20 produktami Product. Każdy produkt ma: name, description (z formatowaniem HTML), brand, offers z UnitPriceSpecification, gtin13 i sku. aggregateRating (ratingValue + ratingCount) jest obecne na 12 z 20 produktów — nie wszystkie mają oceny. BreadcrumbList jest obecna (4 poziomy: zooplus.pl > Psy > Maszynki i pielęgnacja > FURminator). To znacząco bardziej kompletne niż neonet.pl, gdzie brakowało GTIN, reviews i miał uszkodzony breadcrumb.

Luki mimo kompletności: na stronie kolekcji zooplus nie ma indywidualnych obiektów Review w schema — natomiast na poszczególnych kartach produktowych indywidualne obiekty Review są obecne. To częsty wzorzec: strona listingowa eksponuje aggregateRating, a pełne recenzje są na PDP. Brakuje wybranych OG meta tags (og:image, og:type, og:url — choć og:title i og:description są obecne), co osłabia social sharing i potencjalnie rich previews w AI. Description produktów zawiera tagi HTML (strong, br) wewnątrz pola JSON-LD — to technicznie poprawne, ale może utrudniać parsing prostszym crawlerom.

Efekt na AI visibility: zooplus.pl z bardziej kompletną schema ma 5 364 cytowań ChatGPT i 2 806 w Perplexity. Dla porównania: eobuwie.pl (branża obuwnicza) ma 0 cytowań w ChatGPT i 0 w Perplexity – a jednocześnie generuje zaledwie 197 sesji organicznych w Polsce. Nie wiemy, jak wygląda schema eobuwie (serwis jest trudno crawlowalny), ale sam brak widoczności organicznej sugeruje, że nawet idealna schema nie pomoże, jeśli strona nie jest indeksowana w wynikach wyszukiwania.

Wniosek: rozbieżność DOM vs schema nie jest problemem wyłącznie elektroniki. W branży zoologicznej schema jest pełniejsza (GTIN, breadcrumb, aggregateRating), ale wciąż brakuje wybranych OG meta tags i pełnego pokrycia aggregateRating na wszystkich produktach. To potwierdza, że kompletność schema jest spectrum – nie binarna cecha – i audyt musi sprawdzać każde pole osobno, niezależnie od branży.

Jak monitorować rozbieżności w czasie?

Snapshot (jednorazowy audyt) ujawnia bieżący stan, ale nie wyłapie dryfu — sytuacji, w której schema i DOM rozjeżdżają się stopniowo po wdrożeniu. Cena w JSON-LD może przestać się aktualizować po zmianie pluginu, a dostępność w schema może zamrozić się na InStock po migracji platformy. Dlatego oprócz jednorazowego audytu potrzebny jest monitoring ciągły.

Minimalna konfiguracja monitoringu: (1) cotygodniowy cron porównujący wartości critical attributes (cena, dostępność, nazwa) między DOM a JSON-LD na losowej próbie 10-20 PDP; (2) alert przy delta > 0 na cenie lub dostępności; (3) raport miesięczny z trendem aligned % — jeśli spada, szablon lub integracja feedu wymaga przeglądu. Narzędzia: ecom_feed_page_schema_consistency_audit w trybie batch (GSCGA MCP), monitoring component drift dla zmian szablonowych, a dla walidacji technicznej — GSC (zakładka Ulepszenia → Product).

Źródła i narzędzia

Narzędzia GSCGA MCP: ecom_feed_page_schema_consistency_audit, ecom_product_schema_audit, ecom_product_attribute_coverage_audit, ecom_variant_aware_audit. Dane: 20 polskich sklepów, po 1 PDP na sklep, lipiec 2026. Ograniczenia: 1 PDP per sklep (nie pełna reprezentacja katalogu), brak warstwy feed, brak porównania w czasie (snapshot, nie monitoring).