Покупатель видит в карточке новую цену, а структурированные данные по-прежнему содержат старую. Или кнопка сообщает «Нет в наличии», тогда как в JSON-LD записано InStock. Проверять такую ошибку нужно по конкретному товару и состоянию страницы: общий зелёный результат валидатора ещё не подтверждает согласованность предложения.
Для магазина важна цепочка из трёх представлений: данные каталога, видимая карточка и разметка, которую получает поисковая система. Ниже — порядок проверки этой цепочки после импорта, изменения цены или обновления шаблона. Учебные значения служат примером; они не описывают результаты проверки действующего магазина.
Выберите товар и состояние, которые сравниваете
Запишите полный адрес карточки, артикул и выбранный вариант. Товар с несколькими размерами может иметь разные остатки; переключение варианта меняет предмет сравнения. Если в интерфейсе выбран размер M, а JSON-LD относится к общей модели или размеру S, сначала выясните принятую модель разметки. Сравнивать эти цены без уточнения нельзя.
Откройте карточку без авторизации и зафиксируйте валюту, регион доставки, активную акцию и время. Персональная скидка участника программы лояльности не обязательно является общедоступной ценой. Команда должна заранее определить, какое предложение описывает публичная страница. Это решение особенно важно, если посетитель выбирает город, а каталог переключает склад и стоимость.
Для исходной выборки возьмите четыре товара: обычный доступный, акционный, временно отсутствующий и имеющий варианты. У каждого сохраните один определённый сценарий. Такой набор позволяет проверить разные ветки генератора и заметить, что исправление доступного товара испортило статус отсутствующего.
Составьте таблицу фактов из трёх источников
Начните с источника каталога: какой остаток и цена записаны в CMS или учётной системе? Затем прочитайте видимую карточку и содержимое JSON-LD. Укажите время получения каждого результата. Если импорт выполнялся между наблюдениями, сначала повторите измерение после его завершения.
| Учебный товар | Данные каталога | Видимая карточка | JSON-LD | Предмет проверки |
|---|---|---|---|---|
| A-101 | 12 900 RUB, доступен | 12 900 ₽, можно заказать | 11 900 RUB, InStock | Откуда взялась старая цена |
| A-102 | 8 500 RUB, остаток ноль | 8 500 ₽, нет в наличии | 8 500 RUB, InStock | Как вычисляется наличие |
| A-103 | 6 000 RUB по акции | 6 000 ₽, старая цена зачёркнута | 7 000 RUB | Какое предложение опубликовано |
Зачёркнутая цена и текущая стоимость покупки выполняют разные функции. Не переносите произвольно первое найденное число в offers.price. Доставка, рассрочка и ежемесячный платёж также требуют отдельной интерпретации. Для каждой цифры в задаче напишите, что именно она означает покупателю.
Прочитайте разметку в исходнике и после загрузки
Найдите блоки application/ld+json в исходном HTML. Затем проверьте DOM после выполнения JavaScript: приложение или плагин может добавить ещё один объект Product. Сохраните оба результата. По одной вставке из панели Elements трудно понять, какой набор данных был выдан сервером и что изменил браузер.
В упрощённом учебном предложении поля могут выглядеть так:
{
"@type": "Offer",
"url": "https://shop.example/product/a-101/",
"price": "12900.00",
"priceCurrency": "RUB",
"availability": "https://schema.org/InStock"
}Это фрагмент предложения, а не полная готовая разметка магазина. В рабочем Product нужны свойства, подходящие вашему типу страницы. Начальные требования к вариантам товарного представления описаны в документации Google о Product.
Проверьте также ссылки между объектами через @id. Разметка может содержать несколько предложений и вариант товара; найденное число относится к конкретному объекту. Сопоставьте его адрес и артикул с выбранной карточкой, прежде чем объявлять расхождение ошибкой всего каталога.
Найдите независимые источники обновления
Распространённая схема сбоя: видимая цена берётся из свежего API, а JSON-LD встроен в закешированный HTML. Другой вариант — SEO-плагин хранит собственные поля, которые не обновляет импорт. Проверять следует конкретную реализацию магазина: совпадение симптома не доказывает источник проблемы.
Попросите разработчика показать, откуда формируются цена, валюта и наличие в каждом представлении. Укажите имя поля каталога и преобразование статуса остатка. Например, система может различать «на складе», «под заказ» и «снят с продажи», а шаблон сводит их к одному логическому значению. Такое упрощение нужно согласовать с фактическим предложением.
Если причина в кеше, определите, какие записи должны обновляться после изменения товара: HTML карточки, данные API, разметка и связанные варианты. Не ограничивайтесь ручной очисткой одной страницы. Повторите обычный импорт и убедитесь, что согласованность сохраняется без дополнительных действий администратора.
Проверьте акции и варианты отдельно
Для акции сохраните время начала и окончания, текущую публичную цену и условия доступа. Проверьте карточку до изменения, во время действия и после завершения по согласованному сценарию. Дата в шаблоне сама по себе не переключает цену: нужно подтвердить фактический ответ страницы.
У варианта товара сравните прямой URL и выбор через интерфейс. Уточните, меняется ли адрес при переключении цвета или размера. Если несколько состояний используют один URL, запишите, какое состояние открывается по умолчанию. Это позволит объяснить, почему робот и посетитель после переключения видят разные значения.
Проверьте пустой остаток, доступность по предзаказу и отменённую акцию. Не заменяйте все статусы одним InStock ради прохождения проверки. Разметка должна описывать реальное предложение, а неоднозначную модель следует обсудить с разработчиком каталога и специалистом по структурированным данным.
Примите исправление повторным изменением товара
Первый критерий — совпадение выбранного предложения в каталоге, карточке и JSON-LD. Второй — сохранение этого совпадения после обычного изменения данных. На тестовом или согласованном контрольном товаре измените цену, выполните штатное обновление и снова получите публичную страницу.
Проверьте каждую строку исходной выборки. Укажите фактическую цену, валюту, статус наличия, время и полученный объект разметки. Отдельно отметьте, появился ли второй конфликтующий Product. Для технической части пригодятся разбор ошибок Schema.org и руководство по структурированным данным.
Синтаксис и согласованность — разные проверки. JSON может успешно разбираться, но содержать устаревшую цену. Обратная ситуация тоже возможна: числа верны, а повреждённая структура мешает прочитать предложение. Сохраняйте отдельный результат по каждому условию.
Отделите исправление страницы от изменения поиска
После публикации сохраните свежий HTML и дату приёмки. Поисковая система могла ещё не перечитать страницу, поэтому прежнее значение в выдаче не доказывает, что новая реализация не работает. Сначала подтвердите текущий публичный ответ, затем наблюдайте обработку URL в инструментах вебмастера.
Результат исправления формулируется предметно: у проверенных товаров цена и наличие согласованы, штатное обновление сохраняет согласованность, конфликтующих объектов нет. Обещание расширенного сниппета или роста продаж из этого результата не следует.
Закрепите проверку в процессе импорта
Добавьте контрольные товары в лист приёмки каждого изменения импорта и шаблона. Назначьте человека, который проверяет публичную карточку после обновления, и сохраните набор ожидаемых состояний. При добавлении нового склада, валюты или типа акции обновите саму выборку.
Для первичной проверки технических данных используйте аудит страницы reChecker. Затем сопоставьте найденную разметку с каталогом и видимым предложением вручную. Именно проверка всей цепочки защищает от ситуации, когда один источник обновился, а покупатель и поисковая система продолжают получать разные сведения.