Как JSON-LD помогает ИИ понять ваш сайт

Jun 3, 2026 · 8 min read

JSON-LD — это формат на основе тега <script> для встраивания словаря Schema.org в виде структурированных, машиночитаемых метаданных в HTML. Он позволяет поисковым системам и ИИ-системам идентифицировать сущности — статьи, организации, продукты, хлебные крошки, людей — без необходимости извлекать эту информацию из текста. Для Google Search корректный JSON-LD делает страницы пригодными для отображения в специальных поисковых функциях и помогает наполнять Knowledge Graph. Для ИИ-краулеров, таких как GPTBot, ClaudeBot и PerplexityBot, существует одно жёсткое ограничение, которое frontend-разработчики неизменно упускают из виду: эти краулеры не выполняют JavaScript, поэтому JSON-LD должен присутствовать в ответе сервера, чтобы вообще быть им доступным.

В этой статье рассматривается, что JSON-LD реально делает, где он помогает, а где нет, три рабочих примера, которые можно адаптировать под свои нужды, проблема рендеринга, из-за которой разметка, внедряемая на стороне клиента, оказывается недоступна ИИ-краулерам, а также способы валидации того, что вы публикуете.

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

JSON-LD — это рекомендованный Google формат структурированных данных, использующий словарь Schema.org для описания сущностей и их взаимосвязей в машиночитаемой форме.
ИИ-краулеры, включая GPTBot, ClaudeBot и PerplexityBot, не выполняют JavaScript — JSON-LD, внедрённый через useEffect, Google Tag Manager или любым другим клиентским способом, для них невидим.
AI Overviews и AI Mode не требуют специальной разметки для ИИ; применяются те же критерии, что и для обычного Google Search, а структурированные данные помогают интерпретации контента, но не гарантируют включения в результаты.
Google прекратил показывать расширенные результаты для FAQ в мае 2026 года; поддержка в Search Console и Rich Results Test была удалена в июне 2026 года. Тип FAQPage остаётся валидным в Schema.org, однако больше не является инструментом для получения расширенных результатов поиска.
Для долгосрочной валидации validator.schema.org является более надёжным выбором по умолчанию — он проверяет полный словарь Schema.org, тогда как Google Rich Results Test охватывает только функции, поддерживаемые Google.

Что такое JSON-LD и зачем он нужен

JSON-LD (JavaScript Object Notation for Linked Data) — это стандартизированный W3C синтаксис для представления связанных данных в формате JSON. В вебе он почти всегда используется для встраивания словаря Schema.org внутри тега <script type="application/ld+json"> в документе. Данные описывают сущности страницы — о чём она, кто её написал, какая организация опубликовала, как она связана с другими страницами — в форме, которую парсер может обработать без чтения текста.

«Зачем» — это вопрос интерпретационных затрат. Без структурированных данных краулер вынужден самостоятельно определять, что «Apple» на странице относится к компании, а не к фрукту; что «Иван Петров» в строке авторства — это автор, а не упоминаемый персонаж; что цена в разметке относится к продукту на странице, а не к связанному товару в боковой панели. Schema.org задаёт этим фактам явные типы и свойства. JSON-LD доставляет их в блоке, отделённом от видимого DOM, — именно поэтому Google рекомендует его вместо Microdata и RDFa: вы можете генерировать и обновлять его, не затрагивая вёрстку.

Несколько утверждений, которые стоит сформулировать точнее: JSON-LD не является подтверждённым фактором ранжирования в задокументированных системах ранжирования Google. Он не гарантирует расширенные результаты — соответствие требованиям необходимо, но недостаточно. Он не гарантирует включение в AI Overviews или AI Mode. И ИИ-системы не требуют JSON-LD — они могут читать обычный текст. То, что JSON-LD действительно делает, — это снижает объём логических выводов, что повышает вероятность корректной интерпретации и снижает вероятность неправильной классификации неоднозначного контента.

Как JSON-LD вписывается в AI Overviews и AI Mode

AI Overviews и AI Mode работают поверх существующего поискового индекса Google. Согласно опубликованным рекомендациям Google, специальной разметки для ИИ не существует — страницы становятся пригодными для ИИ-функций через те же сигналы контента и структурированных данных, которые управляют обычным поиском. Если ваша страница корректно проиндексирована, структурирована и соответствует намерению пользователя, структурированные данные, которые вы публикуете для Search, — это те же данные, на которые опираются эти функции.

Честная формулировка: структурированные данные помогают ИИ-системам правильно интерпретировать ваш контент. Они не обеспечивают включение в генерируемые ответы. Рассматривайте их как способ устранить неоднозначность, а не как инструмент роста.

Проблема рендеринга для ИИ-краулеров

Это единственный наиболее важный технический момент для frontend-разработчиков, который отсутствует в большинстве материалов по JSON-LD: ИИ-краулеры, как правило, следует рассматривать как краулеры без рендеринга, поэтому структурированные данные должны присутствовать в исходном HTML-ответе.

GPTBot от OpenAI получает HTML и не выполняет клиентский JavaScript.
ClaudeBot от Anthropic работает как стандартный HTTP-краулер без выполнения JS.
PerplexityBot аналогично читает только сырой HTML.

Googlebot является исключением: он как правило рендерит JavaScript в отложенном проходе, поэтому JSON-LD, внедрённый на стороне клиента, в конечном счёте будет обработан для Search. ИИ-краулеры не наверстают упущенное. Если ваш JSON-LD существует только после гидратации, он невидим для систем, о которых сейчас спрашивает большинство читателей.

Типичный сценарий ошибки в реальных frontend-приложениях: разработчик добавляет JSON-LD внутри хука useEffect или публикует его через Google Tag Manager. Блок появляется в отрендеренном DOM, Rich Results Test (который выполняет рендеринг) показывает его как валидный, и команда считает задачу выполненной. Тем временем каждый краулер без рендеринга получает HTML-ответ вообще без каких-либо структурированных данных.

Решение — поместить блок <script type="application/ld+json"> в исходный ответ сервера.

Серверный рендеринг JSON-LD по фреймворкам

Фреймворк	Куда помещать JSON-LD
Next.js App Router	Встроенный `<script type="application/ld+json">` в Server Component или поле `other` в Metadata API
Next.js Pages Router	Встроенный `<script>` внутри `<Head>` из `next/head`, рендеримый в `getServerSideProps`/`getStaticProps`
Nuxt 3	`useHead` с записью `script`, вызываемый в серверном контексте
Astro	Встроенный `<script type="application/ld+json">` непосредственно в шаблоне `.astro` (статический по умолчанию, выполнение JS не требуется)
SvelteKit	Блок `<svelte:head>`, содержащий скрипт, рендеримый на стороне сервера

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

Три рабочих примера JSON-LD

Примеры ниже используют словарь Schema.org версии 30.0, выпущенной 19 марта 2026 года.

BlogPosting (подтип Article)

В иерархии Schema.org BlogPosting является подтипом Article, который, в свою очередь, является подтипом CreativeWork. Объявление "@type": "BlogPosting" неявно наследует все свойства Article — объявлять оба типа не нужно.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://openreplay.com/blog/json-ld-ai-search#article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://openreplay.com/blog/json-ld-ai-search"
  },
  "headline": "How JSON-LD Helps AI Understand Your Website",
  "description": "A frontend-focused guide to JSON-LD, Schema.org, and the server-rendering requirement for AI crawlers.",
  "image": "https://openreplay.com/images/blog/json-ld-ai-search.png",
  "datePublished": "2026-05-20T09:00:00-04:00",
  "dateModified": "2026-05-20T09:00:00-04:00",
  "author": {
    "@type": "Organization",
    "name": "OpenReplay Team",
    "url": "https://openreplay.com"
  },
  "publisher": {
    "@id": "https://openreplay.com/#organization"
  }
}
</script>

Используйте это на страницах со статьями большого объёма. mainEntityOfPage связывает статью с её каноническим URL; dateModified важен, поскольку Google использует его как сигнал актуальности для запросов, чувствительных ко времени.

Organization

Тип Organization описывает публикующую организацию. Используйте sameAs для указания на канонические внешние профили — именно так системы разграничивают ваш бренд от других с похожими названиями.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://openreplay.com/#organization",
  "name": "OpenReplay",
  "url": "https://openreplay.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://openreplay.com/images/logo.png",
    "width": 512,
    "height": 512
  },
  "sameAs": [
    "https://github.com/openreplay",
    "https://www.linkedin.com/company/openreplay",
    "https://x.com/OpenReplayHQ"
  ]
}
</script>

Публикуйте это один раз на всём сайте — как правило, в заголовке документа на каждой странице. Повторно используйте @id из других блоков схемы (как это делает BlogPosting.publisher выше), чтобы единственное каноническое определение Organization было везде на него ссылалось, а не дублировалось.

BreadcrumbList

BreadcrumbList описывает место страницы в иерархии сайта. Google поддерживает расширенные результаты для хлебных крошек, а те же данные помогают ИИ-системам понять структуру сайта.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://openreplay.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://openreplay.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How JSON-LD Helps AI Understand Your Website"
    }
  ]
}
</script>

Последний элемент не содержит item, поскольку это текущая страница. Нумерация position начинается с 1.

Согласованность структурированных данных с видимым контентом

Рекомендации Google по структурированным данным однозначны: контент в JSON-LD должен соответствовать тому, что отображается на странице. Разметка отзывов, которых нет на странице, цен, которые не отображаются, или имён авторов, противоречащих видимым подписям, — это риск получения ручных санкций. Структурированные данные должны описывать страницу, а не дополнять её утверждениями, не подкреплёнными в DOM.

Это важно и для ИИ-систем. Если ваш видимый текст говорит одно, а JSON-LD — другое, вы создаёте именно ту неоднозначность, которую структурированные данные призваны устранять.

Валидация перед публикацией

Два инструмента охватывают весь рабочий процесс:

Инструмент	Что проверяет	Лучше всего подходит для
Google Rich Results Test	Соответствие требованиям для поддерживаемых Google типов расширенных результатов	Проверка перед деплоем для Article, Product, Breadcrumb и т.д.
Schema Markup Validator	Соответствие полному словарю Schema.org	Общая валидация; любые типы, которые Google не отображает как расширенные результаты

Rich Results Test рендерит страницу (поэтому видит JSON-LD, внедрённый на стороне клиента, который ИИ-краулеры не увидят). Чтобы проверить, что видят краулеры без рендеринга, выполните curl -A "GPTBot" https://your-page для вашего URL и найдите в ответе application/ld+json. Если блок отсутствует в этом сыром HTML, ИИ-краулеры его не увидят.

Раздел Enhancements в Google Search Console сообщает об ошибках парсинга и соответствии требованиям для типов структурированных данных, которые отслеживает Google. Используйте его для постоянного мониторинга, а не как замену валидации перед деплоем.

Замечание о FAQPage

FAQPage по-прежнему является валидным типом Schema.org, и Google всё ещё использует его для понимания контента. Однако Google отмечает в своей документации по FAQPage, что связанные с FAQ функции поиска удаляются: расширенные результаты для FAQ перестали отображаться в поиске в мае 2026 года; отчётность в Search Console и поддержка в Rich Results Test удаляются в июне 2026 года; поддержка Search Console API последует в августе 2026 года. Если вы выбираете схему для реализации сейчас с целью получить видимый прирост расширенных результатов, FAQPage — не тот вариант. Реализуйте его, если у вас есть настоящая страница с часто задаваемыми вопросами и вы хотите зафиксировать семантику — но не как инструмент захвата пространства в SERP.

Это также объясняет, почему validator.schema.org является более надёжным выбором по умолчанию для долгосрочной работы по валидации: он не зависит от того, какие функции Google решает отображать как расширенные результаты.

С чего начать

Если вы начинаете с нуля, наиболее ценная последовательность такова: один блок Organization на всём сайте, BreadcrumbList на каждой странице, кроме главной, и Article/BlogPosting для редакционного контента. Рендерите всё это на сервере. Валидируйте обоими инструментами. Затем проверьте сырой HTML-ответ с помощью user agent без рендеринга, чтобы убедиться, что ИИ-краулеры действительно получают то, что вы написали.

Структурированные данные сами по себе не улучшат позиции в поиске и не обеспечат попадание в AI Overviews. Что они делают — надёжно, при правильной реализации — так это устраняют интерпретационные догадки, из-за которых поисковые системы и ИИ-системы неверно понимают ваш контент. Для frontend-команд наиболее важная работа — не выбор типов схем, а определение их места в конвейере рендеринга. Поместите JSON-LD в ответ сервера, а остальное — дело контента.

Часто задаваемые вопросы

Используйте JSON-LD. Google явно рекомендует его вместо Microdata и RDFa, поскольку он находится в едином блоке script, отделённом от видимого DOM, — это означает, что вы можете генерировать и обновлять структурированные данные, не затрагивая разметку вёрстки. Все три формата могут выражать словарь Schema.org и парсятся Google, однако JSON-LD проще в сопровождении, проще серверно рендерится и является форматом, который Google использует во всей своей документации по структурированным данным.

Да. Google поддерживает несколько отдельных тегов script на одной странице — это стандартный подход для комбинирования таких типов, как Organization, BreadcrumbList и BlogPosting. Альтернатива — единый script, содержащий массив graph под ключом @graph, где каждая сущность получает свой @id. Оба подхода валидны; паттерн @graph удобнее, когда сущности ссылаются друг на друга через @id, поскольку позволяет хранить единственное каноническое определение каждой сущности.

Только если JSON-LD присутствует в исходном ответе сервера. SPA, внедряющие структурированные данные после гидратации, невидимы для краулеров без рендеринга, таких как GPTBot, ClaudeBot и PerplexityBot. Решение — серверный рендеринг или статическая генерация для страниц, которым нужны структурированные данные, с использованием Next.js, Nuxt, Astro или SvelteKit в режимах SSR или SSG, — чтобы тег script существовал в байтах HTML до выполнения какого-либо JavaScript.

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

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.