Представете си, че клиент отваря син модел на продукт. Страницата показва една цена, Google Merchant Center е получил друга, а данните за продукта описват червен вариант. За магазина това не са три отделни технически грешки. Това е една неясна оферта, която различните системи разбират по различен начин.
Решението започва от общ източник на продуктови данни. Видимата страница, структурираните данни, Merchant Center и количката трябва да получават една и съща цена, наличност, вариант и идентификатори. Поправка само в една от системите обикновено е временна.
Product Schema е често използваното име за структурираните продуктови данни на страницата. Те описват на машинно четим език продукта и неговата оферта, например име, изображение, цена, валута и наличност. Google обяснява изискванията и възможните представяния в документацията за структурирани продуктови данни.
Merchant Center е мястото, в което магазинът подава и управлява данните за продуктите си за безплатни продуктови представяния и реклами в Google. Данните могат да пристигат чрез файл, автоматично извличане, приложение или Merchant API.
Двете системи не се заменят. Структурираните данни помагат на Google да разбере конкретната продуктова страница. Merchant Center получава организиран набор от продуктови записи. И двете трябва да описват същата оферта, която вижда клиентът.
Валидният код също не е обещание, че Google ще покаже специален резултат. Той е условие за допустимост, а показването зависи и от други изисквания и системи на Google.
Самоличността на продукта е комбинацията, по която човек и система разбират какво точно се продава. Тя включва:
Ако изображението показва един цвят, SKU принадлежи на друг, а цената е за трети размер, записът вече не описва конкретна оферта. Това е по-сериозен проблем от липсващо препоръчително поле, защото клиентът може да получи различен продукт или различни условия от очакваните.
Източникът може да бъде складова система, ERP, WooCommerce или друга платформа за управление на каталога. Важното е всяка критична стойност да има едно определено място, от което се обновява навсякъде.
Практична карта на данните може да изглежда така:
| Данни | Основен източник | Къде трябва да се използват |
|---|---|---|
| Цена и валута | каталог или търговска система | страница, структурирани данни, Merchant Center, количка |
| Наличност | складова система | страница, структурирани данни, Merchant Center, възможност за поръчка |
| SKU | продуктов каталог | правилният продукт или вариант във всички връзки между системите |
| GTIN и MPN | данни от производителя | каталог, структурирани данни и Merchant Center, когато са приложими |
| Изображение | управлявана продуктова галерия | страница и запис за същия вариант в Merchant Center |
Ръчно поле за цена само в източника за Merchant Center създава второ място, което трябва да се поддържа. Ако основният каталог се промени, а това поле остане старо, разминаването е неизбежно.
Не е достатъчно числото да изглежда приблизително правилно. Проверете дали навсякъде съвпадат:
Google изисква подадената цена да съответства на тази на продуктовата страница. Когато на страницата е показана действаща промоционална цена, структурираните данни също трябва да описват нея. Това е обяснено в официалните указания за структурирани данни в Merchant Center.
Чести причини за разлика са стар кеш, забавено обновяване, отделна ръчна цена, неправилно приключила промоция или избор на вариант, който сменя видимата цена, но не обновява останалите данни.
Статусът "в наличност" има смисъл само ако клиентът може да поръча същия продукт или вариант. Проверете едновременно текста на страницата, бутона за покупка, избрания вариант, данните за наличност и поведението на количката.
Merchant Center различава наличен продукт, изчерпан продукт, предварителна поръчка и продукт с отложена доставка. Официалната спецификация на продуктовите данни изисква наличността да съвпада със страницата, процеса на поръчка и структурираните данни.
Когато основният продукт е наличен, но избраният размер е изчерпан, системите трябва да описват избрания размер. Общ статус за цялото продуктово семейство може да подведе клиента и да създаде несъответствие.
Дългосрочното решение за адреса на спрян продукт е отделна тема. Тук задачата е текущият статус да бъде верен навсякъде.
Различните размери, цветове, материали или конфигурации често имат собствена цена, наличност, изображение и SKU. Затова всеки вариант трябва да има уникален идентификатор, а вариантите от едно семейство да бъдат свързани с общ идентификатор на групата.
Google препоръчва всеки вариант да може да бъде отворен в ясно избрано състояние. При отваряне на този адрес трябва да се виждат правилните изображение, цена и наличност, както и да може да се добави правилният вариант в количката. Подробностите са описани в документацията за структурирани данни при продуктови варианти.
Дали магазинът ще използва един адрес с избор на вариант или отделни адреси е решение за структурата на магазина. Независимо от избора, един и същ вариант трябва да остане разпознаваем във всички системи.
Четири често срещани полета имат различни роли:
Google изрично предупреждава да не се подават измислени MPN или други идентификатори. Неправилната стойност може да доведе до неодобрение на продукта. Когато валиден идентификатор липсва, правилното действие е да се следват изискванията за съответната категория, а не да се създава правдоподобно число.
Изберете конкретен продукт и конкретен вариант. След това сравнете четири места:
На всяко място сравнете името, URL адреса, изображението, варианта, SKU, GTIN или MPN, цената, валутата и наличността. При разлика проследете пътя назад до основния източник.
Rich Results Test може да покаже дали структурираните данни са разпознати и дали има критични грешки. Той не доказва, че стойностите съвпадат с каталога, Merchant Center и количката. Тази проверка остава отделна.
Не всички предупреждения имат еднаква тежест. Полезен ред за работа е:
| Приоритет | Проблем | Защо е важен |
|---|---|---|
| Критичен | грешен продукт или вариант | клиентът може да види или поръча друго |
| Критичен | грешна цена, валута или наличност | офертата е различна между системите |
| Висок | невалиден GTIN, MPN, марка или SKU | нарушава се разпознаването на продукта |
| Висок | грешно или остаряло изображение | представя се друг продукт или вариант |
| Следващ | липсващо препоръчително поле | подобрява пълнотата, след като офертата вече е точна |
Този ред не отменя конкретните съобщения в Merchant Center. Той помага първо да се защитят самоличността на продукта и реалните условия за покупка.
Merchant Center може автоматично да коригира определени временни разлики, като използва данните от продуктовата страница. Google посочва, че тези корекции се отнасят до цена, промоционална цена, наличност и състояние на продукта.
Официалното описание на автоматичните корекции на продуктовата информация уточнява, че те не заменят редовното подаване на точни продуктови данни и не обхващат непременно всички продукти. Ако автоматичната корекция постоянно поправя една и съща стойност, основният източник или обновяването между системите остава грешно.
Единична грешна стойност може да се проследи ръчно. При голям каталог проблемът става системен, когато складът, платформата на магазина, разширението за структурирани данни и източникът за Merchant Center се обновяват по различен начин.
Професионална помощ е разумна, когато разминаванията се връщат след всяко обновяване, вариантите се смесват, липсва ясен основен източник или корекциите изискват промени в каталога и техническата свързаност между системите.
При SEO оптимизация за онлайн магазин продуктовите данни се проверяват заедно със структурата на каталога, продуктовите страници и техническата работа по магазина. Целта не е просто валиден код, а една и съща надеждна оферта за клиента и за всяка система, която я използва.
