Schema-разметка и связывание сущностей: @id, sameAs, @graph

Структурированные данные (schema-разметка) — это повторение машиночитаемым языком того, что страница уже говорит текстом. С точки зрения семантического SEO её главная ценность не в «звёздочках» в выдаче: разметка позволяет назвать сущности, объявить их типы и связать друг с другом.

Правила Google по структурированным данным допускают три формата — JSON-LD (рекомендуемый), микроразметку и RDFa. В этом материале используется только JSON-LD: он пишется отдельно от HTML и проще всего в сопровождении.

Что разметка делает и чего не делает

Что делает: однозначно классифицирует информацию на странице. Слово «Баку» в тексте может быть городом, названием ресторана или фамилией; как только вы пишете "@type": "Place", неоднозначность исчезает. Это машинная сторона той самой работы по «уточнению», описанной в материале про entity SEO.

Чего не делает: не гарантирует позиции и не превращает слабый контент в сильный. Документация Google прямо отмечает: даже корректная разметка не гарантирует расширенный результат — алгоритм ставит выше пользовательский опыт и может показать обычный текстовый сниппет.

@id и @graph: связывание сущностей

На большинстве сайтов разметка выглядит так: Organization на главной, отдельный Article в блоге, и они ничего не знают друг о друге. Для Google это несвязанные объекты.

Правильный подход — использовать @id: дать каждой сущности уникальный устойчивый идентификатор в форме URL и затем ссылаться на него.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Пример Агентство",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.com/#logo",
        "url": "https://example.com/storage/logo.png"
      },
      "sameAs": [
        "https://www.linkedin.com/company/example",
        "https://www.facebook.com/example"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Пример Агентство",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/semantic-seo#article",
      "headline": "Что такое семантическое SEO",
      "isPartOf": { "@id": "https://example.com/#website" },
      "publisher": { "@id": "https://example.com/#organization" },
      "author": { "@id": "https://example.com/about#person" }
    }
  ]
}

Обратите внимание: в поле publisher данные компании не дублируются, а указывается ссылка через @id. Это даёт три выигрыша — код короче, данные хранятся в одном месте и, главное, все страницы привязываются для Google к одной сущности.

sameAs: внешнее подтверждение

sameAs — простое, но очень сильное поле. Оно говорит: «эта сущность есть и там». Документация Google по Organization рекомендует его для ссылок на профили в соцсетях и на сайтах отзывов.

"sameAs": [
  "https://www.linkedin.com/company/example-agency",
  "https://www.facebook.com/exampleagency",
  "https://www.instagram.com/exampleagency",
  "https://www.youtube.com/@exampleagency"
]

Два практических правила:

• Перечисляйте только официальные и живые профили. Пустой или заброшенный профиль подтверждающего веса не даёт.
• С профилей должна быть обратная ссылка на сайт. Двустороннее подтверждение надёжнее.

Та же логика работает и для авторов: у сущности Person может быть свой массив sameAs с профессиональными профилями.

Схема Organization: какие поля

Согласно документации Google по Organization, обязательных полей нет — добавляйте те, что относятся к вашей организации. Размещать разметку следует на главной или на отдельной странице вроде «О нас».

Для локального бизнеса вместо Organization лучше выбрать более конкретный тип LocalBusiness — общие правила Google рекомендуют использовать самый специфичный из доступных типов schema.org. Это стандартная часть работ по локальному SEO.

Article и BreadcrumbList для кластера

При сборке контент-кластера логично добавлять к каждой статье две схемы: Article (сам материал) и BreadcrumbList (его место на сайте).

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Главная",
      "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Блог",
      "item": "https://example.com/blog" },
    { "@type": "ListItem", "position": 3, "name": "Что такое семантическое SEO" }
  ]
}

У последнего элемента item не указывается — читатель уже на этой странице.

Если в статье есть настоящий раздел вопросов и ответов, можно добавить и FAQPage. Условие одно: вопросы и ответы должны быть видимым текстом на странице — это прямое требование правил ниже.

Правила и запреты

Правила Google по структурированным данным состоят из трёх блоков: технического, качества и содержания. Главные запреты:

• Не размечайте скрытую информацию. Контент, которого пользователь не видит на странице, в разметку попадать не должен.
• Не размечайте нерелевантное. Пример из самой документации предельно ясен: инструкцию по столярному делу нельзя размечать как рецепт.
• Не давайте ложных и вводящих в заблуждение данных. Фальшивые отзывы, выдача себя за других и искажение связей запрещены.
• Не закрывайте страницу с разметкой. Если страница закрыта в robots.txt или через noindex, разметка не обрабатывается.
• Берите самый конкретный тип и заполняйте поля. Без обязательных свойств страница не получает права на функцию; рекомендуемые улучшают результат.

Проверка и устранение ошибок

Самая частая техническая проблема такая: разметка добавляется через JavaScript и теряется при рендеринге. Если в разделе «отрендеренный HTML» инструмента проверки URL блок JSON-LD виден — всё в порядке.

Частые ошибки

1. Полностью повторять блок Organization на каждой странице. Правильнее ссылаться через @id.

2. Использовать случайную строку в качестве @id. Он должен быть устойчивым и в форме URL, чтобы на него можно было ссылаться.

3. Размечать FAQ, которого нет на странице. Самое частое нарушение правил.

4. Указывать слишком маленький или закрытый логотип. Есть требование к минимальному размеру и доступности для сканирования.

5. Забывать обновлять разметку. Если адрес или телефон изменились, а схема осталась прежней, сигналы о сущности начинают противоречить друг другу.