Dane strukturalne polityki zwrotów brzmią jak robota dla kogoś, kto śpi z instrukcją Google pod poduszką. Spokojnie. Największy problem zwykle nie siedzi w kodzie, tylko w tym, że sklep ma kilka wersji zasad zwrotu. Jedna jest w regulaminie, druga na stronie „Zwroty”, trzecia w Merchant Center, a czwarta — gdzieś w głowie właściciela.
MerchantReturnPolicy nie posprząta tego bałaganu za Ciebie. Te dane mają opisać zasady, które faktycznie obowiązują w sklepie. Najpierw więc porządkujemy informacje, wyjątki i miejsca publikacji. Dopiero potem przechodzimy do oznaczenia technicznego. Poniżej znajdziesz checklistę, prosty podział na politykę ogólną i wyjątki oraz kolejność kontroli po wdrożeniu. Bez obietnic cudów w Google, bo poprawny schema nie gwarantuje konkretnego wyglądu wyniku ani wzrostu sprzedaży.
Najpierw ogarnij zasady zwrotów, potem schema
Dane strukturalne są opisem polityki zwrotów, a nie jej zamiennikiem. Nie ustalają za sklep, ile dni ma klient na zwrot, kto płaci za przesyłkę ani czy dany produkt ma wyjątek. Najpierw trzeba sprawdzić, jakie zasady rzeczywiście znajdują się w regulaminie i na publicznej stronie zwrotów.
Dobry początek to porównanie trzech miejsc: widocznej treści strony, planowanych danych strukturalnych oraz ustawień Merchant Center. Jeśli w jednym miejscu widnieje inny termin, koszt albo metoda zwrotu, kod nie rozwiąże problemu. Przeciwnie — tylko dorzuci kolejną wersję informacji.
Ważne rozróżnienie: techniczne wdrożenie nie jest oceną, czy regulamin sklepu jest zgodny z polskim prawem. Do kodu nie wpisuj też informacji „na oko”. Każde pole powinno mieć potwierdzenie w rzeczywistych zasadach sklepu i publicznej treści.
Checklista polityki zwrotów bez czarnej magii
Zanim ktoś zacznie kodować, warto zebrać informacje w jednym miejscu. Nie musi to być od razu rozbudowany system. Wystarczy czytelna tabela albo dokument, w którym widać, co jest regułą, co wyjątkiem i czy wszystkie kanały mówią to samo.
Co zebrać w jednym miejscu
Przygotuj przede wszystkim odpowiedzi na poniższe kwestie:
- Kraj lub kraje, których dotyczy polityka zwrotów.
- Informację, czy zwroty są dozwolone oraz jaka kategoria polityki opisuje sytuację sklepu.
- Liczbę dni na zwrot, jeżeli sklep określa konkretne okno zwrotu.
- Stan, w jakim produkt powinien zostać odesłany, zgodnie z rzeczywistymi zasadami sklepu.
- Metodę zwrotu, czyli sposób, w jaki klient odsyła produkt.
- Koszt wysyłki zwrotnej i ewentualną opłatę związaną ze zwrotem.
- Sposób uzyskania etykiety oraz kraj lub miejsce, do którego należy odesłać produkt.
- Zasady refundacji, czyli sposób rozliczenia zwrotu opisany przez sklep.
- Wyjątki dotyczące konkretnych produktów albo grup asortymentu.
Praktycznie najlepiej zrobić trzy kolumny: „zasada główna”, „wyjątki” oraz „zgodność informacji na stronie i w Merchant Center”. Taki układ szybko pokazuje, czy polityka jest spójna. Jeżeli sklep sprzedaje do różnych krajów albo ma różne zasady dla różnych grup produktów, nie zakładaj automatycznie, że jedna polityka ogólna wystarczy.
Ta checklista porządkuje dane techniczne. Nie odpowiada natomiast na pytanie, jakie zasady prawnie powinny obowiązywać konkretny sklep. To osobna sprawa, zależna od regulaminu i okoliczności sprzedaży.
Polityka firmy kontra wyjątek dla konkretnego produktu
Tu łatwo zrobić małe zamieszanie. Polityka firmy to domyślne zasady dotyczące większości albo wszystkich produktów. Wyjątek dotyczy konkretnej oferty lub grupy produktów, które mają inne reguły. Na przykład nie chcesz opisywać całego sklepu jako jednego wielkiego wyjątku tylko dlatego, że kilka ofert działa inaczej.
W danych strukturalnych ogólną politykę można powiązać z Organization przez hasMerchantReturnPolicy. Wyjątek przypisany do konkretnej oferty może być oznaczony przy Offer. Trzeba pamiętać, że polityki przypisane do oferty obsługują węższy zestaw właściwości niż polityki na poziomie organizacji. Nie każde pole z polityki firmowej przenosi się więc jeden do jednego.
Najpierw reguła główna, potem wyjątki
Najpierw ustal, co obowiązuje dla większości produktów. Dopiero później wypisz oferty, które naprawdę od tej reguły odstają. W Merchant Center podobna logika opiera się na polityce domyślnej i wyjątkach przypisywanych produktom, między innymi przez etykiety.
Nie twórz wyjątków tylko dlatego, że „może kiedyś się przydadzą”. Każdy wyjątek powinien wynikać z rzeczywistych zasad sklepu. Następnie porównaj go z kartą produktu, stroną zwrotów, danymi strukturalnymi i Merchant Center. Inaczej klient zobaczy jedną informację, Google odczyta drugą, a właściciel sklepu zacznie polować na błąd jak na muchę w kuchni.
Gdzie umieścić politykę zwrotów, żeby klient nie szukał jej z lupą
Najczytelniejszy układ to jedna główna, publicznie dostępna strona z pełną polityką zwrotów firmy. Nie trzeba kopiować pełnych danych na każdej podstronie. Ważniejsze jest to, żeby użytkownik mógł szybko znaleźć właściwą treść i żeby ta treść nie wymagała specjalnej przepustki.
Jedna strona, kilka sensownych punktów dostępu
Polityka powinna być dostępna bez logowania, rejestracji i podawania danych osobowych. Podstawowym miejscem linku może być stopka. W zależności od układu sklepu sensowny będzie też odsyłacz w sekcji pomocy, na stronie produktu albo w koszyku.
Nie chodzi o mnożenie kopii regulaminu. Chodzi o łatwy dostęp do jednej aktualnej wersji. Sprawdź, czy link prowadzi do strony, na której faktycznie opisano obowiązujące zasady. Widoczna treść, dane strukturalne i Merchant Center powinny mówić dokładnie to samo. Jeśli któraś wersja jest starsza, najpierw wyjaśnij, jakie zasady są rzeczywiste, a dopiero potem aktualizuj oznaczenie.
Jak wdrożyć MerchantReturnPolicy bez kopiowania regulaminu do kodu
Nie trzeba wrzucać całego regulaminu do danych strukturalnych. Chodzi o uporządkowane opisanie konkretnych informacji, które Google może odczytać. Ogólna polityka dotycząca większości albo wszystkich produktów może zostać powiązana z Organization. Wyjątek dotyczący konkretnej oferty rozważa się na poziomie Offer.
Jeżeli polityka organizacji opiera się na określonym oknie zwrotu, trzeba uwzględnić właściwość merchantReturnDays, która przy takim podejściu staje się wymagana. W praktyce nie zaczynaj jednak od wpisywania pól do kodu. Zacznij od dokumentu z ustalonymi zasadami. Kod ma je odzwierciedlać, a nie zgadywać.
Organization i Offer w praktyce
Możesz myśleć o tym tak: Organization opisuje regułę sklepu, a Offer — odstępstwo przy konkretnej ofercie. Polityka oferty ma węższy zakres właściwości, więc nie należy mieszać obu poziomów bez sprawdzenia, co faktycznie ma być opisane.
Przed publikacją porównaj oznaczenie z widoczną stroną polityki i ustawieniami Merchant Center. Jeśli sklep ma różne zasady dla krajów lub grup produktów, jedna ogólna konfiguracja może nie opisać sytuacji poprawnie. I jeszcze jedno: poprawny kod nie gwarantuje rich resultu, konkretnej pozycji ani konkretnego wyglądu informacji w Google.
Test po wdrożeniu: Rich Results Test i Search Console
Po wdrożeniu nie kończ pracy na komunikacie „kod się zapisał”. Trzeba jeszcze sprawdzić, czy strona jest dostępna i czy Google może odczytać dane. Test techniczny nie potwierdza jednak, że regulamin jest zgodny z prawem. Pokazuje przede wszystkim, czy oznaczenie ma problemy, które można poprawić.
Szybka kolejność kontroli
- Uruchom stronę w Rich Results Test i popraw błędy krytyczne.
- Użyj URL Inspection w Google Search Console.
- Sprawdź, czy strona nie jest blokowana przez
robots.txt,noindexalbo wymaganie logowania. - Po zmianach uwzględnij czas potrzebny na ponowne pobranie i przetworzenie strony.
- Porównaj wynik testu z treścią strony oraz konfiguracją Merchant Center.
Warto zachować prostą zasadę: test narzędzia, dostępność strony i zgodność źródeł to trzy różne kontrole. Brak błędu w jednym miejscu nie oznacza automatycznie, że wszystko jest spójne. Google nie gwarantuje też, że dane strukturalne wywołają rozszerzony wynik.
Najczęstsze wtopy i bezpieczne podsumowanie
Najczęściej problem zaczyna się od drobiazgu: innego terminu na stronie produktu, innego kosztu w regulaminie albo wyjątku, o którym zapomniano w Merchant Center. Przed publikacją przejdź przez krótką listę:
- Nie zostawiaj różnych terminów, kosztów ani metod zwrotu w różnych miejscach.
- Nie pomijaj wyjątków dotyczących konkretnych produktów lub grup.
- Nie kopiuj do schema informacji bez potwierdzenia w polityce sklepu.
- Sprawdź stronę, dane strukturalne, Merchant Center oraz dostęp bez logowania.
- Nie traktuj poprawnego testu jako gwarancji rich resultu, widoczności albo sprzedaży.
Najbezpieczniejsza kolejność jest prosta: najpierw spisz rzeczywiste zasady i wyjątki, potem udostępnij jedną publiczną stronę, następnie dopasuj MerchantReturnPolicy, a na końcu sprawdź wdrożenie w Rich Results Test i Search Console. Techniczne oznaczenie nie zastępuje regulaminu ani porady prawnej. Jeśli masz bałagan w sklepie, stronie albo wdrożeniu danych strukturalnych, Napisz do Szwagra i opowiedz, czego potrzebujesz — strony, grafiki, filmu albo tekstów.
