Разбираем, какие типы разметки использовать для Google AI Overviews и AI Mode — и почему универсальной «AI Schema» не существует.
Если задача сайта — быть понятным не только классической поисковой выдаче, но и системам генеративного поиска, возникает закономерный вопрос: какая Schema.org нужна для AI-поиска? На практике универсального типа «AI Schema» не существует. Schema.org — это словарь сущностей, свойств и связей, а не отдельная разметка «для искусственного интеллекта».
Google продолжает использовать структурированные данные как один из способов понять содержание страниц и сущности сайта. При этом Google прямо указывает, что для AI-функций Search сохраняются базовые SEO-принципы: качественный, полезный, доступный для сканирования контент важнее попытки найти специальную «магическую» разметку.
Поэтому правильный вопрос звучит так: какая Schema.org наиболее точно описывает сущность страницы, бизнеса, автора, продукта или контента?
Нет. В актуальном словаре Schema.org нет отдельного универсального типа, который давал бы сайту специальный статус для AI Overviews или AI Mode.
Schema.org описывает сущности и отношения между ними: Organization, Person, Article, Product, Service, LocalBusiness, WebPage, BreadcrumbList и другие.
Структурированные данные помогают однозначнее интерпретировать: кто является автором; какая организация стоит за сайтом; что представляет собой продукт; какая услуга предлагается; о чём статья; где находится компания; какие сущности связаны между собой; какие характеристики относятся к конкретной сущности.
Но Schema.org не заменяет текст страницы, внутреннюю перелинковку, авторитетность источника и техническую доступность сайта.
Выбирать разметку следует от типа страницы и главной сущности, а не от самого факта использования AI-поиска.
Для корпоративного сайта базовой сущностью обычно является Organization. Полезные свойства: name, url, logo, description, sameAs, email, telephone, address (если применимо), contactPoint.
Google рекомендует добавлять применимые свойства Organization, чтобы лучше понимать организацию и её данные.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Название компании",
"url": "https://example.ru/",
"logo": "https://example.ru/logo.png",
"sameAs": ["https://t.me/example"]
}Если компания работает из физического адреса и продвигается по локальным запросам, используется наиболее конкретный тип LocalBusiness, например Restaurant, Store, HealthClub и другие. Google рекомендует использовать максимально конкретный подтип локального бизнеса и дополнять его соответствующими данными.
{
"@context": "https://schema.org",
"@type": "Store",
"name": "Название магазина",
"address": {
"@type": "PostalAddress",
"addressLocality": "Москва",
"streetAddress": "ул. Примерная, 1"
},
"telephone": "+7..."
}Для экспертных статей подходят Article и BlogPosting. Особенно важны: headline, author, datePublished, dateModified, image, publisher, mainEntityOfPage.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Заголовок статьи",
"author": { "@type": "Organization", "name": "Название компании" },
"datePublished": "2026-09-01",
"dateModified": "2026-09-10",
"image": "https://example.ru/cover.jpg"
}Для интернет-магазина основой является Product, дополненный Offer и применимыми характеристиками товара: название, бренд, цена, наличие, изображения, варианты, характеристики, условия продажи.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Название товара",
"brand": "Бренд",
"offers": {
"@type": "Offer",
"price": "1990",
"priceCurrency": "RUB",
"availability": "https://schema.org/InStock"
}
}Для услуг логично описывать основную сущность как Service, связывая её с организацией и конкретными характеристиками предложения: Organization → offers → Service. Это особенно полезно для SEO-структуры агентств, медицинских, юридических, строительных и других сервисных компаний. У нашего собственного GEO-продвижения структура построена ровно так же — Service привязан к организации через @id, а не просто продублирован текстом. Похожий принцип мы применяли и в кейсе с подоконниками из мрамора: сначала описали реальную сущность (услугу и результат), а уже потом — разметку под неё.
{
"@context": "https://schema.org",
"@type": "Service",
"serviceType": "Название услуги",
"provider": { "@id": "https://example.ru/#organization" },
"areaServed": "Россия"
}| Тип страницы | Основная Schema.org | Преимущества | Практичность |
|---|---|---|---|
| Главная компании | Organization | Идентификация бизнеса | Высокая |
| Статья | Article / BlogPosting | Авторство и структура | Высокая |
| Услуга | Service | Описание предложения | Высокая |
| Товар | Product + Offer | Цена, наличие, характеристики | Очень высокая |
| Локальный бизнес | LocalBusiness | Адрес, контакты, локация | Высокая |
| Хлебные крошки | BreadcrumbList | Иерархия сайта | Высокая |
Для корпоративного проекта разумно формировать связанную структуру: Organization → WebSite → WebPage → Article/Service/Product. Такой подход лучше, чем набор независимых JSON-LD-блоков без связей.
@id помогает однозначно ссылаться на одну и ту же сущность в разных объектах. Организация может иметь собственный идентификатор, который затем используется в author, publisher, provider и других связях.
Schema.org должна соответствовать видимому содержимому страницы. Если на странице нет услуги, не следует создавать фиктивный Service. Если компания не публикует отзывы пользователей, нельзя искусственно формировать AggregateRating.
Google отдельно устанавливает ограничения для Review/AggregateRating-разметки — определённые отзывы о собственной организации не дают права на соответствующий rich result.
Главной сущностью должна быть сущность, вокруг которой построена страница: компания, человек, статья, услуга, товар, организация, локальный бизнес.
Для полноценной Entity SEO-структуры могут быть связаны: Organization, Person, WebSite, WebPage, Article, BlogPosting, Service, Product, Brand, Offer, Review, Rating, LocalBusiness, PostalAddress, BreadcrumbList, ImageObject, Thing, ContactPoint.
Важно не добавлять все сущности одновременно. Используются только те, которые реально существуют и подтверждаются содержанием сайта.
Entity SEO строится вокруг сущностей, их атрибутов и отношений. Например, вместо простого упоминания «агентство оказывает услуги SEO» можно сформировать более однозначную модель: Organization → offers → Service, где у услуги есть название, описание и URL.
В зависимости от типа сущности могут использоваться: название, описание, URL, изображение, автор, бренд, цена, наличие, адрес, телефон, дата публикации, дата обновления, идентификатор. Именно корректность этих данных важнее количества Schema.org-блоков.
Schema.org — это словарь, а JSON-LD — один из способов его технического представления. Schema.org также поддерживает Microdata и RDFa. Для большинства современных сайтов JSON-LD удобен тем, что структурированные данные отделены от HTML-разметки и проще поддерживаются разработчиками.
Не обязательно. Разметка должна соответствовать конкретной странице: главная — Organization, статья — Article, страница услуги — Service, карточка товара — Product, контакты физического офиса — LocalBusiness, навигация — BreadcrumbList.
Thing, если существует подходящий специализированный тип.Наличие Schema.org само по себе не гарантирует: попадание страницы в AI Overview; цитирование сайта AI Mode; появление Knowledge Panel; рост позиций; генерацию ответа на основе страницы.
Google отдельно подчёркивает, что оптимизация под генеративные функции продолжает опираться на фундаментальные SEO-принципы.
При этом для продвижения сайта в современных поисковых системах всё большее значение имеет работа не только с классической выдачей, но и с тем, как бренд и его услуги представлены в ответах генеративных систем. Этим у нас занимается отдельное направление — GEO-продвижение в нейросетях, нацеленное как раз на повышение представленности бизнеса в AI-поиске и генеративных ответах.
Такого универсального типа нет. В результате сайт получает лишнюю или некорректную разметку.
Количество JSON-LD-блоков не является самостоятельным SEO-преимуществом. Избыточная разметка повышает риск несоответствий.
Если данные не подтверждаются содержанием страницы, разметка становится ненадёжной.
Это может нарушать рекомендации Google и лишать страницу права на соответствующее отображение.
Поисковой системе сложнее определить, что несколько объектов относятся к одной организации или человеку.
Структурированные данные не исправят поверхностную статью, слабую экспертизу или отсутствие полезной информации.
Изменяются товары, авторы, цены, услуги и требования поисковых систем. Разметка должна синхронизироваться с сайтом.
Если задача — подготовить сайт к AI-поиску, мы бы не начинали с вопроса «какую Schema.org поставить для AI». Сначала нужна карта сущностей сайта: компания, её услуги или товары, авторы, страницы, категории и отношения между ними. И только потом для каждой сущности выбирается подходящий тип разметки.
Такой подход устойчивее попыток оптимизировать сайт под отдельный интерфейс Google — форматы отображения меняются, а связная модель сущностей остаётся. Schema.org работает только в связке с качественным контентом, технической доступностью и понятной архитектурой сайта. Главная практическая цель разметки — не «заставить ИИ выбрать страницу», а уменьшить неоднозначность и помочь системам правильно интерпретировать опубликованные данные.
Используйте инструменты Google для проверки структурированных данных и убедитесь, что критические ошибки отсутствуют. Google рекомендует также проверять, как URL видится поисковику, через URL Inspection в Search Console.
После технической проверки ответьте на три вопроса: все ли значения существуют на странице? правильно ли определена главная сущность? связаны ли между собой организация, автор, страница, товар или услуга?
Нет. Специального универсального типа Schema.org для AI Overviews нет. Используются стандартные типы, соответствующие содержанию страницы: Organization, Article, Product, Service, LocalBusiness и другие.
Для информационной статьи обычно подходит Article или BlogPosting — с заголовком, автором, датами публикации и изменения, изображением и издателем.
Разметка может помогать интерпретации, но не гарантирует попадание в Knowledge Graph — важны согласованные данные, внешние источники и общая достоверность.
JSON-LD — не отдельная «AI-разметка», а просто формат представления Schema.org, удобный тем, что отделён от HTML-разметки.
Основной тип для карточки товара — Product, при необходимости связанный с Offer. Для вариантов товара — ProductGroup вместе с Product.
Универсальной Schema.org для AI-поиска не существует. Правильная схема выглядит так: сущность страницы → подходящий тип Schema.org → реальные атрибуты → связи через @id → качественный контент → технически доступный сайт.
Для корпоративного сайта это может быть Organization + WebSite + WebPage + Service + Article; для магазина — Organization + Product + Offer + ProductGroup; для локального бизнеса — Organization/LocalBusiness + WebPage + BreadcrumbList.
Ответ на вопрос «какая Schema.org нужна для AI-поиска» — не «особая AI Schema», а точная структурированная модель реальных сущностей сайта. Именно такой подход соответствует современному Entity SEO: поисковая система должна не просто находить текст, а понимать, о какой сущности, её свойствах и отношениях идёт речь.
Проверим, как сейчас выглядит разметка вашего сайта, и предложим, что усилить для классического SEO и для видимости в нейросетях.