Schema.org — educational pillar
Schema.org — стандарт структурированных данных, который читают Yandex, Google, Yandex GPT, Perplexity, ChatGPT и голосовые помощники. Без Schema-разметки нейросеть видит вашу страницу как «много текста». С разметкой — как структурированную базу знаний: вы — Organization, ваши продукты — Product, ваши ответы — FAQPage, ваши инструкции — HowTo. Это не маркетинг, а технический язык для роботов.
Schema.org — технический фундамент GEO и AEO. На большинстве сайтов в РФ разметка ограничена одним базовым Organization-узлом — этого мало, чтобы попасть в нейросетевой ответ.
Зачем Schema.org
Schema.org решает одну задачу для всех поисковых и нейросетевых систем сразу — превращает страницу из «много текста» в структурированную базу знаний. Но используют эту базу системы по-разному: классические поисковики строят rich-сниппеты и карточки, нейросети собирают из узлов прямой ответ и называют источники. Одна корректная разметка работает на оба канала, и это главный аргумент в пользу того, чтобы делать её один раз и качественно.
Важно, что нейросетевые ответы называют не один сайт, а 2-5 конкретных компаний или источников. Место в этом коротком списке либо ваше, либо чужое — и попадание в него во многом решается тем, насколько полно и связно описана ваша сущность в Schema.org. Ниже — что именно делает разметка для каждой из четырёх систем.
Yandex использует структурированные данные дважды: в классической выдаче — для rich-сниппетов, карточек организации и быстрых ссылок, и в Yandex GPT — как источник фактов при сборке нейросетевого ответа. Раздел «Структурированные данные» в Yandex Webmaster показывает, какие именно JSON-LD-узлы поисковик распознал. Если узел не попал в этот отчёт — ни выдача, ни нейросеть его не используют, и страница для машины остаётся просто текстом.
Google читает Schema.org для Rich Results — FAQ-блоков, breadcrumb-дорожек, карточек товаров, рейтингов и HowTo-шагов прямо в выдаче. Rich Results Test показывает, какие блоки Google готов отрисовать по вашей разметке. Параллельно структурированные данные подаются в Knowledge Graph и в Google AI Overviews — то есть та же разметка работает и на классический SERP, и на нейросетевой слой одновременно.
Yandex GPT при сборке ответа ищет на индексируемых страницах JSON-LD-узлы Organization, Product, Service, FAQPage, HowTo. Через разметку сайт сообщает модели осмысленный контекст: вы — Manufacturer с конкретным NAP, у вас N продуктовых линеек, вы отвечаете на типичные вопросы прямыми формулировками. Без разметки нейросеть видит «много текста про производство» и цитирует вас только в самых очевидных случаях.
Perplexity и другие международные нейросети (ChatGPT Search, Claude) опираются на тот же стандарт Schema.org — он международный, и его читают все. Краулеры PerplexityBot, GPTBot, ClaudeBot обходят сайт и извлекают структурированные данные для атрибуции источников. Чем чище и связнее граф узлов через @id и sameAs, тем выше вероятность, что нейросеть назовёт вас в ответе с указанием источника.
Три слоя видимости
Schema.org-разметку удобно проектировать как три последовательных слоя. Это не теория, а способ не пропустить части: каждый слой отвечает на свой вопрос, и пробел в любом из них оставляет нейросеть без куска картины. Identity отвечает «кто вы», Content — «что вы предлагаете», Answers — «как вы отвечаете на вопросы». Полный стек закрывает все три; половина стека даёт половину результата.
На большинстве сайтов в РФ присутствует только обрывок первого слоя — базовый Organization-узел без sameAs-графа, без слоя Content и без слоя Answers. Этого хватает на строчку в выдаче, но мало для попадания в нейросетевой ответ, где модели нужна вся сущность целиком: кто вы, что у вас есть и как вы это формулируете.
Первый слой описывает саму компанию как сущность. Корневой узел — Organization или его подтип (Manufacturer, LocalBusiness, LegalService, MedicalBusiness, EducationalOrganization, Store) с полным NAP: name, url, logo, ContactPoint, address, areaServed, foundingDate. К нему подключается sameAs-граф — ссылки на Yandex Business, соцсети, Wikidata, отраслевые каталоги. Без этого слоя нейросеть не может консолидировать ваши страницы в одну подтверждённую сущность и видит «несколько похожих компаний» вместо одной вашей.
Второй слой описывает каталог, услуги и навигацию. Узлы Service и Product — для услуг и товаров с ценой, материалом, areaServed. OfferCatalog — для иерархии каталога категория → подкатегория → позиция. WebPage и BreadcrumbList — на каждой посадочной странице, Article — для статей и материалов. Этот слой даёт нейросети возможность отвечать на вопросы «есть ли у вас X» и «сколько стоит Y» конкретикой, а не общей отсылкой к менеджеру.
Третий слой готовит контент к прямому цитированию. FAQPage — пары вопрос-ответ с прямыми формулировками. HowTo — пошаговые инструкции «как заказать», «как настроить». QAPage — для страниц с одним развёрнутым вопросом. Поверх всего — SpeakableSpecification, который через cssSelector помечает короткие ответы для зачитывания голосовым ассистентом. Этот слой напрямую работает на нулевой блок выдачи, карточку нейросети и голосовой поиск.
Слой Answers — это, по сути, граница между Schema.org и AEO: FAQPage, HowTo и Speakable напрямую работают на Featured Snippets и голосовой поиск.
Примеры JSON-LD
Все фрагменты ниже — валидный JSON-LD по спецификации schema.org, с реальными типами и свойствами. Это не полные графы, а минимальные узлы, на которых строится стек: каждый из них дополняется свойствами под конкретный проект, но структура и связки через @id остаются такими же. Внедряются узлы в исходный HTML страницы блоком<script type="application/ld+json">.
Базовый узел для любой компании. Единый @id используется всеми остальными узлами для связки. ContactPoint описывает каналы связи, sameAs связывает с внешними представительствами.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.ru/#organization",
"name": "Acme",
"url": "https://example.ru/",
"logo": "https://example.ru/logo.png",
"sameAs": [
"https://yandex.ru/maps/org/123",
"https://vk.com/acme"
]
}Manufacturer — подтип Organization для производителей. Добавляет areaServed (география поставок) и foundingDate. Подходит заводам и производственным компаниям.
{
"@context": "https://schema.org",
"@type": "Manufacturer",
"@id": "https://example.ru/#organization",
"name": "Acme Завод",
"foundingDate": "1998",
"areaServed": {
"@type": "Country",
"name": "Россия"
}
}Узел физического товара. brand ссылается на узел Organization по @id, offers описывает цену и доступность через Offer.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Преформа ПЭТ 28 г",
"brand": { "@id": "https://example.ru/#organization" },
"offers": {
"@type": "Offer",
"priceCurrency": "RUB",
"price": "12.50",
"availability": "https://schema.org/InStock"
}
}Узел для услуг вместо товаров. provider ссылается на Organization, areaServed задаёт географию оказания услуги.
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Проектирование упаковки",
"provider": { "@id": "https://example.ru/#organization" },
"areaServed": {
"@type": "Country",
"name": "Россия"
}
}Описывает структуру каталога: категория → подкатегории → позиции. itemListElement содержит вложенные OfferCatalog или Offer.
{
"@context": "https://schema.org",
"@type": "OfferCatalog",
"name": "Каталог ПЭТ-упаковки",
"itemListElement": [
{
"@type": "OfferCatalog",
"name": "Преформы"
},
{
"@type": "OfferCatalog",
"name": "Бутылки"
}
]
}Описывает путь страницы в структуре сайта. Каждый ListItem имеет position, name и item — URL раздела.
{
"@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/"
}
]
}Пары вопрос-ответ. mainEntity содержит Question с acceptedAnswer. speakable помечает короткие ответы для зачитывания вслух.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Какой минимальный тираж?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Минимальный тираж — 50 000 штук."
}
}
]
}Узел пошаговой инструкции. Каждый HowToStep имеет position, name и text. Подходит для процессов «как заказать» и «как настроить».
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "Как разместить заказ",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Отправить ТЗ",
"text": "Заполните бриф на странице контактов."
}
]
}Разметка по вертикалям
Schema.org различает бизнесы не на уровне свойств, а на уровне типа: производитель, юрфирма, клиника, образовательный проект и интернет-магазин описываются разными подтипами Organization, и от выбора корневого типа зависит весь дальнейший граф. Ошибка здесь — это формально валидная разметка, которая семантически описывает не то, чем вы являетесь, и относит вас не к той категории в глазах нейросети.
Ниже — пять вертикалей с корневым узлом и минимальным JSON-LD. Кейс из практики: Pet Industria, производитель ПЭТ-упаковки из Челябинска, получил первый московский заказ через нейросеть после внедрения полного стека на узле Manufacturer — с OfferCatalog, Product × N, sameAs из 6 ссылок, FAQPage на 14 пар и Speakable.
Для производителей корневой узел — Manufacturer (подтип Organization). К нему привязывается OfferCatalog с продуктовыми линейками и Product × N с указанием материала, веса, артикула. areaServed описывает географию поставок — критично для B2B, где нейросеть отвечает на запрос «производитель X в РФ» вне зависимости от города пользователя.
LegalService — подтип LocalBusiness для юридических компаний. Добавляет address с PostalAddress, openingHoursSpecification, priceRange. Услуги описываются узлами Service с привязкой к provider. Для юрфирм важен полный NAP — нейросеть и карточка организации опираются на согласованность адреса и контактов.
MedicalBusiness — подтип LocalBusiness для клиник. Описывает address, openingHoursSpecification, telephone. Отдельные направления приёма можно описывать узлами MedicalSpecialty или Service. Schema-разметка медицинского бизнеса требует особой точности данных — нейросети строго проверяют согласованность фактов в этой вертикали.
EducationalOrganization — подтип Organization для образовательных проектов. Программы и курсы описываются узлами Course с привязкой к provider по @id. У Course есть свойства name, description, courseCode. Для EdTech этот слой позволяет нейросети отвечать на запросы «курсы по X» с конкретными названиями программ.
Store — подтип LocalBusiness для торговых компаний. Корень — Store, каталог — OfferCatalog, карточки товаров — Product с offers и priceSpecification. Для e-commerce критичен слой Content: чем полнее описаны товары через Product и Offer, тем точнее нейросеть и rich-сниппеты отвечают на запросы о наличии и цене.
Пошаговая инструкция
Каждый шаг — конкретное действие на сайте, а не теоретический совет. Последовательность важна: слой Identity строится раньше Content, Content раньше Answers, связка узлов — раньше валидации. Силами команды разработки и контент-редактора базовый стек собирается за несколько дней; полный стек под ключ закрывается Build-пакетом.
Перед тем как писать JSON-LD, определите, какой подтип Organization описывает ваш бизнес: Manufacturer для производства, LegalService и MedicalBusiness для услуг с адресом, EducationalOrganization для образования, Store для розницы. От этого выбора зависит весь дальнейший граф — какие свойства доступны, какие узлы подключаются. Ошибка на этом шаге означает, что разметка формально валидна, но семантически описывает не то, чем вы являетесь, и нейросеть относит вас не к той категории.
Соберите корневой узел Organization или его подтип с полным NAP: name, url, logo, ContactPoint × N (sales, support, press), address с PostalAddress, areaServed, foundingDate. Присвойте ему стабильный @id вида https://example.ru/#organization и выводите этот узел на всех страницах сайта с одним и тем же идентификатором. Единый @id — это то, что позволяет нейросети консолидировать разрозненные страницы в одну сущность, а не видеть «200 организаций с одинаковым названием».
В узел Organization добавьте свойство sameAs со ссылками на все живые публичные представительства: карточка Yandex Business, VK, Telegram, Wikidata при наличии, отраслевые каталоги. Минимум — 4-5 ссылок, и все они должны вести на реально заполненные профили, а не на брошенные страницы. sameAs — это техническая мелочь на несколько строк JSON, но именно она часто решает, увидит нейросеть единую подтверждённую сущность или несколько неуверенных «похожих компаний».
На страницах каталога разместите узлы Product для товаров или Service для услуг с описанием, ценой через offers или priceSpecification, материалом и areaServed. Корневую страницу каталога опишите узлом OfferCatalog с иерархией категория → подкатегория → позиция. На каждой посадочной странице добавьте WebPage и BreadcrumbList. Этот слой даёт нейросети возможность отвечать на вопросы «есть ли у вас X» и «сколько стоит Y» конкретикой, а не отсылкой «уточняйте у менеджера».
Добавьте FAQPage с 5-15 парами вопрос-ответ на главной и ключевых посадочных — вопросы берите из реальных обращений в продажи и поддержку, ответы делайте прямыми, первая фраза в 15-20 слов даёт суть. Процессы «как заказать» и «как настроить» опишите узлом HowTo с пронумерованными HowToStep. Привяжите SpeakableSpecification через cssSelector к классам коротких ответов — это активирует одновременно карточку нейросети и зачитывание голосовым ассистентом.
Отдельные валидные узлы — это ещё не граф. Свяжите их: Product указывает brand по @id корневой Organization, Service указывает provider, WebPage — свойство about или isPartOf. Чем плотнее узлы связаны ссылками на @id, тем легче нейросети и парсеру восстановить полную картину компании из фрагментов. Несвязанные узлы парсятся, но не складываются в единую сущность — а именно сущность, а не отдельный узел, попадает в нейросетевой ответ.
Прогоните разметку через Schema Markup Validator — он покажет ошибки структуры и связей. Затем через Rich Results Test — он покажет, какие rich-блоки готов отрисовать Google. Для российского контура обязателен раздел «Структурированные данные» в Yandex Webmaster: если Yandex не видит узел в этом отчёте, ни выдача, ни Yandex GPT его не используют. Валидация — не финальный шаг, а контрольная точка: после правок прогон повторяется до зелёного статуса во всех трёх инструментах.
Инструменты валидации
Валидация — не финальный шаг, а контрольная точка: после каждой правки прогон повторяется до зелёного статуса. Инструменты делятся на три роли — проверка стандарта (валиден ли JSON-LD по схеме), проверка распознавания (что видит конкретный поисковик) и мониторинг (не сломалась ли разметка на работающем сайте). Все восемь — бесплатные и публичные.
Официальный валидатор schema.org. Проверяет корректность JSON-LD по спецификации: правильность типов и свойств, структуру вложенности, связи между узлами по @id. Главный инструмент для отладки сложных графов с несколькими сущностями — показывает не «как это видит поисковик», а «корректна ли разметка по стандарту».
Инструмент Google, который показывает, какие rich-блоки поисковик готов отрисовать по вашей разметке — FAQ, breadcrumb, карточки товаров, HowTo. Предупреждает о критических ошибках, блокирующих rich-результат. Дополняет официальный валидатор: тот проверяет стандарт, этот — практическое распознавание со стороны Google.
Раздел в Yandex Webmaster, который показывает, какие JSON-LD-узлы Yandex распознал на сайте и какие отдают валидную разметку. Первичный валидатор для российского контура: если узел не попал в этот отчёт, ни классическая выдача Yandex, ни Yandex GPT его не используют.
Песочница для отладки JSON-LD как формата. Показывает, как документ разворачивается в граф, помогает находить ошибки в @context и @id, проверять связи между узлами. Полезен, когда нужно понять не «валиден ли тип Schema.org», а «корректен ли сам JSON-LD-документ как структура данных».
Полный справочник типов и свойств на schema.org — первоисточник. Перед тем как использовать тип или свойство, его наличие проверяется здесь: какие свойства допустимы у Manufacturer, чем LegalService отличается от LocalBusiness, какие значения принимает availability. Защита от изобретённых, несуществующих в стандарте узлов.
В Search Console есть отчёты по структурированным данным — они показывают, какие типы разметки Google нашёл на работающем сайте в продакшене, сколько страниц с валидной разметкой и где ошибки. В отличие от Rich Results Test, который проверяет одну страницу, Search Console даёт картину по всему проиндексированному сайту.
Помимо разового валидатора, Yandex Webmaster ведёт сводный отчёт по структурированным данным всего сайта: динамика распознанных узлов, типы разметки, история ошибок. Это инструмент мониторинга после внедрения — он показывает, не сломалась ли разметка после релиза и растёт ли покрытие.
Базовая проверка вручную: в DevTools браузера можно найти все <script type="application/ld+json"> на странице и убедиться, что узлы действительно отдаются в HTML, а не теряются при рендере. JSON-LD-линтер проверяет синтаксис документа — пропущенную запятую, незакрытую скобку, дубль ключа, — то есть ошибки уровня самого JSON, до семантики Schema.org.
Анти-паттерны
Эти ошибки встречаются не у новичков, а в стеках, которые на первый взгляд выглядят профессионально. Общее у них одно — они подрывают доверие поисковика и нейросети к разметке в целом, а не к одному узлу.
Владелец сайта добавляет в разметку AggregateRating «4.8 из 5, 127 отзывов», но никаких отзывов на странице нет и нет ссылки на источник. Yandex и Google трактуют это как Schema-spam — страница теряет доверие, и поисковик начинает игнорировать даже корректные узлы рядом. Решение — либо реальные Review с reviewBody и author, либо никакого AggregateRating вообще.
SpeakableSpecification рассчитан примерно на 50 слов или 60 секунд речи. Если cssSelector указывает на абзац в 200 слов или на заголовок без выраженного ответа, голосовой ассистент либо обрежет фрагмент случайным образом, либо просто проигнорирует разметку. Решение — отдельный класс для заранее написанных «голосовых» 30-50 слов, привязанный только к ним.
В шаблоне сайта Organization выводится на каждой странице с автогенерируемым @id — например, по URL страницы. В итоге у нейросети не одна Organization, а сотни «организаций» с одинаковым name, и консолидировать сущность она не может. Решение — единый стабильный @id вида https://example.ru/#organization на всех страницах сайта без исключений.
Заявка на AI-аудит
Audit за 5-7 дней покажет, что из трёхслойной модели у вас уже есть и чего не хватает, и даст action plan. Build — внедрение полного Schema-стека под ключ за 3-6 недель. Подробности по обоим форматам — на странице AI-аудита и в хабе SEO + GEO + AEO.
Что читать дальше
Кураторский слой поверх Schema.org: текстовый маршрут для LLM-краулеров с человеческими аннотациями к ключевым страницам.
ЧитатьСлой Answers крупным планом: FAQPage, HowTo, Speakable, структура «50-словного ответа» под голосовой поиск и Featured Snippets.
ЧитатьPillar-страница про четыре механизма нейросетевой видимости, на которых Schema.org — технический фундамент.
Читать