Product Schema и Merchant Center: как да поддържате последователни продуктови данни

Един продукт може да има правилна цена на страницата, стара наличност в Merchant Center и различен идентификатор в structured data. За клиента това изглежда като объркваща оферта. За Google това е несъответствие между няколко източника на продуктова информация.

Проблемът рядко се решава само с добавяне на Product Schema или с повторно изпращане на feed-а. Необходимо е магазинът да има един надежден източник на продуктови данни и ясен процес, по който страницата, structured data и Merchant Center се обновяват последователно.

Това ръководство обяснява как да организирате тази система, какво да проверявате и как да приоритизирате грешките, без да смесвате продуктовото съдържание с техническия слой на продуктовите данни.

Най-важното накратко

• Product Schema описва продукта и офертата в машинно четим формат на самата страница.
• Merchant Center получава продуктови данни чрез feed, автоматично извличане, API или комбинация от източници.
• Видимата продуктова страница остава основният източник, който клиентът вижда и използва за покупка.
• Цена, валута, наличност, идентификатори, изображения, доставка и връщане не трябва да си противоречат между тези слоеве.
• Structured data може да даде eligibility за по-богато представяне, но не гарантира показване.
• Merchant Center предупрежденията не са еднакво важни. Грешната цена или грешният вариант са по-критични от липсващо препоръчително поле.

Product Schema, Merchant Center и продуктовият feed не са едно и също

Трите понятия често се използват като взаимозаменяеми, но имат различни роли.

Product Schema

Product structured data е машинно четимо описание, добавено към конкретна продуктова страница. То може да съдържа информация за:

• името на продукта;
• изображенията;
• марката;
• SKU, GTIN или MPN;
• офертата;
• цената и валутата;
• наличността;
• състоянието на продукта;
• доставка и връщане;
• оценки и ревюта, когато са реални и допустими.

Google препоръчва merchant listing markup за страници, от които клиентът може да купи конкретен продукт или негови варианти. Категорийна страница с много различни продукти не е еквивалент на конкретна продуктова оферта.

Merchant Center

Merchant Center е системата, чрез която търговецът предоставя и управлява продуктови данни за различни Google представяния и рекламни или безплатни shopping възможности.

Там могат да се появят проблеми като:

• несъответствие в цената;
• несъответствие в наличността;
• липсващи или невалидни идентификатори;
• проблемни изображения;
• неправилно групирани варианти;
• липсващи условия за доставка;
• policy или destination ограничения.

Продуктов feed

Feed-ът е структуриран източник на данни, който подава продуктите към Merchant Center. Той може да бъде файл, API интеграция, автоматичен източник или комбинация от методи.

Feed-ът не трябва да се превръща във втора независима база данни, която живее отделно от сайта. Колкото повече ръчни и несвързани източници съществуват, толкова по-голям е рискът един продукт да има различни стойности в различните системи.

Определете един източник на истина за продуктовите данни

Най-важното архитектурно решение не е кой плъгин да генерира Schema. То е откъде идва всяка стойност и кой отговаря за нея.

За всеки критичен атрибут трябва да можете да отговорите:

1. Къде се създава стойността?
2. Къде се съхранява?
3. Как се показва на продуктовата страница?
4. Как влиза в Product structured data?
5. Как влиза в Merchant Center?
6. Колко често се променя?
7. Кой проверява и коригира грешките?

Например цената може да идва от ERP или WooCommerce, да се визуализира на страницата, да се използва от JSON-LD и да се изпраща към Merchant Center. Ако feed-ът има отделно ръчно поле за цена, вече съществува възможност за разминаване.

Карта на потока на продуктовите данни

Практичната карта може да изглежда така:

Таблицата не е документация заради самата документация. Тя показва къде може да възникне несъответствие и кой трябва да го поправи.

Какви данни трябва да описват една последователна продуктова оферта

Една оферта е последователна, когато клиентът и системите виждат един и същ продукт, вариант и търговски условия.

Основните елементи са:

• точна product identity;
• правилен URL;
• конкретен вариант, когато има варианти;
• заглавие, което описва същия продукт;
• валидна цена и валута;
• реална наличност;
• правилно състояние: нов, употребяван или refurbished;
• съответстващи изображения;
• марка и продуктови идентификатори;
• ясни условия за доставка и връщане.

Проверка за последователност на продуктовите данни

Изберете един реален продукт и сравнете едновременно:

1. Видимата информация на страницата.
2. Product structured data в rendered HTML.
3. Данните, които Merchant Center е получил.
4. Реалното поведение при добавяне в количката.

Проверете следните полета:

• product name;
• URL;
• selected variant;
• цена;
• валута;
• availability;
• SKU;
• GTIN или MPN;
• brand;
• основно изображение;
• доставка;
• връщане.

Ако страницата показва промоционална цена, но structured data или feed-ът подават старата редовна цена, системата не е последователна. Ако URL адресът отваря син вариант, но изображението и SKU описват червен вариант, проблемът е още по-сериозен, защото се променя самата продуктова идентичност.

Цена и валута

Цената е един от най-чувствителните атрибути. Тя трябва да е:

• видима на landing page;
• достъпна без необходимост от скрити действия;
• същата в structured data;
• същата в Merchant Center;
• свързана с правилната валута;
• свързана с правилния вариант;
• актуална при промоции и изтичане на промоции.

Чести причини за несъответствие:

• кеширана страница;
• отделно обновяване на feed-а;
• промоционална цена, която не е изтекла навсякъде;
• цена без ДДС в една система и с ДДС в друга;
• различни валути или автоматично конвертиране;
• variant selector, който сменя визуалната цена, но не обновява structured data;
• JavaScript цена, която не присъства коректно в rendered output.

При диагностика първо проверете дали грешката е в основния източник, в трансформацията към страницата или в трансформацията към feed-а. Не коригирайте само крайния export, ако източникът остава грешен.

Наличност и състояние на офертата

Наличността трябва да описва какво реално може да купи клиентът.

Не е достатъчно product page да показва „в наличност“, ако:

• бутонът не позволява покупка;
• конкретният вариант е изчерпан;
• срокът за доставка е несъвместим с обещанието;
• Merchant Center получава out_of_stock;
• structured data описва друга конфигурация.

Трябва да се разграничават:

• наличен за директна покупка;
• временно изчерпан;
• предварителна поръчка;
• backorder;
• спрян или окончателно недостъпен продукт.

Дългосрочното решение какво да се случи с URL адреса на спрян продукт принадлежи на отделния owner за изчерпани и спрени продукти. Тук фокусът е данните да описват вярно текущото състояние.

Brand, GTIN, MPN и SKU

Идентификаторите помагат един продукт да бъде разпознат последователно между системите.

Brand

Марката трябва да бъде реалната марка на продукта, а не името на магазина, освен когато магазинът действително е производителят или брандът.

GTIN

GTIN трябва да се използва само когато е валидно присвоен от производителя. Не генерирайте измислени стойности, за да запълните поле.

MPN

MPN е производственият номер на продукта. Той може да бъде важен, когато няма GTIN или когато идентичността на продукта изисква manufacturer part number.

SKU

SKU е вътрешен идентификатор на търговеца. Той трябва да остане стабилен и да съответства на правилния продукт или вариант.

Варианти и item group relationships

При продуктови варианти данните трябва да разграничават:

• основното продуктово семейство;
• конкретния вариант;
• стабилния identifier на варианта;
• общата група на вариантите;
• размер, цвят, материал или конфигурация;
• URL адреса на избрания вариант;
• цена и наличност за същия вариант.

Решението дали вариантите използват един URL или отделни URL адреси принадлежи на owner-а за продуктови вариации. Product data layer трябва да изпълни това решение последователно.

Критичен дефект е един URL да подава:

• изображение за един цвят;
• SKU за втори цвят;
• цена за трети размер;
• availability за основния продукт, а не за избрания вариант.

Изображенията са продуктови данни, не само дизайн

Основното изображение трябва да представя същия продукт и вариант, който се продава на landing page.

Проверете:

• дали изображението е достъпно за Google;
• дали URL адресът е стабилен;
• дали няма placeholder или счупен файл;
• дали основният кадър съответства на избрания вариант;
• дали изображението не съдържа подвеждащи елементи;
• дали качеството и размерите са достатъчни;
• дали feed-ът не сочи стара версия на файла.

През април 2026 г. Google обяви бъдещо увеличение на минималната резолюция за изображенията в Merchant Center до 500 × 500 px, с предупреждения през 2026 г. и enforcement от 31 януари 2027 г. Това не означава, че 500 × 500 е оптимален creative стандарт. Практическият извод е да не изграждате каталог около малки и трудно заменяеми изображения.

Доставка и връщане

Shipping и return information могат да присъстват в различни слоеве:

• видима информация на продуктовата страница;
• site-wide policy страници;
• Product или Offer structured data;
• Merchant Center account settings;
• product-level shipping attributes.

Тези слоеве трябва да си съответстват.

Проблем възниква, когато страницата обещава безплатна доставка, а Merchant Center получава платена доставка, или когато срокът за обработка и доставка не отговаря на реалната операция.

През 2026 г. Google добави нови product-level shipping възможности, включително handling cutoff time и minimum order value. Използването им трябва да следва реалните бизнес правила, а не да създава обещания, които магазинът не може да изпълни.

Structured data и feed могат да се допълват, но не трябва да си противоречат

Structured data помага на Google да разбере информацията на landing page. Feed-ът предоставя организирани продуктови данни към Merchant Center.

Не трябва да мислите за тях като за конкуриращи се методи. При добре организиран магазин те използват един и същ източник на данни и се проверяват взаимно.

Когато има конфликт, трябва да се открие причината:

• стар feed;
• кеширана страница;
• грешна трансформация;
• variant mismatch;
• различни product IDs;
• ръчна корекция само в едната система;
• различен shipping или tax configuration.

Product Schema не гарантира rich result

Валидният markup означава, че страницата може да бъде eligible за определени представяния. Това не означава, че Google е длъжен да ги покаже.

Не оценявайте успеха само по това дали виждате rich result за конкретна заявка. Следете:

• валидност на structured data;
• coverage;
• Merchant Center approval;
• accuracy на данните;
• impressions и clicks;
• product-level performance;
• честота на mismatch грешките.

Чести Merchant Center проблеми и как да ги приоритизирате

1. Грешна цена или наличност

Това е критичен проблем, защото засяга самата оферта. Проверете source-of-truth, cache, variant selection и feed refresh.

2. Грешен продукт или вариант

Проверете URL, title, image, SKU, GTIN, item group и selected state. Това е identity проблем, не просто липсващо поле.

3. Невалидни идентификатори

Не заменяйте липсващ GTIN с измислена стойност. Проверете данните от производителя и правилата за конкретната продуктова категория.

4. Проблемни изображения

Проверете достъпността, качеството, съответствието с продукта и дали image URL не е променен или блокиран.

5. Липсващи shipping или return данни

Проверете дали информацията е конфигурирана на правилното account или product ниво и дали съответства на сайта.

6. Препоръчителни полета

Те могат да подобрят пълнотата, но не трябва да изместват критичните проблеми с identity, price и availability.

Матрица за приоритизация на грешките

Практичен workflow за внедряване

Стъпка 1: Картирайте източниците

Опишете откъде идва всяко критично поле и кой го притежава.

Стъпка 2: Изберете представителни продукти

Проверете поне:

• прост продукт;
• продукт с варианти;
• продукт в промоция;
• временно изчерпан продукт;
• продукт с доставка или специални условия.

Стъпка 3: Сравнете четирите слоя

• видима страница;
• rendered structured data;
• Merchant Center data;
• cart and checkout behavior.

Стъпка 4: Поправете източника, не само export-а

Когато грешката идва от продуктовия каталог или ERP, поправката трябва да започне там.

Стъпка 5: Валидирайте

Използвайте:

• Rich Results Test;
• URL Inspection;
• Merchant Center Needs attention;
• реална проверка на landing page;
• тестова покупка или добавяне в количката;
• сравнение на конкретния product ID.

Стъпка 6: Следете промените

Цената, наличността и промоциите се променят често. Необходим е автоматизиран или периодичен контрол, а не еднократна проверка.

Какво да измервате

Полезните показатели включват:

• процент одобрени продукти;
• брой и дял на disapproved продукти;
• price mismatch rate;
• availability mismatch rate;
• продукти без валидни identifiers;
• structured data errors и warnings;
• продукти с variant inconsistency;
• време за отстраняване на критична грешка;
• impressions, clicks и commercial outcomes по продукт.

Не смесвайте корелация и причинност. Повече валидни полета не гарантират автоматично повече продажби. Целта е Google и клиентът да получават точна, пълна и последователна оферта.

Практичен checklist за Product Schema и Merchant Center

Source of truth

• [ ] Всеки критичен атрибут има основен източник.
• [ ] Има определен собственик на данните.
• [ ] Няма ръчни независими цени или наличности в няколко системи.

Product identity

• [ ] URL, title, image и identifiers описват един и същ продукт.
• [ ] Вариантите имат стабилни IDs.
• [ ] Brand, GTIN, MPN и SKU не са измислени или разменени.

Offer

• [ ] Цена и валута съвпадат.
• [ ] Availability отговаря на реалната покупка.
• [ ] Промоционалните периоди са синхронизирани.
• [ ] Shipping и returns не си противоречат.

Technical validation

• [ ] Structured data е валидно в rendered output.
• [ ] Merchant Center няма критични mismatch грешки.
• [ ] Основните изображения са достъпни и актуални.
• [ ] Feed refresh и cache behavior са проверени.

Monitoring

• [ ] Критичните грешки имат alert или редовна проверка.
• [ ] Има процес за corrections и повторна валидация.
• [ ] Промените се тестват върху реални продукти и варианти.

Кога ви е необходима професионална помощ

Професионална намеса е оправдана, когато:

• хиляди продукти имат различни източници на данни;
• Merchant Center редовно отчита price или availability mismatch;
• вариантите се смесват между URL, image, SKU и feed;
• structured data се генерира от отделен плъгин без връзка с основния каталог;
• ERP, WooCommerce, feed и Merchant Center се обновяват с различен ритъм;
• предупрежденията се поправят ръчно, но се връщат след следващия sync.

При цялостна SEO оптимизация за онлайн магазин продуктовите данни трябва да се разглеждат заедно със структурата, категориите, продуктовите страници и техническата поддръжка. При изграждане на нов магазин тази основа трябва да бъде заложена още в изработката на онлайн магазина, а не да се добавя след като каталогът вече съдържа хиляди несъгласувани записи.

Често задавани въпроси

Product Schema и Merchant Center едно и също ли са?

Не. Product Schema е structured data на продуктовата страница. Merchant Center е платформа за предоставяне и управление на продуктови данни. Те трябва да използват последователна информация, но изпълняват различни функции.

Задължителен ли е продуктов feed?

Конкретният метод зависи от Merchant Center setup-а и мащаба на магазина. При голям и динамичен каталог е необходим надежден автоматизиран източник, който се обновява последователно.

Product Schema гарантира ли rich results?

Не. Валидният markup дава eligibility, но Google решава дали и как да покаже по-богато представяне.

Кое е по-важно: structured data или feed?

По-важно е видимата страница, structured data и Merchant Center да описват една и съща оферта. Изборът не трябва да бъде „едното или другото“.

Какво трябва да поправя първо в Merchant Center?

Първо грешната цена, availability и product identity. След това identifiers, policy или destination disapprovals, изображения и липсващи допълнителни данни.

Трябва ли категориите да имат Product Schema?

Merchant listing guidance е насочена към страници за конкретен продукт или варианти на същия продукт, а не към общи категории с различни продукти.

Как се изгражда надеждна система за продуктови данни

Product Schema и Merchant Center не са отделни SEO отметки. Те са части от една система за продуктови данни.

Устойчивият подход започва с един източник на истина, ясни собственици на атрибутите и последователност между страницата, structured data, feed-а и реалната покупка. Когато тези слоеве описват един и същ продукт, вариант и оферта, диагностицирането е по-бързо, рискът от disapprovals е по-нисък, а клиентът получава по-надеждна информация.