Что такое JSON-LD Validator и что он проверяет?
Валидатор микроразметки нужен и тогда, когда JSON выглядит корректно. Код может успешно обрабатываться как JSON, но содержать неподходящий schema type, отсутствующие свойства или данные неправильного формата. Поэтому проверка Schema.org должна учитывать структуру сущности, значения полей и соответствие разметки содержимому страницы.
JSON-LD Validator проверяет код структурированных данных и помогает найти места, которые могут мешать корректной обработке разметки. В базовую проверку входят JSON syntax, @context, @type, schema properties, вложенные объекты и значения. Если разметка содержит несколько сущностей, отдельно проверяют связи через @id и структуру @graph.
Schema validator полезен для Product, Organization, LocalBusiness, Article, BreadcrumbList, WebSite, WebPage и других типов Schema.org. Набор required properties и recommended properties зависит от конкретной сущности. Поэтому одинаковый набор полей нельзя использовать для всех типов разметки.
Проверка синтаксиса JSON-LD
Проверка начинается с синтаксиса. JSON-LD обычно размещают внутри <script type="application/ld+json">, а содержимое должно соответствовать правилам JSON. Частые JSON syntax error связаны с лишними запятыми, неправильными кавычками, незакрытыми скобками, ошибочной вложенностью массивов и объектов.
Schema checker online должен показывать, где возникла ошибка, чтобы разработчику не приходилось вручную перечитывать весь JSON-LD code. После исправления код проверяют повторно. Один пропущенный символ может нарушить обработку всего блока, поэтому syntax validation лучше выполнять до переноса разметки на рабочий сайт.
Типичные причины ошибки:
- после последнего свойства объекта оставлена лишняя запятая, из-за которой JSON перестаёт корректно разбираться;
- вместо обычных двойных кавычек используются типографские символы, скопированные из текстового редактора;
- массив или объект закрывается неправильной скобкой, поэтому нарушается структура вложенных данных;
- значение вставлено без кавычек там, где ожидается строка, либо строка содержит некорректно экранированные символы.
После исправления синтаксиса нужно перейти к проверке самой Schema.org-разметки. Валидный JSON подтверждает только техническую корректность формата и не говорит о качестве описанной сущности.
Чем ошибка JSON отличается от ошибки Schema.org?
Ошибка JSON означает, что код нарушает правила самого формата. Например, парсер не может обработать объект из-за лишней запятой или незакрытой скобки. Ошибка Schema.org появляется в уже корректном JSON, когда используется неизвестный @type, неподходящее свойство или значение неправильного data type.
Поэтому json ld checker должен проверять оба уровня. Сначала код должен успешно разбираться как JSON, затем выполняется schema validation. Такой порядок помогает отделить техническую поломку документа от ошибки в логике структурированных данных и быстрее найти причину проблемы.
Проверка @context, @type и свойств Schema.org
@context указывает словарь, по которому интерпретируются свойства JSON-LD markup. Для Schema.org обычно используется соответствующий контекст Schema.org. Поле @type определяет entity, которую описывает блок: Product, Organization, Article, LocalBusiness или другой тип.
После определения сущности валидатор JSON LD проверяет свойства, допустимые для выбранного типа. Например, набор данных для Product отличается от Organization Schema или BreadcrumbList. Проверять нужно также nested objects, URL, даты, числовые значения и ссылки между связанными сущностями.
Ошибки и предупреждения – в чём разница?
Error обычно указывает на ошибку, которую нужно исправить до завершения проверки. Причиной может быть неверный синтаксис, отсутствующее обязательное значение или структура, которую валидатор не может корректно обработать. Такие validation errors проверяют в первую очередь.
Warning сообщает о потенциальной проблеме или недостающем рекомендуемом свойстве. Предупреждения тоже требуют внимания, но предупреждение не всегда делает весь JSON-LD невалидным. Решение зависит от типа Schema.org, назначения разметки и требований поисковой системы к конкретному search feature.
Какие ошибки находит JSON-LD Validator?
Валидатор микроразметки помогает найти как простые синтаксические ошибки, так и проблемы со структурой Schema.org. Часть ошибок появляется при ручном редактировании, другая часть связана с CMS, шаблонами, импортом данных или неверной логикой генерации JSON-LD.
На практике проблемы часто повторяются. Поэтому проверять стоит не один URL, а шаблон страницы и несколько разных примеров данных: товар с ценой, товар без наличия, статью с автором, локальную страницу с адресом и другие варианты, которые реально используются на сайте.
| Тип ошибки | Пример | Что проверить |
|---|---|---|
| JSON syntax | Лишняя запятая или неправильная кавычка | Структуру JSON |
| @context | Контекст отсутствует или указан неверно | Используемый словарь |
| @type | Неизвестный или неподходящий тип | Тип описываемой сущности |
| Property | Свойство не подходит выбранному типу | Документацию Schema.org |
| Data type | Дата, цена или URL записаны неверно | Формат значения |
| @id | Ссылка ведёт на отсутствующую сущность | Связи между entity |
| Duplicate schema | Одна сущность выводится несколько раз | CMS, шаблон и SEO-модули |
Таблица помогает определить направление проверки, но каждую ошибку нужно оценивать в контексте конкретного типа Schema.org и содержимого страницы.
Ошибки синтаксиса JSON
Большинство синтаксических проблем появляется после ручного изменения кода. Частая ситуация – разработчик добавляет новое поле и оставляет лишнюю запятую перед закрывающей скобкой. Другой вариант – JSON-LD копируют из документа, где обычные кавычки автоматически заменились типографскими.
При генерации разметки через CMS ошибки могут возникнуть из-за некорректного экранирования пользовательских данных. Например, название содержит кавычки или специальные символы, а шаблон вставляет строку без правильной обработки. В этом случае проверять нужно логику генерации, а не исправлять каждую страницу вручную.
Ошибки Schema.org
Schema.org error появляется, когда синтаксис уже корректен, но структура данных составлена неправильно. Возможны неподходящий @type, отсутствующее required property, неверная вложенность или property, которое не относится к выбранной сущности.
Schema markup validator помогает обнаружить такие проблемы до публикации. После исправления желательно свериться с документацией Schema.org и требованиями поисковой системы, если разметка создаётся для конкретного rich result.
Ошибки дат, цен и URL
Дата должна передаваться в подходящем формате, а цена – отдельным числовым значением. Валюта указывается отдельно через priceCurrency. Строка вроде «20 000 грн» в поле price может привести к неправильной интерпретации данных.
URL тоже нужно проверять внимательно. Для связанных entity обычно используют стабильные абсолютные адреса. При переносах домена старые ссылки в @id, image или других свойствах могут остаться незамеченными, хотя видимая часть страницы уже работает на новом адресе.
Ошибки @id и @graph
@id помогает связать несколько объектов, которые описывают одну страницу, организацию, автора или другой объект. Если ссылка @id указывает на сущность, которой нет в разметке, связь становится некорректной. Подобные ошибки часто встречаются в сложных @graph.
При использовании @graph желательно придерживаться стабильных идентификаторов и не создавать несколько независимых версий одной сущности. Например, Organization не должна бессистемно дублироваться в каждом блоке с разными названиями, URL или логотипами.
Дубли и конфликтующая микроразметка
Дубли появляются, когда разметку одновременно создают CMS, SEO-плагин и дополнительный код шаблона. На одной странице могут оказаться несколько Product или Organization с разными значениями. Формально каждый блок способен пройти отдельную проверку, но вся страница содержит конфликтующие данные.
Поэтому проверка schema org должна включать анализ страницы целиком. Если обнаружено несколько описаний одной сущности, нужно определить источник каждого блока и оставить одну согласованную версию либо связать сущности корректно.
Я не считаю JSON-LD корректным только потому, что парсер не показывает синтаксических ошибок. Я отдельно проверяю тип Schema.org, обязательные свойства, связи через @id и @graph и соответствие данных тому, что пользователь реально видит на странице. После исправлений я повторно проверяю опубликованный URL и, если разметка предназначена для расширенного результата Google, дополнительно запускаю Rich Results Test.
Как проверить JSON-LD онлайн?
Проверка JSON LD занимает несколько шагов. Код вставляют в поле валидатора, запускают анализ и изучают результат. Если инструмент показывает ошибки, их исправляют последовательно, начиная с синтаксиса и базовой структуры, а затем выполняют повторную проверку.
После успешной проверки самого фрагмента желательно проверить уже опубликованную страницу. Это помогает увидеть разметку в том виде, в котором она реально отдаётся браузеру и поисковому роботу после обработки шаблонов, модулей CMS и серверного рендеринга.
Проверка JSON-LD кода
Для проверки скопируйте JSON-LD из шаблона или исходного кода страницы и запустите markup validation. Сначала исправьте проблемы с JSON syntax, затем проверьте @context, @type, свойства сущности, типы значений и связанные элементы.
Рабочий порядок выглядит так:
- Вставьте код JSON-LD в поле проверки и запустите валидатор.
- Исправьте синтаксические ошибки, если они обнаружены в коде.
- Проверьте schema type и набор свойств для выбранной сущности.
- Сверьте значения разметки с фактическими данными на странице.
- Запустите повторную проверку после внесения изменений.
После успешной проверки не стоит сохранять результат без контроля внедрения. Код в редакторе и JSON-LD, который фактически выводится на странице, могут отличаться из-за шаблона, CMS или дополнительного SEO-модуля.
Проверка JSON-LD по URL страницы
Проверка опубликованного page URL полезна после внедрения разметки. Она показывает структурированные данные, которые реально присутствуют в HTML страницы. Такой подход помогает обнаружить дубли, старые блоки Schema.org и данные, которые добавляет CMS автоматически.
Проверка по URL особенно полезна после обновления сайта, переноса на другую CMS или изменения общего шаблона. Если несколько модулей одновременно выводят Organization, Product или другие сущности, ручная проверка одного исходного фрагмента может не показать конфликт.
Как читать результат проверки?
Сначала посмотрите, какой schema type обнаружен и есть ли критические ошибки. Затем проверьте сообщения о недостающих свойствах, неправильных форматах значений и проблемах со связанными entity. Для больших блоков полезно разбирать результат по одной сущности.
После исправления одной группы ошибок проверку запускают снова. Так проще увидеть оставшиеся проблемы и не смешивать старые сообщения с новыми. Если JSON-LD используется для rich results Google, после schema markup validator страницу дополнительно проверяют через Google Rich Results Test.
Что именно мы делали
Стоматология · Киев и Чернигов
+44% кликов из поиска
Домен без истории, сайт на конструкторе. Собрали семантику под услуги и оба города, переработали посадочные страницы, с нуля построили ссылочный профиль. За четыре месяца: 34,8 тыс. кликов, показы 1,32 → 1,76 млн, DR 0 → 41.
E-commerce · международный рынок
+96% кликов за два месяца
Каталог цифровых 3D-моделей. Кластеризовали семантику, перестроили хабовые страницы, закрыли дубли и ошибки индексации. Пользователи из Google 247 → 532, CTR 2,4% → 4%.
Медицинский центр · Украина
+68,75% видимости за первый месяц
Узкая видимость и малая семантика на старте. Семантика, структура посадочных, метаданные и перелинковка, постепенное усиление ссылками.
Ответы на ваши вопросы
Что проверяет JSON-LD Validator?
JSON-LD Validator проверяет синтаксис JSON, @context, @type, свойства Schema.org, структуру вложенных объектов и связанные сущности. В зависимости от инструмента проверка может дополнительно показывать отсутствующие свойства, предупреждения и ошибки формата значений.
После технической проверки желательно сравнить разметку с видимым содержимым страницы. Валидатор не может заменить проверку актуальности фактических данных, которые CMS передаёт в JSON-LD.
Как проверить JSON-LD онлайн?
Скопируйте JSON-LD code из страницы или шаблона и вставьте его в поле проверки. После запуска исправьте ошибки синтаксиса, затем проверьте типы Schema.org, свойства и значения.
После исправлений запустите проверку повторно и протестируйте уже опубликованный URL. Такой подход помогает заметить изменения, которые появляются только после обработки страницы CMS или серверным шаблоном.
Почему JSON-LD валидный, но rich results не появляются?
Корректная Schema.org не гарантирует расширенный результат. Google применяет отдельные требования к поддерживаемым типам структурированных данных и самостоятельно решает, какой вид результата показывать в поиске.
Нужно проверить соответствие данных странице, требования к конкретному типу, индексирование URL и состояние разметки в Google Search Console. После изменения кода также требуется повторный обход страницы.
Чем Schema Markup Validator отличается от Google Rich Results Test?
Schema Markup Validator нужен для общей проверки структуры Schema.org. Он помогает анализировать типы, свойства и техническую корректность разметки независимо от конкретной функции Google.
Google Rich Results Test проверяет разметку с точки зрения поддерживаемых расширенных результатов Google. Поэтому при SEO-проверке инструменты лучше использовать последовательно.
Какие ошибки чаще всего встречаются в JSON-LD?
Чаще всего встречаются лишние запятые, неправильные кавычки, отсутствующий @context, ошибочный @type, неверный формат цены или даты, некорректные связи @id и дубли сущностей.
На сайтах с CMS дополнительно встречаются устаревшие значения, которые продолжают выводиться в структурированных данных после изменения видимого контента. Такие проблемы хорошо заметны при проверке рабочего URL.
Можно ли проверить несколько типов Schema.org на одной странице?
Да, одна страница может содержать несколько связанных сущностей. Например, WebPage может быть связана с Organization, BreadcrumbList и Article. Для сложной структуры часто используют @graph.
При этом сущности должны быть связаны логично и не противоречить друг другу. Если один объект повторяется несколько раз с разными значениями, нужно проверить источник каждого блока.
Нужно ли повторно проверять разметку после исправления?
Да, потому что одна правка способна изменить соседнюю часть JSON-LD или структуру вложенного объекта. После исправления нужно снова запустить валидатор и убедиться, что старые ошибки исчезли и новые не появились.
После публикации стоит проверить именно рабочий URL. Это помогает убедиться, что исправленный код дошёл до боевого сайта и не был изменён шаблоном или кэшем.
Заменяет ли JSON-LD Validator проверку в Google?
Нет. Общая проверка JSON-LD и тесты Google решают разные задачи. Сначала проверяют синтаксис и Schema.org markup, затем при необходимости запускают Google Rich Results Test.
Для уже индексируемого сайта данные дополнительно контролируют в Google Search Console. Такой порядок помогает разделить техническую validation и требования поисковой системы к конкретному типу результата.
Смежные услуги
Генератор FAQ Schema
Генератор FAQ Schema создаёт валидную FAQPage-разметку JSON-LD. Добавьте вопросы и ответы, скопируйте код и проверьте Schema.org онлайн.
Генератор Organization Schema
Бесплатный генератор Organization Schema: создайте JSON-LD разметку компании, добавьте название, логотип, адрес, контакты и sameAs, скопируйте код и проверьте его валидность.
Генератор BreadcrumbList Schema
Breadcrumb Schema Generator для создания JSON-LD разметки BreadcrumbList. Добавьте названия и URL, получите готовый код и проверьте его для Google.
Генератор Article Schema
Бесплатный генератор Article Schema: создайте JSON-LD для Article, BlogPosting и NewsArticle, скопируйте код и проверьте разметку перед публикацией.
Генератор Product Schema
Product Schema Generator онлайн: создайте JSON-LD микроразметку товара с ценой, наличием, брендом, рейтингом и Offer. Скопируйте код и проверьте его перед публикацией.
JSON-LD Validator помогает проверить синтаксис, Schema.org markup, свойства сущностей и связи между ними до публикации страницы. После исправления кода нужно повторно проверить рабочий URL и убедиться, что данные совпадают с содержимым сайта.
Вставьте JSON-LD в валидатор, запустите проверку и исправьте найденные ошибки перед публикацией. Для разметки, рассчитанной на расширенные результаты Google, дополнительно проверьте страницу через Rich Results Test.
Отвечаем в течение рабочего дня. Без рассылок и звонков «просто напомнить».
Посмотрит сайт сам, а не передаст менеджеру.
Подробнее: JSON-LD Validator – проверка Schema.org
Какие типы Schema.org можно проверять?
JSON-LD Validator используют для разных типов Schema.org markup. Среди распространённых вариантов – Organization, LocalBusiness, Product, Article, BlogPosting, BreadcrumbList, WebSite, WebPage, Service и VideoObject. Конкретный набор поддерживаемых проверок зависит от используемого валидатора.
Для каждой сущности нужен свой набор данных. Product Schema работает с товаром, предложением, ценой и доступностью, а Organization Schema описывает компанию. LocalBusiness дополнительно может содержать адрес и другие данные локального бизнеса. Article и BlogPosting требуют другой структуры.
Не нужно добавлять schema type только ради самого наличия микроразметки. Тип должен соответствовать реальному содержимому страницы, а значения в JSON-LD – информации, доступной пользователю.
JSON-LD Validator и Google Rich Results Test – в чём разница?
Schema Markup Validator и Google Rich Results Test решают разные задачи. Общий schema validator проверяет структуру Schema.org и помогает найти технические ошибки в разметке. Google Rich Results Test ориентирован на типы структурированных данных, которые Google использует для поддерживаемых расширенных результатов.
Поэтому корректный результат обычной validation не означает автоматическое появление rich snippet. Страница дополнительно должна соответствовать требованиям Google для конкретного типа результата, а сама поисковая система решает, показывать расширенное представление или обычный сниппет.
Когда использовать Schema Markup Validator?
Schema Markup Validator подходит для общей проверки структурированных данных. Через него удобно проверить используемые типы, свойства, синтаксис и структуру JSON-LD независимо от того, поддерживает ли Google расширенный результат для конкретной сущности.
Такую проверку удобно выполнять во время разработки, после изменения шаблона или при техническом SEO-аудите. Она помогает обнаружить проблемы в самой модели данных до перехода к проверкам, специфичным для отдельной поисковой системы.
Когда использовать Google Rich Results Test?
Google Rich Results Test используют, когда разметка создаётся для поддерживаемого Google расширенного результата. Проверку желательно выполнить перед публикацией, после исправления ошибок и ещё раз на рабочем URL после внедрения.
Результат теста нужно оценивать вместе с содержимым страницы. Даже технически подходящая разметка не должна содержать информацию, которой нет на самой странице или которая расходится с видимыми данными.
Может ли JSON-LD быть валидным, но не давать rich result?
Да. Валидная Schema.org-разметка подтверждает корректность структуры, но не гарантирует показ расширенного результата. Причиной может быть неподдерживаемый тип, недостаточный набор данных для конкретного search feature или несоответствие JSON-LD содержимому страницы.
На показ также влияет индексирование страницы и решение Google по конкретному результату поиска. Поэтому после исправления структурированных данных полезно проверить Google Search Console и дождаться повторного обхода страницы поисковым роботом.
Когда нужно проверять JSON-LD?
Проверять структурированные данные лучше после каждого изменения, которое может затронуть HTML, шаблон страницы или данные Schema.org. Это касается обновлений CMS, SEO-модулей, товарных шаблонов, переноса сайта и массовой загрузки контента.
Особое внимание нужно уделять изменениям, которые автоматически применяются к сотням URL. Ошибка в одном шаблоне способна сразу повлиять на весь раздел сайта.
Проверка нужна в следующих случаях:
- после первого внедрения JSON-LD и перед публикацией нового шаблона;
- после обновления CMS, темы или SEO-модуля, который генерирует структурированные данные;
- после переноса сайта, изменения домена или структуры URL;
- после массового обновления цен, наличия, рейтингов и других данных;
- после появления ошибок структурированных данных в Google Search Console;
- после изменений общего компонента, который формирует Schema.org для разных страниц.
После списка стоит проверить несколько страниц с разными наборами данных. Один успешно проверенный URL не гарантирует, что шаблон корректно работает для всех возможных вариантов содержимого.
Что проверить кроме валидности JSON-LD?
Технически корректный код нужно сравнить с самой страницей. Название, цена, адрес, изображение, автор и другие значения в JSON-LD должны совпадать с фактическими данными. Особенно внимательно проверяют поля, которые обновляются автоматически.
Дополнительно полезно убедиться, что страница индексируема, отдаёт правильный HTTP status, имеет корректный canonical и не закрыта через meta robots. Ошибка индексации не относится к JSON-LD, но может сделать дальнейшую работу со структурированными данными бессмысленной.
Соответствует ли микроразметка содержимому страницы?
Разметка должна описывать то, что действительно есть на странице. Нельзя указывать несуществующий рейтинг, другую цену, чужое название товара или сведения об организации, которые пользователь не может подтвердить по содержимому сайта.
Особенно часто расхождения появляются после изменения данных в CMS. Видимая часть страницы обновляется, а отдельный JSON-LD блок продолжает получать старое значение из другого поля или кэша.
Нет ли нескольких описаний одной сущности?
Несколько JSON-LD блоков на странице допустимы, когда они описывают разные связанные сущности. Проблема начинается, если одна Organization, Product или AggregateRating повторяется несколько раз и содержит разные значения.
При таком результате нужно проверить CMS, плагины и шаблон. Если разметка выводится автоматически, ручной дополнительный блок часто лучше убрать, чем поддерживать две независимые версии одной entity.
Корректно ли поисковик видит страницу?
После markup validation проверьте доступность URL для поискового робота, meta robots, canonical и статус ответа сервера. Затем убедитесь, что JSON-LD присутствует в итоговом HTML и не исчезает из-за ошибки рендеринга.
Если страница уже индексируется, состояние структурированных данных можно дополнительно контролировать через Google Search Console. Такой подход помогает отличить ошибку микроразметки от общей технической проблемы URL.
Что делать после исправления JSON-LD?
После исправления кода нужно повторно запустить валидатор JSON-LD. Затем стоит проверить рабочую страницу по URL и убедиться, что внесённая правка действительно попала в итоговый HTML, а старая версия не осталась в кэше или другом шаблоне.
Дальше порядок зависит от назначения разметки:
- Повторно проверьте JSON-LD после исправления ошибки.
- Откройте рабочий URL и убедитесь, что новая версия разметки уже опубликована.
- Сравните данные Schema.org с видимым содержимым страницы.
- Проверьте поддерживаемую Google разметку через Rich Results Test.
- После повторного обхода страницы контролируйте состояние в Google Search Console.
После проверки желательно сохранить причину ошибки и способ исправления в технической документации проекта. Это особенно полезно для шаблонных проблем, которые способны повториться после следующего обновления CMS.
Приоритет проверки
| Этап проверки | Приоритет |
|---|---|
| Синтаксис JSON | 100% |
| @context и @type | 100% |
| Schema properties | 90% |
| @id и @graph | 80% |
| Соответствие странице | 100% |
| Rich Results Test | 70% |
| Google Search Console | 70% |
Сначала нужно устранить ошибки, которые мешают корректно разобрать код, затем переходить к структуре Schema.org и проверке фактических данных. Rich Results Test и Search Console используются после базовой технической проверки.