Связать Schema через JSON-LD @graph

Зачем связывать Schema через @graph

Когда на странице лежат пять отдельных JSON-LD блоков — Organization, LocalBusiness, WebPage, Service, FAQPage — поисковик видит их как пять разрозненных карточек. Для классической выдачи этого хватало: Google собирал rich snippets из любого блока, не задумываясь о связях. Для Алисы AI и Яндекс.Нейро 2026 года такой подход даёт слабый сигнал — нейросеть не понимает, что услуга оказывается именно вашей организацией, а FAQ относится именно к этой странице.

Контейнер @graph решает проблему. Это массив внутри одного JSON-LD блока, где каждая сущность получает уникальный идентификатор @id и явные ссылки на другие сущности. Алиса разбирает такой блок как единый «скелет бренда»: организация → сайт → страница → услуга → автор → вопросы. Связка сущностей превращает сайт из набора страниц в цельную карточку компании, которую нейросети охотнее цитируют в ответах.

Эффект на цитируемость в нейровыдаче по нашим замерам — рост доли упоминаний на 15–35% в течение 6–10 недель после внедрения. Особенно заметно для локальных бизнесов, где Алиса собирает ответ из связки Organization + LocalBusiness + Service. Для блогов сильнее всего работает связка Organization + WebSite + Article + Person (автор).

Без @graph сайт всё ещё индексируется и ранжируется, но в нейроответах его обходят более структурированные конкуренты. В 2026 это уже не «приятный бонус», а базовая гигиена для любого сайта, который борется за цитирование.

Пошаговая инструкция

Внедрить @graph можно вручную через шаблон темы или через плагин (Yoast, Rank Math — оба умеют выводить graph). Ниже — алгоритм для ручной реализации, чтобы вы понимали логику.

1. Шаг 1 — определите 5–7 ключевых сущностей страницы. Минимум: Organization, WebSite, WebPage. Для услуги добавьте Service, для локального бизнеса — LocalBusiness, для блога — Article и Person.
2. Шаг 2 — присвойте каждой сущности уникальный @id в формате URL с якорем. Например: "@id": "https://site.ru/#organization", "@id": "https://site.ru/uslugi/remont/#service".
3. Шаг 3 — оберните все сущности в один контейнер: {"@context": "https://schema.org", "@graph": [ ... ]}. Это и есть граф.
4. Шаг 4 — пропишите связи через ссылки на @id. У Service укажите "provider": {"@id": "https://site.ru/#organization"}. У WebPage — "isPartOf": {"@id": "https://site.ru/#website"} и "about": {"@id": "...#service"}. У Article — "author": {"@id": "...#person-author"}.
5. Шаг 5 — добавьте FAQPage с привязкой "mainEntityOfPage": {"@id": "...#webpage"}, чтобы вопросы относились к конкретной странице, а не висели в воздухе.
6. Шаг 6 — проверьте граф в Schema.org Validator (validator.schema.org). Google Rich Results Test показывает только rich snippets и пропускает связи между сущностями — он для этой задачи не подходит.

Минимальный пример графа для страницы услуги (15 строк):

{"@context":"https://schema.org","@graph":[
 {"@type":"Organization","@id":"https://site.ru/#org","name":"Бренд","url":"https://site.ru/"},
 {"@type":"WebSite","@id":"https://site.ru/#site","publisher":{"@id":"https://site.ru/#org"}},
 {"@type":"WebPage","@id":"https://site.ru/uslugi/remont/#page","isPartOf":{"@id":"https://site.ru/#site"},"about":{"@id":"https://site.ru/uslugi/remont/#service"}},
 {"@type":"Service","@id":"https://site.ru/uslugi/remont/#service","name":"Ремонт","provider":{"@id":"https://site.ru/#org"}},
 {"@type":"FAQPage","mainEntityOfPage":{"@id":"https://site.ru/uslugi/remont/#page"},"mainEntity":[...]}
]}

Типичные ошибки

• Дублирование сущностей — Organization прописана и в graph, и отдельным JSON-LD блоком. Нейросеть получает противоречивые данные. Исправление: оставить только в graph, остальные блоки удалить из шаблона.
• Несовпадение @id и реального URL — указали @id: https://site.ru/#org, а домен на самом деле www.site.ru. Связи рвутся. Исправление: @id должен начинаться с canonical-домена сайта.
• Связь без обратной отсылки — у Service есть provider на Organization, но сама Organization не существует в graph. Исправление: каждый @id, на который ссылаются, должен быть объявлен в том же graph.
• Перегруз графа — добавили 15 типов «на всякий случай», включая Event, Product, Recipe там, где их нет. Исправление: только то, что реально есть на странице.
• Проверка только в Google Rich Results — он не показывает ошибки связей, и владелец думает «всё работает». Исправление: дублировать проверку в Schema.org Validator.

Что проверить в итоге

• На странице один JSON-LD блок с @graph, а не 5 отдельных
• У каждой сущности уникальный @id в формате URL с якорем
• Связи провайдер/автор/о-странице прописаны через ссылки на @id
• Schema.org Validator не выдаёт ошибок и предупреждений по связям
• Все упомянутые в графе @id объявлены внутри этого же графа
• Нет дублей сущностей вне @graph (в шаблоне, плагинах SEO, footer)
• Для локального бизнеса есть связка Organization + LocalBusiness + Service
• Для блога есть связка Organization + WebSite + Article + Person