Price and Availability in Microdata Disagree with the Page: What to Check on a Product

На карточке товара написано «в наличии», в исходном коде микроразметки остался статус предзаказа, а в товарном фиде ещё живёт вчерашняя цена. Для покупателя это один товар. Для магазина — несколько представлений, обновлённых разными процессами и в разное время. Вот тут интересно: исправить одно поле мало, если остальные снова разойдутся после следующего обмена.

Я бы начала не с повторной проверки валидатором, а с вопроса: какое значение сейчас считается окончательным для выбранного торгового предложения и кто обязан передать его во все каналы. Валидная разметка может быть устаревшей по смыслу. И наоборот, совпадение сегодня ещё не доказывает, что цепочка выдержит смену цены или остатка завтра.

Инструмент проверки расширенных результатов отвечает на важный, но узкий вопрос: распознаёт ли Google поддерживаемые типы и свойства. Он не знает договорённостей внутри магазина, не выбирает владельца цены и не подтверждает, что видимое значение уже прошло через все кэши.

Для товара существенны как минимум цена и доступность предложения. Микроразметка должна описывать содержание этой страницы и тот вариант, который пользователь действительно открыл. Добавление Product или Offer лишь делает страницу подходящей для соответствующего формата в поиске; показ расширенного результата не гарантируется.

• Синтаксическая проверка: свойства распознаны, обязательные поля заполнены, значения имеют допустимый формат.
• Смысловая проверка: разметка описывает видимый товар и выбранный вариант, а цена и наличие совпадают.
• Операционная проверка: после обновления источника все представления получают новое значение в ожидаемое время.

В простом магазине уже есть видимая карточка, серверный или клиентский JSON-LD и товарный фид. Добавьте выбранный размер или цвет, кэш страницы и кэш поискового робота — получится небольшая распределённая система, хотя на экране всего одна кнопка покупки.

Полезно нарисовать маршрут двух полей отдельно. Цена может приходить из 1С или ERP, затем рассчитываться с учётом типа цены и акции. Наличие может начинаться с физического остатка, уменьшаться на резервы и только после этого становиться доступным к продаже. Если оба поля собирает шаблон карточки, а JSON-LD формирует другой модуль, расхождение появляется не из-за «плохой микроразметки», а из-за двух логик расчёта.

У вариативного товара фраза «цена товара» слишком расплывчата. Красная куртка размера M может стоить иначе, чем синяя размера XL, а часть вариантов уже закончилась. Если URL или состояние страницы предвыбирает конкретный вариант, его изображение, цена и доступность должны соответствовать именно ему и позволять добавить его в корзину.

Типичная ошибка возникает, когда видимая часть страницы переключается без перезагрузки, а JSON-LD остаётся от варианта по умолчанию. Покупатель видит новую цену, робот — старое предложение. Другая версия той же ошибки: разметка сообщает диапазон или минимальную цену, но страница открывается на недоступном варианте с другой суммой.

Не стоит автоматически склеивать варианты в одну запись только потому, что у них общее название. Сначала зафиксируйте постоянный идентификатор торгового предложения, способ выбора варианта и адрес, по которому этот вариант доступен. Название и позиция в списке для такой связи ненадёжны.

• Страница и JSON-LD читают разные типы цены или разные склады.
• Видимая карточка обновляется в браузере, а разметка остаётся в первоначальном HTML.
• Фид выгружается по расписанию и закономерно отстаёт от оперативного остатка.
• Кэш страницы очищается по товару, но не по связанному торговому предложению.
• Акция закончилась, однако старое значение сохранилось в одном из вычисляемых полей.
• Недоступный вариант остаётся вариантом по умолчанию для робота.

Задержка сама по себе не всегда дефект. Если фид формируется раз в несколько часов, разница в пределах этого окна ожидаема. Дефект начинается там, где окно не определено, обновление может молча пропуститься или покупатель уже не может оформить предложение на заявленных условиях.

Один популярный товар часто проходит по самому прямому сценарию и скрывает крайние случаи. Для приёмки я бы взяла небольшую, но разную выборку: обычный товар, товар со скидкой, один из вариантов, последнее доступное количество и полностью распроданную позицию. Это не статистическая оценка всего каталога, а быстрый способ проверить разные ветви логики.

Для каждого сценария фиксируют время, URL, выбранный вариант, видимую цену и наличие, значения в JSON-LD и последнее значение в фиде. Если есть допустимая задержка, рядом указывают её границу. Тогда результат «не совпало» превращается в локализованную проблему: неверный источник, не тот вариант, пропущенное событие или ожидающий обновления канал.

Назначить источником истины можно не обязательно одну базу, а конкретное правило. Например, базовая цена приходит из учётной системы, акция рассчитывается на сайте, а доступность равна остатку за вычетом активных резервов. Главное, чтобы это правило было единым для видимой карточки, разметки и фида или чтобы различия были явно ограничены.

Опасная формулировка — «берём актуальное значение». Актуальное где и на какой момент? Для исправления нужны четыре ответа: кто владеет полем, какое событие запускает обновление, сколько может длиться расхождение и что происходит после ошибки. Без них очередная очистка кэша выглядит убедительно только до следующей смены цены.

Сначала меняют значение в его настоящем источнике на тестовом товаре или в безопасном сценарии. Затем наблюдают, когда обновились карточка, выбранный вариант, JSON-LD и фид. После этого повторяют проверку инструментом расширенных результатов и контролируют, не вернулся ли старый результат из кэша.

Поисковая выдача обновляется не по команде магазина, поэтому отсутствие немедленного изменения сниппета ещё не доказывает ошибку. Надёжный критерий раньше: страница и все подготовленные для робота представления уже согласованы, вариант можно купить на показанных условиях, а процесс обновления оставил проверяемый след.

Если цена и наличие расходятся, задача не сводится к замене двух строк JSON-LD. Нужно убрать конкурирующие правила и измерить путь значения от источника до каждого представления. Тогда микроразметка перестаёт быть отдельным SEO-слоем, который чинят после жалобы, и становится обычным потребителем тех же данных, что видит покупатель.

The product card says "in stock," the microdata source code still shows a pre-order status, and the product feed retains yesterday's price. For the buyer, this is one product. For the store, it is several representations updated by different processes at different times. Here is the interesting part: fixing one field is insufficient if the others diverge again after the next data exchange.

I would start not by re-running the validator, but by asking: what value is currently considered final for the selected product variant, and who is responsible for transmitting it to all channels. Valid markup can be semantically outdated. Conversely, a match today does not prove the chain will withstand a price or inventory change tomorrow.

The Rich Results Test tool answers an important but narrow question: does Google recognize supported types and properties? It does not know internal store agreements, does not select the price owner, and does not confirm that the visible value has passed through all caches.

For a product, price and offer availability are at minimum essential. Microdata must describe the content of this page and the specific variant the user actually opened. Adding Product or Offer only makes the page suitable for the corresponding search format; displaying a rich result is not guaranteed.

• Syntax check: properties are recognized, required fields are filled, and values have an acceptable format.
• Semantic check: the markup describes the visible product and the selected variant, and the price and availability match.
• Operational check: after the source is updated, all representations receive the new value within the expected timeframe.

A simple store already has a visible card, server-side or client-side JSON-LD, and a product feed. Add the selected size or color, page cache, and search engine robot cache, and you get a small distributed system, even though only one buy button appears on the screen.

It is useful to map the two fields separately. The price may come from 1C or ERP, then be calculated taking into account the price type and promotion. Stock may start from the physical balance, decrease by reserves, and only then become available for sale. If both fields are collected by the card template while JSON-LD is generated by another module, the discrepancy arises not from "bad microdata" but from two calculation logics.

For a variable product, the phrase "product price" is too vague. A red jacket in size M may cost differently than a blue one in size XL, and some variants may already be out of stock. If the URL or page state preselects a specific variant, its image, price, and availability must correspond exactly to it and allow adding it to the cart.

A typical error occurs when the visible part of the page switches without reloading, while JSON-LD remains from the default variant. The buyer sees a new price, while the robot sees the old offer. Another version of the same error: the markup reports a range or minimum price, but the page opens on an unavailable variant with a different total.

Do not automatically merge variants into a single record just because they share a name. First, fix a persistent product variant identifier, the selection method for the variant, and the address where this variant is available. The name and list position are unreliable for such a link.

• The page and JSON-LD read different price types or different warehouses.
• The visible card updates in the browser, while the markup remains in the original HTML.
• The feed is exported on a schedule and naturally lags behind the real-time stock.
• Page cache is cleared by product, but not by the linked product variant.
• The promotion has ended, yet the old value remains in one of the computed fields.
• An unavailable variant remains the default option for the robot.

Latency alone is not always a defect. If the feed is generated once every few hours, a difference within that window is expected. A defect begins where the window is undefined, an update may be silently skipped, or a shopper can no longer complete a purchase under the stated conditions.

A popular product often follows the most direct scenario, hiding edge cases. For acceptance testing, I would use a small but diverse sample: a standard product, a discounted product, one of its variants, the last available quantity, and a fully sold-out item. This is not a statistical assessment of the entire catalog, but a quick way to check different logic branches.

For each scenario, record the time, URL, selected variant, visible price, and availability, along with values in JSON-LD and the last value in the feed. If an allowable delay exists, indicate its boundary next to it. This way, a result of 'mismatch' becomes a localized issue: an incorrect source, the wrong variant, a missed event, or a channel waiting for an update.

The source of truth does not have to be a single database, but a specific rule. For example, the base price comes from the accounting system, the promotion is calculated on the website, and availability equals the stock minus active reservations. The main requirement is that this rule remains consistent for the visible card, microdata, and feed, or that any differences are explicitly limited.

Dangerous phrasing: 'taking the current value.' Current where and at what moment? Fixing this requires four answers: who owns the field, which event triggers the update, how long a discrepancy can last, and what happens after an error. Without these, another cache clear looks convincing only until the next price change.

First, change the value in its true source on a test product or in a safe scenario. Then observe when the card, selected variant, JSON-LD, and feed update. After that, recheck using the Rich Results tool and ensure the old result has not returned from the cache.

Search results do not update on the store's command, so the absence of an immediate snippet change does not prove an error. A reliable criterion is that the page and all robot-facing representations are already aligned, the variant can be purchased under the displayed conditions, and the update process leaves a verifiable trace.

If price and availability diverge, the task is not limited to replacing two lines of JSON-LD. You must remove conflicting rules and measure the value path from the source to each representation. Then, structured data stops being a separate SEO layer fixed after a complaint and becomes a regular consumer of the same data the buyer sees.