🏷️Schema.org в 2026: что реально влияет на выдачу, а что карго-культ

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

редакция seodb#schema-org#структурированные-данные#geo#ai-поиск#техническое-seo#json-ld

Разметка Schema.org — редкий случай, когда «сделай по документации» и «получи результат» расходятся почти полностью. В спецификации около 800 типов и примерно 1500 свойств. В реальности на выдачу влияет десяток типов, ещё десяток читают языковые модели, а всё остальное размечают потому, что так написано в чек-листе из 2019 года.

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

Это продолжение разбора Organization и Person schema — там про конкретные два типа, здесь про картину целиком.

Три потребителя разметки, и у них разные интересы

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

1. Классические поисковики (Яндекс, Google) — рендер сниппета. Здесь всё жёстко: работает только то, что явно поддерживается, по документации конкретного поисковика. Google публикует список поддерживаемых типов, Яндекс — свой. Разметили Course в надежде на красивый сниппет, а Яндекс этот тип не рендерит — значит, визуально не изменится ничего.

2. Языковые модели и AI-поиск — извлечение фактов. Здесь всё мягко и почти не документировано. Модель не «поддерживает тип» — она читает JSON-LD как ещё один кусок текста на странице, только очень плотный и однозначный. Ей всё равно, есть ли Course в списке Google. Ей важно, что на странице есть машиночитаемое утверждение «это курс, он стоит столько, ведёт его такой-то человек».

3. Агрегаторы и сервисы — маркетплейсы, агрегаторы вакансий, каталоги. Часть из них парсит JobPosting, Product, Event напрямую с сайтов.

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

Слой 1. Работает видимо

Типы, где разметка даёт наблюдаемое изменение сниппета. Проверяется просто: сделали — сходили в выдачу через две недели — увидели.

Заменяет URL в сниппете на цепочку разделов. Работает и в Яндексе, и в Google, поддерживается уже много лет, ломается редко. Одна из немногих разметок с почти гарантированным эффектом.

Условие: цепочка в разметке должна совпадать с реальной навигацией на странице. Расхождение — прямой повод для игнора.

Product + Offer + AggregateRating

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

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

FAQPage

Тип с самой интересной судьбой. Google в 2023 году резко ограничил показ FAQ-сниппетов — фактически до сайтов из области здоровья и госуслуг. Многие после этого выпилили разметку целиком.

Это была ошибка. FAQ-разметка перестала давать видимый сниппет, но осталась одним из самых удобных для языковой модели форматов: явная пара «вопрос — ответ», однозначно связанная. Она переехала из слоя 1 в слой 2, а не в мусор. Подробнее — ниже.

Article / NewsArticle

Дата публикации, автор, издание. Видимого эффекта немного (дата в сниппете), но тип дешёвый и лежит в фундаменте авторства, о котором дальше.

Organization и LocalBusiness

Для локального бизнеса — адрес, телефон, часы работы в карточке. Для остальных — фундамент сущности, слой 2.

VideoObject, Recipe, Event, JobPosting

Работают, если вы ровно в этой нише. Если нет — не трогайте, это не «дополнительный сигнал качества».

Слой 2. Работает невидимо — и именно здесь GEO

Разметка, которая не меняет сниппет, но меняет, как вас понимают и цитируют языковые модели.

@id и связывание сущностей

Самое недооценённое в списке. Разметка без @id — это набор независимых утверждений на каждой странице. Разметка с @id — граф: одна и та же организация, один и тот же автор, на всех страницах — один и тот же объект.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://seodb.tech/blog/schema-org-chto-vliyaet#article",
  "author": { "@id": "https://seodb.tech/#person-denis" },
  "publisher": { "@id": "https://seodb.tech/#organization" },
  "isPartOf": { "@id": "https://seodb.tech/#website" }
}

Разница на практике: без @id модель видит сто статей, у каждой автор со строковым именем. С @id — одного автора, у которого сто статей. Второе — это уже основание для утверждения «такой-то пишет про GEO», то есть ровно то, что цитируется в AI-ответе.

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

sameAs — привязка к внешним профилям

Массив ссылок на профили в других местах: Telegram, Дзен, Хабр, профиль в отраслевом каталоге, страница в Википедии, если есть.

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

FAQPage — теперь как источник цитат

Формат «вопрос — короткий однозначный ответ» — идеальный кусок для извлечения. Модели вытаскивают из FAQ-блоков прямые ответы охотнее, чем из сплошного текста, где тот же ответ размазан по трём абзацам.

Практический вывод: FAQ-разметку стоит держать, но писать ответы иначе, чем раньше. Не «Мы работаем с 2015 года и наша команда стремится…», а первым предложением — сам ответ, дальше пояснение. Ответ, который нельзя вырезать из контекста, не будет процитирован.

HowTo

Google убрал HowTo-сниппеты из выдачи почти полностью. Как источник структуры пошаговой инструкции для модели — тип живой. Та же миграция, что у FAQPage.

Person с реальной обвязкой

Person с одним полем name бесполезен. Person с jobTitle, worksFor (через @id на организацию), sameAs на профили и knowsAbout со списком тем — это заявка на экспертность, которую можно проверить.

knowsAbout — свойство, которое почти никто не заполняет, а оно ровно про «в чём этот человек разбирается»:

"knowsAbout": ["Поисковая оптимизация", "GEO", "Яндекс.Вебмастер", "Структурированные данные"]

Никакого видимого эффекта. Прямое отношение к тому, будет ли модель считать вас релевантным источником по теме.

Слой 3. Карго-культ

Разметка, которую делают годами без единого результата.

WebPage на каждой странице

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

Исключение — WebPage как контейнер со связями (isPartOf, breadcrumb, primaryImageOfPage). Тогда это часть графа и имеет смысл. Сама по себе, с name и url, — байты.

AggregateRating без отзывов

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

Speakable

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

Дублирование разметки в трёх форматах

JSON-LD плюс микроданные в HTML плюс RDFa «на всякий случай». Не усиливает сигнал, а создаёт риск расхождения между копиями — и тогда парсер выбирает сам, какой версии верить.

Только JSON-LD. Это рекомендованный формат у всех, он отделён от вёрстки и не ломается при редизайне.

Максимизация числа свойств

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

Разметка — это утверждения о фактах. Каждое неверное утверждение — минус к доверию к остальным.

Разметка того, чего нет на странице

Формально запрещено правилами и Яндекса, и Google, но делается постоянно: в разметке цена, а на странице «по запросу»; в разметке автор, а на странице никакого автора не видно.

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

Как проверять

  • Валидатор Schema.org — validator.schema.org. Синтаксис и структура графа, без привязки к поисковику.
  • Rich Results Test от Google — что именно Google готов отрендерить.
  • Валидатор микроразметки Яндекса — в Вебмастере, «Инструменты» → «Валидатор микроразметки». Показывает картину глазами Яндекса, она отличается.
  • Проверка глазами модели — просто спросить у ChatGPT/Нейро/Perplexity про свою страницу и посмотреть, какие факты о ней воспроизводятся корректно. Если модель уверенно называет автора и тему — граф читается. Если путает — где-то разрыв.

Последний способ неформальный, но он единственный, который проверяет слой 2. Валидаторов «правильно ли вас понимает языковая модель» не существует.

Минимальный набор, с которого стоит начать

Если разметки нет вообще, порядок такой:

  1. Organization с @id, sameAs и логотипом — один раз, на весь сайт.
  2. WebSite с @id — тоже один раз.
  3. BreadcrumbList — на всех вложенных страницах.
  4. Article с author и publisher через @id — на всех статьях.
  5. Person с knowsAbout и sameAs — для автора.
  6. Product/LocalBusiness/Event — только если вы ровно в этой нише.

Шесть пунктов. Дальше — по конкретной потребности, а не по принципу «добавим ещё типов».

Итог

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

И не выкидывайте разметку только потому, что перестали видеть от неё сниппет. FAQPage и HowTo — живой пример: они не умерли, они сменили потребителя. Тот потребитель сниппетов не рисует, но именно он всё чаще решает, кого процитировать в ответе.