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

Структурированные данные Schema.org в формате JSON-LD - одновременно самая недоиспользованная SEO-техника (большинство сайтов отдают либо ноль разметки, либо сломанную) и самое сильное единичное изменение, которое можно сделать: правильно собранная Product-схема с AggregateRating приносит звёздочки в выдаче без единой строчки нового контента. В этом гайде я разбираю три вещи: модель графа сущностей Schema.org - как связывание через @id превращает разрозненные блоки JSON-LD в представление знаний, которым Google и языковые модели действительно могут пользоваться; архитектуру вставки в Next.js App Router - что generateMetadata() может и чего не может, почему вставка через серверный компонент правильная и какой XSS-вектор в dangerouslySetInnerHTML большинство реализаций оставляет открытым; и картину с rich results на 2026 год - какие типы ещё работают, что удалили (HowTo, сентябрь 2023), что ограничили (FAQPage, август 2023) и почему «невознаграждаемую» разметку всё равно стоит держать ради цитирования в AI.

Почему Schema.org - это граф сущностей, а не словарь тегов?

Потому что он описывает сущности и связи между ними, а не страницу, на которой они оказались. Schema.org - это общий словарь для описания сущностей и их связей, рассчитанный на машины, которые строят представления знаний, а не только на парсер rich results в Google. Концептуальная ошибка, из которой рождаются бесполезные внедрения, - относиться к нему как к словарю тегов, то есть к списку меток @type, украшающих содержимое страницы. Разница в подходе даёт разные архитектурные решения.

Schema.org определяет три базовые категории: Things (любая сущность, существующая в мире: Person, Product, Article, Organization), Actions (события, которые можно подтвердить: Purchase, SearchAction, ReviewAction) и DataTypes (текст, число, дата, URL). Каждый тип схемы - подкласс одной из них. BlogPosting наследуется от Article → CreativeWork → Thing. Эта цепочка определяет, какие свойства допустимы: BlogPosting получает все свойства Article и CreativeWork, включая headline, author, datePublished и image.

Граф сущностей от набора JSON-блоков отличает связывание через @id. У каждой сущности, на которую ссылаются другие, должно быть свойство @id - глобально уникальный URI, служащий её идентификатором. BlogPosting со свойством "author": { "@type": "Person", "name": "Yevhen Samkov" } описывает анонимную сущность Person. Тот же BlogPosting со свойством "author": { "@type": "Person", "@id": "https://samcheek.com/about#person", "name": "Yevhen Samkov" } ссылается на известную сущность с постоянным идентификатором - ту самую, что описана схемой Person на странице About, в свойстве author у WebSite и в схемах Review. Когда Google видит один и тот же URI в @id на разных страницах и в разных свойствах, он накапливает свидетельства об этой сущности. Именно так личные бренды и компании получают карточки Knowledge Panel: через последовательные перекрёстные описания сущности, а не через разметку одной страницы.

• Паттерн @graph: Несколько связанных сущностей одной страницы можно объединить в один блок JSON-LD под ключом "@graph": [...]. Это чище, чем несколько тегов <script type="application/ld+json">, и делает связи между сущностями явными. Пример: страница поста объединяет WebPage, BlogPosting, BreadcrumbList и Person (автора) в один блок @graph. Google обрабатывает @graph как единое целое, что помогает ему вывести отношения между сущностями.
• sameAs как механизм перекрёстных ссылок: Свойство sameAs связывает сущность с её представлениями в других авторитетных источниках. "sameAs": ["https://www.linkedin.com/in/...", "https://twitter.com/...", "https://www.wikidata.org/wiki/Q..."] говорит Google, что все эти внешние профили описывают одну и ту же сущность. Каждая ссылка в sameAs - сигнал подтверждения: чем больше авторитетных источников подтверждают сущность, тем увереннее Google в её представлении в Knowledge Graph.
• @context как объявление словаря: В каждом блоке JSON-LD обязан быть "@context": "https://schema.org". Без него имена типов и свойств ничего не значат - это произвольные строки. @context сопоставляет их с определениями словаря Schema.org. Блок JSON-LD без @context не даёт вообще никакой ценности и не проходит валидацию.

JSON-LD vs Microdata vs RDFa: какой формат выбрать в 2026?

Все три формата выражают одни и те же структурированные данные Schema.org. Разница в технических компромиссах, и она объясняет, почему в 2026 году стоит использовать только JSON-LD.

• Microdata (атрибуты HTML5): Добавляет атрибуты itemscope, itemtype и itemprop прямо в HTML-элементы. <div itemscope itemtype="https://schema.org/Product"><span itemprop="name">Blue Shirt</span></div>. Проблемы: (1) жёстко привязывает разметку данных к структуре DOM - любой рефакторинг вёрстки может незаметно сломать схему; (2) не даёт описать то, что на странице не отрисовано - dateModified статьи не попадёт в Microdata, если он не показан пользователю; (3) плохо читается на код-ревью. Microdata доминировал в 2012–2016 годах, до того как Google окончательно встал на сторону JSON-LD.
• RDFa (атрибуты HTML от W3C): Похож на Microdata, но с пространствами имён, унаследованными из XML: <div vocab="https://schema.org/" typeof="Product"><span property="name">Blue Shirt</span></div>. Немного выразительнее Microdata, но с той же привязкой к представлению. В веб-разработке встречается редко, зато распространён в академических публикациях и государственных данных.
• JSON-LD (JavaScript Object Notation for Linked Data): Структурированные данные в блоке <script type="application/ld+json">, полностью отделённые от HTML-разметки страницы. Плюсы: (1) независимость от представления - описать можно любые данные, а не только отрисованные; (2) устойчивость к рефакторингу - изменения вёрстки на разметку не влияют; (3) генерируется программно из тех же объектов данных, которыми рендерится страница; (4) рекомендованный Google формат с 2016 года и единственный поддерживаемый для некоторых типов rich results. Важно: <script type="application/ld+json"> браузер не исполняет как JavaScript - MIME-тип говорит ему, что это данные, а не код. Но парсится он как JSON, а не как JS, поэтому JS-комментарии и висячие запятые ломают разбор.

Где вставлять JSON-LD в Next.js App Router: Server Component или generateMetadata?

В App Router есть два механизма вставки содержимого в <head>: функция generateMetadata() и прямой рендер серверного компонента. Понимание, что за что отвечает, определяет всю архитектуру разметки.

• Чего generateMetadata() НЕ умеет: Тип Metadata, который она возвращает, управляет <title>, <meta>, <link rel> и тегами социальных карточек. Произвольные теги <script> он не поддерживает. Полей structuredData или jsonLd в типе Metadata нет. Вставить JSON-LD через generateMetadata() невозможно.
• Вставка <script> в серверном компоненте (правильный путь): JSON-LD вставляется прямо в JSX серверного компонента: <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }} />. Это отрисовывается в <head> или <body> страницы в зависимости от места размещения. Клиентский JavaScript не участвует: тег уже есть в исходном серверном HTML.
• Паттерн компонента <StructuredData>: Тонкая обёртка (components/Seo/StructuredData.tsx), которая инкапсулирует вставку: принимает проп data (типизированный как Record<string, unknown>) и рендерит тег <script>. Так на всех страницах появляется единый канонический способ вставки, и становится легко проверить, у каких страниц разметка есть и какие типы они отдают.
• XSS через dangerouslySetInnerHTML - уязвимость, которую пропускают: JSON.stringify(data) может выдать строку, содержащую </script>, если это сочетание попало в любое поле данных. Название товара вида 'Example</script><script>alert(1)</script>' заставит браузер считать тег JSON-LD закрытым на </script> и выполнить внедрённый скрипт. Лечение: JSON.stringify(data).replace(/</g, '\\u003c'). Экранированные юникод-последовательности - валидный JSON, поэтому парсеры структурированных данных получают правильный символ <, а браузер никогда не видит буквального </script> внутри блока. Ровно так же поступает и сам Google при сериализации своих структурированных данных.

Где что размещать: Сущности уровня сайта (WebSite, Organization/Person, SearchAction) живут в app/layout.tsx - они есть на каждой странице и описывают сайт как сущность, а не содержимое конкретной страницы. Сущности уровня страницы (Article, Product, BreadcrumbList, FAQPage) генерируются в page.tsx соответствующего маршрута из данных этой страницы. Разделение повторяет иерархию сущностей: сущность сайта стабильна и присутствует везде, сущности страниц динамичны и привязаны к маршруту.

Какая site-level схема нужна каждому Next.js-сайту (WebSite, Organization, Person)?

Блок разметки уровня сайта в app/layout.tsx задаёт фундамент графа сущностей для всего проекта. Для сайта личного бренда или независимого архитектора правильный тип - Person, а не Organization: последний для компаний с сотрудниками. Для агентства или SaaS-продукта верен именно Organization.

• Схема WebSite (нужна для Sitelinks Searchbox): { "@type": "WebSite", "@id": "https://example.com#website", "url": "https://example.com", "name": "Site Name", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/search?q={search_term_string}" }, "query-input": "required name=search_term_string" } }. Именно potentialAction.SearchAction включает Sitelinks Searchbox - поле поиска под ссылкой сайта в брендовой выдаче. Работает только если у вас действительно есть поисковый эндпоинт.
• Схема Person (личный бренд): Ключевые свойства: name, url (страница профиля), image (портрет, Google берёт его в Knowledge Panel), jobTitle, description, sameAs (ссылки на соцпрофили), address (PostalAddress с addressLocality и addressCountry), knowsAbout (массив тем, помогает AI-системам понять экспертизу), worksFor для сотрудников или hasOccupation для фрилансеров и консультантов. URI в @id (https://example.com/about#person) - постоянный идентификатор сущности, на который ссылаются все схемы статей и отзывов.
• Схема ProfessionalService: Для сервисного бизнеса ProfessionalService (подкласс LocalBusiness) добавляет serviceType и разрешает hasOfferCatalog. Google требует для локальных rich results: name, address (PostalAddress), telephone, openingHours. Для полностью удалённого бизнеса вместо физического адреса подойдёт areaServed со страной или массивом объектов GeoShape - но физический адрес заметно усиливает локальные сигналы.
• Полнота sameAs: Каждый уникальный авторитетный внешний профиль в sameAs - сигнал подтверждения сущности. Минимум для портфолио разработчика: LinkedIn и GitHub. Настоятельно стоит добавить: Twitter/X, Crunchbase (если есть) и Wikidata (если применимо). Google сверяет их между собой, набирая уверенность в личности и области экспертизы.

Как связать BlogPosting с единой сущностью автора во всех постах?

Разметка Article внедряется чаще всех и чаще всех ломается. Причина в том, что обязательные для rich results поля у Google конкретнее, чем описывает большинство туториалов, а неправильная привязка автора - самый частый способ всё испортить.

• Иерархия типов: Для статей блога правильный тип - BlogPosting. Цепочка наследования: BlogPosting → Article → CreativeWork → Thing. NewsArticle берите только для журналистики признанных новостных изданий: к этому типу Google применяет другие требования по E-E-A-T. Article - общий тип, BlogPosting сигнализирует именно редакционный блоговый формат.
• Обязательные поля для rich results Google (2026): headline (строка, до 110 символов для нормального отображения), image (ImageObject или URL, минимум 1200×630 пикселей для карусели), datePublished (ISO 8601: "2026-03-18" или "2026-03-18T10:00:00Z", а не человекочитаемая дата), author (Person или Organization с name и, что критично, с @id, указывающим на сущность Person этого сайта, ради наследования E-E-A-T). Пропуск любого из них даёт warnings в Rich Results Test, а они гасят право на rich result.
• dateModified важен для свежести: Инструкции Google для асессоров прямо велят учитывать свежесть контента. dateModified в разметке даёт машиночитаемый сигнал свежести отдельно от HTTP-заголовка Last-Modified. Для вечнозелёного технического материала обновляйте dateModified, когда переписан существенный раздел, а не когда поправлена опечатка.
• Привязка автора через @id (цепочка E-E-A-T): "author": { "@type": "Person", "@id": "https://samcheek.com/about#person", "name": "Yevhen Samkov", "url": "https://samcheek.com/about" }. Это связывает авторство статьи с описанной на сайте сущностью Person, у которой есть knowsAbout, sameAs и description. Google идёт по ссылке @id и учитывает заявленную экспертизу человека, оценивая E-E-A-T статьи. Анонимный автор (только имя, без @id) даёт сигнал заметно слабее.

Что требуется Product-схеме, чтобы попасть в merchant listings и rich results?

Product - самый конверсионный тип разметки: собранный правильно, он даёт в выдаче звёздочки рейтинга, цену и статус наличия, а это поднимает CTR на 15–30% (Google, документация по Product Markup, 2025). Как это устроено в headless-витрине на Shopify, разобрано в гайде по архитектуре headless Shopify; здесь - требования самой схемы.

• Обязательные поля для Product rich results: name, image (хотя бы один URL или ImageObject), offers (сущность Offer). В Offer должны быть: price (строка, не число: "29.99"), priceCurrency (ISO 4217: "USD"), availability ("https://schema.org/InStock", OutOfStock или PreOrder), url (канонический URL товара). Без полного набора Rich Results Test выдаёт ошибки и снимает право на rich result.
• AggregateRating (звёздочки в выдаче): "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.8", "bestRating": "5", "worstRating": "1", "ratingCount": 247 }. Поле ratingCount Google требует обязательно - одного reviewCount мало. Можно указать оба: ratingCount - число оценок, включая те, что без текста, reviewCount - число написанных отзывов. Звёздочки Google не покажет, пока ratingCount не будет хотя бы 1 и пока оценки не окажутся проверяемо настоящими: за накрученные отзывы прилетают ручные санкции.
• Merchant listings (Google Shopping): Товары с валидной разметкой Product + Offer попадают в бесплатные merchant listings во вкладке Shopping - отдельно от платных PLA. Условия: свойство Offer.seller указывает продавца ({ "@type": "Organization", "name": "Store Name" }), а страница должна быть карточкой одного товара, а не категорией. Это бесплатный канал, который большинство headless-внедрений просто не подключает.
• Варианты, канонические URL и схема: У товара с 50 вариантами цвета и размера каждый URL варианта (/products/shirt?variant=123) должен нести схему Product со своей ценой, наличием и SKU, но со свойством url, указывающим на канонический URL базового товара. Если варианты отдельно не индексируются (каноникал ведёт на базовый товар), оставьте одну схему Product на базовом URL, а offers сделайте массивом сущностей Offer по числу доступных вариантов.

Полезна ли всё ещё FAQPage-схема после ограничения Google от августа 2023?

С 2019 по 2023 год FAQPage была одной из самых отдачливых разметок для коммерческих сайтов: она давала аккордеон под основным результатом выдачи и резко расширяла занимаемое место. В августе 2023 года Google оставил право на этот rich result только государственным и медицинским сайтам. Это не значит, что FAQPage бесполезна. Это значит, что её ценность переехала из выдачи Google в цитируемость у AI-систем.

• Как именно ограничили в 2023: Изменение Rich Results в августе 2023 убрало аккордеоны FAQPage для «неавторитетных» сайтов, то есть для коммерческих, блогов и большинства изданий. Саму разметку не объявляли устаревшей, в отличие от HowTo: она просто перестала включать визуальное расширение для этих типов сайтов. Государственные порталы здравоохранения и официальные госсайты право сохранили.
• Ценность для цитирования в AI (почему FAQPage стоит оставить): Языковые модели и AI-поиск (Google AI Overviews, Perplexity, ChatGPT с браузингом) вытаскивают структурированный контент со страниц, чтобы процитировать его в сгенерированной сводке. Структура Question + acceptedAnswer.text даёт заранее размеченный формат вопрос-ответ, который AI-системы извлекают точнее, чем эквивалентную прозу. В acceptedAnswer.text должен быть полный самодостаточный ответ, а не «подробнее по ссылке»: собирая цитаты, AI-системы по ссылкам не ходят. Это и есть основной принцип Generative Engine Optimization (GEO) - структурировать контент под извлечение машиной, а не только под визуальные фичи выдачи.
• Что делать коммерческому сайту: Существующую разметку FAQPage оставьте: она даёт ценность для цитирования у моделей, а Bing до сих пор показывает часть FAQ-подобных результатов и коммерческим сайтам. Удалять не нужно. Но и добавлять FAQPage ради rich results в Google уже не стоит - этот поезд ушёл. Зато стоит проектировать блоки вопросов с полноценными acceptedAnswer.text ради машинной цитируемости, а не ради вхождений ключей. Более подробный разбор оптимизации под AI-поиск - в услуге технического SEO.
• Как это выглядит: { "@type": "FAQPage", "mainEntity": [{ "@type": "Question", "name": "Что такое headless Shopify?", "acceptedAnswer": { "@type": "Answer", "text": "Headless Shopify отделяет коммерческий бэкенд Shopify от слоя отрисовки, позволяя кастомной витрине на Next.js или другом фреймворке получать данные Shopify через Storefront API." } }] }. Question.name - текст вопроса, acceptedAnswer.text - полный ответ.

Как BreadcrumbList управляет отображением URL в Google SERP?

• Структура схемы: { "@type": "BreadcrumbList", "itemListElement": [{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" }, { "@type": "ListItem", "position": 3, "name": "Article Title" }] }. Последнему элементу цепочки item не нужен - это текущая страница. Значения position должны идти последовательными целыми числами начиная с 1.
• Что меняется в выдаче: BreadcrumbList меняет то, как Google показывает URL страницы: вместо https://example.com/blog/long-post-slug-2026 появляется человекочитаемый путь example.com › Blog › Article Title. Это поднимает CTR, потому что снимает у сканирующего выдачу пользователя тревогу от непонятного адреса.
• Совпадение с видимыми хлебными крошками: Требования Google к структурированным данным обязывают, чтобы BreadcrumbList совпадал с видимой навигацией на странице. Схема, которая заявляет иерархию, отличную от отрисованных крошек, считается вводящей в заблуждение разметкой, а за это прилетают ручные санкции. Генерируйте схему и компонент навигации из одного источника данных - тогда расхождение невозможно.

Какие поля Service-схемы обязательны для сервисного бизнеса в 2026?

• Тип Service: { "@type": "Service", "name": "Next.js Performance Optimization", "serviceType": "Frontend Architecture Consulting", "provider": { "@type": "Person", "@id": "https://samcheek.com/about#person" }, "areaServed": "Worldwide", "url": "https://samcheek.com/services/performance-optimization" }. Свойство provider связывает услугу с сущностью Person через @id, выстраивая цепочку сайт → человек → услуга. Google использует её для локальных сервисных rich results (если есть адрес) и для записей «услуги, которые оказывает» в графе знаний.
• hasOfferCatalog: Группирует несколько услуг: "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Frontend Architecture Services", "itemListElement": [ { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Headless eCommerce Architecture" } }, ... ] }. Особенно полезно агентствам, где Google нужно понять широту предложения.
• BreadcrumbList на странице услуги: У каждой страницы услуги должна быть своя цепочка: Home → Services → [название услуги]. Это закрепляет архитектуру сайта в структурированных данных и дополняет иерархию XML-карты.

Какие типы Schema.org Google объявил устаревшими, и на что переходить?

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

• HowTo - убран в сентябре 2023: Google прекратил поддержку rich results для HowTo в сентябре 2023 года, тем же пакетом, что и ограничение FAQPage. Раньше HowTo давал в выдаче пошаговые блоки с нумерацией и картинками. Всю разметку HowTo на коммерческих сайтах стоит удалить: пользы в выдаче ноль, а предупреждения в Rich Results Test она создаёт.
• Частая ошибка: нет @context: В каждом блоке JSON-LD обязан быть "@context": "https://schema.org". Без него парсер Google считает имена типов и свойств произвольными строками без смысла. Rich Results Test отрапортует «No structured data found», даже если JSON в остальном валиден.
• Частая ошибка: регистр в @type: Типы Schema.org пишутся в PascalCase: Product, BlogPosting, BreadcrumbList, а не product, blog-posting, breadcrumb-list. Свойства - в camelCase: datePublished, ratingValue, offerCount. Типы в нижнем регистре часть парсеров молча не проходит, а Google рапортует «unknown type».
• Частая ошибка: формат datePublished: Только ISO 8601. Валидно: "2026-03-18", "2026-03-18T10:00:00Z", "2026-03-18T10:00:00+02:00". Невалидно: "18 марта 2026", "18.03.2026". Rich Results Test иногда проглатывает неверный формат без ошибки, но конвейер индексации Google молча его отбрасывает, и rich result для статьи гасится.
• Частая ошибка: цена числом: В Offer у Schema.org price обязан быть строкой: "price": "29.99", а не "price": 29.99. Это особенность спецификации, противоречащая привычкам JSON. Причина в том, что Schema.org должен уметь представлять цены, невыразимые числом с плавающей точкой IEEE 754 - в некоторых валютах нужна недесятичная арифметика. Валидаторы Google и Bing принимают число с предупреждением, но спецификация требует строку.
• Частая ошибка: относительные URL в url или item: Все URL-свойства JSON-LD (url, item, @id, image в строковом виде) должны быть абсолютными. "/blog/post" невалиден, "https://example.com/blog/post" - верен. Относительные адреса валят валидацию и лишают затронутую сущность права на rich result.
• Вектор внедрения через </script>: Как разобрано выше, JSON.stringify(data) без экранирования открывает XSS, если в данные попало сочетание </script>. Всегда санируйте: JSON.stringify(data).replace(/</g, '\\u003c'). Особенно критично для пользовательского контента - названий товаров, текстов отзывов, ответов FAQ из CMS, - который попадает в разметку перед рендером.

Как валидировать JSON-LD до выката в прод?

• Google Rich Results Test (search.google.com/test/rich-results): Проверяет URL или сырой HTML на право получить rich result. Возвращает найденные типы схем, статус обязательных полей, предупреждения и ошибки. «No errors» означает, что схема валидна; «Eligible for rich results» - что страница претендует на расширение в выдаче. Валидная схема не гарантирует rich result: за Google всегда остаётся редакционное решение о качестве страницы и разнообразии выдачи.
• Schema.org Validator (validator.schema.org): Проверяет соответствие спецификации Schema.org, а не требованиям Google. Строже, чем Rich Results Test: ловит несоответствия типов и свойств и неизвестные имена свойств. Пользуйтесь обоими: Rich Results Test - для права на rich result у Google, Schema.org Validator - для соответствия спецификации.
• Google Search Console, отчёт «Улучшения»: Когда разметка проиндексирована, раздел «Улучшения» показывает найденные типы rich results, количество элементов, ошибки и предупреждения в целом по сайту. Это единственный инструмент, который показывает здоровье разметки в продакшен-масштабе, а не по одному URL. Подпишитесь на письма GSC об ошибках структурированных данных: они приходят в течение 1–2 дней после индексации новых страниц с проблемами.

Заключение

Разметка, собранная как граф сущностей - связывание через @id, последовательные ссылки на одни и те же сущности, перекрёстные sameAs, полный набор обязательных полей, - накапливает эффект со временем так, как подход «поставить галочки по типам» не умеет. Rich result - это немедленная выплата. Долгая ценность в том, что представление сущности в Knowledge Graph превращает сайт и его автора в цитируемый источник для AI Overviews, сводок Perplexity и другого поиска на языковых моделях.

Архитектура серверных компонентов в Next.js App Router делает вставку JSON-LD чистой и предсказуемой: схема генерируется на сервере из тех же объектов данных, которыми рендерится страница, и клиентский JavaScript в этом не участвует. Паттерн компонента <StructuredData> и безопасная сериализация (replace(/</g, '\\u003c')) - две детали, на которых спотыкается большинство реализаций. Живой пример того, как пронести схему и SEO-метаданные через смену платформы без потерь, есть в разборе миграции WordPress на Next.js-CMS, где сохранены метаданные Yoast и право на rich results.

Аудит структурированных данных, внедрение или полное техническое SEO-ревью - услуга технического SEO и схемы | кейсы | обсудить проект.

Частые вопросы

• Что выбрать: @graph или несколько тегов <script type="application/ld+json">? Оба варианта валидны и обрабатываются Google одинаково. @graph чище, когда между сущностями страницы есть явные связи - например, свойство author у BlogPosting ссылается на Person, описанный в том же блоке. Несколько тегов <script> проще, когда типы генерируются независимо: скажем, BreadcrumbList и Article собираются из разных источников в разных компонентах.
• Влияет ли разметка на ранжирование напрямую? Нет. Google последовательно говорит, что структурированные данные - не фактор ранжирования. Это сигнал права на rich results, инструмент разведения сущностей в Knowledge Graph и усилитель цитируемости у AI. Косвенная польза для позиций идёт от роста CTR за счёт rich results и от усиления E-E-A-T через связывание сущностей.
• Как размечать постраничную навигацию (/blog?page=2)? У каждой страницы пагинации должен быть свой BreadcrumbList. В схеме WebPage свойство url должно совпадать с каноническим URL именно этой страницы. Листинги статей размечайте схемой ItemList со статьями этой страницы. Схему WebSite можно оставить на первой странице; на последующих её дублировать не нужно.
• Безопасно ли генерировать JSON-LD на сервере из данных CMS? Да, с оговоркой про XSS: сериализуйте только через JSON.stringify().replace(/</g, '\\u003c') и никогда не склеивайте JSON-LD строками. В данных CMS - названиях товаров, описаниях, текстах отзывов - регулярно попадаются символы, способные сломать разбор JSON-LD или, в худшем случае, внедрить теги скриптов.
• Что будет, если убрать ранее проиндексированный тип схемы? Google потеряет право на rich result для этой страницы при следующем обходе. В GSC ненадолго может подрасти число «Ошибок», пока ранее проиндексированные улучшения инвалидируются. На органические позиции страницы это напрямую не влияет - теряется только расширение в выдаче.

Источники

• Schema.org. «Full Hierarchy»
• Google. «Introduction to Structured Data»
• Google. «Rich Results Types»
• Google. «Article structured data»
• Google. «Product structured data»
• Google. «FAQPage update (август 2023)»
• W3C. «JSON-LD 1.1 Specification»
• Google. «Rich Results Test»
• Schema.org Validator
• Barnett, M. «XSS via JSON-LD in Next.js»
• Google. «How structured data works»