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.
Google nie widzi Twojego sklepu jako „strony z produktami” – widzi go jako sieć encji: produkty, marki, merchant (sklep jako podmiot), poradniki, kategorie. Patent US8812435B1 (Google LLC) opisuje „learning objects and facts from documents” – system, który automatycznie rozpoznaje obiekty (produkty, marki, osoby) i relacje między nimi. Im jaśniej Twój sklep komunikuje te relacje (przez schema, linkowanie wewnętrzne i strukturę treści), tym lepiej system buduje graf wiedzy o Twoim asortymencie.
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 e-commerce.
Jakie encje Google rozpoznaje w sklepie e-commerce?
| Encja | Co reprezentuje | Skąd Google bierze dane | Powiązany artykuł z cyklu |
|---|---|---|---|
| Produkt | Konkretny model/SKU z atrybutami | Product schema (JSON-LD), tabela specyfikacji, opis | Art. 2: Product schema |
| Marka | Producent/brand z reputacją | Organization/Brand schema, strona „O marce”, linkowanie zewnętrzne | Art. 6: Merchant Knowledge Graph |
| Merchant (sklep) | Podmiot sprzedający z atrybutami zaufania | Merchant schema, trust signals, Google Business Profile | Art. 6 + 8 |
| Kategoria | Grupa produktów z atrybutami wyboru | BreadcrumbList, nawigacja, opis kategorii | Art. 14: Opisy kategorii |
| Poradnik | Treść wspierająca decyzję zakupową | Artykuł blogowy, FAQ, strona „Jak wybrać” | Art. 10: Content quality |
| Opinia | Ocena produktu z aspektami | Review schema z ratingValue | Art. 9: Recenzje |
Jak Google buduje relacje między encjami?
Patent US8812435B1 (Google LLC) opisuje system, który „uczy się” rozpoznawać relacje między obiektami w dokumentach. Dla e-commerce kluczowe relacje to:
| Relacja | Przykład | Jak ją zbudować |
|---|---|---|
| Produkt → Marka | Pompa Omnitron 5000 → Omnigena | Product schema: brand → Organization/Brand |
| Produkt → Kategoria | Pompa Omnitron 5000 → Pompy głębinowe | BreadcrumbList, linkowanie w opisie, nawigacja |
| Produkt → Akcesoria | Pompa → Zbiornik → Wyłącznik | isAccessoryOrSparePartFor w schema, sekcja „Kupowane razem” |
| Produkt → Alternatywy | Omnitron 5000 → Omnitron 3000 | isSimilarTo w schema, sekcja „Porównaj z” |
| Marka → Merchant | Omnigena → DoStudni.pl | Organization schema z brand, strona „O nas” z brandami |
| Poradnik → Produkty | „Jak dobrać pompę” → 5 modeli | Linkowanie z poradnika do kart produktów |
| Produkt → Opinia | Omnitron 5000 → 4.7/5 (bateria 5/5, wydajność 4/5) | Review schema z aspektami per produkt |
Jak verified entity attributes wpływają na widoczność?
Patent US12061594B2 (Google LLC) opisuje „verified entity attributes” – system, który weryfikuje atrybuty encji (produktu, marki, merchantu) z wielu źródeł. Jeśli Product schema mówi „cena: 1200 zł”, feed produktowy mówi „cena: 1200 zł” i strona wizualnie pokazuje „1200 zł” – atrybut jest zweryfikowany. Jeśli źródła się nie zgadzają – atrybut jest oznaczony jako „conflicting.”
Omówiliśmy to w artykule o inventory trust: niespójność danych (schema vs feed vs strona) podważa wiarygodność całej encji. W kontekście relacji: jeśli Product schema mówi, że brand to „Omnigena”, ale strona nigdzie nie wspomina tej marki – relacja produkt→marka jest słaba.
Jak knowledge graph łączy wszystkie elementy?
Patenty WO2014150214A2 i US11222048B2 (Google LLC) opisują systemy, które budują bazy wiedzy z pytań i odpowiedzi oraz przeszukują te bazy. Dla e-commerce:
- FAQ na kartach produktów buduje relacje pytanie→produkt: „Jaki zbiornik do Omnitron 5000?” → odpowiedź linkuje do zbiornika.
- Poradniki budują relacje problem→rozwiązanie→produkty: „Jak dobrać pompę do studni?” → kryteria → rekomendacje konkretnych modeli.
- Breadcrumby budują hierarchię: produkt → kategoria → nadkategoria → sklep.
- Cross-sell buduje relacje użytkowe: „Kupowane razem” = produkt A i produkt B często są kupowane w zestawie.
Jak wypadają sklepy z różnych branż pod kątem cross-sell i entity graph?
Uruchomiliśmy narzędzia ECOM Cross-sell Semantic Audit i Entity Graph Audit na kartach produktów i stronach kategorii 6 sklepów z różnych branż. Narzędzia analizują HTML zwrócony przez serwer (nie JavaScript) – więc wyniki pokazują, co crawler Google widzi „out of the box”:
| Sklep | Branża | Cross-sell (HTML) | Entity clarity | Product schema | FAQ |
|---|---|---|---|---|---|
| Sklep odzieżowy A (duży marketplace) | Moda | 0 linków (P1) | 0/100 | Brak w server-side HTML | Brak |
| Sklep odzieżowy B (katalogowy) | Moda | 0 linków (P1) | Nie audytowane | Brak widocznego | Brak |
| Sklep C (budynki drewniane) | Budynki | 0 linków (P1) | 12/100 | Brak | Brak |
| Sklep D (taping/sport) | Sport/medycyna | 3 akcesoria, 1 alternatywa | Nie audytowane | Brak | Brak |
| Sklep E (pompy/instalacje) | Instalacje | 0 linków (P1) | Nie audytowane | MA (z brand!) | Brak |
| Sklep F (żywność/suplementy) | FMCG | 0 linków (P1) | Nie audytowane | Brak | Brak |
Wynik: 5 z 6 sklepów ma ZERO cross-sell w HTML. Jedyny sklep z jakimikolwiek linkami do akcesoriów to sklep D (taping/sport) z 3 linkami. Reszta – w tym dwaj duzi gracze z branży modowej – nie ma w server-side HTML ani jednego linku do kompatybilnych produktów, alternatyw czy poradników.
Dlaczego to problem? Cross-sell ładowany przez JavaScript (React, Vue, lazy loading) nie jest widoczny dla crawlera w momencie indeksacji. Google renderuje JavaScript, ale z opóźnieniem i nie zawsze kompletnie. Jeśli sekcja „Podobne produkty” lub „Kup razem z” jest ładowana dynamicznie – system retrieval może jej nie zobaczyć. To nie jest teoria – narzędzie Entity Graph Audit na sklepie odzieżowym A (entity_clarity: 0/100) potwierdza: w server-side HTML nie ma ani Product schema, ani brand, ani ceny, ani dostępności. Wszystko jest renderowane przez JavaScript.
Jedyny sklep z Product schema w server-side HTML to sklep E (pompy/instalacje) – i to jest ten sam sklep, który w artykule o Product schema pokazaliśmy jako przykład poprawnej implementacji z polem brand. To nie jest przypadek: sklep na dedykowanej platformie e-commerce ma schema w HTML, sklepy na SPA-first frameworkach (React) – nie mają.
Case study: jak sklepy budują (lub nie budują) relacje między encjami?
Uruchomiliśmy narzędzie ECOM Cross-sell Semantic Audit i ECOM Product Entity Graph Audit na stronach trzech klientów e-commerce. Wyniki pokazują, ile relacji między encjami system może „zobaczyć” z poziomu HTML:
| Relacja | Sklep A (budynki drewniane) | Sklep B (taping / sport) | Sklep C (pompy / instalacje) |
|---|---|---|---|
| Produkt → Marka (brand w schema) | Brak Product schema | Brak Product schema | MA Product schema z brand |
| Produkt → Kategoria (breadcrumby) | Nawigacja bez BreadcrumbList | Nawigacja bez BreadcrumbList | Nawigacja bez BreadcrumbList |
| Produkt → Akcesoria (cross-sell) | 0 linków | 3 linki („Akcesoria do tapingu”) | 0 linków |
| Produkt → Alternatywy | 0 linków | 1 link („Zamienniki posiłku”) | 0 linków |
| Produkt → Poradnik | 0 linków | 0 linków | 1 link (blog) |
| Merchant → Organization schema | Brak | Brak | Brak |
Najważniejszy finding: żaden z 3 sklepów nie ma BreadcrumbList schema – najprostszej relacji hierarchicznej (produkt → kategoria → nadkategoria → sklep). Bez niej system musi sam zgadywać hierarchię z nawigacji HTML. Drugi finding: tylko 1 z 3 sklepów ma Product schema z polem brand – bez tego relacja produkt→marka nie istnieje w grafie wiedzy Google.
Sklep B (taping/sport) wyróżnia się pozytywnie: ma 3 linki do akcesoriów i 1 do zamienników. To jest początek relacji komplementarnych. Ale brakuje poradników („Jak dobrać taping do kontuzji kolana?”) i breadcrumbów. Sklep A (budynki drewniane) ma najgorszy wynik: 120 linków wewnętrznych, ale zero relacji produktowych w sensie cross-sell, zero schema, zero poradników. System widzi drzewo nawigacji, ale nie widzi relacji między produktami.
Dla porównania: dobrze zoptymalizowany sklep powinien mieć na każdej karcie produktu minimum 3-5 linków do akcesoriów/kompatybilnych, 2-3 linki do alternatyw, 1-2 linki do poradników, breadcrumby z BreadcrumbList schema i Product schema z brand, gtin i isRelatedTo. To buduje sieć relacji, którą system może wykorzystać do budowania product graph.
Case study: ile encji system „widzi” na stronie kategorii?
Narzędzie ECOM Category Semantic Full Auto generuje entity matrix – macierz pokrycia encji na stronie. Dla kategorii sklepu z budynkami drewnianymi (zanonimizowane) wyniki są dramatyczne:
| Tier encji | Oczekiwane | Pokryte | Procent |
|---|---|---|---|
| Core entity (domek, altana, wiata, garaż) | 10 | 1 | 10% |
| Subtype (domki letniskowe, całoroczne, altany) | 6 | 1 | 17% |
| Decision attributes (metraż, ściany, dach, ocieplenie) | 13 | 0 | 0% |
| Use case (do ogrodu, na działkę, do rekreacji) | 5 | 0 | 0% |
| Modifier (drewniane, ocieplone, z tarasem) | 5 | 0 | 0% |
| FAQ themes (jak dobrać, czy wymaga pozwolenia) | 6 | 0 | 0% |
| RAZEM | 45 | 2 | 4.4% |
2 z 45 oczekiwanych encji pokryte. System widzi słowo „domki” (w H1 i nawigacji) i „domki ogrodowe” (w jednym linku). Nie widzi: „domki letniskowe”, „domki całoroczne”, „drewniane”, „ocieplone”, „z tarasem” – chociaż sklep sprzedaje wszystkie te typy. Nie widzi żadnych atrybutów decyzyjnych: metraż, grubość ścian, rodzaj dachu, ocieplenie – chociaż to są kryteria, po których użytkownicy wybierają.
To jest praktyczne znaczenie patentu US8812435B1 („learning objects and facts from documents”): system próbuje rozpoznać encje i relacje z treści strony. Jeśli treść to nawigacja + listing bez opisu – system nie ma z czego budować grafu. Kategoria „Domki” z entity completeness 12/100 to w grafie wiedzy praktycznie pusta karta – system wie, że ta strona istnieje, ale nie wie, co ta kategoria oferuje, jakie ma podtypy, ani jakie są kryteria wyboru.
Jak audytować relacje między encjami w sklepie?
Jakość opisów produktów to osobny temat – w artykule o opisach produktów pod Google i AI pokazujemy, że opis faktograficzny ma 3.5× wyższą gęstość cytowalnych passages niż marketingowy. A opisy kategorii wymagają zupełnie innego podejścia – o tym w artykule o opisach kategorii e-commerce. Checklista 8 punktów:
- Czy Product schema ma pole brand z Organization/Brand?
- Czy Product schema ma pola isRelatedTo i isAccessoryOrSparePartFor?
- Czy breadcrumby mają BreadcrumbList schema?
- Czy strona „O nas” / „O marce” ma Organization schema z name, url, logo, sameAs?
- Czy poradniki linkują do konkretnych produktów (nie tylko do kategorii)?
- Czy karty produktów linkują do poradników („Przeczytaj: Jak dobrać pompę”)?
- Czy dane schema ↔ feed ↔ strona są spójne (cena, dostępność, marka)?
- Czy cross-sell jest skonfigurowany ręcznie (kupowane razem) czy losowo (platforma)?
Jakie wnioski płyną z patentów o relacjach encji?
Sklep e-commerce to nie kolekcja kart produktów – to sieć encji połączonych relacjami. Patenty opisują system, w którym:
- Objects and facts (US8812435B1) – system automatycznie rozpoznaje produkty, marki i fakty z dokumentów. Im jaśniejsza struktura (schema, tabele, nagłówki), tym łatwiej system buduje graf.
- Verified attributes (US12061594B2) – atrybuty są weryfikowane z wielu źródeł. Spójność danych = zaufanie. Niespójność = degradacja.
- Knowledge base (WO2014150214A2, US11222048B2) – system buduje bazę wiedzy z pytań i odpowiedzi. FAQ, poradniki i cross-sell to materiał do tej bazy.
Dane z badań potwierdzają wagę kompletnych relacji produktowych. Według badania Icecat/Shopware (2025), sklepy z dokładnymi danymi produktowymi (w tym relacjami: produkt→marka, produkt→kategoria, produkt→akcesoria) widzą poprawę konwersji do 30% i redukcję zwrotów o 20%. Akeneo (maj 2026) pokazuje skalę problemu od drugiej strony: 43% konsumentów zwróciło produkt, bo informacje przed zakupem były niepełne lub błędne. Koszty? National Retail Federation szacuje zwroty w USA na ~$900 miliardów rocznie.
Dane zewnętrzne potwierdzają skalę problemu. Według Schema App (grudzień 2024), tylko 12.4% zarejestrowanych domen ma wdrożone dane strukturalne schema.org (45 milionów z ~360 milionów). Schema.org Product jest używany na 1-10 milionów domen (dane Google, maj 2026) – ale sam fakt wdrożenia nie wystarczy. Audyt 5000 stron (Digital Applied, kwiecień 2026) wykazał, że większość wdrożeń schema ma co najmniej jeden błąd walidacji: brakujące pola wymagane, nieprawidłowe formaty dat, type-content mismatch (Product schema na stronie kategorii). Korelacja między poprawnym schema a cytowaniem przez AI: Pearson +0.34.
Jednocześnie badanie SE Ranking (marzec 2026) pokazuje, że tylko 38% stron cytowanych w AI Overviews rankuje w top 10 tradycyjnego SERP. To oznacza, że budowanie relacji między encjami (product graph) daje szansę na widoczność w AI nawet bez pozycji #1 w organiku – ale wymaga kompletnych, zweryfikowanych danych strukturalnych.
Ten artykuł spina 14 poprzednich artykułów cyklu w jedną całość: feed, schema, duplikacja, visual search, discovery, MKG, inventory, trust, recenzje, content quality, implicit feedback i AI Search. Każdy element to jedna warstwa. Razem tworzą product graph – graf wiedzy, z którego Google i AI budują odpowiedzi.
To jest piętnasty artykuł z cyklu „SEO e-commerce w świetle patentów Google.” Jeśli szukasz wsparcia w pozycjonowaniu sklepu internetowego lub potrzebujesz audytu SEO – skontaktuj się z nami.
Źródła
Patenty
Czy muszę mieć osobną stronę dla każdej marki?
Nie musisz, ale pomaga. Strona marki (’O marce Omnigena’) z Organization schema, historią, certyfikatami i linkami do produktów tej marki buduje encję marki w systemie Google. Bez niej relacja produkt→marka opiera się tylko na polu brand w Product schema.
Jak poradnik zakupowy buduje relacje między encjami?
Poradnik 'Jak dobrać pompę do studni’ linkuje do konkretnych modeli (produkt), wspomina marki (Brand), odpowiada na pytania (FAQ→knowledge base) i jest częścią sklepu (merchant). Jeden poradnik buduje 4 typy relacji jednocześnie.
Czy Google naprawdę buduje knowledge graph z mojego sklepu?
Google buduje Merchant Knowledge Graph ze źródeł takich jak Product schema, Google Business Profile, Merchant Center feed i treść strony. Opisaliśmy to w artykule o Merchant Knowledge Graph. Im więcej ustrukturyzowanych danych, tym pełniejszy graf.
Co jest ważniejsze: schema czy linkowanie wewnętrzne?
Oba pełnią różne role. Schema mówi systemowi CO jest encją i jakie ma atrybuty. Linkowanie mówi JAK encje są ze sobą powiązane. Produkt bez schema to encja bez paszportu. Produkt bez linków to encja bez relacji. Potrzebujesz obu.
Jak sprawdzić, czy moje relacje między encjami działają?
Wpisz w Google 'site:twojsklep.pl marka X’ – czy Google pokazuje produkty tej marki? Wpisz w ChatGPT 'jakie produkty ma [sklep]’ – czy AI zna Twój asortyment? Użyj narzędzia Entity Graph Audit z naszego MCP do audytu relacji.
1. US8812435B1 – „Learning objects and facts from documents.” Google LLC. patents.google.com/patent/US8812435
2. US12061594B2 – „Verified entity attributes.” Google LLC. patents.google.com/patent/US12061594
3. WO2014150214A2 – „Questions answering to populate knowledge base.” Google LLC. patents.google.com/patent/WO2014150214
4. US11222048B2 – „Knowledge search system.” Google LLC. patents.google.com/patent/US11222048
Badania i raporty
5. Schema App – „The Semantic Value of Schema Markup in 2025.” schemaapp.com
6. SE Ranking / Alhena – „65% of AI-Cited Pages Use Structured Data.” Marzec 2026. alhena.ai
7. Digital Applied – „Schema Markup Adoption: 5,000-Site Audit.” digitalapplied.com
8. Xenara – „Product schema for e-commerce: what triggers rich results in 2026.” xenara.ai patents.google.com/patent/US11222048
