Разметка Product: цена и наличие должны совпасть со страницей

Цена на карточке и в разметке Product расходятся, а наличие в сниппете не совпадает с реальным складом. Разберём, как сверять видимое предложение со структурированными данными и что делать с вариантами, предзаказом и старой разметкой в шаблоне.

Разметка Product должна описывать то же предложение, что видит анонимный посетитель: цену, наличие и варианты. Сверяйте видимую цену и статус наличия с полями структурированных данных по каждому варианту товара. Валидная схема не гарантирует расширенный результат и не оправдывает заглушки вроде нуля в цене.

Цена на карточке — 4 990 ₽, в разметке Product — 5 490 ₽, а в наличии остался один размер из трёх. Условный магазин обуви обновил цены в админке в пятницу вечером, шаблон микроразметки остался прежним, и к понедельнику поисковый сниппет показывает покупателю не то, что он увидит на странице. Это не редкий сбой, а типичное расхождение между витриной и структурированными данными: два источника правды живут в разных местах и обновляются с разной скоростью.

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

Где именно расходятся витрина и структурированные данные

Расхождение почти никогда не бывает в одном поле. Оно распределяется по нескольким слоям, и каждый живёт по своему расписанию. Цена может приходить из прайса поставщика, наличие — из складской системы, варианты — из карточки товара, а условия доставки и скидки — из промо-модуля. Шаблон разметки при этом часто собирает значения из одного источника и не знает про остальные.

Первый слой — цена. Витрина умеет показывать цену со скидкой, цену по промокоду, цену для авторизованного клиента. Разметка обычно фиксирует одно число. Если это число не совпадает с той ценой, которую видит анонимный посетитель, возникает прямое противоречие.

Второй слой — наличие. «В наличии», «под заказ», «предзаказ», «нет в наличии» — это разные состояния, и не каждое из них корректно описывается одним и тем же значением готовности к продаже. Товар, который можно только предзаказать, и товар, который лежит на складе, — не одно и то же предложение.

Третий слой — варианты. Один товар с размерами, цветами или комплектациями — это несколько предложений с разными ценами и разным наличием. Если разметка описывает только базовый вариант, остальные остаются невидимыми для машины, а покупатель в сниппете видит цену, которой для его размера не существует.

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

Если ваша задача — проверить разметку товаров, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Соответствие Product и страницы: карточка соответствия

Прежде чем что-то чинить, полезно завести один рабочий объект, вокруг которого будет крутиться вся проверка. Это не отчёт и не чек-лист на сто пунктов, а компактная карточка соответствия по каждому товару. Её удобно держать в таблице или в задаче трекера, и она переживает смену подрядчика.

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

Условный эпизод: кроссовки, которые «подешевели» только на витрине

Разберём подробно. Условный интернет-магазин спортивной обуви держит в каталоге модель кроссовок в трёх размерах: 41, 42, 43. Цена для всех размеров — 7 900 ₽, размер 43 идёт по акции 6 900 ₽. На складе остались только 41 и 43, размер 42 — под заказ с ожиданием две недели.

Витрина показывает это честно: у размера 43 цена перечёркнута и стоит 6 900 ₽, у размера 42 — пометка «под заказ». А разметка Product на странице описывает один товар с ценой 7 900 ₽ и статусом «в наличии». Что видит поисковая система: товар за 7 900 ₽, который есть на складе. Что видит покупатель, кликнув: размер 43 за 6 900 ₽, размер 42 недоступен сразу.

Здесь сразу два расхождения. Первое — цена: сниппет обещает 7 900 ₽, а для части покупателей актуальна цена 6 900 ₽. Второе — наличие: статус «в наличии» не различает склад и предзаказ. Покупатель, которому нужен 42-й, приходит на страницу, ожидая быструю покупку, и обнаруживает ожидание.

Лечится это не косметикой, а приведением разметки к структуре вариантов. Каждый размер — отдельное предложение со своей ценой и своим состоянием наличия. Тогда машина получает ту же картину, что и человек. Важно, что при этом не нужно ничего выдумывать: если размер под заказ, так и описывается, если цена акционная — она и указывается.

Предзаказ и отсутствие цены: два разных «нет»

Самая частая ошибка — считать, что «нет в наличии» и «нет цены» описываются одинаково. Это не так, и путаница здесь стоит дорого.

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

Когда цены нет вовсе — например, товар продаётся только по запросу или цена зависит от комплектации, — нельзя подставлять ноль, пустую строку или условную заглушку. Ноль в поле цены читается как «бесплатно», а это уже прямое введение в заблуждение. Заглушка вроде «1 ₽» ради прохождения валидатора — то же самое.

Правильный подход — либо честно описать предложение как «цена по запросу» без поля цены, либо не размечать товар как Product с конкретной ценой вовсе. Валидная схема не равна правдивой схеме, и вторая важнее первой.

Условный эпизод: распродажа, которая закончилась, а разметка — нет

Второй эпизод про другой тип расхождения — временной. Условный магазин электроники провёл недельную распродажу ноутбуков: цена упала с 54 000 ₽ до 47 000 ₽, на странице появился баннер акции и перечёркнутая старая цена. Разметку обновили: в поле price встало 47 000 ₽, в поле «цена до скидки» — 54 000 ₽.

Распродажа закончилась в воскресенье. Витрина вернулась к 54 000 ₽, баннер убрали, перечёркнутую цену убрали. А шаблон разметки, который собирал данные из промо-модуля, продолжал отдавать 47 000 ₽ и старую цену как «до скидки». Формально разметка валидна: все поля на месте, структура правильная. Фактически она сообщает о скидке, которой больше нет.

Этот случай опаснее первого, потому что визуально всё выглядит прилично: страница аккуратная, сниппет аккуратный, а расхождение спрятано. Покупатель приходит за ценой 47 000 ₽ и видит 54 000 ₽. Даже если он купит, доверие уже подорвано.

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

Соответствие Product и страницы: исключения и проверка условий

Простое правило «цена в разметке равна цене на странице» работает, пока товар один и цена одна. Реальные каталоги состоят из исключений, и именно на них проверка чаще всего буксует.

Товар с диапазоном цен. Один товар, у которого варианты стоят от 3 000 до 5 000 ₽. Витрина показывает «от 3 000 ₽». Разметка с одним числом 3 000 ₽ формально совпадает с видимым «от», но не описывает остальные варианты. Корректнее описать каждый вариант отдельно, а не схлопывать в минимум.

Товар-набор. Комплект из нескольких позиций с общей ценой. Здесь важно не размечать набор как один товар с ценой, сложенной из чужих цен, если на странице продаётся именно комплект по своей цене.

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

Товар, снятый с продажи. Страница ещё существует, но товар больше не продаётся. Разметка с ценой и наличием вводит в заблуждение. Здесь корректно либо убрать товарное описание, либо явно показать, что товар недоступен.

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

Каждое из этих исключений требует не универсального правила, а явного решения, зафиксированного в карточке соответствия. Молчаливое «само разрулится» здесь не работает.

Соответствие Product и страницы на экране сотрудника

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

Минимальный такой интерфейс — не дашборд с графиками, а понятная пометка прямо в карточке товара. Например, рядом с полем цены — значок «разметка совпадает» или «разметка расходится: в коде 5 490 ₽, на странице 4 990 ₽». Контент-менеджер меняет цену и сразу видит, обновилась ли разметка.

Второй элемент — список товаров, где расхождение уже есть, отсортированный по важности: сначала те, что в промо, потом те, что в топе каталога. Сотруднику не нужно проверять весь каталог вручную — он работает с очередью.

Третий элемент — понятное действие. Если разметка собирается автоматически, сотруднику достаточно нажать «пересобрать». Если вручную — рядом должна быть инструкция, какие поля менять и где. Кнопка «исправить» без объяснения, что именно исправится, порождает новые ошибки.

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

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

Документация поисковых систем описывает, какие поля обязательны, какие рекомендуемы и как должен выглядеть корректный товарный объект. Полезно держать под рукой первоисточник: описание Product structured data перечисляет обязательные и рекомендуемые свойства, а общие требования Search Essentials объясняют, что разметка не заменяет качество страницы и не гарантирует показ расширенного результата.

Здесь важно не перепутать две вещи. Валидность разметки — это техническое соответствие схеме. Она не доказывает, что данные правдивы, и не обещает, что поисковая система покажет расширенный сниппет. Более того, наличие корректной разметки — необходимое, но не достаточное условие: решение о показе принимает поисковая система, и никакая схема этого не гарантирует.

Отдельно стоит помнить про изображения товара. Если карточка размечает картинки, полезно свериться с рекомендациями по изображениям: качество, размер, релевантность изображения видимому товару. Разметка картинки, которая не совпадает с тем, что на странице, — то же расхождение, только в другой плоскости.

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

Тесты: как убедиться, что соответствие держится

Проверка «один раз руками» не годится, потому что расхождения возвращаются с каждой правкой каталога. Нужен набор повторяемых тестов — не обязательно автоматических, но обязательно регулярных.

Тест на совпадение цены. Для выборки товаров сравнить видимую цену для анонимного посетителя и значение в разметке. Расхождение — сигнал.

Тест на наличие. Проверить, что статус наличия в разметке соответствует реальному состоянию: склад, предзаказ, отсутствие.

Тест на варианты. Убедиться, что все варианты товара, доступные на витрине, описаны в разметке, а не только базовый.

Тест на промо. После окончания акции проверить, что разметка вернулась к обычной цене и не хранит старую скидку.

Тест на товары без цены. Убедиться, что в поле цены нет нулей и заглушек.

Тест на снятые товары. Проверить, что страницы снятых с продажи товаров не выдают их как доступные к покупке.

Эти тесты можно прогнать вручную по выборке раз в неделю или автоматизировать. Важнее не способ, а регулярность и адресность: у каждого теста есть владелец и результат.

Практикум: сверка одного товара за пятнадцать минут

Возьмём другой пример, чтобы отработать методику на нейтральном случае. Условный магазин товаров для дома продаёт кофемолку в двух цветах: чёрный за 3 200 ₽ и белый за 3 400 ₽. Чёрная есть на складе, белая — под заказ. На странице есть общая карточка с выбором цвета.

Шаг первый. Открываем страницу как анонимный посетитель, без авторизации. Записываем видимую цену для каждого цвета и статус наличия. Получаем: чёрная — 3 200 ₽, в наличии; белая — 3 400 ₽, под заказ.

Шаг второй. Смотрим исходный код страницы и находим блок структурированных данных. Выписываем, что там указано: цена, наличие, сколько вариантов описано.

Шаг третий. Сравниваем. Если в разметке одна цена 3 200 ₽ и статус «в наличии», а белая стоит 3 400 ₽ и идёт под заказ — расхождение по цене и наличию для одного из вариантов.

Шаг четвёртый. Заполняем карточку соответствия: артикул, обе цены, оба статуса, список вариантов, владелец, дата сверки.

Шаг пятый. Решаем, что чинить: источник данных, шаблон или ручную правку. И назначаем дату повторной проверки.

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

Что делать, когда расхождение нашлось, а виноватого нет

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

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

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

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

Итог: один конкретный шаг проверки

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

Если расхождений нет — у вас есть базовая точка, от которой можно строить регулярную сверку. Если расхождения есть — вы только что нашли их раньше покупателя и поисковой системы, и у вас на руках конкретный список, с которым можно идти к ответственному за каталог. Дальше — карточка соответствия, очередь на исправление и повторная проверка через неделю. Разметка Product не украшение страницы, а обещание, которое витрина должна выполнять.

Смежный вопрос разобран отдельно: Проверка карточек товаров агентом: где факты спорят друг с другом.