Микроразметка Schema.org: что даёт сайту и как внедрить

Что микроразметка Schema.org даёт сайту

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

Представим карточку настольного светильника. Человек понимает по оформлению, где название, фотография и стоимость. В структурированных данных эти связи задают отдельно: объект Product описывает товар, а вложенный Offer — предложение с ценой и доступностью. Это дополнительное описание уже существующей информации.

Мы советуем начинать с вопроса «какие сведения нужно передать и кому?». Для интернет-магазина это могут быть товары и предложения, для корпоративного сайта — организация и навигация, для блога — статьи. Разметить всё доступными типами ради количества — плохая постановка задачи: сначала выбирают подходящий сценарий поисковой системы.

Какой результат можно ожидать

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

Из этого нельзя вывести обещание «после внедрения трафик вырастет». Google прямо предупреждает: даже корректная разметка не гарантирует показа расширенного результата. Яндекс также оставляет за собой выбор, использовать ли переданные данные. Поэтому принимать работу только по скриншоту выдачи ненадёжно: сначала проверяют код, содержание и доступность страницы.

Микроразметка не заменяет понятный текст, навигацию и заполнение title и description. Если на странице нет цены или фактического адреса, скрипт не должен создавать их из предположений. Начать стоит с полноты самой страницы, затем описать её машиночитаемым способом.

JSON-LD, микроданные и RDFa: как записать одни сведения

Schema.org — словарь: он определяет типы и свойства. Формат отвечает за то, как записать их в документе. Например, Product остаётся типом товара и в JSON-LD, и в микроданных. Называть JSON-LD «другой микроразметкой вместо Schema.org» неточно: эти названия относятся к разным уровням.

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

В справке Вебмастера об организациях пример дан микроданными, а для товаров справка Яндекс Товаров рекомендует и микроданные, и JSON-LD. Если проекту нужны соответствующие представления в обеих системах, разработчик должен проверить их требования отдельно. Не стоит автоматически удалять работающие HTML-атрибуты после добавления скрипта для Google.

Какие типы нужны Google и Яндексу

Ниже — не полный словарь Schema.org, а карта основных задач сайта по официальным справкам поисковых систем. «Есть в словаре», «распознаётся валидатором» и «используется для специального представления в поиске» — разные утверждения.

Отсутствие Article в списке специальных представлений Яндекса не доказывает, что система не читает такие данные. Но обещать расширенный сниппет обычной статьи только на основании валидного BlogPosting нельзя.

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

Organization, LocalBusiness и хлебные крошки: примеры JSON-LD

Все примеры ниже учебные. Компания «Пример», товары, даты, адреса и цены условны, а example.com используется как демонстрационный домен. Перед внедрением замените значения реальными сведениями страницы. Это не данные студии и не готовый код для копирования на любой сайт.

Organization: кто стоит за сайтом

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Компания Пример",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png"
}
</script>

Поле @id задаёт идентификатор объекта. С его помощью другие блоки могут ссылаться на ту же организацию, например как на издателя статьи. Это не требование создавать отдельную страницу с адресом #organization.

LocalBusiness: конкретная точка или филиал

LocalBusiness относится к физическому предприятию или филиалу. Для онлайн-компании без такой точки не нужно изобретать адрес, чтобы использовать этот тип. В инструкции Google обязательны name и address; если есть более точный подходящий подтип, выбирают его. Для Яндекса дополнительно сверяют список поддерживаемых организационных схем.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Магазин Пример",
  "url": "https://example.com/shop/",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Учебная улица, 1",
    "addressLocality": "Москва",
    "addressCountry": "RU"
  }
}
</script>

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

BreadcrumbList: где находится страница

Навигационная цепочка описывает положение материала в иерархии. Для Google нужны как минимум два элемента ListItem. В них указывают название и позицию, а ссылку item у последнего элемента можно не задавать. В примере оставлены все адреса, чтобы связь была нагляднее.

<script type="application/ld+json">
{
  "@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/table-lamps/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Светильник Серия",
      "item": "https://example.com/catalog/table-lamps/seriya/"
    }
  ]
}
</script>

Яндекс тоже описывает BreadcrumbList в JSON-LD. Проверьте адреса промежуточных разделов, заполненные названия и числовые позиции. Поисковая система может сократить цепочку при показе. А если самих разделов нет или они недоступны посетителю, сначала исправьте структуру сайта для SEO, затем её описание.

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

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

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Настольный светильник Серия",
  "description": "Настольный светильник с металлическим основанием.",
  "image": "https://example.com/images/seriya.jpg",
  "sku": "LS-01",
  "brand": {
    "@type": "Brand",
    "name": "Пример"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/catalog/table-lamps/seriya/",
    "price": "12900",
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock"
  }
}
</script>

В price передают число или числовую строку без знака валюты и разделителя тысяч. При дробной части используют точку. Валюта записывается отдельно: RUB — код российского рубля. В availability указывают фактическое состояние предложения; InStock не должно оставаться постоянной надписью в шаблоне после исчезновения товара из продажи.

Почему нет одного обязательного набора полей

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

У Яндекса свой перечень обязательных полей: у Product — name, brand и image, у Offer — availability, price (или lowPrice) и priceCurrency. Справка Яндекс Товаров рекомендует для товаров микроданные или JSON-LD и приводит JSON-LD-пример той же структуры, что выше. Перед запуском проверьте страницу валидатором Вебмастера.

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

Что проверить на реальном каталоге

• Видимая цена и price рассчитаны по одному предложению, в одной валюте и для тех же условий.
• Выбранный размер, цвет или комплектация соответствуют товару, о котором сообщает разметка.
• Адрес картинки ведёт на фотографию именно этого товара; файл доступен поисковому роботу.
• После обмена с учётной системой меняются и карточка, и структурированные данные.
• Отсутствие товара отражено фактическим availability, а не шаблонным InStock.
• Страница категории не выдаётся за один Product с искусственно выбранной ценой.

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

Статьи и FAQ: полезная разметка без устаревших обещаний

Article и BlogPosting

Для записи корпоративного блога подходит BlogPosting — один из типов, перечисленных Google в инструкции Article. Через него передают заголовок, автора, иллюстрацию и даты. У этой инструкции нет универсального набора обязательных свойств: добавляют рекомендуемые данные, которые действительно относятся к материалу.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Как выбрать настольный светильник",
  "image": "https://example.com/images/lamp-guide.jpg",
  "datePublished": "2026-10-20T10:00:00+03:00",
  "dateModified": "2026-10-22T12:00:00+03:00",
  "author": {
    "@type": "Organization",
    "name": "Редакция компании Пример",
    "url": "https://example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Компания Пример",
    "url": "https://example.com/"
  }
}
</script>

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

Для Яндекса не обещайте специальное оформление обычной статьи на основании BlogPosting. Текст по-прежнему должен самостоятельно отвечать на вопрос читателя. Код не добавляет материалу несуществующую экспертизу и не подтверждает достоверность написанного.

FAQPage: тип существует, показ Google прекращён

Раньше Google ограничивал расширенные результаты FAQ известными авторитетными государственными и медицинскими сайтами. Это историческое правило 2023 года. Согласно журналу Google Search Central, с 7 мая 2026 года такое представление больше не показывается, а 15 июня документация о нём удалена.

Сам тип FAQPage остался в Schema.org. Его можно использовать для описания реального раздела частых вопросов, если для этого есть задача, но внедрять его ради раскрывающихся ответов в Google сейчас не следует.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Есть ли у светильника сменный источник света?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Да, в этой учебной модели источник света сменный."
      }
    }
  ]
}
</script>

Пример показывает только устройство JSON-LD; учебный ответ нельзя переносить в карточку реального товара без проверки. У Яндекса для мобильных ответов описан QAPage: одна страница с одним вопросом и ответами пользователей. Обычный блок из разных частых вопросов в конце статьи не нужно переименовывать в QAPage ради сниппета.

Как внедрить микроразметку на 1С-Битрикс

В 1С-Битрикс разметку удобно формировать там, где уже собраны данные страницы: в пользовательском шаблоне компонента. Для статьи это может быть news.detail, для товара — catalog.element, для навигации — соответствующий шаблон цепочки. Точное место зависит от устройства проекта, особенно если страницы выводит комплексный компонент.

Общие возможности CMS разобраны в статье о выборе 1С-Битрикс для сайта. Здесь задача уже конкретная: получить согласованное описание текущей страницы и проверить его после работы шаблона и кеша.

Сначала найдите уже существующую разметку

Перед изменениями откройте итоговый HTML и найдите application/ld+json, itemscope и itemtype. Готовое решение, модуль и шаблон могли добавить данные независимо друг от друга. Несколько разных сущностей на одной странице допустимы, но конфликтующие описания одной организации или товара нужно согласовать.

1. Составьте карту типов страниц и нужных поисковых сценариев.
2. Назначьте источник каждого поля: название элемента, описание, файл картинки, рассчитанное предложение, дата публикации.
3. Определите место вывода, чтобы общий шаблон и компонент не создавали противоречащие друг другу объекты.
4. Подготовьте изменения на тестовой копии, затем проверьте их на разных страницах и состояниях.

Используйте пользовательскую копию шаблона

В документации 1С-Битрикс пользовательские шаблоны размещены в /local/templates/. Системный шаблон править не рекомендуется: обновление может восстановить его исходное состояние. Например, для отдельного компонента статьи путь может выглядеть так:

/local/templates/main/components/bitrix/news.detail/article/
  result_modifier.php
  template.php

Названия main и article здесь условные. У комплексного компонента путь к дочернему шаблону может отличаться. Разработчик должен найти реально подключённую копию, а не создать файл по примеру и предположить, что система начнёт его использовать.

Подготовьте данные и передайте их JSON-кодировщику

result_modifier.php позволяет подготовить результат перед подключением шаблона. В нём можно собрать массив для JSON-LD из проверенных полей текущей страницы. В template.php остаётся вывод. Не склеивайте JSON вручную строками: кавычка в названии или перенос в описании могут нарушить синтаксис.

Ниже — фрагмент template.php. Мы предполагаем, что разработчик уже подготовил массив SCHEMA_ARTICLE в result_modifier.php. Это выбранное для примера имя, а не штатное поле Битрикс. Массив должен содержать данные по образцу BlogPosting выше, со значениями конкретной статьи.

<?php
$schema = $arResult['SCHEMA_ARTICLE'] ?? null;
if (is_array($schema) && !empty($schema)) {
    try {
        $json = \Bitrix\Main\Web\Json::encode($schema);
        echo '<script type="application/ld+json">';
        echo $json;
        echo '</script>';
    } catch (\Bitrix\Main\ArgumentException $e) {
        // разметку не выводим, ошибку записываем в журнал проекта
    }
}
?>

Метод Json::encode превращает PHP-значение в JSON. Его стандартные параметры включают экранирование HTML-значимых символов, что подходит для помещения результата в script. Обычное HTML-экранирование всей JSON-строки здесь не подставляют вместо JSON-кодировщика. При ошибке кодирования метод выбрасывает исключение ArgumentException, поэтому вызов обёрнут в try: страница выйдет без разметки, а не с ошибкой. Проверяют именно тот текст, который попал в готовую страницу.

Проверьте кеш и обновление содержимого

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

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

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

Как проверить разметку: три инструмента и ручная сверка

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

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

Порядок приёмки

1. Откройте страницу без режима редактирования и сравните её с машинным описанием: название, цена, валюта, наличие, автор, адрес, даты.
2. Передайте код в Schema Markup Validator и посмотрите, какие объекты и свойства он распознал.
3. Проверьте нужные Google-сценарии в Rich Results Test. Исправьте критические ошибки; рекомендации оцените по фактическим данным страницы.
4. Для Яндекса проверьте разметку его валидатором и сопоставьте результат с инструкцией конкретного типа.
5. После публикации повторите проверку по URL. Убедитесь, что роботу доступны страница и изображения, а доступ не требует входа.
6. После обхода отслеживайте состояние поддерживаемых представлений в инструментах поисковых систем. Отдельно оценивайте показы и переходы, не приписывая любое изменение одному внедрению.

Если сайт ещё не проверяли технически, включите эти действия в SEO-аудит. Отчёт должен различать «код исправен», «данные получены роботом» и «представление появилось в поиске». Между этими состояниями нет автоматического перехода по обещанному сроку.

Ошибки, которые не исправить добавлением ещё одного типа

• Размечен невидимый контент. В скрипте есть ответы, рейтинг или условия, которых посетитель не находит на странице. Уберите неподтверждённые сведения из разметки; достоверные данные, которые нужны посетителю, добавьте и в видимый текст.
• Подставлены ложные значения. Постоянные InStock, нулевая цена вместо «по запросу», выдуманный автор не становятся достоверными после успешной проверки.
• Перепутаны товар и раздел. Не переносите пример одного Product на страницу с разными товарами. Для категории в Яндексе описан OfferCatalog, а Google рекомендует товарную разметку на страницах отдельных товаров.
• Данные расходятся между блоками. Модуль и пользовательский шаблон сообщают разные цены. Найдите источники вывода и устраните противоречие.
• Старое правило выдано за актуальное. Инструкция обещает FAQ в Google. Сверьте дату и журнал изменений, а не только наличие FAQPage в словаре.
• Проверили только вставленный пример. После импорта или кеширования на странице другой код. Проверяйте фактически отданный HTML и доступный роботу результат.

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

Частые вопросы

Нужна ли микроразметка небольшому корпоративному сайту?

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

Повышает ли Schema.org позиции в поиске?

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

Что выбрать: JSON-LD или микроданные?

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

Можно ли получить FAQ-сниппет после добавления FAQPage?

В Google такой показ прекращён с 7 мая 2026 года. У Яндекса документирован другой случай — QAPage для страницы одного вопроса и ответов на него в мобильной выдаче. Обычный раздел частых вопросов полезен читателю, но сам по себе не соответствует этому сценарию.

Достаточно ли установить готовый модуль Битрикс?

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

Почему ошибок нет, а расширенного результата не видно?

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

Источники

• Определение структурированных данных и форматы — Google Search Central, введение в структурированные данные.
• Соответствие содержимому и отсутствие гарантии показа — Google Search Central, общие правила.
• Поддерживаемые поисковые функции — галерея Google; отдельные инструкции: Organization, BreadcrumbList, LocalBusiness, Article.
• Товарные сценарии Google — Product snippets и Merchant listings.
• Изменения FAQ — журнал Google Search Central, записи 8 мая и 15 июня 2026 года; историческое ограничение — объявление от 8 августа 2023 года; описание типа — FAQPage в Schema.org.
• Особенности Яндекса — JSON-LD, навигационные цепочки, информация о товарах (в том числе OfferCatalog для каталогов), строгая микроразметка товаров,адреса и организации, мобильные вопросы и ответы.
• Форматы и обязательные поля товарной разметки, отсутствие прямого влияния на ранжирование — Яндекс Товары, «Семантическая разметка страниц с товарами».
• Формат цены — Schema.org, свойство price; точность важнее полноты свойств — Google Search Central, введение в структурированные данные.
• Границы словаря и поисковых сценариев —Schema.org в справке Яндекса; определение физического предприятия — LocalBusiness в Schema.org; идентификаторы объектов — W3C, JSON-LD 1.1.
• Проверка Google — Rich Results Test; общая проверка — Schema Markup Validator и его документация; проверка Яндекса — валидатор Вебмастера и его справка.
• Внедрение в CMS — 1С-Битрикс: шаблоны компонентов, result_modifier.php, Json::encode.