Що таке JSON-LD Validator та що він перевіряє?
Валідатор мікророзмітки потрібний і тоді, коли JSON виглядає коректно. Код може успішно оброблятися як JSON, але містити невідповідний тип schema, відсутні властивості або дані неправильного формату. Тому перевірка Schema.org повинна враховувати структуру сутності, значення полів та відповідність розмітки вмісту сторінки.
JSON-LD Validator перевіряє код структурованих даних та допомагає знайти місця, які можуть заважати коректній обробці розмітки. У базову перевірку входять JSON syntax, @context, @type, schema properties, вкладені об'єкти та значення. Якщо розмітка містить кілька сутностей, окремо перевіряють зв'язки через @id та структуру @graph.
Schema validator корисний для Product, Organization, LocalBusiness, Article, BreadcrumbList, WebSite, WebPage та інших типів Schema.org. Набір необхідних властивостей і відповідних властивостей залежить від конкретної сутності. Тому не можна використовувати однаковий набір полів для всіх типів розмітки.
Перевірка синтаксису 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 виявлений і чи є критичні помилки. Потім перевірте повідомлення про відсутні властивості, неправильні формати значень і проблеми зі зв'язаними 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 вирішують різні завдання. Загальний validator schema перевіряє структуру 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 використовуються після базової технічної перевірки.