Schema.org для AI-поиска: что действительно имеет смысл размечать на сайте

Вокруг AI-поиска появляется всё больше рекомендаций о специальной разметке для генеративных систем. Иногда можно встретить утверждение, что для попадания в AI Overviews или AI Mode сайту нужна отдельная Schema.org.

Такой универсальной разметки не существует.

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

Поэтому вопрос «какую Schema.org поставить для AI?» не совсем корректен.

Гораздо полезнее сначала определить:

что является главной сущностью страницы и как точно описать её поисковой системе?

Обычный HTML сообщает поисковой системе о содержании страницы через текст и структуру документа.

Структурированные данные добавляют ещё один слой формализованной информации.

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

Человеку из текста понятна связь между организацией и услугой.

В структурированных данных её можно представить примерно так:

Organization → offers → Service

Для информационной статьи связи могут выглядеть иначе:

Article → author → Person

Article → publisher → Organization

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

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

В Schema.org нет универсального типа:

AIOverview

AIContent

GenerativeSearch

или

ChatGPTOptimization.

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

Используются обычные типы Schema.org, соответствующие содержанию страницы:

Конкретный набор зависит от того, что находится на странице.

Представим обычный сайт.

На нём могут быть:

Если исходить только из задачи «подготовить сайт к AI-поиску», возникает соблазн использовать один универсальный набор JSON-LD на всём сайте.

Но разные страницы описывают разные сущности.

Карточка товара — это прежде всего Product.

Информационная статья — Article или BlogPosting.

Организация — Organization.

Страница физического бизнеса — соответствующий тип LocalBusiness.

Навигационная структура — BreadcrumbList.

Поэтому логика должна быть обратной:

сначала определить содержание страницы → затем выбрать подходящий тип Schema.org.

Главная сущность — организация.

Обычно подходит:

Organization

В зависимости от ситуации могут указываться название, сайт, логотип, описание, контакты, адрес и официальные профили.

Главная сущность — материал.

Обычно используется:

Article

или

BlogPosting

В разметке могут быть указаны автор, издатель, заголовок, дата публикации, дата изменения и изображение.

Главная сущность — человек.

Для этого может использоваться:

Person

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

Главная сущность — услуга.

Подходящий тип:

Service

Например:

Organization → offers → Service

Но Service имеет смысл использовать именно на странице, которая действительно описывает услугу.

Если статья лишь упоминает какую-либо услугу в качестве примера, превращать всю статью в Service не нужно.

Главная сущность — товар.

Используется:

Product

При наличии конкретного коммерческого предложения он может быть связан с:

Offer

Для групп товаров с вариантами может использоваться ProductGroup.

Если страница действительно описывает физическое место, может использоваться:

LocalBusiness

В зависимости от характера бизнеса можно выбрать более конкретный подтип.

Для навигационной структуры используется:

BreadcrumbList

Это отдельная сущность, которая описывает положение страницы в иерархии сайта.

Представим сайт, на котором есть организация, авторы, статьи и страницы услуг.

Эти объекты можно связывать:

Organization → WebSite → WebPage → Article

Для статьи:

Article → author → Person

Article → publisher → Organization

Для услуги:

Service → provider → Organization

Для товара:

Product → brand → Brand

Получается не набор независимых JSON-LD-блоков, а связанная структура.

При этом не стоит переоценивать значение таких связей.

Они не являются гарантией появления сайта в AI-ответах и не превращают автоматически набор структурированных данных в Knowledge Graph.

Их практический смысл — точнее описать отношения между сущностями.

Одна из полезных возможностей JSON-LD — использование @id.

Например, организация может иметь постоянный идентификатор:

https://example.ru/#organization

После этого разные объекты сайта могут ссылаться именно на неё.

Например:

Article → publisher → @id

Service → provider → @id

WebPage → about → @id

Это позволяет не создавать несколько независимых описаний одной и той же организации.

Важно понимать: @id — не специальный «сигнал для AI».

Это механизм идентификации и связывания объектов внутри структурированных данных.

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

Для организации обычно используются применимые свойства, например:

Но заполнять все возможные свойства только ради количества не нужно.

Если у организации нет физического адреса, не нужно создавать искусственный address.

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

Главный принцип:

структурированные данные должны отражать реальные данные организации.

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

Для информационных материалов подходят Article и BlogPosting.

В разметке могут быть указаны:

Например:

{ "@context": "https://schema.org", "@type": "Article", "headline": "Заголовок статьи", "author": { "@type": "Person", "name": "Имя автора" }, "publisher": { "@type": "Organization", "name": "Название организации" }, "datePublished": "2026-09-17", "dateModified": "2026-09-17" }

Здесь важно различать автора и издателя.

Если материал написал конкретный человек, автором логичнее указать Person.

Организация, которая публикует материал, может выступать как publisher.

То есть:

Person → author → Article

Organization → publisher → Article

Так структура точнее отражает происхождение материала.

Google рекомендует для Article-разметки указывать соответствующие данные об авторе, издателе, заголовке и датах.

Для страницы конкретной услуги естественным типом может быть Service.

Например:

Organization → offers → Service

Но здесь особенно важно не смешивать страницу услуги и информационную статью.

Материал:

Как работает технический аудит сайта

не становится автоматически страницей услуги.

Если отдельная страница посвящена конкретной услуге и содержит её описание, условия и другие соответствующие сведения, Service может быть уместен.

Иными словами, Schema.org выбирается не по ключевому слову, а по главной сущности страницы.

Иногда встречается подход:

Чем больше типов Schema.org, тем лучше.

На практике количество блоков само по себе не является преимуществом.

Если без оснований добавить:

Organization + Person + Product + Service + Review + Rating + LocalBusiness + Event + Article

получится не более понятная структура, а набор сущностей, часть которых может не соответствовать странице.

Если на странице нет товара, не нужен Product.

Если нет реального пользовательского отзыва, не нужен Review.

Если страница не описывает локальный бизнес, не нужен LocalBusiness.

Если материал не является событием, не нужен Event.

Разметка должна описывать существующие объекты, а не желаемый результат в поиске.

Это один из самых важных моментов.

Можно корректно оформить JSON-LD, но если сама страница:

одна Schema.org проблему не решит.

Структурированные данные — дополнительный слой описания.

Они не превращают слабый материал в качественный источник.

Поэтому работа со структурированными данными имеет смысл после того, как понятны содержание и структура самого сайта.

Здесь важно разделять несколько разных вещей.

AI Overviews и AI Mode используют информацию из различных источников, включая веб-страницы. Но из этого не следует формула:

Schema.org → попадание в AI Overview.

Такой гарантии нет.

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

Поэтому структурированные данные разумнее рассматривать как один из элементов общей системы:

доступность сайта → содержание → структура страниц → сущности → внутренние связи → структурированные данные.

А не как отдельный способ «оптимизации под нейросеть».

Здесь часто возникает путаница.

Schema.org — это технический словарь.

Работа с сущностями — более широкая задача.

Например, на сайте могут существовать:

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

Schema.org может формально описать часть этих отношений.

Но сама разметка не создаёт репутацию организации и не подтверждает автоматически все сведения, которые в неё внесены.

Поэтому полезно сначала составить карту сущностей сайта, а уже потом решать, какие объекты и связи стоит описывать структурированными данными.

Перед внедрением или переработкой Schema.org можно пройти восемь шагов.

Что пользователь фактически изучает?

Организацию, человека, товар, услугу, статью или другой объект?

Есть ли в Schema.org специализированный тип для этой сущности?

Если есть, не обязательно использовать общий Thing.

Можно ли подтвердить данные в разметке содержимым, которое реально доступно пользователю?

Не описывается ли одна и та же сущность несколько раз как разные объекты?

Связаны ли автор, организация, страница, товар или услуга там, где такая связь действительно существует?

Можно ли использовать @id, чтобы однозначно ссылаться на повторяющиеся сущности?

Не добавлены ли фиктивные отзывы, рейтинги, адреса, организации или другие сведения?

Если мысленно убрать JSON-LD, остаётся ли страница понятной и полезной?

Если нет, проблема, скорее всего, находится не в структурированных данных.

После внедрения разметки стоит проверить её на нескольких уровнях.

JSON-LD должен корректно обрабатываться.

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

Google рекомендует проверять, как URL видится поисковой системе, через URL Inspection в Search Console. Также для поддерживаемых форматов можно использовать Rich Results Test.

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

Если нужен отдельный разбор типов Schema.org, связей через @id и вариантов структурированных данных для разных типов страниц, можно посмотреть:

«Какая Schema.org нужна для AI-поиска».

В материале отдельно разобраны Organization, Article, Service, Product, LocalBusiness и связанные с ними сущности.

Для AI-поиска не существует отдельной универсальной Schema.org.

Логика работы выглядит проще:

1. Определить сущность страницы.

2. Выбрать соответствующий тип Schema.org.

3. Заполнить реальные свойства.

4. Связать связанные сущности.

5. Проверить соответствие разметки видимому содержанию.

6. Не рассчитывать на структурированные данные как на замену качественному контенту.

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

Schema.org в этом случае — не «магическая кнопка для AI», а формальный способ описать уже существующую структуру информации.

#ai #chatgpt #schemaorg #seo