Выделите свой сайт с помощью JSON-LD согласно Schema.org

Структурированные данные помогают поисковым системам лучше понимать веб-сайты. Семантическая аннотация позволяет устанавливать новые значения/контексты, автоматически считывать информацию и переносить ее в другие формы. Google, на сегодняшний день самая используемая поисковая система, опирается на структурированные данные с целью предоставления пользователям богатых результатов поиска и других подобных элементов SERP. Преимущество для оператора сайта заключается в том, что такие результаты поиска значительно повышают видимость и имеют гораздо больше шансов привлечь внимание потенциальных клиентов.

Одно из требований заключается в том, чтобы вся релевантная информация была соответствующим образом помечена. Со временем интернет-сообщество разработало различные стандарты для структурирования данных. Здесь мы расскажем, почему вам стоит выбрать JSON-LD в качестве альтернативы таким форматам данных, как Microformats, RDFa или Microdata.

JSON-LD расшифровывается как JavaScript Object Notation for Linked Data. Это основанный на JSON метод встраивания структурированных данных в веб-сайт. В отличие от других форматов структурирования данных, таких как Microformats, RDFa и Microdata, разметка не выполняется в виде аннотации к исходному тексту. Вместо этого метаданные реализуются как тег сценария, отдельный от содержимого веб-сайта в элементе head или body HTML-документа. JSON-LD использует нотацию JSON и расширяет ее синтаксисом, который позволяет различать данные в соответствии с универсально допустимыми, глобально стандартизированными схемами.

Спецификация JSON-LD принадлежит основателю Digital Bazaar Ману Спорни, и с 16 января 2014 года является официальной рекомендацией W3C.

Аббревиатура JSON расшифровывается как JavaScript Object Notation и обозначает компактный текстовый формат для обмена данными. Его легко обрабатывать как людям, так и машинам. JSON является производной от JavaScript, однако он может быть реализован на различных платформах независимо от соответствующего языка программирования. Как формат данных для сериализации — отображения программируемых объектов в формат последовательного представления — JSON используется для передачи и хранения структурированных данных на веб-сайтах и в мобильных приложениях. Синтаксис объекта JSON состоит, по сути, из пар имя-значение (за исключением цифр), заключенных в двойные кавычки и выделенных двоеточием. Каждая пара имя-значение обычно начинается с новой строки и заканчивается запятой. Исключением является последняя пара имя-значение перед закрывающей скобкой, которая указывается без запятой.

Следующий пример наглядно демонстрирует основную схему синтаксиса JSON:

В начальном предложении вы видите пару слов ‘Manu Sporny’. Читатель быстро поймет по последовательности букв, что это имя, а гиперссылка является ссылкой на веб-сайт разработчика JSON LD. Такие программы, как веб-браузеры и поисковые машины, требуют метаданных для создания такой связи. Именно это и предлагает JSON.

В коде примера показаны элементы имен ‘name’ и ‘homepage’ с соответствующими значениями. Это гарантирует, что программа, которая читает веб-сайт с этим объектом JSON, сможет определить «Manu Sporny» как имя и «http://manu.sporny.org/about/» как домашнюю страницу.

В то время как присвоение смысла с помощью JSON прекрасно работает в рамках одного сайта, анализ данных JSON с разных сайтов быстро приводит к проблеме неоднозначности. Обычно программы анализируют большое количество веб-сайтов и оценивают полученную информацию в базах данных. Например, при использовании вышеупомянутого кода JSON нельзя гарантировать, что элементы ‘name’ и ‘homepage’ всегда используются в одном и том же смысловом контексте на разных сайтах. Чтобы избежать двусмысленности, JSON-LD добавляет контекстные элементы к классической нотации JSON. Это делается на основе связанных данных — свободно доступных данных в Интернете, доступ к которым можно получить через унифицированный идентификатор ресурса (URI).

Дополнительную информацию о связанных данных можно найти в следующем видео от разработчика JSON-LD Ману Спорни:

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

Чтобы подготовить JSON для связанных данных, JSON-LD дополняет классические пары имя-значение нотации JSON так называемыми ключевыми словами. Ключевые слова вводятся в синтаксис JSON-LD перед символом @. Особое значение здесь имеют ключевые слова @context и @type. В то время как @context определяет базовый словарь метки, @type указывает используемый тип данных (схему).

Стандартизированная база данных схем для структурирования данных предлагается проектом Schema.org. На одноименном сайте проекта операторы сайтов могут найти различные схемы (типы) данных, а также «свойства», присвоенные этим типам данных, которые делают возможным детальное семантическое отображение содержимого сайта.

При добавлении соответствующих элементов контекста для приведенного выше примера получается следующий код:

Ключевое слово @context в столбце 2 определяет словарь, на котором основана семантическая метка — в данном случае Schema.org. В столбце 3 с помощью ключевого слова @type реализован тип данных ‘Person’. Этот тип данных уточняется далее в колонках 4 и 5 через характеристики ‘name’ и ‘url’. Таким образом, программа, анализирующая данный пример кода, может идентифицировать текстовый элемент ‘Manu Sporny’, обозначенный как ‘name’, как имя человека. Это соответствует типу данных ‘person’ согласно Schema.org. Пары имя-значение, представленные ‘name’ и ‘url’, обрабатываются как свойства схемы ‘Person’. Базовый словарь определяет, какие свойства могут быть присвоены схеме.

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

В JSON-LD назначение схем и свойств происходит по аналогии с другими форматами для семантической разметки содержимого веб-страниц. Преобразованный в аннотацию к исходному тексту, приведенный выше пример скрипта также может быть идентифицирован с помощью Microdata или RDFa согласно Schema.org, и это без потери информации.

Синтаксис Microdata в соответствии со Schema.org:

Синтаксис RDFa согласно Schema.org:

Самое большое преимущество JSON-LD по сравнению с другими конкурентами заключается в том, что метаданные не встраиваются непосредственно в HTML-код, а могут быть реализованы отдельно в нужном месте. Реализация JSON-LD может быть осуществлена с помощью тега скрипта в соответствии со следующей схемой:

Относительно приведенного выше примера, согласно Schema.org, делается следующая награда:

Строгое разделение между HTML и семантической аннотацией не только набирает очки за счет явно лучшей читабельности исходных текстов. Подобная реализация также позволяет динамически генерировать структуры данных, независимо от видимого содержимого. С помощью JSON-LD метаданные могут быть импортированы через бэкэнд, выбраны из базы данных, а затем автоматически сгенерированы с помощью шаблона. Это делает возможным более удобное семантическое аннотирование, даже для динамического веб-контента, который требует больше места в сети.

С июня 2013 года веб-проект Schema.org назвал JSON-LD одним из самых распространенных форматов данных. Google также рекомендует (где это возможно) встраивание метаданных через JSON-LD на основе скриптов. Такое разграничение является основой для различных элементов SERP, которые Google использует для представления пользователям расширенных результатов поиска.

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

В настоящее время Google поддерживает разметку JSON-LD для следующих ниже расширений. Пример для каждой функции результатов поиска можно найти в галерее поиска на сайте developers.google.com.

• Хлебные крошки: Так называемые «хлебные крошки» показывают положение текущей веб-страницы в иерархии сайта. Операторы веб-страниц, которые семантически содержат хлебные крошки, позволяют Google отображать их в SERP. Хлебные крошки относятся к тем немногим функциям результатов поиска, которые Google также включает в основные результаты.
• Контактная информация: Если контактные данные предприятия представлены семантически, Google может показать их в виде отображения графа знаний; это форма отображения алгоритма графа знаний.
• Логотипы: С помощью разметки логотипа операторы сайта дают понять, какое графическое изображение должно использоваться поисковой системой в качестве логотипа компании. Это дает возможность Google расширить результаты поиска для данной компании, включив в них логотип компании.
• Поисковая строка Sitelinks: Если на сайте предусмотрена функция поиска и он написан семантически, Google может использовать поисковую строку sitelinks для поиска результатов о сайте.
• Ссылки на профили социальных сетей: Если вы используете разметку для ссылок на профили социальных сетей, Google расширяет отображение графа знаний, включая людей или организации и соответствующие им кнопки. В настоящее время Google поддерживает разметку JSON-LD для Facebook, Twitter, Google+, Instagram, YouTube, LinkedIn, Myspace, Pinterest, SoundCloud и Tumblr.

Операторы сайтов, желающие убедиться, что их контент хорошо размещен и заметен в Google SERPs, имеют возможность семантически отображать различные типы данных. Здесь стоит отметить, что только Google решает, будет ли результат поиска показан как основной результат или как результат с расширениями. В настоящее время Google поддерживает разметку JSON-LD для нескольких типов данных и использует их для обработки информации в виде результатов расширенного поиска, обогащенных результатов поиска или результатов графа знаний.

• Статьи: Операторы веб-сайтов, которые хотят семантически отобразить новости и/или статьи из блогов на своей странице, позволяют Google включать их в карусель лучших статей или добавлять в SERP такие функции результатов поиска, как заголовки или миниатюры.
• Книги: Может случиться так, что ответственные за веб-сайт лица захотят предложить разметку JSON-LD для информации, относящейся к книгам. В этом случае Google создаст карту графа знаний для соответствующих поисковых запросов. Они содержат не только описательную информацию о книге, но и, при необходимости, дают возможность пользователям поисковой системы получить соответствующую информацию непосредственно из поисковой системы.
• Музыка (записи об исполнителях и альбомах): Подобно информации о книгах, музыкальные предложения также могут быть аннотированы. Это означает, что Google может генерировать карточки графа знаний для музыкального контента. Это не только предлагает пользователям поисковой системы информацию об альбомах и исполнителях, но и позволяет взаимодействовать с музыкой, например, воспроизводить ее или даже покупать.
• Предложения курсов: Операторы сайтов, предоставляющие курсы (например, языковые) с разметкой JSON-LD, позволяют автоматически считывать название курса, краткое описание и поставщика курса. Существует также большая вероятность того, что Google будет использовать эту информацию в качестве расширенных результатов поиска в SERPs.
• События: Те, кто предлагает публичные мероприятия, такие как концерты и фестивали, имеют возможность аннотировать всю необходимую информацию (например, место проведения мероприятия, дату, время и т.д.) с помощью JSON-LD, чтобы Google мог автоматически извлекать эту информацию и отображать ее в SERP, а также в других приложениях Google, например, в Картах.
• Объявления о работе: Даже вакансии, которые организации публикуют на своем сайте, могут быть составлены таким образом, чтобы Google мог считывать соответствующую информацию и отображать ее в расширенных результатах поиска.
• Местные предприятия: Местные предприятия, которые размещают структурированные данные на сайте своего магазина или ресторана, позволяют Google генерировать карточки графа знаний. Затем они будут отображаться в SERPS или на Картах Google при любых соответствующих поисковых запросах. Например, если пользователь Google ищет вьетнамский ресторан, Google впоследствии отобразит карусель со всеми соответствующими предложениями в этом районе.
• Наборы данных: Даже такие наборы данных, как таблицы CSV или файлы в проприетарных форматах, могут быть доступны для поисковых систем с помощью JSON-LD.
• Подкасты: Google также поддерживает разметку JSON-LD для подкастов. Соответствующие тематические предложения можно просматривать и даже воспроизводить непосредственно в поисковой системе.
• Видео: Поставщики контента, предоставляющие структурированные данные для видео на своем сайте, такие как описание, ссылка на миниатюру, дата загрузки или время воспроизведения, позволяют Google извлекать эту информацию и отображать ее в виде насыщенных карточек или карусели в SERP.
• Фильмы и шоу: Если веб-сайт предоставляет структурированные данные о фильмах или передачах, Google может перенести их на страницы результатов поиска в виде карточек графа знаний для соответствующих поисковых запросов. При необходимости их можно дополнить интерактивными элементами, позволяющими потребителю посмотреть или приобрести продукт.
• Рецепты: Вот уже несколько лет Google предлагает кулинарные рецепты в качестве основного результата в своей поисковой системе. Одним из условий для этого является то, что поставщик контента представляет всю необходимую информацию в виде структурированных данных. Одна из возможных презентаций после поискового запроса — в SERPs в карусели с подходящими богатыми картами.
• Рейтинги:  Google поддерживает рейтинги для различных типов данных Schema.org, таких как местные предприятия, рестораны, продукты, книги, фильмы и творческие работы. Представление этого контента осуществляется в виде сниппета. При этом Google проводит различие между критикой, сделанной отдельными авторами, и записями на других рейтинговых порталах. Если они содержат семантическую аннотацию, то оба типа оценок будут появляться в SERPs как результат поиска по соответствующему поисковому запросу.
• Продукты: Интернет-магазины, которые представляют информацию о товарах (например, цену, наличие, рейтинги и т.д.) на своем сайте в виде структурированных данных, дают возможность Google отображать эту информацию в виде расширенных результатов поиска после того, как запрос был отправлен.

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

Google размещает дисплеи и карусели на самом видном месте над основными результатами. Это также известно как «позиция 0». Отображения графа знаний появляются либо в виде карусели в верхней части страницы, либо в отдельной рамке справа от органического веб-поиска. Это означает, что расширенные результаты поиска предлагают операторам веб-сайтов возможность занять почетное место на странице результатов поиска без необходимости вкладывать много времени и денег в улучшение органического рейтинга.

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

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

Однако Google не считает наличие или отсутствие семантической разметки с помощью JSON-LD фактором ранжирования. Бывший руководитель команды Google по борьбе с веб-спамом Мэтт Каттс разъяснил это в следующем видеоролике на YouTube из серии Google Web Masters в 2012 году:

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

Как и в случае с приложением, JSON-LD также набирает очки за свою ползаемость благодаря перемещению разметки в отдельные разделы скрипта. По сравнению с альтернативными аннотациями, такими как Microdata или RDFa, JSON-LD позволяет сделать исходный код более компактным. И это несмотря на семантическую аннотацию, которая может быстро искаться и легко индексироваться ботом Google и другими краулерами.

Но аутсорсинг структурированных данных также имеет свои недостатки. В принципе, Google и другие поставщики поисковых систем применяют основное правило, согласно которому машиночитаемым является только тот контент, который доступен для человеческих посетителей. Однако с помощью JSON-LD теоретически можно реализовать любую разметку, даже если в реальном содержимом сайта нет эквивалента метаданным. В этом случае и поисковая система, и пользователь получают возможную дополнительную ценность; то, чего не может предложить более приукрашенный сайт. С точки зрения простоты и практичности, такой подход не рекомендуется, поскольку операторы веб-сайтов рискуют быть наказанными за рассылку спама в Интернете.

Чтобы посетители сайта случайно не вышли за рамки семантической аннотации в поисковых системах, в Общем руководстве по структурированным данным Google содержится подробный свод правил. Их можно свести к следующим пунктам:

• Формат: Структурированные данные должны быть представлены в одном из трех установленных форматов: Microdata, RDFa или JSON-LD. Google рекомендует последний.
• Доступность: Веб-страницы со структурированными данными должны быть доступны для бота Google. Методы контроля доступа (например, через robots.txt или noindex) препятствуют чтению метаданных.
• Эквивалентность содержимого: Разметка JSON-LD может описывать только сущности, которые также могут быть описаны в HTML-коде. 
• Актуальность: Разметка JSON-LD должна ссылаться только на релевантные эквиваленты используемых типов данных. Например, оператор сайта, представляющий техническое руководство в виде рецепта, нарушает директиву релевантности.
• Полнота: Все типы данных, перечисленные в разметке JSON-LD, должны быть обозначены полностью и включать необходимые свойства. Фактически, типы данных, в которых отсутствуют необходимые свойства, не подходят для результатов расширенного поиска.
• Специфичность: Проекты связанных данных, такие как Schema.org, предлагают множество типов данных. Чтобы ваш контент мог претендовать на представление в расширенных результатах поиска, операторам сайта следует выбирать схемы, которые являются максимально конкретными.

В следующих параграфах мы покажем на примере, как наиболее эффективно обогатить веб-сайт соответствующими метаданными. Руководство по JSON-LD основано на словаре проекта Schema.org.

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

Как правило, разметка должна структурировать и представлять информацию сайта в форме, которая может быть прочитана поисковыми системами. Цель — продемонстрировать Google и co., что оптимизированный сайт предоставляет лучшие ресурсы для любых релевантных поисковых запросов, относящихся к тематике веб-проекта. Вы должны задать себе следующие вопросы:

• Каково основное содержание вашего сайта?
• Какую ценность он может представлять для потенциальных посетителей?
• Какой контент, в частности, имеет отношение к тематике вашего сайта, чтобы сделать его «дружественным» для поисковых систем?

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

Например, Google рекомендует использовать аннотацию с JSON-LD для информации, связанной с событиями. В HTML можно отображать анонсы событий для концертов, мюзиклов или театральных представлений по следующей схеме:

Типичная информация типа данных ‘event’ включает дату, время, цену, наличие билетов, адрес места проведения, а также ссылки на дополнительную информацию о мероприятии или месте проведения. Посетители страницы могут взять эту информацию из текстового раздела, таблицы или других форм представления, а затем отнести ее к соответствующему контексту. С другой стороны, такие программы, как поисковые машины, требуют метаданные, содержащие инструкции по обработке представленной информации. JSON-LD предоставляет их в виде формата данных, который вставляется в любую позицию исходного кода HTML, отдельно от содержимого.

Schema.org предлагает операторам веб-сайтов широкий и всеобъемлющий словарь для структурирования данных. В общей сложности он включает в себя около 600 типов, которые могут быть заданы более чем 860 свойствами.

Когда дело доходит до выбора подходящих типов данных, можно выбрать одну из двух стратегий:

1. Теоретически, можно сравнить весь ранее определенный контент с доступными типами данных словаря Schema.org, а затем выбрать наиболее специфический тип данных для каждого элемента контента. Однако такой подход длителен и обычно не нужен.
2. На практике операторы веб-сайтов обычно ограничиваются подмножеством типов данных Schema.org. Если вы используете разметку JSON-LD только с целью предоставления поисковой системе структурированных данных, достаточно сначала ограничиться теми типами данных, которые в настоящее время поддерживаются Google и подробно описаны в разделе для разработчиков Google.

Мы рекомендуем последний из этих вариантов по следующей причине: Google предлагает подробную документацию по всем типам данных, поддерживаемым поисковой системой. Для каждого типа данных приводится пример разметки.

Чтобы оснастить свой сайт структурированными данными, не обязательно изобретать велосипед. Это особенно актуально, если у вас нет опыта работы с синтаксисом JSON-LD. Вы сэкономите время и силы, если будете использовать готовые шаблоны, а не переписывать разметку для каждого типа данных с нуля.

В следующем документе Google операторы сайта могут найти следующий пример разметки для событий:

Теги сценария определяют элемент со строки 01 по 39 как сценарий типа ‘application/ld+json’. Следующая информация предназначена для программ, которые могут читать связанные данные в формате JSON.

Первый уровень содержит ключевые слова ‘@context’ и ‘@type’ со значениями ‘http://schema.org’ и ‘Event’ (строки 03 и 04). Программа синтаксического анализа получает указание, что следующая информация должна быть отнесена к схеме ‘Event’ согласно Schema.org, что означает, что это конкретное свойство описываемого события. Они отображаются в виде пар «имя-значение».

Аналогично, первый уровень также содержит свойства ‘name’, ‘startDate’, ‘location’, ‘image’, ‘description’, ‘enddate’, ‘offers’ и ‘performer’, которым в качестве значений присваивается соответствующая информация о событии. Поисковая система может определить информацию «Концертная серия Яна Либермана: Journey in Jazz» как название события (name) и «2017-04-24T19:30-08:00» как точное время начала (StartDate).

Подобно RDFa и Microdata, синтаксис JSON-LD поддерживает вложенность. Свойству присваивается не значение, а (под-)схема, которая может быть определена с помощью конкретных свойств. Такой случай вы найдете на втором уровне примера кода в строках 08, 27 и 35.

Например, в строке 08 свойство события ‘location’ определено как (под)схема типа ‘Place’ и снабжено свойствами ‘name’ и ‘address’. В свою очередь, в строке 11 свойство ‘address’ определяется как (под)схема типа ‘PostalAddress’ и, как следствие, помечается специфическими для схемы свойствами ‘streetAddress’, ‘addressLocality’, ‘postalCode’, ‘addressRegion’ и ‘addressCountry’.

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

Секция (строки с 07 по 18):

Таким образом, Schema.org предоставляет операторам веб-сайтов типы данных в виде иерархической древовидной структуры. Это то, что становится все более и более конкретным на основе самого общего типа данных ‘Thing’.

В следующем шаге мы покажем вам, как адаптировать пример Google для типа данных ‘Event’, чтобы он соответствовал вышеупомянутому анонсу события.

Документация Google содержит только примеры, показывающие, как перечисленные типы данных можно различать с помощью JSON-LD. Если они используются в качестве шаблонов для вашей собственной разметки метаданных, код всегда должен быть адаптирован индивидуально. Может быть полезно обратиться к документации Schema.org для соответствующего типа данных, чтобы узнать больше об использовании схемы и возможных свойствах. В следующем примере показана индивидуальная настройка кода шаблона Google для типа данных «Событие»:

На первом этапе мы заменили все значения образца разметки на соответствующие значения вышеуказанного объявления о событии. Неправильные (под)схемы и свойства были заменены. Вместо ‘PerformingGroup’ мы используем (под)схему ‘Person’ под ‘performer’, потому что мы имеем дело не с группой, а с одним исполнителем. Наконец, мы добавили в разметку информацию, которая не была включена в шаблон Google. Например, строки 07 и 10 содержат URL-адреса, относящиеся к событию или месту проведения мероприятия. Для получения информации о возможных свойствах обратитесь к документации Schema.org.

Даже если вы решили создать свою разметку JSON-LD с нуля и без шаблона, вам все равно следует заглянуть на страницу документации Google по каждому типу данных. Здесь Google указывает как обязательные, так и рекомендуемые свойства для всех поддерживаемых типов данных.

Примеры в документации Google всегда включают все необходимые и рекомендуемые свойства.

Проверять, нет ли в вашей разметке важных свойств, лучше всего с помощью инструмента проверки, предоставляемого Google.

Примеры в документации Google всегда включают все необходимые и рекомендуемые свойства.

Проверять, нет ли в вашей разметке важных свойств, лучше всего с помощью инструмента проверки, предоставляемого Google.

Благодаря вложению типов, подтипов и свойств друг в друга становятся возможными сложные сценарии JSON LD. Разделение HTML-разметки и семантической аннотации обеспечивает гораздо более четкую читаемость, чем это обычно наблюдается в других форматах, таких как RDFa и Microdata, которые полагаются на аннотацию исходного текста. Чтобы избежать ошибок при программировании, Google предлагает бесплатный инструмент, позволяющий разработчикам проверять сценарии JSON-LD для структурирования данных.

Действуйте следующим образом:

1. Скопируйте и вставьте код JSON-LD в нужное поле.

Можно также вставить саму разметку или URL сайта, разметку метаданных которого вы хотите проверить.

1. Запустите проверку, нажав на кнопку ‘Run Test’.

В процессе проверки инструмент считывает структурированные данные из разметки JSON-LD и проверяет их на полноту. Затем пользователям представляются прочитанные данные в виде табличного обзора. Этот обзор также содержит примечания и предупреждения, если инструмент обнаружил синтаксические ошибки или недостающие данные.

Созданный нами тестовый сценарий не содержит ошибок и содержит все необходимые свойства. Однако если мы удалим необходимое свойство ‘startDate’, то получим следующее сообщение:

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

1. Генерация предварительного просмотра

Помимо функции тестирования, инструмент тестирования структурированных данных Google также предлагает режим предварительного просмотра. Это позволяет операторам сайта увидеть, как может выглядеть результат расширенного поиска, основанный на проверенной валидной разметке.

Если Google не отображает результаты расширенного поиска для вашего сайта, несмотря на разметку JSON-LD, обычно это означает, что вы допустили ошибку в структурировании данных. Проверьте свой код еще раз и проверьте следующие возможные источники ошибок:

• Синтаксическая ошибка: Синтаксис JSON-LD понятен и прост. Но, как и в любом другом языке разметки, в него время от времени могут вкрадываться ошибки. Одним из известных источников ошибок является разница между двойными символами кодирования («…») и типографскими кавычками («…»). В то время как кодовые символы используются при программировании, кавычки применяются для обозначения дословной речи в письменном языке. Поскольку часто бывает так, что программы обработки текстов автоматически преобразуют дублирующиеся символы кодировки в кавычки, лучше всего использовать редактор, такой как Notepad, для создания разметки JSON-LD. В JSON также не допускаются одиночные кавычки, которые обычно используются в программном коде.

• Неполный, неправильный или неконкретный словарь: Иерархическая древовидная структура Schema.org точно определяет, какие свойства могут быть использованы с каким типом данных. Если вы используете свойство для типа данных, который его не поддерживает, соответствующее значение не может быть интерпретировано Google. В 6 таком случае код классифицируется как ошибочный. Инструмент тестирования структурированных данных Google также выявляет такие ошибки.

Вы всегда должны использовать страницы документации Schema.org и проверять свой JSON-LD код с помощью инструмента тестирования структурированных данных. Также обратите внимание на Общие рекомендации по структурированным данным, а также на общие рекомендации Google для веб-мастеров, чтобы избежать нарушений правил, которые могут привести к исключению из расширенного ранжирования результатов поиска.