Микроразметка Schema.org: какие типы ставить, как внедрить и чем проверить

Микроразметка Schema.org — это способ записать содержание страницы словарём, который понимают роботы: вот организация, вот товар и его цена, вот вопрос и ответ.

Проверить её можно тремя бесплатными валидаторами: «Валидатор микроразметки» в Яндекс Вебмастере, Rich Results Test у Google и validator.schema.org. Они отвечают на три разных вопроса и регулярно расходятся в выводах.

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

Коротко.

• Schema.org — словарь структурированных данных, микроразметка — то, как этот словарь вписан в код. Формат по умолчанию — JSON-LD.
• Разметка работает не через позиции, а через вид страницы в выдаче: Google описывает её как путь к расширенным результатам.
• Три валидатора закрывают три разных вопроса: требования Яндекса, требования расширенного результата Google, корректность самого словаря. Показ в выдаче не гарантирует ни один.
• Разошлись выводы инструментов — это не диагноз, а повод пройти пять проверок по адресу: дата, доступность, поддерживаемые типы, исходный код против DOM, что получил сам инструмент.
• Универсального набора типов нет: ставят то, что на странице реально есть, — организацию, товар, услугу, человека, блок вопросов.

Что такое микроразметка Schema.org и как она связана со структурированными данными

Структурированные данные — это сами факты о странице в машиночитаемом виде. Микроразметка — синтаксис, которым эти данные вписаны в HTML. Связаны они как «что передаём» и «как записываем»: словарь один, способов записи три.

Робот видит страницу иначе, чем человек. Мы смотрим на карточку товара и сразу отделяем цену от артикула. Робот видит поток тегов, где цена — просто число рядом с другими числами.

Справка Яндекс Вебмастера описывает смысл разметки так: «Добавляя специальные теги к HTML-коду своих страниц, вы как бы говорите: „Эй, поисковая система, вот здесь описывается такой-то фильм (место, человек, видеоролик)“».

Schema.org — общедоступный словарь этих типов и свойств: Organization, Product, Service, Article, FAQPage и ещё несколько сотен.

Словарь объявили летом 2011 года Google, Bing и Yahoo!, и в том же году к проекту подключился Яндекс: schema.org называет его среди компаний-основателей.

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

В поиске словарь часто набирают с опечаткой — «shema org» или «схема орг». Это одно и то же: официальный адрес словаря — schema.org, и разметка с любым из написаний в запросе означает его же.

С помощью типа Organization сайт передаёт роботам контакты организации: название, телефон, адрес, регион работы и ссылки на соцсети.

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

Рядом живёт Open Graph — отдельный стандарт для соцсетей и мессенджеров: он управляет картинкой и заголовком ссылки в Telegram или ВКонтакте. Schema.org он не заменяет, нормальный сайт использует оба.

Как проверить микроразметку: три валидатора и что видит каждый

Проверять стоит всеми тремя: каждый отвечает на свой вопрос. Валидатор Яндекса — про требования Яндекса, Rich Results Test — про требования расширенных результатов Google, validator.schema.org — про сам словарь.

Ни один из трёх не отвечает на вопрос «покажет ли поисковик расширенный результат». Google к Rich Results Test пишет прямо: он не гарантирует, что страница будет выглядеть так, как в предпросмотре.

Валидатор Яндекса живёт в Вебмастере, в разделе инструментов. По справке он поддерживает «микроформаты, Schema.org, Open Graph, микроданные HTML и RDFa» и проверяет не только синтаксис, а соответствие требованиям сервисов Яндекса.

Если Вебмастер ещё не подключён — у нас есть гайд по Яндекс Вебмастеру. Массовую картину по сайту показывает Search Console в разделе «Улучшения»: там видно, на каких шаблонах разметка сломана.

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

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

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

Почему Google Search Console видит хлебные крошки schema.org, а validator.schema.org не видит

Одного диагноза у такого расхождения нет. Разные списки типов сами по себе не доказывают даже того, что инструменты читали разные данные: один и тот же HTML они разбирают по-разному.

Ходовое объяснение «разметку дописывает скрипт, а валидатор словаря её не видит» проверки не выдерживает.

В описании validator.schema.org среди его возможностей прямо названо извлечение структурированных данных, вставленных JavaScript, — «например виджетами».

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

Последовательность проверки одного адреса:

1. Дата и версия. Сверьте дату отчёта Search Console с датой последней правки шаблона. Валидатор смотрит на страницу сейчас, отчёт — какой она была на обходе.
2. Доступность. Открыт ли адрес для инструмента: robots.txt, авторизация, редирект, разный ответ для разных регионов и устройств.
3. Поддерживаемые типы. Rich Results Test разбирает только типы своих расширенных результатов, у валидатора Яндекса свой список, validator.schema.org — весь словарь.
4. Исходный и отрисованный HTML. Найдите application/ld+json в исходном коде и в отрисованном DOM. Есть только в DOM — блок вставляет скрипт. Это способ вставки, а не причина расхождения.
5. Что получил сам инструмент. Если он показывает разобранный им код, сверьте, есть ли нужный блок там. Заодно — ошибки в консоли у того скрипта, который ставит разметку: упал он или не загрузился его файл.

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

Таких данных инструмент показывает не всегда. Когда их нет, «это из-за JavaScript» остаётся гипотезой, и проверять дальше приходится по конкретному скрипту разметки.

Сама по себе вставка скриптом ошибкой не является: validator.schema.org по своему описанию извлекает данные, добавленные JavaScript, а Google страницы рендерит.

Зависимость от выполнения JavaScript можно просто убрать — отдавать JSON-LD в исходном HTML. Тогда результат не зависит от того, чей рендеринг и когда отработал.

Как читать ошибки и предупреждения

Сначала поймите, какого уровня ошибку вы смотрите. Уровня три, и каждый инструмент закрывает свой — поэтому «ошибок нет» у одного ещё не значит «всё в порядке».

• Синтаксис и словарь. Сценарий: в имени свойства опечатка — agregateRating вместо aggregateRating. Такого свойства в словаре нет. Ловит validator.schema.org.
• Требования расширенного результата. Сценарий: у страницы с покупкой нет priceCurrency — для товарного сниппета это рекомендация, для merchant listing требование. Ловит Rich Results Test.
• Совпадение с видимым содержимым. Сценарий: в коде цена 5 000, на витрине 7 500. Этого не ловит ни один валидатор — только сверка глазами или свой скрипт сравнения.

Формат цены стоит разобрать отдельно, потому что его чаще всего понимают неверно. Свойство price в словаре принимает и число, и текст, так что строка сама по себе ошибкой не является.

Мешает не строка, а то, что внутрь значения кладут знак валюты и пробелы. Schema.org советует вместо неоднозначных символов вроде «$» отдавать валюту в priceCurrency, а разделитель писать точкой.

То есть машинное значение — "price": "12990.00" и "priceCurrency": "RUB", а «12 990 ₽» остаётся человеку на витрине.

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

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

Важная оговорка: обязательное и рекомендованное — свойство сценария, а не поля. Товар без цены ошибкой быть не обязан: Google требует имя и одно из offers, review, aggregateRating.

Отдельный случай — валидатор всё разобрал, а в выдаче ничего нет. Так и должно быть.

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

Что даёт микроразметка, а что нет — и для чего нужно её внедрение

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

Замера «CTR до и после внедрения разметки» у нас нет: в опубликованных исследованиях такой пары по одной и той же странице не собрано. Поэтому рост кликов здесь — наблюдение, а не измеренный эффект.

Цепочка «заметный сниппет → больше кликов → сильнее поведенческие сигналы» выглядит логично, но мы её не проверяли, и в документации поисковиков её нет.

Что мы действительно померили — размер канала нейросетей: за 90 дней по 13 клиентским сайтам из ИИ-сервисов пришло 156 визитов против 87 769 органических, это 0,18% (срез от 21.09.2026).

Цифра говорит об объёме канала, а не о пользе разметки. Для своих ИИ-функций Google специальной разметки не требует и пишет об этом прямо.

Польза разметки для машин в другом: она снимает разночтения. Цена, адрес и автор отданы полями, а не угаданы из вёрстки. Подробнее — в гайдах по GEO-оптимизации и товарам в рекомендациях нейросетей.

Это наблюдение из практики, а не измеренный эффект: отделить разметку от остальных работ на тех же проектах мы не пробовали.

Второй аргумент за внедрение — состояние рынка. Корректная разметка до сих пор не стала гигиеническим минимумом, который есть у всех.

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

Форматы: JSON-LD, микроданные, RDFa

Словарь один, а вписать его в страницу можно тремя способами. Для нового сайта выбор очевиден — JSON-LD.

Google в справке по структурированным данным пишет, что все три формата для него равнозначны, «пока разметка корректна», а JSON-LD называет самым простым во внедрении и поддержке.

Так выглядит JSON-LD организации. Пример демонстрационный: домен, телефон и адрес здесь условные, подставьте свои настоящие.

Блок ставится в <head> или в конец <body>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Название компании",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "telephone": "+7 495 000-00-00",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Москва",
    "addressCountry": "RU"
  },
  "sameAs": [
    "https://vk.com/example",
    "https://t.me/example"
  ]
}
</script>

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

Какие типы ставить: Organization, Product, Service, FAQPage, Author

Типов в словаре сотни, рабочих — около десяти. Выбирают их не «для сайта», а под то, что на конкретной странице реально есть: товар, услуга, организация, человек, блок вопросов.

Author в этом списке — не тип, а свойство: автора статьи указывают полем author внутри Article или BlogPosting, а самого человека описывают типом Person на его странице.

Универсального набора «всем сайтам» нет. Личный сайт не обязан описывать организацию, у плоской структуры нет крошек, а карточка без блока вопросов не должна получать FAQPage.

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

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

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

С января 2025 года — только на десктопе. Из мобильной выдачи Google этот элемент убрал: на узком экране путь всё равно обрезался и пользы не приносил.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1,
     "name": "Главная", "item": "https://example.com/"},
    {"@type": "ListItem", "position": 2,
     "name": "Кроссовки", "item": "https://example.com/krossovki/"},
    {"@type": "ListItem", "position": 3,
     "name": "Кроссовки для бега, модель 270"}
  ]
}
</script>

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

Schema.org Product: обязательные поля

Google требует от Product немного. Обязательно имя товара и хотя бы одно из трёх свойств: offers, review или aggregateRating. Всё остальное — рекомендации.

Дальше требования уходят внутрь вложенных типов. У Offer обязательна цена. У AggregateRating — значение рейтинга и количество оценок или отзывов: хватает одного из полей ratingCount и reviewCount.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Кроссовки для бега, модель 270",
  "image": "https://example.com/images/krossovki-270.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/krossovki/model-270/",
    "price": "12990",
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "38"
  }
}
</script>

Дальше начинается то, о чём забывают. У Google два товарных сценария, и делятся они не по принципу «можно купить или нет».

Merchant listing — результаты, где покупатель может купить товар прямо у вас. Требований больше: name, image и вложенный Offer, а валюта из рекомендованной становится обязательной.

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

А shippingDetails, hasMerchantReturnPolicy и priceValidUntil остаются рекомендованными: их отсутствие валидатор покажет предупреждением, а не ошибкой.

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

Про саму карточку товара у нас есть отдельный гайд.

Важная поправка: наличие типа в словаре не значит, что поисковик что-то нарисует в выдаче.

Документацию по HowTo Google убрал в сентябре 2023 года с формулировкой, что «этот расширенный результат больше не показывается в выдаче». С FAQ история дошла до того же конца, но позже.

Сверяться стоит с галереей расширенных результатов Google. Из нашей таблицы в ней есть Product, Breadcrumb, Review snippet, Article, Organization и Local business.

FAQ и How-to в галерее нет. Такие типы работают на машинное понимание страницы, а не на картинку в выдаче, и это нормальная причина их ставить.

FAQPage или QAPage на карточке товара: какая разметка полезнее с точки зрения поиска

Если на карточке есть блок вопросов от самого магазина — это FAQPage; если такого блока нет, разметке там браться не из чего. QAPage — не альтернатива, а другой случай.

Google разрешает QAPage только там, где ответ на вопрос может оставить пользователь.

В справке Google примеры QAPage — страница форума и страница поддержки товара, где отвечают посетители. Страница с вопросами, написанными самим сайтом, под этот тип не подходит.

У Яндекса своя история. Его блок вопросов и ответов на мобильной выдаче построен именно на QAPage, и требования там жёсткие: «Одна страница сайта должна содержать один вопрос и ответы на него».

То есть карточка товара с пятью вопросами под описанием под мобильный блок Яндекса не подойдёт по определению. Остаётся FAQPage — и польза от него сегодня не в картинке в выдаче.

Расширенного результата из FAQPage в Google сегодня не получит никто. С 7 мая 2026 года функция перестала показываться, а 15 июня 2026 года её документацию удалили.

Исключение для известных государственных и медицинских сайтов, которое действовало с августа 2023 года, закончилось вместе с самой функцией.

Тип при этом остался в словаре и остаётся корректной разметкой. Наличие типа в schema.org и действующая функция поиска — разные вещи, и путать их не стоит.

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Сколько идёт доставка?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "По Москве — на следующий день, в регионы — 3–5 дней."
      }
    },
    {
      "@type": "Question",
      "name": "Можно ли вернуть товар?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Да, в течение 14 дней, если сохранён товарный вид."
      }
    }
  ]
}
</script>

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

Сроки доставки и возврата из примера подставьте свои фактические: «14 дней» — условие конкретного магазина, а не универсальная норма.

Что остаётся: пара «вопрос — короткий ответ» отдельными полями, а не абзацем, склеенным с остальным текстом страницы. Как собирать такие блоки — в разборе FAQ на карточке товара для AI-поиска.

Карточка врача или эксперта: какую микроразметку выбрать основной

На странице конкретного человека основной тип — Person, а клиника или компания подключается вложенно через worksFor. Логика простая: страница описывает человека, а не юрлицо.

Ловушка тут в типе Physician. По словарю это «отдельный врач или кабинет врача, рассматриваемый как MedicalOrganization» — он наследуется от Organization и LocalBusiness, а не от Person.

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

Schema.org для страниц с услугами

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

Практичнее всего связка: Service на самой услуге и Organization на сайте целиком. BreadcrumbList добавляют, если у сайта есть вложенность, FAQPage — если под услугой висит живой блок вопросов.

Как внедрить: WordPress, Битрикс, Тильда и самописный сайт

На популярных CMS разметку ставят плагином, а руками дописывают только то, чего плагин не умеет. На самописном сайте JSON-LD вписывают в шаблоны — один раз на шаблон, а не на страницу.

WordPress. SEO-плагины вроде Yoast и Rank Math из коробки отдают Organization, Article и BreadcrumbList, а для WooCommerce — базовый Product. Обычно достаточно один раз заполнить данные организации в настройках.

Руками дописывают частные типы: FAQPage там, где на странице есть блок вопросов, Person на страницах авторов. Ставить второй SEO-плагин ради разметки не нужно — получите дубли.

Битрикс. Часть шаблонов и модулей отдаёт микроданные сама, чаще всего крошки и товары в старом формате. Типовой путь — задача программисту: вписать JSON-LD в шаблоны разделов.

Готовые решения из Маркетплейса берут не всё и нередко дублируют то, что уже есть в шаблоне. Поэтому первый шаг на Битриксе — посмотреть, что страница отдаёт сейчас.

Тильда. Конструктор сам генерирует Open Graph и разметку магазинных блоков. Остальное добавляется своим кодом, по шагам:

1. Для одной страницы: «Настройки страницы» → «Вставка кода» → «HTML-код для вставки внутрь head».
2. Для всего сайта: «Настройки сайта» → «Ещё» → «HTML-код для вставки внутрь head». В части версий интерфейса раздел называется «Дополнительно» — поле в нём то же.
3. Вставьте блок JSON-LD целиком, вместе с тегом <script>, и сохраните.
4. Опубликуйте страницу заново, а при общем коде — все страницы: без публикации код в живой версии не появится.

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

Когда поле для head недоступно, тот же код кладут в блок «T123. HTML-код» из библиотеки блоков, раздел «Другое». Разметка окажется в теле страницы, а не в head — обоим поисковикам это подходит.

Так на Тильду вставляют и JSON-LD микроразметку типа Product: код из примера выше идёт в поле для head нужной страницы товара.

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

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

Собрать код можно генератором микроразметки. Из бесплатных обычно хватает Structured Data Markup Helper от Google: он размечает страницу мышкой и отдаёт готовый JSON-LD.

Нейросеть тоже соберёт блок по описанию. Но проверять результат валидатором нужно в любом случае: генераторы стабильно пропускают обязательные поля и путают близкие типы вроде Organization и LocalBusiness.

Порядок внедрения одинаковый для любой CMS:

1. Посмотреть, что страницы отдают сейчас, — чтобы не наплодить дублей поверх существующей разметки.
2. Составить карту: какой тип на какой шаблон страниц ставим.
3. Внедрить по шаблонам, начиная с денежных: карточки товаров и страницы услуг.
4. Прогнать через валидаторы по одной странице каждого шаблона, а потом по вариантам данных: товар без цены, без отзывов, под заказ.
5. Через 2–4 недели посмотреть отчёты Search Console и Вебмастера: подхватилась ли разметка и не появились ли ошибки.

Что не переедет само: старые микроданные в шаблоне остаются на месте и после установки плагина, а уже проиндексированные страницы обновят сниппет только после переобхода. Откат — снять новый блок и переопубликовать шаблон.

Как следить за разметкой дальше

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

Массовую картину дают отчёты «Улучшения» в Search Console и раздел микроразметки в Вебмастере. Там видно число страниц с ошибками и день, с которого они пошли, — по этой дате и ищут виноватый релиз.

Разумный ритм — заглядывать туда раз в месяц и обязательно после любого обновления CMS, шаблона или SEO-плагина.

Звёзды в выдаче и разметка отзывов: что работает, а что нет

Звёзды появляются из Review и AggregateRating, но только когда отзывы реально опубликованы на странице. Гарантии показа нет ни у Яндекса, ни у Google — это всегда решение поисковика.

Самый частый запрос от клиентов звучит как «хотим звёздочки, как у конкурента». Технически это делается за час. Проблема начинается, когда отзывов под звёздами нет.

И ещё до всякого риска работает ограничение, о котором почти не пишут. Звёзды из Review и AggregateRating Google отдаёт товарам, книгам, рецептам, фильмам и приложениям.

А для типов Organization и LocalBusiness — только сайтам, которые собирают отзывы о других компаниях. Отзывы о себе Google называет self-serving и звёзды за них не показывает.

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

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

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

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

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

Частые ошибки разметки — и как их поймать до индексации

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

Вот что повторяется в наших аудитах чаще всего.

• Разметка расходится с контентом. В коде цена 5 000, на витрине давно 7 500; рейтинг 4,9 при пустом блоке отзывов. Это прямой путь к недоверию поисковика.
• Размечена только главная. Organization на главной есть, а карточки товаров и страницы услуг — те, что приносят деньги — остались без разметки.
• Дубли. Плагин отдаёт Product, и программист когда-то добавил свой. Поисковик получает два противоречащих описания одного товара.
• Пропущены обязательные поля. AggregateRating без количества оценок, Review без автора, LocalBusiness без адреса. Валидатор ловит это сразу.
• Цена живёт своей жизнью. В разметке нет availability, а priceCurrency на витрине с покупкой обязателен; на распродаже цена в коде не меняется вместе с ценником.
• Размечено невидимое. FAQPage в коде есть, блока с вопросами на странице нет. Для поисковика это то же самое, что фиктивный рейтинг.

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

Микроразметка — один из пунктов внутренней оптимизации. Полный список работ этого слоя — в чек-листе внутренней оптимизации, а фундамент под ней разбираем в гайде по техническому SEO.

FAQ: микроразметка Schema.org

Что такое микроразметка простыми словами?

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

Человек этот код не видит — его читают поисковики и нейросети.

Влияет ли микроразметка на позиции сайта?

Напрямую — нет. В документации Google разметка описана как путь к расширенным результатам; фактором ранжирования Google её не называет.

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

Какой формат микроразметки выбрать?

JSON-LD: отдельный script-блок, который рекомендует Google и понимает Яндекс. Все три формата для Google равнозначны, но JSON-LD проще внедрять и править.

Если на сайте уже есть корректные микроданные — срочно переделывать их не нужно, новые типы добавляйте в JSON-LD.

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

Универсального минимума нет: начинают с того, что на странице есть. Сайт компании описывают через Organization (или LocalBusiness при офлайн-точках), магазин — Product с Offer, сайт услуг — Service, блог — Article.

BreadcrumbList — при реальной вложенности, FAQPage — при живом блоке вопросов. Отзывы и рейтинг в последнюю очередь и только когда отзывы опубликованы на странице.

Как проверить микроразметку сайта?

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

Формальную корректность по словарю проверяет validator.schema.org, а картину по всему сайту — отчёты «Улучшения» в Search Console.

Валидатор не нашёл ошибок, а расширенного сниппета нет — почему?

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

Вторая причина — у типа просто нет действующего расширенного результата. FAQ-блок Google перестал показывать 7 мая 2026 года, HowTo — ещё в сентябре 2023-го.

Можно ли получить звёзды в выдаче без реальных отзывов?

Технически можно, но это спам в структурированных данных. По правилам Google такая страница теряет право на расширенный результат, а Яндекс перестаёт доверять разметке сайта.

Отдельно: за отзывы о самом себе Google звёзды не показывает и при настоящих отзывах — только сайтам, которые собирают отзывы о других компаниях.

Что проверить на своём сайте за 15 минут

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

1. Соберите пять адресов — по одному на шаблон: главная, карточка товара, категория, страница услуги, статья. Дальше работаете только с ними.
2. Прогоните эти пять через валидатор микроразметки Яндекс Вебмастера и выпишите, какие типы он нашёл на каждом.
3. Те же пять — через Rich Results Test. Списки типов не сошлись хотя бы на одном адресе — пройдите по нему пять проверок из раздела о расхождении валидаторов.
4. Сверьте цену и рейтинг в найденной разметке с тем, что написано на самой странице. Расхождение — первое, что нужно чинить.

Чтобы не гонять каждый адрес по двум вкладкам, разметку, Open Graph и ошибки в них показывает наше бесплатное расширение для SEO-аудита — прямо на открытой странице, вместе с остальной технической частью.