JSON-LD

Происхождение и история термина

W3C опубликовал JSON-LD 1.1 как рекомендацию 16 июля 2020 года. На странице стандарта предыдущей версией указана рекомендация JSON-LD 1.0 от 16 января 2014 года. Это даты стандартизации версий формата, а не появления JSON, Schema.org или всех структурированных данных. ^[1]

У JSON отдельная хронология. Действующий RFC 8259, закрепляющий формат обмена данными JSON, датирован декабрём 2017 года и имеет статус Internet Standard. ^[2] Словарь Schema.org и правила конкретных поисковых функций тоже развиваются независимо. Поэтому выражения «стандарт Google» или «формат Schema.org» искажают устройство технологии.

Суть и механизм

JSON-LD сохраняет привычные объекты, массивы и значения JSON, но добавляет специальные ключевые слова. Контекст сопоставляет короткие имена с идентификаторами терминов. Узел — это описание одной сущности в графе данных: например, статьи, автора или организации вместе с её свойствами и связями. Тип указывает, какая именно сущность описана.

Идентификатор задаёт IRI — Internationalized Resource Identifier, или интернационализированный идентификатор ресурса. Простыми словами, это однозначная адресоподобная строка; в @id часто используют полный HTTPS-адрес. Если несколько описаний имеют одинаковый @id, обработчик относит их к одному узлу и объединяет указанные свойства. ^[1]

Ниже — минимальный учебный пример для страницы статьи:

```html

```

@context подключает термины Schema.org, @type выбирает тип Article, @id идентифицирует описываемую статью, а headline передаёт её заголовок. ^{[1, 4]} Пример показывает конструкцию блока, но не является готовой разметкой для функции Google или Яндекса: у конкретного сервиса могут быть обязательные свойства и дополнительные правила.

Короткий учебный пример показывает, как @id связывает два описания:

json [ { "@context": "https://schema.org", "@id": "https://example.org/articles/demo#article", "@type": "Article", "headline": "Учебный заголовок" }, { "@context": "https://schema.org", "@id": "https://example.org/articles/demo#article", "inLanguage": "ru" } ]

Оба объекта имеют один и тот же @id, поэтому описывают один узел — ту же статью. Первый объект сообщает её тип и заголовок, второй добавляет язык. Если бы значения @id различались, обработчик считал бы их разными сущностями. ^{[1, 4]}

W3C описывает JSON-LD внутри HTML в элементе script с типом application/ld+json. Google допускает такой элемент в head или body и сообщает, что может читать JSON-LD, добавленный в страницу динамически. ^{[1, 3]} Однако динамическая вставка создаёт дополнительную точку отказа: при проверке нужно видеть итоговый код страницы после выполнения скриптов.

Что часто смешивают

Для приёмки удобно разделить три уровня. Это редакционная модель проверки, а не классификация W3C.

Первый уровень опирается на JSON и JSON-LD, второй — также на выбранный словарь, третий — на документацию системы, которая читает данные. ^{[1, 2, 3, 4]} Успех на одном уровне не доказывает успех на остальных.

Как внедрять и проверять

Сначала перечисляют сведения, которые действительно есть на странице: название, URL, автора, даты, изображения и другие данные. Затем выбирают наиболее точный тип и свойства словаря. Недостающие сведения не следует придумывать ради заполнения шаблона.

После этого для основной сущности задают стабильный @id, формируют JSON-LD и размещают блок на описываемой странице. Значения связывают с источниками в системе управления контентом (CMS, content management system): headline должен получать заголовок материала, а не имя сайта или рубрики. Если страница описывает несколько сущностей, их лучше моделировать отдельными связанными узлами, сохраняя понятные роли.

Проверка состоит из нескольких разных действий:

1. Разобрать JSON и убедиться, что итоговый HTML содержит ожидаемый блок.
2. Сверить типы и свойства со словарём Schema.org.
3. Проверить обязательные и рекомендуемые поля по руководству выбранной функции.
4. Сопоставить каждое значение с видимым содержанием страницы.
5. Повторить проверку после публикации и изменений шаблона.

Google рекомендует JSON-LD для структурированных данных, если устройство сайта позволяет его использовать, и отдельно требует соблюдать общие правила и документацию выбранного типа расширенного результата. ^{[3, 6]} Российская документация Яндекса также описывает размещение JSON-LD в script, ключи @context и @type и проверку через валидатор. ^[5] Совпадение формата не означает совпадения поисковых функций: поддержку нужно выяснять для каждого сервиса и сценария.

Как оценивать качество

Для редакционной выборки можно считать долю согласованных полей:

где $N$ — число проверенных полей, а $A$ — число полей, значения которых совпадают с опубликованным материалом и соответствуют выбранной модели. Если согласованы восемь полей из десяти, $K = 8 / 10 \times 100\% = 80\%$. Это внутренний показатель качества данных, а не оценка поисковой видимости и не прогноз трафика.

Полезны и отрицательные тесты: пустой заголовок, отсутствующая дата, кавычки внутри текста, недоступное изображение, две конфликтующие версии одной сущности. Ожидаемый результат фиксируют заранее: корректное экранирование, пропуск необязательного поля или явная ошибка сборки. Такой тест показывает устойчивость шаблона, но не доказывает право страницы на расширенный результат.

Ошибки и ограничения

Валидатор может подтвердить синтаксис и часть правил, но не способен гарантировать фактическую правдивость разметки. Google требует, чтобы данные представляли основное содержание страницы, не были скрыты от читателя и включали обязательные свойства конкретной функции. Даже корректная разметка не гарантирует показ расширенного результата. ^[6]

Нельзя переносить требования одной системы на другую или считать наличие термина в Schema.org доказательством его поддержки поисковой функцией. Текущая страница Article на Schema.org перечисляет тип и свойства словаря; требования к расширенному результату нужно брать из отдельной документации сервиса. ^[4]

Ручная мера Google за проблему со структурированными данными лишает страницу права на расширенный результат, но, согласно общим правилам, сама по себе не меняет её ранжирование в обычном веб-поиске. ^[6] Это узкая граница утверждения, а не обещание отсутствия любых иных последствий при нарушениях сайта.

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

Связанные термины

• mikrorazmetka
• schema-org
• snippet
• kanonicheskiy-adres
• open-graph
• seo dlya smi