Schema.org для доставки, возврата и программы лояльности

Покупателю недостаточно увидеть название и цену товара. До оплаты он хочет понять, куда магазин доставляет заказ, сколько это стоит, когда посылка придёт, можно ли вернуть покупку и какие условия действуют для участника программы лояльности. Эти сведения сначала должны быть понятны на сайте и в оформлении заказа. Разметка Schema.org лишь передаёт уже существующие правила в машиночитаемом виде; она не исправляет неясную политику и не заменяет фактический расчёт.

Google Search поддерживает отдельные модели для стандартной доставки, возврата и членской программы: ShippingService, MerchantReturnPolicy и MemberProgram. Общие правила обычно связывают с Organization или более точным типом OnlineStore, а исключения конкретного предложения — с Offer. Ошибка уровня приводит к дублированию JSON-LD, конфликтам и ложным обещаниям: бесплатная доставка для одной категории внезапно выглядит правилом всего магазина.

Поддержка этих данных зависит от поискового продукта, страны, устройства и состояния функции. Особенно ограничено отображение преимуществ лояльности: в актуальной документации Google перечислен конкретный набор стран, куда Россия не входит. Даже валидная разметка не гарантирует специальный элемент в выдаче. Практическая цель — согласовать сайт, структурированные данные, Merchant Center и checkout, а затем контролировать расхождения.

Какие данные размечать и зачем

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

Если правило нельзя однозначно пересказать сотруднику поддержки, его рано кодировать. Формулировка «быстрая доставка по выгодной цене» не превращается в корректный диапазон дней и сумму. Сначала владельцы логистики, клиентского сервиса и CRM утверждают таблицу условий, юрист проверяет обязательные тексты для нужных юрисдикций, а разработчик получает структурированную модель. Общая архитектура разметки разобрана в материале о Schema.org.

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

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

Как разделить Organization и Offer

Google рекомендует размещать административные сведения на главной или на одной странице об организации и использовать наиболее точный тип. Для интернет-магазина это обычно OnlineStore, подтип Organization. Здесь уместны стандартные для большинства ассортимента доставка, возврат и программа участия. Не нужно копировать большой объект организации в каждую карточку: одна каноническая сущность с постоянным @id проще для поддержки.

Уровень Offer нужен, когда конкретное предложение действительно отступает от общего правила. Крупногабаритный шкаф может доставляться только специальной службой, персонализированный товар — не подлежать обычному возврату, а выбранная позиция — иметь цену для определённого уровня программы. Для доставки товара применяют OfferShippingDetails, для возврата — поддерживаемое подмножество MerchantReturnPolicy, для членской цены — отдельный UnitPriceSpecification.

Исключение не должно становиться вторым глобальным правилом. Создайте матрицу «условие по умолчанию → причина исключения → затронутые SKU → источник». Товар без исключения наследует общую операционную логику; товар с исключением получает точное значение в интерфейсе, разметке и расчёте заказа. Правила самой карточки полезно сверить с руководством по SEO товарной страницы, а сущность продавца — со статьёй о разметке организации.

Используйте постоянные идентификаторы: например, https://shop.example/policies/#standard-shipping и #member-silver. Ссылки через @id уменьшают копирование и помогают различать уровни. Однако идентификатор не исправит логическую ошибку: если CMS одновременно создаёт две сущности с одним @id и разными сроками, потребителю данных всё равно придётся разрешать конфликт.

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

Как описать стандартную доставку

Стандартную политику задают свойством hasShippingService у Organization или OnlineStore. Тип ShippingService содержит одно или несколько правил shippingConditions. Условие связывает направление, стоимость и время с параметрами заказа: страной или регионом, диапазоном суммы, весом либо габаритами. Название и описание помогают команде различать службы, но основное значение имеют формализованные условия.

Разделяйте обработку и перевозку. handlingTime описывает период от принятия заказа до передачи отправления, включая рабочие дни и время отсечки. transitTime относится к пути после отправки. Если склад собирает заказ от нуля до двух дней, а перевозчик везёт от одного до трёх, не обещайте общий срок «1–3 дня»: фактический диапазон составляет 1–5 рабочих дней при выполнении остальных условий.

Стоимость может быть фиксированной, нулевой, процентной или зависеть от порога заказа. Для зон, куда магазин не доставляет, предусмотрено явное условие отказа. Если к одной покупке подходят несколько условий, документация Google описывает выбор наиболее низкой стоимости, а при равной стоимости — более быстрого варианта. Поэтому пересекающиеся диапазоны необходимо тестировать на границах: 2 999 и 3 000 рублей, 4,99 и 5 килограммов, город и область.

Нестандартную доставку отдельного товара помещают в OfferShippingDetails под соответствующим Offer. Поддерживаемый набор полей там уже, чем на уровне организации. Не копируйте свойства только потому, что они существуют в Schema.org: поисковый продукт может их не учитывать. Для сложных вариантов товара проверяйте каждое покупаемое предложение; подход описан в статье о вариантах и SKU.

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

Как оформить политику возврата

Общую политику связывают с магазином через hasMerchantReturnPolicy. MerchantReturnPolicy может передавать ссылку на видимую страницу или подробные условия: применимые страны, категорию срока, число дней, состояние товара, способ возврата, расходы и тип возмещения. Для конечного срока используется категория MerchantReturnFiniteReturnWindow и количество дней; существуют также варианты неограниченного окна и запрета возврата.

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

Исключение конкретного предложения можно задать под Offer, но Google поддерживает для этого более узкий набор свойств. Типичный сценарий — товар финальной распродажи или изготовление под заказ. Сначала убедитесь, что ограничение законно и заметно до оплаты, затем отразите его в карточке, корзине, справочном разделе и JSON-LD. Нельзя показывать общее «30 дней бесплатно», если checkout фактически удерживает стоимость пересылки.

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

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

Как описать программу лояльности

MemberProgram задают под Organization через hasMemberProgram. Google требует название, описание и хотя бы один уровень MemberProgramTier. У уровня указывают имя и реальную выгоду: баллы, специальную цену или другое поддерживаемое преимущество. Страница программы должна объяснять, как вступить, бесплатное ли участие, как меняется уровень, когда сгорают баллы и какие товары исключены.

Региональное ограничение здесь критично. По состоянию документации на дату статьи Google Search перечисляет доступность информации о программе в Австралии, Бразилии, Канаде, Франции, Германии, Мексике, Великобритании и США на мобильных и настольных устройствах. Россия в этом перечне отсутствует. Интерфейс Merchant Center может иметь иной и более широкий список стран, поэтому наличие настройки в аккаунте не доказывает показ в органическом поиске конкретного региона.

Цена участника описывается на уровне предложения, а не только в объекте программы. Нужен обычный текущий price и отдельный UnitPriceSpecification с validForMemberTier. Баллы связывают с тем же уровнем; часть свойств, включая отдельные сценарии баллов и ссылку на уровень с другой страницы, отмечена Google как beta. Следовательно, корректный код может не дать видимого эффекта сразу.

Не смешивайте обычную скидку и членскую цену в одном ценовом объекте. Документация предупреждает о конфликте priceType и validForMemberTier. Сначала опишите регулярную и акционную цену по правилам предложения, затем отдельную цену участника. Бизнес-механика, начисление и списание баллов должны быть устойчивы без поискового представления; основы программы раскрыты в материале о лояльности покупателей.

Уровень участника должен иметь стабильный идентификатор и понятное человеку название. Не создавайте новый @id при каждом переименовании «Серебра» в «Плюс», если права уровня не изменились: иначе аналитика и внешние потребители увидят новую сущность. Отдельно опишите бесплатные и платные программы, сроки ожидания после регистрации, подтверждение статуса и правила для гостевого заказа. Если специальная цена появляется только после входа, обычная цена остаётся обязательной точкой сравнения. А когда преимущество не действует на часть брендов, список исключений должен быть доступен до добавления товара в корзину.

Как связать условия с конкретным товаром

Карточка товара соединяет три слоя: Product описывает объект, Offer — покупаемое предложение, а административная сущность магазина — общие правила. Не помещайте цену, наличие и исключение доставки в абстрактный Product, если они относятся к конкретному продавцу или варианту. Современная товарная модель подробнее разобрана в руководстве по Product и Offer.

Для каждого SKU сформируйте единый снимок: URL, идентификатор, обычная цена, валюта, наличие, применимая доставка, возврат и членские условия. Серверный шаблон должен брать эти значения из тех же систем, что карточка и checkout. Если JSON-LD генерирует SEO-модуль из отдельной таблицы, а корзина обращается к ERP, задержки неизбежно создадут расхождения. Установите допустимое время синхронизации и журналируйте публикацию.

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

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

Какие источники данных приоритетны

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

Для доставки и возврата Google описывает явный порядок разрешения конфликтов. Данные, переданные через товарные источники Merchant Center или API, сильнее настроек Merchant Center и Search Console; затем идут свойства конкретного Offer, а после них — общая политика Organization. Если политика задана одновременно в Search Console и разметке сайта, Google использует настройку Search Console. Поэтому при проверке нужно знать не только значение, но и поверхность, на которой оно опубликовано.

У программы лояльности своё правило: если сведения одновременно переданы через Merchant Center и структурированные данные, Google использует Merchant Center. Такой приоритет не разрешает публиковать там более привлекательные условия. Все каналы обязаны совпадать с видимой страницей и checkout; иначе поисковая система может отклонить сведения, а покупатель получит неожиданное ограничение.

Определите владельца каждого поля. Логистика отвечает за зоны, стоимость и сроки; клиентский сервис — за возврат; CRM — за уровни и баллы; каталог — за исключения SKU; разработка — за доставку значений во все каналы. В PIM или другой мастер-системе храните версию правила и дату начала действия. Ручное изменение в интерфейсе допустимо как временное исключение с ответственным и сроком пересмотра.

Приоритет нужно понимать как операционный порядок разрешения конфликтов, а не как способ «переубедить» поисковик. Если сайт, фид и аккаунт расходятся, исправляйте первичный источник и распространяйте изменение дальше. Полезный регламент контроля каталога можно связать с SEO-мониторингом и регрессионными проверками релизов.

Как внедрить JSON-LD без дублей

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

{
  "@context": "https://schema.org",
  "@type": "OnlineStore",
  "@id": "https://shop.example/#store",
  "name": "Магазин",
  "hasShippingService": { "@id": "https://shop.example/policies/#standard-delivery" },
  "hasMerchantReturnPolicy": { "@id": "https://shop.example/policies/#standard-return" },
  "hasMemberProgram": { "@id": "https://shop.example/loyalty/#club" }
}

Это только каркас, а не готовый объект: связанные сущности должны содержать обязательные для выбранной функции свойства и соответствовать видимому тексту. Не копируйте пример страны, валюты и дней из документации. Разработчик генерирует значения из утверждённой модели, а редактор управляет понятным описанием. Слишком длинный JSON-LD, собранный из свободного текста, трудно проверить и легко сломать кавычкой.

Карточки получают только необходимые исключения и ссылку на того же продавца. Если CMS добавляет Product через плагин, а Organization — через шаблон, определите контракт идентификаторов. Проверьте исходный HTML и отрендерированный DOM: поздняя вставка JavaScript допустима для Google в некоторых сценариях, но увеличивает число точек отказа. Серверная выдача стабильного JSON-LD обычно проще для контроля.

Перед массовым выпуском создайте эталонные примеры: обычный товар, крупногабаритный, финальная распродажа, два уровня программы, регион без доставки и временно отсутствующий вариант. Для каждого зафиксируйте ожидаемый объект и фактический checkout. Такой набор становится автоматическим контрактом релиза, а не одноразовой проверкой валидатора.

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

Как проверить ограничения и ошибки

Сначала проверьте синтаксис Rich Results Test и валидатором Schema.org, затем смысл вручную. Отсутствие критической ошибки означает лишь, что инструмент смог разобрать поддерживаемые поля. Он не подтверждает законность политики, совпадение с корзиной, доступность функции в стране или будущий показ. Предупреждение о рекомендуемом поле рассматривайте по существу, а не заполняйте случайным значением ради зелёного отчёта.

После публикации откройте страницу без авторизации, проверьте код 200, canonical, доступность JSON-LD и отсутствие noindex. URL Inspection показывает версию, доступную Google, но переобход и обработка требуют времени. В Search Console следите за отчётами торговых представлений и сообщениями, если они доступны свойству. Базовая работа с панелью описана в руководстве по Search Console.

Отдельно составьте таблицу регионов. Для каждого укажите доступность доставки, валюту, страницу условий, поддержку Merchant Center, поддержку конкретного представления Search и юридического владельца текста. Интерфейсы и списки стран меняются; дата проверки должна храниться рядом с решением. Нельзя считать российский магазин участником loyalty-функции Google Search только потому, что тип существует в Schema.org.

Тестируйте границы и отрицательные сценарии: заказ ниже порога бесплатной доставки, выходной после cutoff, неподдерживаемый индекс, товар с запретом возврата, пользователь без членства и просроченный уровень. Сравнивайте HTML, JSON-LD, источник Merchant Center и checkout. Контроль улучшает качество данных и снижает риск отказов, но не обещает расширенный сниппет, позицию или рост продаж.

Многоязычные и региональные версии проверяйте как отдельные пользовательские пути. Перевод заголовка не меняет применимую страну автоматически, а переключение валюты не превращает рублёвый порог доставки в эквивалент без утверждённого расчёта. Откройте URL с чистой сессией, выберите регион, добавьте эталонный товар и сравните финальную сумму. Если сервер отдаёт роботу одну политику, а браузеру после геолокации другую, сначала устраните неоднозначность. В отчёте фиксируйте URL, локаль, регион, время и тестовый SKU, чтобы следующий специалист мог повторить наблюдение.

Числовой пример аудита магазина

Рассмотрим учебный каталог из 2 400 предложений. У 1 920 действует стандартная доставка и возврат, у 240 крупногабаритных товаров особая перевозка, у 120 есть региональное ограничение, у 72 позиций финальной распродажи отдельный возврат, у 48 предложений опубликована цена участника. Группы в этом примере не пересекаются: 1 920 + 240 + 120 + 72 + 48 = 2 400.

Автоматическая сверка находит 86 расхождений цены, 54 ошибки доставки, 31 несовпадение возврата и 9 дублирующихся идентификаторов уровней. Всего проблемных предложений 180: 86 + 54 + 31 + 9 = 180. Чистыми остаются 2 220: 2 400 − 180 = 2 220. Доля ошибок равна 7,5%: 180 / 2 400 × 100.

После исправления остаётся 12 расхождений: 3 цены, 5 доставок и 4 возврата. Новая доля — 0,5%: 12 / 2 400 × 100. Число ошибок уменьшилось на 168, то есть на 93,3% относительно исходных 180: (180 − 12) / 180 × 100 ≈ 93,3%. Эти числа измеряют согласованность данных, а не влияние на трафик.

Команда не публикует все 2 400 карточек заново одновременно. Сначала выпускает эталонные товары каждой группы, проверяет страницу, разметку, Merchant Center и checkout, затем расширяет охват. Для оценки бизнеса отдельно смотрят отмены из-за условий, обращения в поддержку и завершение заказа. Методика повышения конверсии описана в статье о конверсии сайта.

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

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

Каждое изменение политики проходит один маршрут: утверждение, дата начала, обновление мастер-системы, видимых страниц, checkout, JSON-LD и внешних источников. Релиз имеет владельца и возможность отката. Если правило меняется ночью, заранее определите временную зону и порядок обновления, чтобы старая цена не сочеталась с новым условием участия.

Раз в квартал проверяйте официальную документацию и доступность функций по странам. Новое поле может оставаться beta, старое — получить ограничения, а интерфейс Merchant Center — измениться независимо от Schema.org. Документируйте, какие свойства вы используете ради внутренней однозначности, а какие поддерживает конкретный поисковый продукт. Это предотвращает обещания, основанные на одном скриншоте из другого региона.

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

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

Главный вывод

Разметка доставки, возврата и лояльности начинается с честных коммерческих правил. Общие условия связывайте с одной сущностью OnlineStore, исключения — с конкретным Offer, а цену и выгоды участника — с явно определённым уровнем. Проверяйте страну, beta-статус и интерфейсные ограничения, согласуйте видимые страницы, JSON-LD, Merchant Center и checkout. Валидный код улучшает однозначность данных, но не гарантирует специальное представление, позицию или продажи.