Экран и карточки данных. Иллюстративная сцена.

РУКОВОДСТВО / ПРОТОКОЛ

Проверка структурированных данных

Корректная разметка не исправит неясную страницу, отсутствующие сведения или неподтверждённую личность.

Прямой ответ

Как проверить структурированные данные помимо синтаксиса?

Начните с отображённой страницы и её канонического URL. Перечислите заявленные сущности и свойства, сверьте утверждения с видимым текстом, затем проверьте синтаксис и требования нужной функции поиска.

01 / Метод проверки

Метод проверки

01

Выбрать страницы и типы

Составьте список шаблонов, полезных типов схем и языковых версий. Исключите типы, не связанные с содержимым.

02

Сопоставить HTML и разметку

Проверьте имена, авторов, даты, изображения, ссылки и отношения в видимом HTML и JSON-LD. Покажите важные сведения читателю либо уберите их из разметки.

03

Проверить двумя способами

Валидатор Schema.org проверяет структуру, а тест расширенных результатов — применимые функции Google. Разделяйте ошибки и предупреждения.

04

Повторить после изменений

Проверяйте шаблоны и реальные страницы после публикации, а также другие языки и канонические URL.

НА ПРАКТИКЕ

Исправление завершено после проверки его последствий

Страница связана с резюме, заголовком, таблицами, ссылками, языковыми версиями и структурированными данными. Исправляя фразу, найдите её повторы и убедитесь, что смысл согласован.

Что проверить в первую очередь?

Выберите наблюдаемую ситуацию. Каждый вариант описывает первую проверку, нужные доказательства и её ограничения.

Две страницы дают несовместимые сведения

Первая проверка
Выделите одно утверждение и сравните источник, срок действия и охват. Определите опорную страницу и ответственного до распространения исправления.
Что сохранить
Оба URL, точные формулировки, источники, дата действия, решение и страницы либо фрагменты с повторением.
Ограничение
Самая новая страница не обязательно верна. Изменение даты публикации не исправляет разные определения или отсутствие источника.
Читать связанное руководство

Дополнительные материалы

Перед публикацией
СитуацияЧего избегатьПолезное исправление
Исправленное числоИзменить только абзац.Проверить связанные таблицу, подпись, резюме и структурированное значение.
Перенос страницыИзменить только видимую ссылку.Проверить адрес, якорь и обратный путь.
ПереводСкопировать слова с устаревшим примером.Проверить единицу, дату, источник, ссылки и рамки вывода.

  1. Выявить

    Какие утверждения зависят от изменения?

  2. Распространить

    Какие страницы и языки их повторяют?

  3. Перечитать

    Согласованы ли числа, ссылки и ограничения?

Итоговая проверка

Дата обновления обозначает реальное редактирование, а не новую дату источника или наблюдения. Разделяйте эти роли в тексте и ссылках.

Документальные источники

Дата обращения .

Практикум чтения данных

Читаемый JSON с неверным автором

Страница DEMO — французская статья за подписью Лины DEMO. Лаборатория DEMO отдельно названа организацией; оба объекта вымышлены.

Вымышленные данные и записи для обучения: результаты не получены запросами к действующим сервисам.

Четыре проверки после синтаксиса

Вымышленная разметка смешивает идентичность, авторство и язык. Внешний валидатор не запускается: таблица разделяет проверки отображаемой страницы.

Если таблица шире экрана, прокрутите её по горизонтали; стрелки работают, когда область в фокусе.

Четыре проверки после синтаксиса
ПроверкаСостояние DEMOЧто установленоКакое исправление изучить
Синтаксис JSONКорректные скобки, строки и массивыТекст разбирается как JSONПродолжить смысловую проверку.
Идентичность @idОдин #entity у Лины и лабораторииСмешаны два разных объекта этого случаяНазначить согласованные идентификаторы описанным объектам.
Автор статьиВидна Лина, в author лабораторияАтрибуция расходится со страницейИспользовать подтверждённого автора, не превращать организацию в человека.
Объявленный языкФранцузская статья; inLanguage=enОбъявлен другой языкПроверить сущность статьи и этот вариант страницы.

Что позволяет успешная синтаксическая проверка?

Раскройте каждый вариант и сравните разбор. Дополнительные проверки могут оставаться необходимыми.

Удостоверить автора и идентичность сущностей

Нет. Грамматически корректное значение может указывать не на тот объект.

Обещать расширенный результат поиска

Нет. Синтаксис не гарантирует соответствие критериям и отображение.

Продолжить проверку идентичности, видимого текста и правил типа

Да. Раздельно записать синтаксис, редакционную согласованность и применимые критерии.

Вымышленный журнал проверки разметки

Страница: французская статья DEMO
Видимый автор: Лина DEMO
Ошибка: #entity общий у человека и организации
Ошибка: author указывает на лабораторию
Ошибка: inLanguage=en у этой французской статьи
Решение: исправить разметку, расширенный результат не подтверждён

Фрагменты #entity и inLanguage — подсказки примера, не выводы о коде сайта и не полная схема для копирования.

Документация правил отдельно от вымышленных примеров

02 / Сохраняемые доказательства

Сохраняемые доказательства

Реестр шаблонов

URL, тип страницы, ожидаемая схема, ответственный и дата.

Сверка полей

Значение в разметке, подтверждение на странице, источник и расхождение.

Отчёт проверки

Инструмент, URL, дата, ошибки, предупреждения и снимок.

Решение об исправлении

Исправленное или удалённое поле, ответственный и повторная проверка.

Сравнить другие ситуации и упражнения

КОНТРОЛЬНАЯ ТОЧКА

Прежде чем делать вывод

Типичная ошибка трактовки и проверка, которая помогает её избежать.

Поспешный вывод

Правильный синтаксис JSON-LD недостаточен, если разметка описывает отсутствующие, устаревшие или противоречащие странице сведения.

Решающая проверка

Сверить важные свойства с видимым текстом, каноническим URL и ожидаемым типом. Отдельно проверить синтаксис и правила поисковика, затем опубликованный результат.

ПОСЛЕ ПРОВЕРКИ

Решение по результату

01

JSON-LD корректен, но факт отсутствует на странице

Исправьте разметку или покажите проверяемый факт читателю. Корректный синтаксис не гарантирует соответствия содержанию.

02

Страницы противоречат друг другу об одной сущности

Определите редакционный первоисточник, согласуйте поля и переводы до новой проверки.

Решение и возможность пересмотра

Решение и возможность пересмотра

Что позволяет решить проверка и какие сведения сохранять для пересмотра.

Достаточные данные

Сравните выведенный JSON-LD с видимым текстом, canonical и свойствами выбранного типа. Проверьте разные шаблоны и языки.

Следующее решение

Уберите неподтверждённые поля, исправьте расхождения и проверьте готовый HTML. Задокументируйте поддержку используемых типов.

Подробные случаи проверки

Типовые ситуации для подготовки проверки. Они не описывают выполненные проекты или реальные наблюдения.

Разметка обещает больше текста

Что изучить

Свяжите каждое структурированное свойство с видимой информацией и доказательством.

Решение и действие

Уберите неподтверждённые значения; правильный синтаксис не подтверждает рейтинг, цену или связь.

Что сохранить

Свойство, видимый текст, доказательство и исправление.

Идентификатор обозначает два объекта

Что изучить

Сравните одинаковый @id на страницах и атрибуты идентичности.

Решение и действие

Закрепите идентификатор за одним объектом; различайте человека, организацию и страницу без раздвоения сущности.

Что сохранить

Вхождения, затронутые объекты и исправленное правило идентификации.

Разметка выходит за пределы видимого текста

Что изучить

Сравнить утверждения JSON-LD с текстом страницы и источниками.

Решение и действие

Удалить или исправить необоснованные свойства.

Что сохранить

Свойство, видимое значение, источник и итог проверки.

ДОКУМЕНТИРОВАННЫЕ ОРИЕНТИРЫ

Канонический JSON: точный договор, а не только сортировка ключей

JCS из информационного RFC 8785 задаёт детерминированное представление для криптографии. Он строже произвольного JSON и сложнее удаления пробелов.

Канонический JSON: точный договор, а не только сортировка ключей
ОриентирЗначение или формаЧто обозначает
INPUTI-JSON · уникальные именаИмена свойств должны быть уникальны, данные совместимы с I-JSON. Парсер, уже перезаписавший дубликат, скрывает неверный ввод: проверяйте до потери информации.
WHITESPACEбез пробелов между токенамиПробелы между токенами не выводятся. Пробелы внутри строк остаются; удаление всех пробелов исходного текста изменило бы данные.
NUMBERSECMAScript · IEEE 754 binary64Числа сериализуются по ECMAScript для binary64. NaN и Infinity отклоняются; большая точность требует отдельного договора, часто явной строки.
PROPERTY ORDERрекурсивно · единицы UTF-16Рекурсивная сортировка сравнивает декодированные имена как беззнаковые единицы UTF-16 без локального алфавитного порядка. Сортировка UTF-8 или кодовых точек может отличаться.
ARRAY ORDERсохранёнПорядок элементов массива сохраняется, хотя вложенные объекты обрабатываются. Сортировка всех списков меняет смысл.
UNICODEсохранён · выход UTF-8Unicode-строки сохраняются: JCS не применяет NFC или NFKC. Выход кодируется UTF-8. Канонизация JSON не равна языковой нормализации.

Эталонный порядок семи имён JSON

RFC 8785 § 3.2.3. Подписи оставлены на английском. Единицы UTF-16 показывают порядок, включая символ вне основной многоязычной плоскости.

Эталонный порядок семи имён JSON
Кодовые точкиЕдиницы UTF-16Подпись источника (английский)
U+000D000DCarriage Return
U+00310031One
U+00800080Control
U+00F600F6Latin Small Letter O With Diaeresis
U+20AC20ACEuro Sign
U+1F600D83D DE00Emoji: Grinning Face
U+FB33FB33Hebrew Letter Dalet With Dagesh

RFC 8785 § 3.2.3. Copyright © 2020 IETF Trust and the persons identified as document authors. UTF-16 units added for explanation.

Что учитывать в досье

Явно обозначайте хеш выхода JCS и профиль. Он не заменяет хеш исходных байтов; сохраняйте оба объекта для прослеживаемости.

Достаточно JSON.stringify для JCS?

Не самого по себе. Он не проверяет все ограничения и рекурсивную сортировку. Пример RFC помогает обнаружить неподходящий порядок Unicode.

Первичная документация

Документация просмотрена .

ДОКУМЕНТИРОВАННЫЕ ОРИЕНТИРЫ

JSON Merge Patch: удалить, сохранить или заменить значение

Частичное обновление должно указывать формат. JSON Merge Patch описывает значения для слияния с целью, JSON Patch — операции. Их медиатипы и трактовка null различаются. Симулятор позволяет изучить слияние без обращения к API.

JSON Merge Patch: удалить, сохранить или заменить значение
ОриентирЗначение или формаЧто обозначает
member absentkeepПропущенный член patch не меняется, если цель — объект. Член со значением null запрашивает удаление; если его уже нет, ничего не добавляется. Пустая строка, false и ноль — значения, а не команды удаления.
member: nulldeleteОбъект patch сливается рекурсивно. Соответствующая цель-массив, скаляр или null сначала становится пустым объектом. Поэтому применение {} к числу 7 даёт {}, а не 7.
{}object targetPatch, не являющийся объектом, целиком заменяет цель на этом уровне. Массив заменяется полностью: он не конкатенируется и не сопоставляется по индексам или идентификаторам.
null / [] / scalarreplaceNull в корне patch заменяет всю цель на null. Null как член объекта patch удаляет этот член. Для явного присвоения null свойству лучше может подойти операция JSON Patch.
JSON values≠ text diffРасчёт работает со значениями JSON. Пробелы, отступы и порядок отображения свойств не сохраняются. Корректный результат слияния всё ещё может нарушать схему API или бизнес-правила.

Симуляция JSON Merge Patch

Авторские учебные примеры; реальные документы не изменяются.

Два значения JSON, не более 4 000 единиц UTF-16 каждое, глубина 20 контейнеров и 500 значений на ввод. Числа: целые без дроби и экспоненты от −9 007 199 254 740 991 до +9 007 199 254 740 991. Имена членов уникальны; строки Unicode без одиночных суррогатов. Это ограничения инструмента.

Локальный расчёт; ввод не отправляется и не сохраняется. Результат остаётся на странице.

Симуляция обновлена.

Итоговое значение

{
    "title": "B",
    "keep": true
}
Один null, два формата обновленияУчебное сравнение: удаление члена через Merge Patch и присвоение null через JSON Patch дают разные объекты.Merge Patch{"note": null}{}JSON Patchreplace /note → null{"note": null}
Учебное сравнение: удаление члена через Merge Patch и присвоение null через JSON Patch дают разные объекты. target = {"note":"old"}
Десять слияний: цель, patch и результат
Десять слияний: цель, patch и результат
ШагИсходная цельПрименяемый patchИтоговое значение
1
{
    "title": "A",
    "note": "old",
    "keep": true
}
{
    "note": null,
    "title": "B"
}
{
    "title": "B",
    "keep": true
}
2
{
    "items": [
        "A",
        "B",
        "C"
    ]
}
{
    "items": [
        "B"
    ]
}
{
    "items": [
        "B"
    ]
}
3
[
    1,
    2
]
{
    "x": 1
}
{
    "x": 1
}
4
{
    "x": 1
}
null
null
5
[]
{
    "missing": null
}
[]
6
7
[]
[]
7
{
    "a": {
        "x": 1,
        "y": 2
    },
    "z": 3
}
{
    "a": {
        "x": null
    }
}
{
    "a": {
        "y": 2
    },
    "z": 3
}
8
{
    "a": null,
    "b": 5
}
{
    "b": 0,
    "c": false,
    "d": ""
}
{
    "a": null,
    "b": 0,
    "c": false,
    "d": ""
}
9
{
    "items": [
        "A",
        "B"
    ]
}
{
    "items": [
        "X"
    ]
}
{
    "items": [
        "X"
    ]
}
10
{
    "__proto__": {
        "x": 1
    },
    "constructor": 2
}
{
    "__proto__": {
        "y": 3
    }
}
{
    "__proto__": {
        "x": 1,
        "y": 3
    },
    "constructor": 2
}

Что учитывать в досье

Симуляция не меняет ресурсы и не проверяет права, контракт API или параллельные обновления. Ограничения ввода и чисел защищают интерпретацию браузером, но не определяют весь JSON. Отдельно фиксируйте идентификатор и версию действительно обновляемого ресурса.

Всегда ли пустой объект означает «ничего не менять»?

Нет. В Merge Patch {} сохраняет цель-объект, но заменяет иную цель пустым объектом. Значение зависит от типа цели на этом уровне. Проверка схемы после слияния — отдельная задача.

Первичная документация

Документация просмотрена .

Проверка перед решением

Эти вопросы дополняют метод. Они помогают установить подтверждённое, сохранив оговорки в записи.

Видимые факты

Есть ли у размеченных даты, цены, роли, отзыва и доступности обоснованный видимый эквивалент? Удаляйте выведенные или устаревшие свойства вместо искусственного заполнения.

Посмотреть разбор решения

Вымышленный пример: статус относится только к указанному критерию и охвату.

Вымышленное наблюдение
JSON-LD показывает цену 100; страница — 120 для того же предложения и периода.
Заявленное состояние
Наблюдаемое расхождение
Решение и следующая проверка
Согласовать видимое обоснованное значение. Проверить варианты и данные генерации разметки.

Синтаксис и охват

Проходят ли тип, свойства и связи подходящий валидатор? Разделяйте корректность разметки, правила поисковой функции и реально наблюдаемое отображение.

Посмотреть разбор решения

Вымышленный пример: статус относится только к указанному критерию и охвату.

Вымышленное наблюдение
Валидатор не сообщает ошибок; наблюдений поискового результата нет.
Заявленное состояние
Не проверено
Решение и следующая проверка
Сохранить проверку синтаксиса, оставив реальный показ непроверенным. Не обещать расширенный результат.

Пример или действующее предложение

Различает ли разметка условные данные, старые значения и видимое предложение? Учебный пример не должен становиться коммерческим обещанием в разметке.

Изученная документация : Google Search Central · Structured data policies ·

Посмотреть разбор решения

Вымышленный пример: статус относится только к указанному критерию и охвату.

Вымышленное наблюдение
Упражнение помечено вымышленным; разметка описывает учебный ресурс без предложения продажи.
Заявленное состояние
Подтверждено в этих рамках
Решение и следующая проверка
Тип содержимого согласован в этом охвате. Повторить, если оно станет реальным предложением.
Документировать проверку

ИНСТРУМЕНТЫ / РЕЕСТРЫ

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

Сравните заявленные свойства с видимым содержимым и источниками. Валидный JSON может содержать ложные сведения; техническая проверка не заменяет редакционную.

  • Дата просмотра и часовой пояс
  • Точный URL
  • Вид документа
  • Проверяемое утверждение
  • Наблюдаемый результат
  • Критерий приёмки
  • Решение / следующий шаг
  • Ответственный за проверку
  • Следующая проверка
Заполненный вымышленный фрагмент

03 / FAQ

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

Гарантирует ли JSON-LD расширенный результат?

Нет. Тип должен соответствовать странице и правилам; показ решает поисковая система.

Нужна ли разметка для каждой FAQ?

Нет. Полезные вопросы могут оставаться обычным HTML.

Что делать при разных заголовках языковых версий?

Каждая версия должна описывать своё видимое содержание с согласованными URL и кодами языка.

Можно ли описать услугу, которой нет на странице?

Нет. Разметка должна отражать страницу без непроверяемых обещаний.

Как контролировать повторяемые значения на нескольких страницах?

Идентификаторы и общие свойства. Сравнить их ценности с ссылками на сайт, а затем проверить модели, которые их производят, чтобы исправить причину и зависимости от происшествий.

04 / Официальные источники

Официальные источники

05 / Читать далее

Читать далее

Папки документов и картотека. Иллюстративная сцена.

Проверяемая карточка сущности

Читать протокол Два экрана и справочные документы. Иллюстративная сцена.

Аудит обхода и индексации

Читать протокол Корректуры, разделители и редакционный блокнот. Иллюстративная сцена.

Поддержание достоверного редакционного корпуса

Читать протокол Оценка ответов ассистентов и ссылок на двух экранах.

Руководства · IA & Search

Читать протокол

Описать задачу

Контакт

ДОКУМЕНТИРОВАННЫЕ ОРИЕНТИРЫ

JSON Schema: наличие, не-NULL и разрешение различны

Используется диалект 2020-12 и совместимый валидатор. Примеры учебные. Правила объекта предполагают type: object; required один его не задаёт.

JSON Schema: наличие, не-NULL и разрешение различны
ОриентирЗначение или формаЧто обозначает
$schemahttps://json-schema.org/draft/2020-12/schemaURI задаёт диалект; храните версию валидатора.
propertiesСвойство присутствуетproperties проверяет существующие ключи, не требует их.
required: ["id"]Наличие ≠ не-nullrequired ["id"] требует ключ; null считается присутствием.
type: ["string", "null"]Строка или JSON nullstring/null допускает оба; наличие и пустота различны.
additionalProperties: falseОбласть соседних объявленийadditionalProperties учитывает соседние определения, не обнаруживает другой allOf автоматически.
unevaluatedProperties: falseОценённые свойства подсхемunevaluatedProperties учитывает оценки успешных применимых подсхем; проверьте поддержку.

Что учитывать в досье

Структура не доказывает существование в реестре или правду связи. Разделяйте синтаксис, схему и предметную проверку.

properties id:string делает id обязательным?

Нет: отдельно задайте объект, required и допустимость null.

Первичная документация

Документация просмотрена .

ПОДРОБНЕЕ / ПРАКТИКА

Проверить согласованность за пределами синтаксиса

Валидатор принимает маркировку, когда имя, дата или URL больше не соответствуют странице. Контроль должен приближать декларированные данные к размещенной информации.

Обновлено .

Приоритетные проверки

Рассмотрим объекты, их идентификаторы и их отношения. Проверьте конечные URL-адресы, даты и свойства, повторяемые на нескольких страницах, а затем отслеживайте противоречия.

Ошибки интерпретации

Уведомление о валидации не всегда оказывает то же влияние, что и ложные данные. Приоритет зависит от собственности, ее использования и информации, которую она стремится представлять.

Рабочий документ для сохранения

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