Микроразметка Schema.org: от первой строки кода до расширенного сниппета

Что такое микроразметка и зачем она нужна

Поисковый робот видит страницу как текст с тегами. Он неплохо догадывается о смысле, но именно догадывается. Строка «1290 ₽» на странице — это цена товара, стоимость доставки или сумма скидки? Дата 12.09.2026 — день публикации, дата события или срок акции? Человек поймёт по контексту, машине приходится строить предположения.

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

Словарь появился 2 июня 2011 года как совместная инициатива Bing, Yahoo и Google — редкий случай, когда конкурирующие поисковики договорились об общем стандарте. В ноябре того же года к проекту присоединился Яндекс. Словарь развивается до сих пор: актуальная версия — 30.0, опубликована 19 марта 2026 года.

Что микроразметка даёт на самом деле

Раз позиций она не даёт, разберём, ради чего её внедряют.

Расширенный сниппет и кликабельность

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

Google приводит в документации данные компаний, внедривших разметку: Nestlé замерила на 82% более высокую кликабельность у страниц, показывавшихся расширенным результатом, по сравнению с обычными; Rakuten зафиксировала в полтора раза большее время на странице. Это не гарантия такого же результата у вас — это порядок величины, ради которого работу делают.

Понимание сущностей и Knowledge Graph

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

Сигнал достоверности

Разметка задаёт машиночитаемые факты, которые совпадают с видимым текстом. Это упрощает извлечение данных не только Google, но и другим системам, которые читают веб, — от Bing до поисковых роботов ИИ-сервисов.

Три синтаксиса и почему выбирают JSON-LD

Один и тот же словарь Schema.org можно записать тремя способами.

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

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

Анатомия JSON-LD: разбираем по частям

Минимальный рабочий блок выглядит так:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Neorank",
  "url": "https://neorank.ru"
}
</script>

Разберём каждый элемент:

• type="application/ld+json" — обязательный тип блока. Именно по нему робот понимает, что внутри разметка, а не обычный скрипт.
• @context — указание на словарь. Практически всегда https://schema.org. Без него набор свойств не с чем сопоставить.
• @type — тип описываемой сущности: Organization, Product, Article. Определяет, какие свойства вообще применимы.
• Дальше идут свойства — пары «название: значение». Их набор зависит от типа.

Вложенность: сущность внутри сущности

Свойство может быть не строкой, а другим объектом со своим @type. Так описываются связи: у статьи есть автор, у автора — своё описание.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Микроразметка Schema.org",
  "author": {
    "@type": "Person",
    "name": "Сергей Костюк",
    "url": "https://neorank.ru/about"
  }
}

Массивы: несколько значений

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

Что Google поддерживает сейчас

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

В галерее есть и более узкие типы: Course list, Dataset, Education Q&A, Employer aggregate rating, Image metadata, Math solver, Movie, Speakable, Vacation rental, а также разметка платного контента. Полный перечень стоит сверять по официальной галерее Google перед внедрением — он меняется чаще, чем принято думать.

Что Google убрал: хронология

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

Отдельно про FAQ: что это значит на практике

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

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

Расширенный результат FAQ — раскрывающийся блок вопросов под ссылкой в выдаче. Вот его больше нет.

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

Пять типов, которые нужны почти всем

Если не углубляться в отраслевые случаи, базовый набор выглядит так. Код ниже можно взять за основу, заменив значения на свои.

1. Organization — кто владеет сайтом

Ставится один раз на главной странице. Описывает организацию: название, логотип, контакты, официальные профили.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.ru/#organization",
  "name": "Название компании",
  "url": "https://example.ru",
  "logo": "https://example.ru/logo.png",
  "email": "info@example.ru",
  "telephone": "+7 000 000-00-00",
  "sameAs": [
    "https://vk.com/example",
    "https://t.me/example"
  ]
}

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

2. BreadcrumbList — навигационная цепочка

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

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Главная",
      "item": "https://example.ru"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Каталог",
      "item": "https://example.ru/catalog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Название товара"
    }
  ]
}

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

3. Article — для материалов блога

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

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Заголовок материала",
  "description": "Краткое описание",
  "image": "https://example.ru/cover.jpg",
  "datePublished": "2026-09-02",
  "dateModified": "2026-10-12",
  "author": {
    "@type": "Organization",
    "name": "Название компании",
    "url": "https://example.ru/about"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Название компании",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.ru/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.ru/blog/material"
  }
}

4. Product — для карточки товара

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

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Название товара",
  "image": "https://example.ru/product.jpg",
  "description": "Описание товара",
  "sku": "ART-12345",
  "brand": {
    "@type": "Brand",
    "name": "Производитель"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.ru/product",
    "price": "1290.00",
    "priceCurrency": "RUB",
    "availability": "https://schema.org/InStock"
  }
}

Значение availability — не произвольный текст, а адрес из словаря: InStock, OutOfStock, PreOrder, BackOrder. Цена пишется числом без пробелов и символа валюты; сама валюта — отдельным свойством в коде RUB, KZT, BYN.

5. LocalBusiness — для бизнеса с адресом

Нужен всем, к кому приходят физически: магазинам, клиникам, кафе, салонам. Вместо общего LocalBusiness лучше брать конкретный подтип — Restaurant, Dentist, BeautySalon: чем точнее тип, тем лучше поисковик понимает контекст.

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Название заведения",
  "image": "https://example.ru/photo.jpg",
  "telephone": "+7 000 000-00-00",
  "priceRange": "1000-2500 ₽",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "ул. Примерная, 1",
    "addressLocality": "Москва",
    "postalCode": "101000",
    "addressCountry": "RU"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
    "opens": "10:00",
    "closes": "22:00"
  }]
}

Уровень выше: связывание сущностей через @id

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

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

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Заголовок материала",
  "publisher": { "@id": "https://example.ru/#organization" }
}

В качестве идентификатора берут адрес с якорем — #organization, #website. Он не обязан существовать как реальная страница: это метка, а не ссылка. Главное — использовать её одинаково по всему сайту.

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

Правила Google, за нарушение которых прилетает

У разметки есть отдельные правила, и они входят в спам-политику. Санкция называется «скрытые или несоответствующие структурированные данные» и снимает право на расширенные результаты — иногда по всему сайту.

• Разметка обязана соответствовать видимому содержимому. Главное правило. Если в коде цена 1290 ₽, а на странице 1990 ₽ — это нарушение. Разметка описывает то, что человек видит, а не то, что хотелось бы показать поисковику.
• Размечать можно только то, что есть на странице. Нельзя добавить Recipe на страницу без рецепта или Product на страницу услуги, чтобы получить звёзды.
• Нельзя размечать чужие отзывы как свои. Рейтинг в разметке должен относиться к тому, что описано на странице, и собираться из реальных отзывов на ней же.
• Разметка не должна вводить в заблуждение. Оценка 5,0 при отсутствии отзывов, «в наличии» при отсутствии товара, вымышленный автор — всё это нарушения.
• Содержимое не должно быть скрыто от пользователя. Данные могут находиться в свёрнутом блоке или во вкладке — это допустимо. Недопустимо, когда они существуют только в коде.

Как внедрить разметку

Куда вставлять

Блок <script type="application/ld+json"> размещают в <head> или перед закрывающим </body>. Разницы для поисковика нет. На одной странице может быть несколько блоков — например, Article и BreadcrumbList отдельно; объединять их в один не требуется.

Через систему управления сайтом

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

Вручную

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

Через диспетчер тегов — с осторожностью

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

Как проверить, что всё работает

Три инструмента, и они решают разные задачи — их постоянно путают.

Разница принципиальная. Валидатор schema.org скажет «ошибок нет» для типа, который Google давно не поддерживает, — он проверяет соответствие словарю, а не пригодность для выдачи. Rich Results Test, наоборот, ничего не покажет для типа вне галереи Google, хотя разметка корректна. Для задач SEO ориентироваться нужно на Rich Results Test.

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

Семь ошибок, которые встречаются чаще всего

• Разметка не совпадает с содержимым страницы. Разобрано выше — самая дорогая ошибка из списка.
• Разметка типа, который отключён. HowTo и FAQPage расширенных результатов больше не дают. Вреда нет, но и эффекта тоже.
• Забыт @context. Без него блок не связывается со словарём, и разметка игнорируется целиком.
• Синтаксическая ошибка в JSON. Лишняя запятая после последнего свойства, неэкранированная кавычка внутри строки, «умные» кавычки после копирования из редактора — блок не разбирается, ошибок в выдаче не видно, просто ничего не происходит.
• Неверный формат даты. Требуется ISO 8601: 2026-09-02, а не 02.09.2026.
• Разметка на служебных страницах. Product на странице корзины или результатов фильтра — источник шума и ошибок в отчётах.
• Внедрили и забыли. Разметка живёт вместе с сайтом: сменился шаблон, обновилась CMS, переехали адреса — и она молча ломается. Проверять состояние в Search Console стоит регулярно, а не однократно после внедрения.

Микроразметка и Яндекс

Яндекс участвует в проекте Schema.org с ноября 2011 года и поддерживает тот же словарь, поэтому отдельную разметку «для Яндекса» делать не нужно — один корректный блок JSON-LD работает на обе системы.

Различия в деталях. Наборы обязательных полей и перечень оформлений выдачи у Яндекса свои и не совпадают с галереей Google один в один; для проверки в Вебмастере есть собственный валидатор структурированных данных. Практический подход простой: собирать разметку по требованиям Google как по более строгим и подробным, а затем прогонять её через валидатор Яндекса — если тип поддерживается обеими системами, корректный код пройдёт обе проверки.

С чего начать: порядок действий

1. Проверьте, что уже есть. Прогоните несколько типовых страниц через Rich Results Test и загляните в «Улучшения» в Search Console. Нередко выясняется, что разметка стоит, но с ошибками.
2. Закройте базу: Organization на главной и BreadcrumbList на внутренних страницах. Быстро внедряется, работает на любом сайте.
3. Добавьте профильный тип под характер сайта: Product для магазина, Article для блога, LocalBusiness для офлайн-бизнеса, Event для мероприятий.
4. Свяжите сущности через @id, если продвигаете бренд и хотите цельную картину вместо разрозненных блоков.
5. Поставьте на контроль. Раз в квартал сверяйте отчёты Search Console и проверяйте, не отключил ли Google используемый вами тип.

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

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

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

Нет, это подтверждено Google напрямую. Она влияет на оформление результата, а оформление — на кликабельность. Косвенный эффект есть, прямого влияния на ранжирование нет.

Через сколько появится расширенный сниппет?

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

Нужно ли удалять разметку FAQ и HowTo?

Не обязательно. Google подтверждает, что неиспользуемая разметка не вредит, а FAQPage остаётся валидным типом Schema.org. Но при следующей переработке шаблонов её разумно убрать, чтобы не раздувать код без пользы. Чего точно не стоит делать — добавлять новые блоки FAQ в расчёте на сниппет.

Можно ли использовать несколько блоков разметки на странице?

Да, и это обычная практика: Article, BreadcrumbList и Organization спокойно живут отдельными блоками на одной странице.

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

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

Работает ли разметка для попадания в ИИ-ответы?

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

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

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

Коротко

Микроразметка не поднимает позиции — она даёт право на расширенное оформление результата, а оно уже приносит клики. Формат один и тот же для Google и Яндекса, рекомендуемый синтаксис — JSON-LD, обязательные поля задаёт документация Google, а не сам словарь Schema.org.

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

И держите в голове, что список поддерживаемых типов сжимается: с 2023 года Google отключил HowTo, семь типов летом 2025-го и FAQPage в мае 2026-го. Устойчиво работает разметка проверяемых фактов — цена, наличие, адрес, дата. На неё и стоит тратить время.

Источники

Сверено с источниками на 12 октября 2026 года. Использована документация Google, Яндекса и schema.org; принципы работы структурированных данных, правила Google, отключение расширенного результата FAQ и перечень форматов разметки, которые читает Яндекс, сверены с оригиналами.

1. Google Search Central. Intro to how structured data markup works.
2. Google Search Central. General structured data guidelines.
3. Google Search Central. Removing documentation for the FAQ rich result feature (запись в журнале обновлений, июнь 2026).
4. Schema.org. Getting Started.
5. Яндекс Вебмастер. Schema.org.