Чекліст доказів сторінки товару: шаблон

Чекліст доказів сторінки товару (для заповнення)

Коли використовувати: Один рядок на кожне твердження: показане значення, джерело істини, значення у фіді, властивість структурованих даних, відповідальний і статус, плюс фінальна перевірка.

Чекліст доказів сторінки товару

Один рядок на кожне твердження, яке робить сторінка. Для кожного рядка потрібне джерело істини, а сторінка, фід і структуровані дані мають показувати те саме.

Деталі по кожному рядку (заповніть для всіх)

• Джерело характеристики: [документ або система, версія, дата перевірки]
• Де з'являється твердження: [назва, список переваг, таблиця характеристик, зображення, FAQ, JSON-LD]
• Як оновлюється: [наживо із системи / нічна синхронізація / ручне редагування]
• Знайдена розбіжність: [на сторінці X, у фіді Y, у розмітці Z]
• Виправлення: [змінити сторінку / змінити фід / змінити розмітку / змінити джерело]
• Дата перевірки: [РРРР-ММ-ДД]

Наступний крок

• Відповідальний: [ім'я] - дія: [виправити перший рядок зі статусом «Виправити» або «Відсутнє»] до [дата]
• Власник даних: [керівник мерчандайзингу або операційного відділу] - дія: підтвердити, що кожне джерело істини справді змінюється першим
• Розробник: [ім'я] - дія: [оновити шаблон JSON-LD, щоб він брав дані з тих самих полів, що й сторінка]

Фінальна перевірка

• Кожне твердження на сторінці має назване джерело істини та дату перевірки.
• Ціна, валюта та наявність однакові на сторінці, у фіді та в розмітці.
• Кожен варіант має власний ідентифікатор, а його URL показує правильне зображення, ціну й наявність.
• Доставка та повернення на сторінці збігаються з налаштуваннями, які Google читає в першу чергу.
• Усе, що є в структурованих даних, видно на сторінці.
• Жоден рядок не має статусу «Виправити» чи «Відсутнє» без відповідального та дати.

Реєстр джерел істини

Коли використовувати: Визначте одну систему, якій належить кожен факт про товар, хто може його змінювати і як він потрапляє на сторінку.

Одне джерело істини для кожного факту

Більшість помилок на сторінках товарів з'являється, коли той самий факт зберігається у двох системах. Оберіть ту, що змінюється першою. Усе інше, зокрема сторінка, має брати дані з неї.

Характеристики: що вважати джерелом

• Надійне: специфікація виробника з версією або датою, ваш власний вимір із зазначенням, хто міряв, сертифікат, який у вас є.
• Слабке: картка товару конкурента, старий каталог, копія вашої ж сторінки на маркетплейсі.
• Не джерело: «ми так думаємо», лист від постачальника без вкладення, опис, написаний ШІ.

Правила

• Якщо сторінка і джерело розходяться, спершу виправте джерело, а потім дайте сторінці оновитися.
• Текст, написаний вручну (списки переваг, FAQ, текст на зображеннях), потребує окремої перевірки. Він не оновлюється, коли змінюються дані.
• Записуйте дату перевірки. Характеристика, правдива минулого сезону, може вже бути неактуальною.

Перепишіть слабкий або скопійований опис характеристик в інструменті Content Optimizer, а потім поверніться й запишіть джерело для кожного числа, яке в ньому залишилося.

Перевірка узгодженості структурованих даних

Коли використовувати: Оберіть розмітку сніпета товару або оголошення продавця, а потім звірте кожну властивість із тим, що показує сторінка.

Сніпет товару чи оголошення продавця?

У Google є два види структурованих даних Product. Оберіть потрібний, перш ніж перевіряти властивості. Перевірено в Google Search Central 7 листопада 2026 року.

Звірте кожну властивість зі сторінкою

Що кажуть правила Google

• Не розмічайте контент, який не бачать читачі сторінки.
• Структуровані дані мають правдиво відображати вміст сторінки.
• Google може спробувати перевірити дані про товар з оголошення продавця, перш ніж показати їх у результатах пошуку.
• Якщо ви продаєте в кількох валютах, використовуйте окремий URL для кожної валюти.

Створіть JSON-LD за допомогою Schema Markup Generator. Для повної перевірки розмітки перед запуском скористайтеся шаблоном брифу з перевірки структурованих даних.

Варіанти, наявність і доставка

Коли використовувати: Перевірте ідентифікатори та URL варіантів, значення наявності та те, де Google читає ваші правила доставки й повернення.

Варіанти

Саме у варіантах сторінка найчастіше розходиться з даними. Вибір розміру показує одне, а розмітка - інше. Перевіряйте кожен варіант, а не лише стандартний.

• ID групи: [productGroupID або inProductGroupWithID] - Google вимагає одне з них. Якщо задано обидва, вони мають збігатися.
• ID варіантів: [окремий sku або gtin для кожного варіанта] - кожен варіант потребує унікального ідентифікатора в розмітці.
• URL варіантів: [?size=26] - кожен варіант має відкриватися вже вибраним за окремим URL і показувати власне зображення, ціну та наявність.
• Чим відрізняються: [розмір, колір, матеріал] - для ProductGroup рекомендовано variesBy і hasVariant.
• Одна сторінка чи окрема сторінка для кожного варіанта: [одна / кілька сторінок] - якщо сторінок кілька, кожна потребує повної, самодостатньої розмітки.

Наявність

• Показане повідомлення про наявність: [Є в наявності / Залишилося 3 шт. / Передзамовлення / Немає в наявності]
• Значення schema.org: [InStock / LimitedAvailability / PreOrder / BackOrder / OutOfStock]
• Значення у фіді: [in_stock / out_of_stock / preorder / backorder]
• Інтервал синхронізації між складом, сторінкою та фідом: [у реальному часі / щогодини / щодня]

Доставка та повернення

Google рекомендує задати одні правила доставки й одні правила повернення для всього магазину в розмітці Organization. shippingDetails або hasMerchantReturnPolicy в Offer використовуйте лише для винятків.

Google застосовує такий порядок, від найвагомішого: налаштування Content API for Shopping, потім Merchant Center або Search Console, потім розмітка товару, потім розмітка Organization.

• Показані тариф і регіони доставки: [тариф, країни]
• Показані час обробки та час доставки: [дні]
• Показані строк, спосіб і вартість повернення: [дні, поштою / у магазині, безкоштовно чи платно]
• Де їх читає Google: [Search Console / Merchant Center / розмітка Organization / розмітка Offer]
• Чи скрізь вказано одне й те саме? [Так / Ні, опишіть розбіжність]

Якщо доставку задано і в Search Console, і в розмітці, Google використовує лише Search Console. Спершу виправте налаштування, а не тільки JSON-LD.

Аудит відповідності Merchant Center і фіду

Коли використовувати: Порівняйте ціну, валюту, наявність та ідентифікатори в HTML сторінки, у фіді та в JSON-LD.

Аудит: сторінка, фід і розмітка

Merchant Center порівнює ваші дані про товари з цільовою сторінкою. Через розбіжність товар можуть відхилити, тому звіряйте всі три джерела поруч.

Що каже Довідка Merchant Center

• Ціни в HTML мають точно збігатися з цінами, завантаженими в Merchant Center.
• Googlebot читає HTML, який повертає ваш сервер. Ціна, яку JavaScript додає після завантаження сторінки, може спричинити помилку.
• Google використовує структуровані дані, щоб розуміти ціни на цільових сторінках, тому помилкова розмітка може призвести до розбіжності.
• Наявність у ваших даних про товари має збігатися з цільовою сторінкою. Якщо в багатьох товарів вона вказана неправильно, акаунт можуть заблокувати.

Типові причини, які варто перевірити

• Фід оновлюється раз на день, а залишки змінюються щогодини.
• На сторінці показано ціну зі знижкою, а у фіді досі стара ціна.
• JSON-LD показує стандартний варіант, а сторінка - інший.
• Ціну підставляє JavaScript, тому в HTML ціни немає або вона застаріла.

Проскануйте URL товарів за допомогою Website Audit, щоб знайти сторінки з відсутньою або зламаною розміткою, а потім перевірте заголовки та описи в інструменті On-Page SEO.

Заголовок таблиці (CSV)

Коли використовувати: Готовий рядок заголовків і допустимі значення, щоб вести чекліст у Google Sheets або Excel.

Готовий заголовок таблиці

Вставте цей рядок у клітинку A1 у Google Sheets або Excel, а потім розділіть текст на стовпці за комою. Один рядок на кожне твердження для кожного URL товару.

product_url,variant_sku,claim_type,value_on_page,source_of_truth,source_ref,feed_value,markup_property,markup_value,where_google_reads_it,result,fix,owner,status,date_checked

Допустимі значення

• claim_type: spec, price, sale_price, currency, availability, variant, shipping, returns, rating, review, image
• where_google_reads_it: content_api, merchant_center, search_console, offer_markup, organization_markup, page_only
• result: match, mismatch, missing_on_page, missing_in_feed, missing_in_markup
• status: ok, fix, missing, blocked

Поради щодо таблиці

• Додайте випадні списки (перевірка даних) для claim_type, result і status.
• Додайте формулу, яка позначає рядок, якщо value_on_page, feed_value і markup_value не однакові.
• Для щотижневого перегляду відфільтруйте status = fix і відсортуйте за owner.
• Зберігайте в source_ref посилання на специфікацію, екран налаштувань або сторінку правил.

Заповнений приклад (вигаданий магазин посуду)

Коли використовувати: Заповнений чекліст для вигаданої сковороди трьох розмірів: чотири розбіжності та їх виправлення.

Заповнений приклад: Cobblemarsh Kitchen, сковорода Thornquay

Лише приклад. Cobblemarsh Kitchen, сковорода Thornquay, Brindlefen Foundry, а також усі URL, ціни та висновки нижче вигадані, щоб показати заповнений чекліст.

Сторінка: /skillets/thornquay-cast-iron/ із трьома розмірами (20, 26 і 30 см). Магазин продає напряму, тому використовує розмітку оголошення продавця.

Що виявив чекліст

• Вагу взяли зі старого каталогу. Тепер сторінка показує 2,4 кг і посилається на специфікацію v3.
• Ціну зі знижкою додавав JavaScript після завантаження, тому в HTML і JSON-LD залишалася стара ціна, а фід так і не оновили. Тепер ціна рендериться на сервері з ERP.
• JSON-LD завжди брав статус наявності розміру 20 см. Тепер кожен варіант бере власні залишки.
• Текст на сторінці обіцяв швидшу відправку, ніж зазначено в налаштуваннях доставки. Тепер там написано 2-3 дні.

Чому це працює

• Тепер кожен факт має одного відповідального й одну систему, тож наступна зміна оновить усе одразу.
• Виправлення внесли в джерело та шаблон, а не лише на одну сторінку.
• Покупці бачать ту саму обіцянку на сторінці, у Google і під час оформлення замовлення.

Хочете, щоб сторінки товарів і фіди даних одразу будувалися саме так? Перегляньте розробку інтернет-магазинів або запишіться на безкоштовну консультацію з Анатолієм Улітовським.