SKU-скоупный граф сущностей (SKU-Scoped Entity Graph)

1. Архитектура и принцип работы

Для каждого SKU строится локальный подграф: базовый Product (модель), Variant (цвет/размер/объём), Offer (цена, наличие, продавец), привязка к Brand, Category, Material, CompatibleModel. Узлы связываются устойчивыми @id (URL#product, URL#offer-), а не вложенными анонимными объектами. Кросс-SKU связи (isVariantOf, isSimilarTo, isAccessoryOf) формируют кластеры. Поисковик и ИИ-агент читают граф, чтобы понять, что 12 карточек — это 12 вариантов одной сущности, а не 12 дублей. Внутренняя перелинковка и canonical выстраиваются по границам скоупа: варианты живут на одном URL с параметрами или на дочерних URL с self-canonical, а не конкурируют между собой.

2. Математическая механика и триггеры ранжирования

Механика опирается на три слоя. Первый — идентичность: каждому узлу присваивается стабильный @id, не меняющийся при смене цены или наличия, иначе граф «рвётся» и накопленные сигналы теряются. Второй — типизация связей: isVariantOf (вариант→модель), hasVariant (модель→варианты), isSimilarTo (кросс-селл), isAccessoryOf. Это позволяет движку отличать вариативность от каннибализации. Третий — согласованность с HTML: видимый контент карточки (характеристики, цена, наличие) обязан совпадать с JSON-LD, иначе возникает entity mismatch и фильтр недоверия к разметке. На уровне краулинга скоуп задаёт приоритеты: модельные страницы получают большую crawl-частоту, чем отдельные варианты, а варианты индексируются через sitemap с hreflang/параметрами. Для LLM-выдачи граф работает как контекст: агент извлекает Offer с актуальной ценой и Variant с нужным атрибутом, снижая риск галлюцинаций о товаре.

3. Специфика в Яндекс (YATI) vs Google

Яндекс сильнее опирается на товарные фиды YML и коммерческие факторы, поэтому SKU-граф в первую очередь должен синхронизироваться с фидом (offer id = @id в JSON-LD), иначе расхождение цены/наличия бьёт по ранжированию и попаданию в товарную выдачу. Google глубже парсит Schema.org-граф и merchant listing, требуя корректных Product/Offer/AggregateRating и GTIN/MPN. В Яндексе вес имеет привязка к категорийному дереву и региональность, в Google — к entity understanding через Knowledge Graph. Практический вывод: единый @id-стандарт между JSON-LD, фидом и URL — обязателен для обеих систем, но приоритет валидации разный: для Яндекса — фид и КФ, для Google — структурная полнота графа и merchant-фиды.

4. Нормативы SLA и диагностическая матрица

5. Пошаговый инженерный протокол внедрения

• Ввести единый реестр @id: product-, offer-, variant- и синхронизировать его с offer id в YML-фиде.
• Разделять модель и варианты: модельная страница — хаб с hasVariant, варианты — self-canonical дочерние URL или параметры с корректным canonical.
• Связывать кросс-SKU рёбра isSimilarTo/isAccessoryOf для формирования тематических кластеров и усиления внутренней перелинковки.
• Автоматически валидировать совпадение JSON-LD и видимого HTML (цена, наличие, характеристики) в CI перед деплоем.

{"@context":"https://schema.org","@graph":[{"@type":"Product","@id":"https://shop.ru/model-42#product","name":"Кроссовки Model 42","brand":{"@type":"Brand","name":"BrandX"},"hasVariant":[{"@type":"Product","@id":"https://shop.ru/model-42/red-42#variant","sku":"M42-RED-42","color":"red","isVariantOf":{"@id":"https://shop.ru/model-42#product"},"offers":{"@type":"Offer","@id":"https://shop.ru/model-42/red-42#offer","price":"7990","priceCurrency":"RUB","availability":"https://schema.org/InStock"}}]}]}

6. Типичные ошибки при оптимизации

• Анонимные вложенные Offer без @id — граф распадается, и варианты выглядят как дубли.
• Расхождение цены в JSON-LD, фиде и на странице — entity mismatch и потеря доверия к разметке.
• Canonical всех вариантов на модель без self-canonical — потеря индексации длинного хвоста по атрибутам.