Skip to content
SSamcheek.

JSON-LD Schema.org в Next.js App Router: полный справочник (2026)

Schema.org - не набор HTML-тегов, а спецификация графа сущностей. Разница определяет результат: сайт с JSON-LD как тегами получает редкие rich snippets; сайт с JSON-LD как knowledge graph получает устойчивое представление сущности в Google Knowledge Graph, AI Overviews и LLM-индексах цитирования.

Архитектура JSON-LD Schema.org в Next.js App Router
Опубликовано:•Обновлено:•Время чтения:18 мин

JSON-LD Schema.org - одновременно наиболее недоиспользуемая SEO-техника (большинство сайтов не имеют структурированных данных или имеют сломанные) и самое высокорычажное одиночное изменение (правильно реализованная схема Product с AggregateRating даёт звёздные рейтинги в SERP без дополнительной контентной работы). В этой статье разбираю три вещи: модель entity graph Schema.org - как @id-линковка соединяет разрозненные JSON-LD блоки в представление знаний, которое реально используют Google и LLM-системы; архитектуру инъекции в Next.js App Router - что умеет generateMetadata(), а что нет, почему Server Component <script> - правильный паттерн, и XSS-вектор в dangerouslySetInnerHTML, который большинство оставляет открытым; и картину eligibility Google rich results в 2026 - что работает, что устарело (HowTo, сент. 2023), что ограничено (FAQPage, авг. 2023), и зачем сохранять 'невознаграждённые' структурированные данные для AI/LLM-цитирования.

Часть I - Модель entity graph: Schema.org - не тегологарный словарь

Концептуальная ошибка, продуцирующая низкоценные реализации, - трактовать Schema.org как набор меток @type для декорирования контента. Schema.org - это *общий словарь для описания сущностей и их связей*, предназначенный для машин, строящих представления знаний. Три базовых категории: Things (любая сущность: Person, Product, Article), Actions (верифицируемые события: SearchAction, ReviewAction) и DataTypes (text, number, date, URL).

  • @id линковка: Каждая сущность, на которую ссылаются другие, должна иметь @id - глобально уникальный URI. BlogPosting с "author": { "@type": "Person", "@id": "https://samcheek.com/about#person" } ссылается на известную идентифицированную сущность, описанную на странице About. Когда Google видит одинаковый @id URI на нескольких страницах, он накапливает доказательства об этой сущности - так личные бренды получают Knowledge Panel записи.
  • @graph паттерн: Несколько связанных сущностей страницы объединяются в один JSON-LD блок под "@graph": [...]. Чище, чем несколько <script> тегов, и делает связи между сущностями явными.
  • sameAs: Связывает сущность с её представлениями на авторитетных источниках (LinkedIn, GitHub, Twitter, Wikidata). Каждый sameAs URL - сигнал подтверждения сущности. Google использует его для построения уверенности в Knowledge Graph-представлении.
  • @context обязателен: Каждый JSON-LD блок должен включать "@context": "https://schema.org". Без него типы и свойства - произвольные строки без семантики. JSON-LD блок без @context производит нулевую ценность структурированных данных.

Часть II - JSON-LD vs Microdata vs RDFa

  • Microdata: HTML-атрибуты itemscope, itemtype, itemprop непосредственно в разметке. Проблемы: тесная связь данных с DOM - любой рефактор разметки молча ломает схему; не может описать данные, которые не отображаются на странице.
  • RDFa: XML-пространства имён в HTML. Те же проблемы связанности, что и у Microdata.
  • JSON-LD: Структурированные данные в блоке <script type="application/ld+json">, полностью отделены от HTML. Преимущества: презентационно-независим; безопасен к рефакторингу; легко генерируется программно; рекомендуемый формат Google. <script type="application/ld+json"> не выполняется браузером как JavaScript - MIME-тип сигнализирует, что это данные.

Часть III - Архитектура инъекции в Next.js App Router

  • `generateMetadata()` НЕ поддерживает JSON-LD: API Metadata управляет <title>, <meta>, <link rel> - но не произвольными <script> тегами. Поля structuredData или jsonLd не существует в типе Next.js Metadata.
  • Server Component `<script>` инъекция (правильный паттерн): <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }} />. Рендерится в начальный серверный HTML; никакого клиентского JavaScript.
  • Компонент `<StructuredData>`: Тонкая обёртка, принимающая data пропс и рендерящая <script> тег. Единственный канонический паттерн инъекции структурированных данных по всем страницам.
  • XSS через dangerouslySetInnerHTML: JSON.stringify(data) может содержать </script>, если поле данных содержит эту подстроку. Исправление: JSON.stringify(data).replace(/</g, '\\u003c'). Unicode-экранирование валидно для JSON, браузер никогда не увидит буквальный </script> внутри блока <script>.
  • Стратегия размещения: Site-level сущности (WebSite, Person/Organization) - в app/layout.tsx. Page-level сущности (Article, Product, BreadcrumbList) - в page.tsx каждого маршрута.

Часть IV - Site-level схема: WebSite, Person, Organization

  • WebSite + SearchAction (Sitelinks Searchbox): { "@type": "WebSite", "@id": "https://example.com#website", "url": "https://example.com", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/search?q={search_term_string}" }, "query-input": "required name=search_term_string" } }. Триггерит поисковый виджет Sitelinks в брендированных SERP.
  • Person (личный бренд): Ключевые свойства: name, url, image (Google использует для Knowledge Panel), jobTitle, sameAs (массив URL соцпрофилей), address (PostalAddress), knowsAbout (массив тематических строк - помогает AI-системам определить экспертизу). URI @id - персистентный идентификатор сущности, используемый всеми article и review схемами.
  • ProfessionalService: Субкласс LocalBusiness. Добавляет serviceType, hasOfferCatalog. Требуется для Google local service rich results: name, address, telephone. Для remote-only бизнеса - areaServed: 'Worldwide'.

Часть V - Content Schema: Article, BlogPosting

  • Иерархия типов: BlogPosting → Article → CreativeWork → Thing. Используйте BlogPosting для блог-статей; NewsArticle только для журналистики от признанных новостных издателей.
  • Обязательные поля для Google rich results: headline (≤ 110 символов), image (min 1200×630px), datePublished (ISO 8601: "2026-03-18" - не строка типа "18 марта 2026"), author (Person с name и @id для E-E-A-T). Отсутствие любого из них подавляет eligibility rich result.
  • author @id entity linking (цепочка E-E-A-T): "author": { "@type": "Person", "@id": "https://samcheek.com/about#person", "name": "Yevhen Samkov" }. Google следует @id-ссылке на Person-сущность с knowsAbout и sameAs при оценке E-E-A-T статьи.
  • dateModified: Включать всегда. Обновлять при любых содержательных правках - не только при исправлении опечаток. Машиночитаемый сигнал свежести контента.

Часть VI - Product, Offer, AggregateRating

  • Обязательные поля для Product rich results: name, image, offers.price (строка: "29.99"), offers.priceCurrency (ISO 4217: "USD"), offers.availability ("https://schema.org/InStock"). Полная архитектура Product-схемы для headless Shopify - в гайде по headless Shopify.
  • AggregateRating (звёздные рейтинги в SERP): ratingValue, bestRating, worstRating, ratingCount - обязательны. Без ratingCount Google не отображает звёзды.
  • Merchant listings (Google Shopping бесплатно): Продукты с валидным Product + Offer eligible для бесплатных merchant listings в Shopping-вкладке. Обязательно: Offer.seller идентифицирует продавца.

Часть VII - FAQPage после ограничения августа 2023

  • Ограничение 2023: Google убрал FAQPage accordion rich results для коммерческих сайтов в августе 2023. Остаётся только для государственных и медицинских сайтов. Техническая реализация FAQPage не устарела - только визуальное SERP-улучшение убрано.
  • Ценность для AI/LLM-цитирования (GEO): Структура Question + acceptedAnswer.text обеспечивает AI-системам (Google AI Overviews, Perplexity, ChatGPT) данные с высокой точностью извлечения для цитирования в AI-генерируемых сводках. acceptedAnswer.text должен быть полным самодостаточным ответом - AI-системы не переходят по ссылкам при построении цитат.
  • Рекомендация: Существующую FAQPage схему сохранять - LLM-цитирование + Bing rich results. Не добавлять новую исключительно ради Google rich results. FAQ-секции проектировать с полными acceptedAnswer.text для AI-извлечения.

Часть VIII - BreadcrumbList, устаревшие типы и частые ошибки

  • BreadcrumbList: Изменяет отображение URL в SERP с технического пути на читаемую хлебную крошку. Требует полного соответствия визуальной навигации на странице - расхождение может вызвать ручное действие Google.
  • HowTo - устарел сентябрь 2023: Google убрал HowTo rich results. Всю HowTo-схему на коммерческих сайтах следует удалить - производит нулевую ценность и вызывает предупреждения в Rich Results Test.
  • Частые ошибки:
  • Отсутствие @context - JSON-LD блок без семантики.
  • Регистр @type: PascalCase (Product, BlogPosting) - не product, blog-posting.
  • datePublished формат: только ISO 8601 ("2026-03-18").
  • price - строка, не число: "29.99", не 29.99.
  • Относительные URL в url/item/@id - только абсолютные URL.
  • XSS через dangerouslySetInnerHTML: JSON.stringify(data).replace(/</g, '\\u003c').

Заключение

Структурированные данные, реализованные как entity graph с @id-линковкой, sameAs-перекрёстными ссылками и полными обязательными полями, производят накопительную ценность, которую тег-чеклист не даёт. Немедленная ценность - SERP-улучшения; долгосрочная - Knowledge Graph-представление сущности, делающее сайт цитируемым источником в AI Overviews и LLM-поиске. Для аудита структурированных данных или полного technical SEO - сервис technical SEO & schema | кейсы | обсудить проект.

Источники

Похожие статьи

Архитектура веб-производительности: системный анализ 12 инженерных принципов (издание 2026)

Глубокий технический разбор веб-производительности 2026 года: физика сетей, конвейеры изображений, модели выполнения JavaScript, Critical Rendering Path, edge-вычисления, Core Web Vitals и продакшн RUM - с реальными бенчмарками и конкретными примерами реализации.

EngineeringArchitectureCore Web Vitals
Читать статью

React 19: useOptimistic, use(), Server Actions - механизм и архитектура (2026)

Детальный разбор пяти новых примитивов React 19: useOptimistic (конкурентная composition оптимистичного состояния с автоматическим rollback), use() (условное чтение Promise и Context), Server Actions (RPC-over-HTTP контракт и Progressive Enhancement), useActionState (стейт-threading паттерн), useFormStatus. Action-based mutation архитектура, которая заменяет Redux/Zustand для серверных мутаций.

React 19ArchitectureNext.js
Читать статью

Partial Prerendering (PPR) в продакшне: архитектурные паттерны (2026)

Детальный разбор Next.js Partial Prerendering в продакшне. Механизм двухфазного ответа (статический shell с CDN + стриминговые dynamic holes), правила размещения Suspense-границ, взаимодействие с Full Route Cache, дизайн fallback для нулевого CLS, измеренные TTFB/LCP, сравнение с ISR+CSR и full SSR, известные ограничения и фреймворк принятия решений.

Next.jsPerformancePPR
Читать статью