На карточке товара уже новая цена, а в коде микроразметки осталась старая. Валидатор не ругается: JSON записан правильно. Но поисковику передаются другие сведения, чем покупателю. Этот пример хорошо показывает, почему одной зелёной галочки при внедрении недостаточно.
В Гуси-Лебеди предлагаем проверять микроразметку от содержания страницы до опубликованного шаблона. Разберём, что такое Schema.org и JSON-LD, какие данные размечать, как избежать конфликтов плагинов и что проверить в Яндексе и Google. Учебные примеры ниже не описывают реальные товары и клиентские результаты.
Что такое микроразметка и зачем она нужна сайту
Микроразметка передаёт сведения о странице в структурированном виде. Программа получает не просто набор слов, а описание сущностей и свойств: вот товар, вот его предложение, вот статья и её издатель. Это помогает сервисам извлекать нужную информацию.
Полезно разделять три понятия. Словарь задаёт смысл типов и свойств. Формат определяет, как их записать в коде. Поисковая функция задаёт условия использования этих данных конкретным поисковиком. Schema.org относится к словарю; JSON-LD, Microdata и RDFa являются способами записи.
JSON-LD размещают отдельным блоком данных, Microdata и RDFa используют атрибуты HTML. Google рекомендует JSON-LD для поддерживаемых расширенных результатов. Но выбранный формат нужно сверять с требованиями нужной функции, особенно если сайт ориентирован на несколько поисковых систем.
Open Graph решает отдельную задачу: передаёт сведения для превью ссылки. Наличие красивой карточки при отправке в мессенджере не подтверждает разметку товара или статьи по Schema.org. Семантические HTML-теги и атрибуты доступности также имеют свои назначения.
Структурированные данные могут использоваться для дополнительного представления результата, но не заменяют понятное содержание и работающий сайт. Подробно Яндекс описывает назначение и способы использования в справке по Schema.org. Не обещайте рост позиций, CTR или обязательные звёзды только после добавления кода. Для оценки нужны фактические данные, а не вид сниппета конкурента.
Какие типы Schema.org выбрать для разных страниц
Начните с перечня шаблонов и содержания каждого. Что посетитель действительно видит: одну карточку, подборку товаров, статью, контакты организации или описание услуги? Сущность выбирают по этому ответу, а не по желанию занять больше места в выдаче.
| Тип | Что описывает | Что проверить до внедрения |
|---|---|---|
| Organization | Конкретную организацию | Название, контакты и ссылки относятся к ней |
| Article | Отдельный материал | Заголовок, авторство и даты соответствуют публикации |
| BreadcrumbList | Навигационную цепочку | Названия и порядок отражают реальный путь |
| Product и Offer | Товар и предложение продавца | Модель, цена, валюта и наличие согласованы |
| LocalBusiness | Соответствующий локальный бизнес | Сведения о месте и работе подтверждены |
Наличие типа в Schema.org не означает, что любой поисковик использует его для любого оформления. У Яндекса справка JSON-LD перечисляет конкретные сценарии. У Google проверяйте документацию нужного расширенного результата. Не переносите требования к товару на страницу услуги.
У страницы категории не должно появляться предложение одного вымышленного товара со средней ценой всего каталога. У статьи о продукте нельзя автоматически приписывать предложение магазина, которого на странице нет. Если реальная сущность не подходит поддерживаемой поисковой функции, это не повод подменять её другой.
Для каждого поля назначьте источник: каталог, CMS, редактор или подтверждённые сведения компании. Обязательные и рекомендуемые свойства зависят от выбранной функции. Если нужной информации нет, сначала выясните её наличие и правила обработки отсутствующего значения. Не добавляйте произвольный телефон, автора или рейтинг для прохождения проверки.
Как добавить микроразметку и не рассинхронизировать данные
Представим учебную лампу: её цену изменили с 4 900 на 5 200 рублей. Если видимая карточка обновилась, а отдельный JSON-LD нет, оба фрагмента могут быть синтаксически корректными. Ошибка находится в данных и способе обновления.
Формируйте видимое содержание и структурированные сведения из согласованного источника. В разработке шаблонов интерфейса это стоит предусмотреть сразу: название, цена, валюта, изображение и наличие не должны поддерживаться в двух независимых ручных копиях.
Заранее определите, какое предложение описывается при вариантах комплектации, региональных ценах и персональных скидках. Не сочетайте фотографию одного варианта с артикулом и стоимостью другого. После изменения проверьте опубликованный URL с учётом кэша, а не только значения в редакторе.
Для статьи тот же принцип относится к автору, издателю, датам и изображению. Дата изменения должна отражать реальную правку материала. Обновление её при каждом открытии страницы не делает публикацию новой. Для товаров подробный состав содержания разбираем в статье о карточке товара.
В WordPress и Битрикс сначала выясните, что уже выводят тема, модуль или SEO-плагин. Генератор подходит для подготовки примера, но ручная вставка одинакового кода во все страницы не создаёт надёжный шаблон. На Tilda разметка товаров каталога предусмотрена по умолчанию, поэтому перед дополнительной вставкой проверьте существующие данные; это описано в инструкции платформы.
JSON формируйте штатным сериализатором. Ручное соединение строк легко ломается на кавычках в названии. При вставке внутрь HTML нужен также способ сериализации, безопасный для контекста script: корректный JSON сам по себе не предотвращает закрытие HTML-тега значением из данных.
Пример JSON-LD для хлебных крошек
Учебный каталог показывает путь «Каталог → Настольные лампы → Лампа L-01». Ниже приведено описание этой цепочки. Все адреса example.com являются примерами: при внедрении замените их реальными адресами соответствующих разделов.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Каталог",
"item": "https://example.com/catalog/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Настольные лампы",
"item": "https://example.com/catalog/lamps/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Лампа L-01",
"item": "https://example.com/catalog/lamps/l-01/"
}
]
}Для внедрения этот объект помещают в HTML внутри <script type="application/ld+json"> с закрывающим тегом </script>. В статье он показан как учебный текст и не размечает саму публикацию как каталог ламп.
position задаёт порядок, name задаёт название, item указывает адрес. Проверьте, что категории открываются и соответствуют названиям. В описании BreadcrumbList можно сверить модель. Не добавляйте несуществующие промежуточные разделы ради дополнительных ключевых слов.
Для Яндекса используйте условия обработки навигационных цепочек. Google отдельно описывает свою функцию хлебных крошек: в текущей документации она доступна на компьютерах. Это ограничение оформления Google, а не причина убирать полезную навигацию с мобильного сайта.
Структуру самой цепочки продумывайте вместе с иерархией разделов сайта. Разметка должна описывать понятный путь, а не исправлять хаотичный каталог только внутри кода.
Как избежать дублей от темы, плагинов и отдельных модулей
Одна страница может содержать несколько связанных сущностей: статью, издателя, автора и навигационную цепочку. Несколько блоков данных сами по себе не означают ошибку. Проблема возникает, когда они противоречат друг другу или описывают нужные связи неоднозначно.
Например, тема выводит компанию с актуальным телефоном, SEO-плагин добавляет ту же компанию со старым, а пользовательская вставка использует третье название. Проверка только нового фрагмента не обнаружит весь конфликт. Соберите все структурированные данные опубликованной страницы и установите источник каждого блока.
Назначьте владельца каждой сущности и согласуйте её идентичность. В JSON-LD стабильный @id используют для связи описаний одного объекта; это идентификатор, а не обещание отдельной индексируемой страницы. Не отключайте весь вывод плагина вслепую: вместе с конфликтом можно убрать правильную разметку статьи или навигации.
После правки проверьте полный набор данных и видимое содержание. Пройдите несколько страниц каждого шаблона, включая неполные поля и необычные названия. Обновление темы, SEO-плагина или пользовательского модуля должно сопровождаться повторной проверкой.
Сохраните карту: сущность, источник, поля, место вывода и способ обновления. Тогда при смене телефона или перенесённом URL можно найти нужную настройку, а не добавлять четвёртый блок поверх трёх предыдущих.
Как проверить микроразметку и принять результат внедрения
Проверка состоит из разных задач. Сначала убедитесь, что данные читаются. Затем проверьте условия выбранной поисковой функции. После этого сравните сведения с видимой страницей и убедитесь, что робот получает актуальную версию. Одна удачная проверка кода не закрывает остальные вопросы.
Schema Markup Validator извлекает граф Schema.org и выявляет синтаксические ошибки. Его назначение описано в документации валидатора. Google Rich Results Test проверяет поддерживаемые расширенные результаты Google. Валидатор Яндекса учитывает требования его сервисов; справка инструмента объясняет ошибки и предупреждения.
Начинайте с фрагмента, затем проверяйте публичный URL. Кэш, фильтры CMS или клиентские скрипты могут изменить итоговую страницу. Ошибка загрузки означает, что инструмент не получил проверяемую страницу; это нужно отличать от ошибки в самих данных.
| Проверка | Ожидаемый результат |
|---|---|
| Изменить цену в источнике | На странице и в разметке актуальны сумма и валюта |
| Добавить кавычки в название | JSON читается, название не обрезано |
| Оставить необязательное поле пустым | Нет выдуманного заполнителя, структура корректна |
| Изменить URL | Обновлены адреса, связи и навигация |
| Обновить тему или плагин | Не появился противоречащий дубликат |
| Проверить несколько состояний товара | Наличие, варианты и предложение соответствуют странице |
Не добавляйте фиктивные отзывы и рейтинги. Google требует достоверности, актуальности и соответствия основному содержанию, а корректная разметка не гарантирует показ расширенного результата. Эти условия приведены в общих правилах структурированных данных.
Учитывайте изменения функций. С 7 мая 2026 года Google больше не показывает расширенный результат FAQ; это зафиксировано в официальном журнале обновлений. Блок вопросов остаётся полезным для читателя, но обещание дополнительного FAQ-блока в Google стало устаревшим.
Если ожидаемое оформление не появилось, последовательно проверьте доступность, обработку новой версии, поддержку функции, её условия и соответствие данных. Не добавляйте новые схемы наугад. Отсутствие цены или звёзд само по себе не доказывает неисправность JSON.
В аудит структурированных данных включайте проверку всего шаблона, а не одной удобной страницы. Сохраните URL, HTML, результаты инструментов и дату проверки. После переобхода наблюдайте состояние через Яндекс Вебмастер и применимые отчёты Search Console.
Принимайте внедрение по воспроизводимому результату: сведения берутся из понятного источника, совпадают с содержанием и остаются согласованными после обновления. Именно такой шаблон можно поддерживать дальше.