Структурированные данные для ИИ-агентов: schema.org, который читают ассистенты

Schema.org и JSON-LD — это не секретный буст для ChatGPT или Google AI. Это нечто более долговечное: явный машиночитаемый слой, который сообщает поисковым и ИИ-системам, кто вы, что предлагаете и как связаны между собой факты на странице. Google прямо пишет, что использует найденные в вебе структурированные данные, чтобы понимать содержание страницы и собирать сведения о мире, а schema.org описывает себя как общий словарь для структурированных данных, используемый поисковиками и другими приложениями (Google). Это и есть честное обещание — не больше и не меньше.

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

Ключевые выводы

• Schema.org/JSON-LD не заставят ИИ вас цитировать. Они снижают неоднозначность, чтобы система извлекла ваши канонические факты, а не собрала менее точную версию из текста (Google).
• Google говорит, что никаких дополнительных требований и специальной разметки для появления в AI Overviews или AI Mode нет, а чрезмерный фокус на структурированных данных называет мифом (Google).
• Но явная структура может выигрывать: Google пишет, что предоставленные издателем структурированные данные могут иметь приоритет над автоматически извлечёнными (Google).
• Сначала добавьте сущности, которые ассистенты обязаны распознать: Organization + WebSite, затем SoftwareApplication, Product + Offer и FAQPage — только там, где есть реальный видимый Q&A.
• Разметка — лишь один канал. Агенты читают ещё сырой HTML и accessibility tree, поэтому schema не заменяет семантический HTML (web.dev). aiSiteReady проверяет всё это и оценивает сайт от 0 до 100.

Помогает ли schema.org ChatGPT и Google AI?

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

Для ИИ-функций Google документация прямолинейна. Google заявляет, что нет дополнительных требований для появления в AI Overviews и AI Mode, что специальные «оптимизации» не нужны, а обычные практики SEO по-прежнему применимы. Утверждения «нужны специальные файлы разметки» и «нужна отдельная ИИ-оптимизация» компания прямо относит к мифам и называет чрезмерный фокус на структурированных данных ненужным (Google). Поэтому честно продавать schema как обходной путь в ИИ-сводки нельзя.

При этом недооценивать её тоже неверно. Google также пишет, что явные подсказки о смысле страницы помогают Поиску её понять, а в примере с pros and cons показывает: когда издатель предоставляет структурированные данные, Google предпочитает их тем, что извлёк бы автоматически (Google). Вот реальный механизм: schema не заставляет ИИ вас цитировать — она повышает шансы, что система прочитает ваши канонические факты, а не соберёт менее точную версию из свободного текста.

Для ChatGPT формулируйте аккуратно. OpenAI не публикует чеклист «добавьте тип X и свойство Y, чтобы расти в ChatGPT Search». Компания пишет, что ранжирование зависит от множества факторов, топ-позиции гарантировать нельзя, а практическое требование, чтобы вас показывали, — не блокировать OAI-SearchBot (OpenAI). Поскольку ChatGPT Search переписывает запросы в подзапросы и может опираться на сторонних поисковых провайдеров, schema, скорее всего, помогает ему через системы извлечения, на которые он опирается, — это вывод из архитектуры, а не заявленный OpenAI фактор ранжирования.

Почему JSON-LD помогает ИИ, но не является магией

Рассматривайте JSON-LD как самый удобный транспортный слой для смысла, а не как SEO-хитрость. Google рекомендует JSON-LD именно потому, что его проще внедрять и поддерживать в масштабе, а W3C определяет его как JSON-совместимую сериализацию linked data, спроектированную так, чтобы встраиваться в системы, уже использующие JSON (W3C). Это стандартный способ сделать факты машиночитаемыми, а не трюк, нацеленный на языковые модели.

Картина извлечения объясняет, почему это важно. Собственное руководство Google по генеративным ИИ-функциям описывает их как RAG плюс query fan-out поверх обычного поискового индекса: система извлекает релевантные страницы, затем использует конкретные фрагменты этих страниц, чтобы сгенерировать ответ с заметными ссылками на источники (Google). Чем меньше неоднозначности в ваших сущностях и фактах, тем надёжнее система достанет нужный фрагмент и заземлит на нём ответ.

Есть жёсткое ограничение, которое стоит проговорить прямо: структурированные данные — лишь один из нескольких каналов. Руководство Google на web.dev говорит, что агенты воспринимают сайт тремя способами — скриншоты, сырой HTML и accessibility tree, — а OpenAI добавляет, что доступность и метки ARIA помогают агенту ChatGPT понять структуру сайта и интерактивные элементы (web.dev). Вывод для разработчиков: schema описывает факты о сущностях; семантический HTML и доступность описывают структуру и действия. JSON-LD не заменяет ни то, ни другое.

Какие типы schema.org добавить в первую очередь?

Не начинайте с «максимального числа типов». Начните с сущностей, которые ассистент должен распознать и процитировать без двусмысленности. Совет Google — использовать наиболее специфичные применимые типы и имена свойств, а когда на странице несколько связанных сущностей — связывать их общим @id (Google).

Organization + WebSite — базовый слой идентичности: ассистент понимает, кто издаёт сайт, какой у него официальный URL, какой логотип использовать и какие внешние профили подтверждают эту идентичность. Различайте url (официальный URL самой сущности) и sameAs (внешние страницы, которые её однозначно подтверждают). Используйте один канонический @id на сущность и переиспользуйте его.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "url": "https://example.com/",
      "name": "Acme AI",
      "legalName": "Acme AI LLC",
      "logo": "https://example.com/static/logo.png",
      "sameAs": [
        "https://www.linkedin.com/company/acme-ai/",
        "https://github.com/acme-ai"
      ],
      "contactPoint": [
        { "@type": "ContactPoint", "contactType": "sales", "email": "sales@example.com" }
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Acme AI",
      "inLanguage": "ru-RU",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}

Именно общий @id позволяет потребителю считать Organization и WebSite одной связанной идентичностью, а не двумя несвязанными блоками. Та же дисциплина окупается между страницами: связывайте Product, его Organization и WebSite через устойчивые идентификаторы.

SoftwareApplication уместен на страницах SaaS и приложений, потому что ассистентам часто задают очень фактические вопросы: есть ли бесплатный тариф, это веб или мобайл, сколько стоит, кто выпускает. Полезные свойства — name, description, applicationCategory, operatingSystem, offers и aggregateRating. Универсального «обязательного» списка на уровне словаря нет — соберите минимальный набор фактов, который агент сможет извлечь, не читая маркетинговый текст.

{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "@id": "https://example.com/app/#software",
  "name": "Acme Copilot",
  "url": "https://example.com/app/",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "offers": { "@type": "Offer", "price": "29", "priceCurrency": "USD" },
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.8", "ratingCount": "127" }
}

Product + Offer — самый измеримый тип для коммерции. Для merchant listings Google требует у Product как минимум name, image и offers, а внутри Offer — действующую цену (price или priceSpecification.price) и валюту. availability относится к рекомендуемым, а description, brand и GTIN Google настоятельно советует добавлять, потому что они улучшают качество и проверяемость данных (Google).

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/widget-pro#product",
  "name": "Widget Pro",
  "image": ["https://example.com/images/widget-pro.jpg"],
  "brand": { "@type": "Brand", "name": "Acme" },
  "sku": "WIDGET-PRO-1",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/widget-pro",
    "price": "199.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Для шопинга page-level schema — лишь часть истории. OpenAI публично продвигает структурированные product feeds: документация Agentic Commerce описывает, как мерчанты передают feed, который ChatGPT индексирует, чтобы понимать атрибуты товара и показывать актуальные цену и наличие, и называет эти поля «канонической записью», используемой для показа и ссылки на товар (OpenAI). Так что для каталога schema.org на странице — хорошая база, но product feed — ещё более прямой канал в ChatGPT shopping.

FAQPage всё ещё работает как строго структурированный формат Q&A, но в 2026 году требует оговорки. Валидный FAQPage строится вокруг mainEntity, где у каждого Question есть name и acceptedAnswer, а у каждого Answer — text. Однако текущая документация Google сообщает, что FAQ rich results перестали показываться в Google Поиске 7 мая 2026 года, а поддержка FAQ в Rich Results Test удаляется в июне 2026 года (Google). Используйте его как честную семантическую нормализацию FAQ, которые пользователи реально видят, — а не как новый рычаг роста для ИИ. И только там, где у каждого вопроса один официальный ответ; если ответы могут добавлять пользователи, Google рекомендует QAPage.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is there a free plan?",
      "acceptedAnswer": { "@type": "Answer", "text": "Yes. There is a free tier with core features." }
    }
  ]
}

Какие ошибки ломают пользу от JSON-LD?

«Мы добавили schema, и ничего не произошло» почти всегда сводится к одному из этого.

• Сломанный JSON. W3C прямо указывает, что документ JSON-LD всегда должен быть валидным JSON; если базовый JSON синтаксически неверен, ни один потребитель не сможет надёжно прочитать его как linked data (W3C).
• Разорванный граф. Когда одна и та же сущность размечена разными @id — или вовсе без него, — потребитель не понимает, что это один объект. Google советует использовать @id, чтобы связать элементы и Поиск понял, например, что видео относится к конкретному рецепту (Google). Один канонический id на сущность, переиспользуемый везде.
• Разметка, не совпадающая со страницей. Google предупреждает, что структурированные данные должны представлять основной контент страницы, не должны описывать скрытый от пользователя контент и не должны вводить в заблуждение; для FAQ — что контент должен быть виден на странице (Google). Валидная, но невидимая разметка подрывает доверие ко всей вашей разметке.
• Неполные consumer-specific поля. Словарь гибок, но конкретные потребители определяют свои обязательные поля. Без name, image, offers и действующей цены с валютой Product просто не получает eligibility как merchant listing (Google).
• Неверный тип страницы. Размечать пользовательский support-тред как FAQPage — плохая модель; Google рекомендует QAPage, когда ответы могут добавлять пользователи. Давайте странице основной тип, соответствующий её реальной теме.
• Блокировки, устаревание или данные только через JS. Google просит не блокировать страницы со структурированными данными через robots.txt или noindex и поддерживать актуальность time-sensitive данных. OpenAI пишет, что OAI-SearchBot нужно разрешить, иначе сайт не появится в поиске ChatGPT (OpenAI). А если критические факты существуют только после запуска клиентского JavaScript, многие ИИ-краулеры, которые не рендерят JavaScript, их не увидят. Размещайте семантическое ядро и JSON-LD в первом HTML.

Как структурированные данные связаны с ИИ-ответами и измерением?

Для ИИ-функций Google продавайте schema как часть чистой технической структуры и eligibility для rich results, а не как ярлык в сводки — документация ясно говорит, что специальных требований нет (Google). Выигрыш — снижение неоднозначности, а не гарантированное цитирование.

Для ChatGPT связь идёт через доступ к обходу и citability. FAQ OpenAI для издателей говорит, что любой публичный сайт может появляться в поиске ChatGPT, а чтобы вас обнаружили, показали и явно процитировали, нельзя блокировать OAI-SearchBot — это отдельная настройка от обучающего краулера GPTBot (OpenAI). Если не уверены, каких ботов вы разрешаете, наш гайд по управлению ИИ-краулерами в robots.txt распутывает эту матрицу. Для агентного браузинга OpenAI пишет, что агент ChatGPT лучше понимает сайты, которые следуют практикам доступности и используют роли и метки ARIA, — так что семантика интерфейса нередко важна не меньше, чем JSON-LD в <head>.

Измерять результат тоже стало проще. 3 июня 2026 года Google запустил отчёты Search Console для генеративных ИИ-функций, включая видимость в AI Overviews, AI Mode и генеративном ИИ в Discover (Google). OpenAI сообщает, что издатели, разрешившие OAI-SearchBot, могут отслеживать реферальный трафик из ChatGPT по utm_source=chatgpt.com. Ни то, ни другое не докажет, что конкретный рост вызван schema, но вместе они позволяют связать улучшения технической структуры с изменениями ИИ-видимости и реферального трафика.

Как проверять разметку?

Проверяйте в три слоя, потому что «валидно по schema.org» и «поддерживается конкретной платформой» — не одно и то же.

1. Schema Markup Validator — для базового синтаксиса и корректности на уровне словаря (schema.org).
2. Google Rich Results Test — чтобы увидеть, какие rich results Google может сгенерировать (consumer-specific eligibility).
3. URL Inspection / Search Console — чтобы увидеть страницу так, как её видит Google, и проверить индексацию, доступность и отсутствие препятствий для краулера.

Случай с FAQ показывает, почему различие важно: идеально валидный FAQPage больше нельзя подавать как актуальный рычаг роста в Google теперь, когда FAQ rich results исчезли, а поддержка FAQ уходит из Rich Results Test. После этого опирайтесь на schema-валидатор и проверки «контент совпадает со страницей», а не на превью rich result.

Как проверить весь сайт сразу?

Проверить один шаблон вручную реально; проверять каждый шаблон на каждом релизе, по структурированным данным и по слоям под ними, — нет. Эту работу делает aiSiteReady. Он загружает ваш сайт так, как это сделал бы агент, и сообщает по Meta & structured data (JSON-LD, Open Graph), HTML без JavaScript, robots.txt, sitemap.xml, правилам для ИИ-краулеров и обнаружению протоколов вроде MCP и OAuth — в виде оценки от 0 до 100 с блокерами и приоритизированными исправлениями.

Это относится к проверкам обнаружимости и протоколов в оценке, рядом со шлюзом доступности контента, который решает, может ли агент вообще прочитать вашу страницу. Точные проверки и веса описаны на странице методологии, а этот гайд — подробный разбор структурированных данных за материалом о том, что значит готовность к ИИ-агентам. Когда страницы станут читаемыми, можно также дать ассистентам курируемую карту чтения через llms.txt.

Запустите бесплатное сканирование, чтобы увидеть, действительно ли ChatGPT, Claude, Perplexity и Google AI читают ваш JSON-LD, переживает ли контент отсутствие JavaScript, не мешают ли robots.txt и sitemap.xml и какие исправления дадут наибольший эффект первыми — на английском, украинском или русском.

Если коротко: schema.org не заставит ассистентов вас цитировать, но делает ваш сайт гораздо легче для правильного чтения, сопоставления и извлечения фактов — а именно на этом строится качественный ИИ-retrieval.

У IMozz 20 лет в разработке ПО, а последний год он строит продукты с помощью LLM. Он развивает aiSiteReady, сканер только для чтения, который проверяет, может ли ИИ-агент прочитать сайт. Сканер серверно рендерит собственный контент как рабочий пример.