Dane strukturalne Product w marketplace: ceny, dostępność i oferty

Dane strukturalne Product w marketplace pomagają Google zrozumieć, czym jest oferta, jaka jest cena, w jakiej walucie można kupić produkt i czy jest on dostępny. Nie są jednak skrótem do widoczności ani zamiennikiem dobrej strony. Markup musi odpowiadać temu, co użytkownik widzi i może faktycznie kupić. Największe ryzyko w platformach wielosprzedawczych wynika z rozjechanych danych: stara cena w JSON-LD, aktualna cena w interfejsie, inny stan w feedzie i jeszcze inny na stronie.

Najpierw rozdziel Product i Offer

`Product` opisuje przedmiot lub usługę, a `Offer` konkretną możliwość zakupu: cenę, walutę, dostępność, warunki i sprzedawcę. W marketplace jeden produkt może mieć wiele ofert. Zanim wdrożysz dane, ustal, czy adres URL jest stroną produktu, pojedynczej oferty czy profilu sprzedawcy. Nie oznaczaj kategorii z listą wielu produktów jako jednej karty produktu.

Google wskazuje, że product rich results są przeznaczone przede wszystkim dla stron skupionych na jednym produkcie albo jego wariantach. Strony listingu, kategorii i marketplace nie powinny udawać pojedynczej karty tylko po to, aby spełnić schemat.

Minimalny zestaw danych do kontroli

• Nazwa produktu odpowiada tytułowi i widocznej treści.
• URL oferty jest stabilny i prowadzi do strony zakupu.
• Cena ma poprawny format i walutę ISO 4217.
• Dostępność jest zgodna z komunikatem dla użytkownika.
• Zdjęcie przedstawia oznaczany produkt.
• Identyfikator, marka i wariant nie są kopiowane z innej oferty.

W przypadku wielu sprzedawców dodaj tylko dane, które możesz zweryfikować. Nie generuj fikcyjnych ocen, liczby opinii ani identyfikatorów. Dane strukturalne z błędami mogą zostać zignorowane, a sprzeczne dane obniżają zaufanie do całego procesu.

Cena i dostępność muszą się zgadzać

Synchronizuj markup z tym samym źródłem, które zasila widoczny interfejs. Jeśli cena zależy od wariantu, kraju, zalogowania lub ilości, użytkownik powinien od razu widzieć warunek. Nie wpisuj najniższej możliwej ceny, jeśli większość osób nie może jej uzyskać.

Podobnie działa dostępność. `InStock`, `OutOfStock`, `PreOrder` i `Discontinued` nie są ozdobnymi etykietami. Użyj jednej wartości odpowiadającej aktualnemu stanowi. Jeśli produkt jest chwilowo niedostępny, strona może pozostać dostępna, ale nie powinna przedstawiać nieaktualnej oferty jako gotowej do zakupu.

Opinie i oceny w marketplace

Ocena dotyczy konkretnego produktu, sprzedawcy albo transakcji — nie mieszaj tych poziomów. Jeśli pokazujesz aggregateRating produktu, musisz mieć wiarygodny proces zbierania opinii i jasne powiązanie z oznaczaną kartą. Nie przenoś średniej sprzedawcy na każdy produkt bez wyjaśnienia.

Strona z samą listą ofert nie powinna otrzymywać danych, które sugerują, że cała lista jest jednym produktem. Lepiej poprawnie oznaczyć pojedyncze, dostępne karty niż pokryć schematem cały katalog w sposób niezgodny z treścią.

Warianty i wielu sprzedawców

Warianty koloru, rozmiaru lub pojemności mogą mieć osobne URL-e, jeśli użytkownik może je jednoznacznie wybrać i kupić. Ustal, który adres jest stroną rodzica, a który wariantem. Linki, canonical i dane Product muszą używać tej samej logiki.

Jeśli kilku sprzedawców oferuje ten sam produkt, rozważ stronę produktu z listą ofert zamiast kopiowania tego samego opisu. Każda oferta może mieć własną cenę i dostępność. Profil sprzedawcy powinien być linkowany i opisany osobno. Ten podział ogranicza duplikację oraz pozwala użytkownikowi zrozumieć, co właściwie porównuje.

Jak wdrożyć i testować

1. Zdefiniuj model produktu, oferty, wariantu i sprzedawcy.
2. Wybierz kilka reprezentatywnych stron: aktywną, niedostępną, wielowariantową i z wieloma sprzedawcami.
3. Dodaj dane z bieżącego źródła cen i dostępności.
4. Sprawdź kod w Rich Results Test.
5. Użyj URL Inspection dla strony dostępnej dla Google.
6. Po wdrożeniu obserwuj raport Merchant listings i błędy danych.

Google nie gwarantuje, że poprawny markup spowoduje wyświetlenie konkretnego rozszerzenia. Celem jest przekazanie precyzyjnych danych i ograniczenie niejasności, a nie obietnica rich result dla każdej karty.

Najczęstsze błędy techniczne

• Wartość `price` jest w JSON-LD, ale nie występuje w widocznej treści.
• Markup używa starego URL-u po migracji oferty.
• Wiele kart kopiuje ten sam identyfikator SKU lub zdjęcie innego produktu.
• Oferta ma `InStock`, choć przycisk zakupu jest wyłączony.
• Skrypt generuje markup dopiero po interakcji, której robot nie wykonuje.
• Opinie sprzedawcy są przedstawiane jako ocena konkretnego produktu.

Przy szybko zmieniających się ofertach warto umieszczać podstawowe dane w początkowym HTML, jeśli architektura na to pozwala. Google zwraca uwagę, że dynamicznie generowane dane Product mogą być mniej niezawodne przy częstych zmianach ceny i dostępności. Nie oznacza to, że JavaScript jest zawsze błędem, ale wymaga dodatkowych testów i zasobów serwera.

Feed, strona i Merchant Center

Marketplace powinien mieć jedno źródło prawdy albo jasno określone priorytety między bazą, stroną, feedem i markupem. Jeśli te kanały różnią się, nie próbuj maskować problemu dodatkowymi właściwościami schema. Najpierw popraw synchronizację, zaokrąglenia ceny, walutę i harmonogram aktualizacji. Następnie sprawdź kilka przypadków granicznych: produkt darmowy, promocję, wariant, brak magazynu i ofertę wielu sprzedawców.

Raporty Search Console pomagają wykrywać wzrost ostrzeżeń i błędów, ale nie zastępują testu strony jako użytkownik. Otwórz kartę, wybierz wariant, sprawdź cenę i dopiero wtedy porównaj dane z markupem.

Jeśli platforma obsługuje wiele walut, krajów lub sprzedawców, zapisz te różnice w modelu danych, zamiast dopisywać przypadkowe warunki w szablonie. Osobny URL dla różnych walut lub wariantów może ułatwić Google rozpoznanie oferty, ale tylko wtedy, gdy każdy adres przedstawia realnie dostępny i spójny produkt.

Architekturę stron opisuje hub Marketplace SEO, a problemy duplikatów i niedostępnych kart omawia poradnik o statusach ofert.

Kontrola po publikacji

Raz w tygodniu porównaj losową próbę markup z ekranem użytkownika i źródłem danych. Przy dużym katalogu automatyzuj wykrywanie brakującej ceny, przeterminowanego `priceValidUntil`, nieaktualnej dostępności i błędnego URL-u. Najpierw napraw zgodność danych, dopiero później rozszerzaj schema o dodatkowe właściwości.

Źródła

• Google Search Central — wybór Product snippets i merchant listings
• Google Search Central — Product, Offer, cena i dostępność
• Google Search Central — dane strukturalne e-commerce
• Google Search Central — struktura e-commerce i linkowanie produktów
• Google Search Central — wymagania Product snippet i availability
• Unsplash — fotografia produktów i oferty, Adly Hakim, licencja Unsplash
• Unsplash — fotografia transakcji cyfrowej, Blake Wisz, licencja Unsplash