Po co sklepowi dane strukturalne

Mechanizm jest prosty: znaczniki tłumaczą treść strony na format, którego wyszukiwarka nie musi zgadywać. Cena zapisana w kodzie jako liczba z walutą jest jednoznaczna; ta sama cena jako tekst w akapicie już nie, zwłaszcza przy promocjach i wariantach.

W zamian karta produktu może dostać w wynikach dodatkowe elementy: cenę, informację o dostępności, gwiazdki oceny, a przy spełnieniu dalszych warunków także dane o zwrotach i dostawie. Sklep zaczyna też pojawiać się w zestawieniach ofert i w powierzchniach zakupowych Google, do których zwykły opis tekstowy nie daje wejścia.

Jest jeszcze argument, który podaję rzadziej, ale uważam za ważny: znaczniki wymuszają porządek w danych. Nie da się poprawnie oznaczyć dostępności, jeśli sklep sam nie wie, co ma na stanie. Wdrożenie danych strukturalnych bardzo szybko obnaża tego typu zaległości.

Product: co jest wymagane, a co zalecane

Podstawą jest typ opisujący produkt, a w nim zagnieżdżona oferta. Tu warto rozróżnić dwa poziomy, bo w dokumentacji łatwo je pomieszać.

Bezwzględnie potrzebne są nazwa, obraz oraz oferta z ceną, walutą i dostępnością. Bez tego zestawu nie ma o czym rozmawiać — brak dostępności to najczęstszy powód, dla którego karta nie kwalifikuje się do rozszerzonego wyniku, i najczęściej pomijane pole w gotowych szablonach sklepowych.

Silnie zalecane, bo realnie zwiększają szansę na dopasowanie produktu do tego samego przedmiotu u innych sprzedawców: identyfikator globalny, numer katalogowy producenta, nazwa marki oraz opis. Sklep, który sprzedaje towar dostępny u konkurencji i nie podaje identyfikatorów, sam utrudnia sobie życie.

Kilka pułapek, które widzę najczęściej. Cena musi być liczbą bez symbolu waluty i bez spacji rozdzielających tysiące. Dostępność to jedna z wartości ze zdefiniowanej listy, nie dowolny tekst po polsku. Dla produktów z ceną zmienną w czasie warto podać datę ważności ceny. A przy wariantach — rozmiar, kolor — trzeba zdecydować, czy każdy wariant ma własny adres z własnymi znacznikami, czy jeden adres opisuje zakres cen. Oba podejścia są dopuszczalne, mieszanie ich nie.

Dwa różne warianty wyniku

To rozróżnienie jest kluczowe dla planowania pracy, a prawie nigdy nie pojawia się w rozmowach o „wdrożeniu schemy”.

Google traktuje inaczej stronę, na której produkt można kupić, a inaczej stronę, która o produkcie tylko pisze — recenzję, porównanie, wpis blogowy. Pierwsza kwalifikuje się do wyniku sprzedażowego, z ceną, dostępnością i ewentualnie danymi o zwrotach oraz dostawie. Druga może dostać skromniejszy wariant z oceną i zakresem cen, ale nie wejdzie do powierzchni zakupowych.

Praktyczny wniosek: karta produktu i wpis o produkcie potrzebują innego zestawu pól. Oznaczanie recenzji pełnym zestawem sprzedażowym nie da nic poza ostrzeżeniami w narzędziach, a często wprowadza w błąd, sugerując możliwość zakupu tam, gdzie jej nie ma.

W Search Console te dwa warianty mają zresztą osobne raporty i warto sprawdzać oba. Rozjazd między nimi bywa pierwszą wskazówką, że szablon strony kategorii albo wpisu na blogu generuje znaczniki, których nikt tam nie planował.

AggregateRating i pułapka opinii

Ocena zbiorcza to element, o który klienci proszą najczęściej, bo gwiazdki w wynikach są widoczne od razu. To też element, przy którym najłatwiej złamać zasady.

Reguła podstawowa jest jedna i nie ma od niej wyjątków: oznaczona ocena musi być widoczna na stronie dla użytkownika. Wartość zaszyta w kodzie, której nie da się zobaczyć w treści, jest naruszeniem wytycznych i przy wykryciu kończy się utratą rozszerzeń dla całej domeny, nie tylko dla jednej podstrony.

Poza tym trzy rzeczy do sprawdzenia. Ocena musi opierać się na opiniach zebranych od klientów, a nie wystawionych przez sklep sobie samemu — Google od lat nie akceptuje ocen własnych dla organizacji ani jej usług. Liczba opinii musi być prawdziwa i musi się zgadzać z tym, co widać. Skala oceny powinna być zadeklarowana, jeśli nie jest to standardowa skala pięciostopniowa.

Osobna sprawa to produkty bez opinii. Nie wolno wtedy wystawiać zerowej oceny ani żadnej wartości zastępczej — pole trzeba po prostu pominąć. Widzę sklepy, w których szablon zawsze generuje ocenę, także dla nowości bez ani jednej opinii, i przy większym asortymencie ląduje to jako lawina błędów.

MerchantReturnPolicy i informacje o dostawie

Ten element pojawił się w danych strukturalnych stosunkowo niedawno i jest dziś najmniej wykorzystywany, mimo że dla sklepu jest wyjątkowo praktyczny — informacja o darmowym zwrocie i terminie widoczna przy wyniku rozstrzyga część wątpliwości jeszcze przed kliknięciem.

Politykę zwrotów można podać na dwa sposoby. Pierwszy to zagnieżdżenie jej w ofercie na karcie produktu, wraz z krajem, do którego się stosuje, kategorią polityki, liczbą dni na zwrot, informacją o tym, kto płaci za przesyłkę zwrotną, i sposobem zwrotu. Drugi, dostępny od czerwca tego roku, to podanie jednej polityki dla całego sklepu na poziomie znacznika organizacji — w praktyce w podtypie opisującym sklep internetowy.

Ta druga droga jest w większości przypadków rozsądniejsza. Warunki zwrotu są zwykle takie same dla całego asortymentu, więc powtarzanie ich w każdym produkcie tylko rozdmuchuje kod i mnoży miejsca, w których dane mogą się rozjechać po zmianie regulaminu.

Dwa zastrzeżenia. Jeżeli sklep ma konto w Merchant Center, Google zaleca konfigurację zwrotów właśnie tam, a znaczniki traktować jako uzupełnienie — ustawienia w Merchant Center mają pierwszeństwo. I rzecz oczywista, o której łatwo zapomnieć: oznaczona polityka musi odpowiadać regulaminowi. Rozbieżność między znacznikiem a regulaminem to nie tylko problem z Google, ale i z prawem konsumenckim.

Analogicznie działają dane o dostawie — koszt, kraj, przewidywany czas realizacji. Na dziś obsługiwane są w ramach oferty produktu; podawanie ich zbiorczo na poziomie organizacji, tak jak przy zwrotach, nie jest jeszcze możliwe.

Jak to wdrożyć technicznie

Zaczynam od formatu: zapis w formie osobnego bloku danych w skrypcie, a nie atrybutów rozsypanych po szablonie. Google zaleca ten sposób, a przy utrzymaniu różnica jest przepaścią — blok generuje się w jednym miejscu, zamiast być rozproszonym po dwudziestu plikach widoku.

Dalej kolejność prac, którą stosuję w typowym sklepie. Najpierw jeden szablon dla karty produktu i sprawdzenie go na kilku przypadkach: produkt dostępny, niedostępny, w promocji, z wariantami, bez opinii. Potem znacznik organizacji z polityką zwrotów, wstawiany globalnie. Na końcu pozostałe typy: okruszki nawigacyjne, strona kategorii, wpisy blogowe o produktach.

Trzy uwagi z praktyki. Jeśli sklep stoi na popularnym silniku, znaczniki generuje zwykle wtyczka i najpierw trzeba sprawdzić, czego brakuje w tym, co już wychodzi — zamiast dokładać drugi zestaw obok. Dwa bloki opisujące ten sam produkt to jedno z trudniejszych do wykrycia źródeł błędów.

Jeżeli treść generuje się skryptem po wczytaniu strony, blok danych musi się w źródle znaleźć w sposób, który wyszukiwarka zobaczy — najbezpieczniej po stronie serwera. I ostatnia: dane w znacznikach muszą pochodzić z tego samego miejsca co dane na stronie. Cena renderowana z jednego pola, a oznaczona z drugiego, rozjedzie się przy pierwszej promocji.

Walidacja i utrzymanie

Test wyników z elementami rozszerzonymi mówi, czy strona kwalifikuje się do konkretnego wariantu wyniku. Walidator schematu mówi, czy zapis jest formalnie poprawny. To dwa różne pytania i potrzebne są oba narzędzia — kod bywa poprawny formalnie i jednocześnie bezużyteczny dla wyszukiwarki.

Utrzymanie sprowadzam do trzech nawyków. Raz w miesiącu przeglądam raporty danych strukturalnych w Search Console i patrzę na trend liczby błędów, nie na wartość bezwzględną — nagły skok prawie zawsze oznacza wdrożenie, nie zmianę u Google. Po każdej aktualizacji silnika sklepu albo wtyczki sprawdzam jedną kartę produktu ręcznie. A raz na kwartał czytam listę zmian w dokumentacji Google, bo wymagania w tym obszarze bywają zaostrzane bez rozgłosu.

Na koniec rzecz, którą powtarzam przy każdym takim wdrożeniu: to praca, która nie kończy się w dniu publikacji. Znaczniki opisują stan sklepu, a stan sklepu zmienia się codziennie. Jeżeli nikt nie odpowiada za ich zgodność z rzeczywistością, po roku będą opisywać sklep, którego już nie ma.