Зачем сайту разметка Schema.org

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

Что дают структурированные данные

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

Какие типы полезны коммерческому сайту

Не любой тип из справочника Schema.org одинаково нужен. Для сайта услуг или магазина набор обычно такой:

• Organization или ProfessionalService — кто оказывает услугу, в каком городе, по какому телефону.
• Service — конкретная услуга: название, описание, цена от, если она фиксирована как минимальная, а не единственная.
• Article — статья блога: автор, дата публикации и обновления, заголовок.
• BreadcrumbList — хлебные крошки: путь от главной до текущей страницы.
• FAQPage — вопросы и ответы на странице услуги.

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

Почему JSON-LD, а не микроразметка

У Schema.org есть два способа встроить данные в страницу: микроразметка атрибутами прямо в видимых тегах и JSON-LD — отдельный блок, не связанный с вёрсткой. Микроразметка ломается при любой правке дизайна: переставили div, атрибут уехал не туда, разметка сломалась незаметно. JSON-LD живёт отдельно от разметки страницы, поэтому редизайн его не задевает, а собрать один и тот же блок для однотипных страниц шаблоном — с типизацией и проверкой на сборке — проще, чем следить за атрибутами в каждом файле вручную. Это и закладывается при разработке сайта: разметка генерируется из тех же данных, что и видимый текст, поэтому одно с другим не расходится.

Пример разметки

Блок для страницы услуги может выглядеть так — это иллюстрация формата, не готовый к копированию код:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Продвижение сайта",
  "description": "Поисковое продвижение сайта в Яндексе и Google",
  "url": "https://example.ru/uslugi/prodvizhenie",
  "provider": {
    "@type": "Organization",
    "name": "Компания «Пример»"
  }
}

Такой блок кладётся в тег script с типом application/ld+json и не влияет на то, что видит посетитель страницы.

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

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

Типичные ошибки

Разметка расходится с текстом на странице — например, priceSpecification называет одну сумму, а в тексте написана другая: расхождение подрывает доверие к обеим версиям. Забывают обновлять dateModified у статьи после правки текста — тогда разметка утверждает, что материал не менялся, хотя менялся. Ставят один и тот же @id организации на разных страницах с разными данными — тогда для поисковика это два разных описания одной сущности, и непонятно, какое верное.

Чего разметкой не делать

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