Страница может быть понятна человеку и при этом оставаться неоднозначной для машины. Цена рядом с названием — это цена товара, тарифа или услуги? «Иван Петров» — автор статьи, сотрудник компании или клиент, оставивший отзыв? Микроразметка добавляет к видимому контенту явные связи и типы сущностей.
Но Schema.org не является волшебной кнопкой для топа. Корректная разметка помогает поисковым системам понимать содержание и может сделать страницу подходящей для расширенного результата, однако Google не гарантирует его показ даже при отсутствии ошибок. Разберём, как внедрить структурированные данные без лишних сущностей, выдуманных рейтингов и кода, который расходится с самой страницей.
Schema.org, JSON-LD и расширенный результат — не одно и то же
Эти понятия часто смешивают:
-
Schema.org — словарь типов и свойств:
Organization,Product,Article,name,priceи тысячи других. - JSON-LD — формат, в котором можно записать структурированные данные отдельным блоком JSON.
- Расширенный результат — специальное отображение в поиске, доступное только для поддерживаемых поисковой системой типов и при выполнении её правил.
Разметка может быть полностью валидной по словарю Schema.org, но не давать расширенного сниппета. Например, тип существует в словаре, однако Google не использует его для отдельного визуального элемента. И наоборот, синтаксически правильного JSON недостаточно, если данные не соответствуют видимому контенту.
Почему для старта удобен JSON-LD
Google поддерживает JSON-LD, Microdata и RDFa, а JSON-LD рекомендует как основной формат. Его удобно держать отдельным блоком:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Пример",
"url": "https://example.ru/"
}
</script>
В отличие от Microdata, не приходится добавлять атрибуты к десяткам HTML-элементов. Код проще генерировать из данных CMS, читать и обновлять. Но отдельный блок создаёт риск рассинхронизации: цена на странице изменилась, а в JSON-LD осталась прежней. Поэтому источник данных должен быть один.
Шаг 1. Определите главную сущность страницы
Начинайте не с вопроса «какую схему любит Google», а с вопроса «что это за страница».
| Страница | Основная сущность | Возможные дополнительные сущности |
|---|---|---|
| Главная компании | Organization или более точный подтип |
WebSite |
| Контакты локального бизнеса | LocalBusiness и подходящий подтип |
PostalAddress, GeoCoordinates |
| Карточка товара | Product |
Offer, реальные Review и AggregateRating |
| Статья | Article, BlogPosting или NewsArticle |
Person/Organization как автор и издатель |
| Страница услуги | Service |
Organization, Offer, areaServed |
| Навигационная цепочка | BreadcrumbList |
элементы ListItem |
| Видео | VideoObject |
автор, миниатюра, дата публикации |
Выбирайте наиболее конкретный корректный тип. Стоматология может быть Dentist, ресторан — Restaurant, интернет-магазин как компания — OnlineStore, если такой тип и правила подходят вашему сценарию.
Не нужно превращать каждый абзац в отдельную сущность. Разметка должна описывать главное содержание и полезные связи, а не демонстрировать размер словаря.
Генератор и валидатор Schema.org ITSEO
Шаг 2. Сверьтесь с требованиями поисковой системы
У Schema.org и поисковой функции разные уровни требований:
- Словарь говорит, какие свойства существуют и как связаны.
- Документация поисковой системы указывает обязательные и рекомендуемые поля для конкретного расширенного результата.
- Правила качества требуют, чтобы данные были правдивыми, актуальными и видимыми пользователю.
Перед внедрением откройте актуальную документацию Google или Яндекса по нужному типу. Состав поддерживаемых функций и требования меняются, поэтому старый шаблон из статьи нельзя считать вечным.
Правильная разметка не должна:
- описывать контент, которого нет на странице;
- добавлять вымышленный рейтинг;
- размечать отзывы самой компании о себе как пользовательские;
- подменять основную тему страницы нерелевантной сущностью;
- содержать скрытое предложение, недоступное посетителю.
Шаг 3. Соберите данные до генерации кода
Для карточки товара подготовьте:
- стабильное название;
- описание именно этого товара;
- абсолютный URL изображения, доступного роботу;
- SKU или другой идентификатор;
- бренд;
- актуальную цену и валюту;
- наличие;
- URL предложения;
- реальные отзывы и рейтинг, если они показаны на странице.
Для организации понадобятся название, официальный URL, логотип, контакты, адрес и проверенные профили. Для статьи — заголовок, изображение, дата публикации и изменения, автор, издатель.
Если обязательного свойства нет в бизнес-данных, не придумывайте его ради зелёной галочки. Сначала исправьте источник и видимый контент либо выберите более подходящую схему.
Шаг 4. Создайте JSON-LD в генераторе
Откройте генератор микроразметки ITSEO, выберите тип страницы и заполните только достоверные поля. Инструмент создаст блок JSON-LD, который можно передать разработчику или добавить через возможности CMS.
Пример упрощённой разметки статьи:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Как правильно снимать позиции сайта",
"datePublished": "2026-09-03",
"dateModified": "2026-09-03",
"author": {
"@type": "Person",
"name": "Имя автора"
},
"publisher": {
"@type": "Organization",
"name": "ITSEO",
"url": "/"
}
}
</script>
В рабочей версии добавьте поля, которые требуются для выбранной поисковой функции, включая корректное изображение. Пример выше показывает структуру, а не универсальный шаблон для копирования.

заполнение и готовый JSON-LD
несколько заполненных полей и фрагмент результата без персональных данных.
Шаг 5. Внедрите разметку без дубликатов
JSON-LD размещают в HTML страницы внутри элемента <script type="application/ld+json">. Реализация зависит от CMS и архитектуры:
- шаблон темы — для типов, общих для многих страниц;
- SEO-модуль или плагин — если он поддерживает нужные поля;
- менеджер тегов — только с пониманием ограничений и обязательной проверкой результата;
- серверный шаблон или компонент приложения — наиболее управляемый вариант для каталога.
Перед добавлением проверьте, не создаёт ли CMS разметку уже сейчас. Два плагина могут одновременно вывести две Organization, две цепочки крошек или разные цены одного товара. Само наличие нескольких сущностей допустимо, но противоречащие дубли запутывают данные.
Для повторяемых страниц не вставляйте статический JSON вручную. Карточка должна брать название, цену, наличие и изображение из товарной базы. Иначе разметка устареет раньше следующего аудита.
Шаг 6. Проверьте исходный HTML
После внедрения откройте валидатор микроразметки ITSEO и передайте URL. Он анализирует JSON-LD, Microdata и RDFa в серверном HTML, показывает найденные сущности, отсутствующие свойства и рекомендации с учётом типа страницы и сайта.

Проверка именно URL после публикации важнее проверки отдельного фрагмента:
- код мог не попасть в шаблон;
- CMS могла экранировать кавычки;
- данные могут выводиться только после JavaScript;
- на странице уже существует второй конфликтующий блок;
- робот может получать другой HTML, чем редактор в предпросмотре.
результат валидатора ITSEO
список найденных сущностей, одно предупреждение и одну рекомендацию. URL тестового сайта допустимо скрыть частично.
После исправлений дополнительно используйте официальный Rich Results Test Google для типов, поддерживающих расширенные результаты, и проверку URL в Search Console. Валидатор Schema.org отвечает за словарь и структуру, а инструмент поисковой системы — за пригодность к конкретной функции выдачи.
Ошибка, предупреждение и рекомендация: что исправлять первым
Ошибка
Нарушена структура или отсутствует обязательное поле. Такая сущность может не обрабатываться либо не соответствовать требованиям функции. Исправляйте до релиза.
Предупреждение
Часто отсутствует рекомендуемое свойство. Разметка может оставаться допустимой, но результат будет менее полным. Добавляйте поле, если на странице действительно есть данные.
Рекомендация
Совет по качеству или полноте, который нужно оценить в контексте. Не следует добавлять фиктивное значение только ради исчезновения сообщения.
Приоритет простой: достоверность → обязательные поля → согласованность с видимым контентом → рекомендуемые свойства.
Семь типичных ошибок
1. Размечать то, чего посетитель не видит
Если JSON-LD содержит цену, рейтинг или автора, эти сведения должны соответствовать странице. Официальные правила Google прямо запрещают разметку скрытого и вводящего в заблуждение контента.
2. Ставить Product на категорию товаров
Категория — список, а не один товар. Одна сущность Product с минимальной ценой всей категории описывает несуществующий объект.
3. Добавлять звёзды без реальных отзывов
AggregateRating должен опираться на реальные оценки, доступные пользователю. Самооценка «5 из 5» — не SEO-приём, а риск нарушения правил качества.
4. Оставлять старую цену или наличие
Это особенно часто происходит при ручном JSON-LD. Автоматизируйте вывод из единого источника.
5. Использовать относительные и закрытые URL изображений
Поисковый робот должен иметь доступ к изображению. Используйте абсолютный канонический URL и проверьте его ответ.
6. Дублировать разметку плагинами
Проверьте исходный код и список сущностей после каждого изменения SEO-модуля или темы.
7. Считать отсутствие расширенного сниппета ошибкой
Валидная разметка делает страницу подходящей для функции, но не гарантирует её показ. Решение зависит от алгоритмов, запроса, устройства и качества страницы.
Как поддерживать разметку после запуска
Микроразметка — часть продукта, а не разовая вставка кода.
- Повторно проверяйте шаблоны после редизайна и обновления CMS.
- Следите за отчётами Search Console и Яндекс Вебмастера.
- Проверяйте несколько URL каждого шаблона, а не только одну идеальную карточку.
- Добавляйте тесты на обязательные поля в процесс релиза.
- Сверяйте цену, наличие, даты и рейтинг с видимым контентом.
- Пересматривайте требования поисковых систем перед крупным обновлением.
Для большого сайта выберите по 3–5 страниц каждого типа: товар в наличии, без наличия, со скидкой, без отзывов; статья с автором и старая статья; филиал с полным и неполным адресом. Такой набор ловит шаблонные ошибки лучше проверки главной страницы.
Чек-лист перед публикацией
- Главная сущность соответствует типу страницы.
- Выбран самый конкретный корректный тип.
- Все значения правдивы и видимы пользователю.
- Обязательные свойства заполнены по актуальной документации поисковика.
- Цена, наличие, даты и рейтинг берутся из актуального источника.
- Нет противоречащих дублей от темы и плагинов.
- JSON-LD найден в итоговом HTML страницы.
- URL проверен в валидаторе ITSEO и официальном инструменте поисковой системы.
- После релиза настроен повторный контроль.
Начните с одной типовой страницы. Соберите достоверные поля в генераторе Schema.org ITSEO, внедрите код и проверьте опубликованный URL в валидаторе. Когда схема стабильно работает на одном шаблоне, масштабируйте её на раздел — так исправление ошибки не превратится в переработку тысяч страниц.