Як перевіряти структуровані дані без інструментів Google

Перевірка структурованих даних стала дивно залежною від інструментів, орієнтованих на Google. Це зрозуміло: багато команд додають JSON-LD, бо хочуть отримати розширені результати, а інструменти тестування Google добре знайомі. Але структуровані дані — це не формат Google. Зазвичай це JSON-LD зі словником Schema.org, вбудований в HTML, інтерпретований багатьма споживачами й підтримуваний вашим власним видавничим процесом.

Якщо перевіряти дані лише крізь призму пошукової системи, можна пропустити базові проблеми: некоректний JSON, дані, що зникають після рендерингу, застарілі ціни товарів, суперечливі canonical URL або розмітку, яка технічно коректна, але семантично безглузда.

Кращий робочий процес починається зі стандартів. Спершу перевіряйте дані як дані, потім словник, а потім сторінку такою, якою вона існує у продакшені.

Що саме ви перевіряєте?

“Структуровані дані” — це не одна річ. На більшості сайтів вони мають чотири шари:

1. Синтаксис JSON — чи можна розібрати код?
2. Модель JSON-LD — чи розгортається вона у змістовні пов’язані дані?
3. Словник Schema.org — чи є типи й властивості правдоподібними?
4. Правдивість на рівні сторінки — чи відповідає розмітка тому, що бачать користувачі й сканери?

Інструменти Google здебільшого зосереджені на четвертому шарі плюс на Google-специфічній придатності до розширених результатів. Корисно — так. Повно — ні.

Наприклад, це може бути коректним JSON-LD і водночас поганими структурованими даними:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Тут нічого не зламано. Але якщо видима сторінка має інший заголовок, не містить зазначення автора, а дата останньої зміни суперечить розмітці, це вже проблема якості, а не синтаксису.

Крок 1: Розберіть JSON, перш ніж думати про SEO

Почніть із нудної перевірки: чи можна розібрати JSON?

JSON-LD, вбудований в HTML, часто ламається через невеликі помилки в шаблонах:

• зайві коми в кінці
• неекрановані лапки в назвах товарів
• некоректні переноси рядків усередині рядків
• відсутні фігурні дужки після умовних полів
• дубльовані script-блоки через успадкування макета
• CMS-плагіни, що виводять неповні об’єкти

Для локальних перевірок вам не потрібна SEO-платформа. Використовуйте інструменти, які вже є у вашому стеку розробки.

У JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

У CI витягніть вміст script із відрендереного HTML і розберіть його як JSON. Це виявляє багато проблем до того, як вони потраплять у продакшен.

Головне: робіть це до будь-якої перевірки Schema.org. Валідатор словника не допоможе, якщо дані не є коректним JSON.

Крок 2: Перевіряйте поведінку JSON-LD, а не лише синтаксис JSON

Коректний JSON не є автоматично коректним JSON-LD. JSON-LD використовує такі поняття, як @context, @type, @id і зв’язки графа. Якщо вони сформовані неправильно, парсери можуть інтерпретувати ваші дані не так, як ви задумали.

Щонайменше переконайтеся, що:

• кожен блок має відповідний @context
• основні сутності мають чіткі значення @type
• повторювані сутності використовують стабільні значення @id, де це корисно
• вкладені сутності логічно пов’язані
• масиви використовуються там, де можливі кілька значень

Для більших сайтів стабільні ідентифікатори особливо корисні. Якщо ваша організація з’являється в даних Article, Product, BreadcrumbList і FAQPage, використання того самого @id допомагає споживачам зрозуміти, що це посилання на одну й ту саму сутність, а не на чотири непов’язані організації з однаковою назвою.

Типовий шаблон виглядає так:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Тут ви не намагаєтеся вразити валідатор. Ви робите свої дані менш неоднозначними.

Крок 3: Перевірте відповідність словнику Schema.org

Коли JSON і структура JSON-LD у порядку, перевірте словник.

Валідатор Schema.org корисний, бо перевіряє дані за термінами Schema.org, а не за правилами розширених результатів однієї пошукової системи. Він може показати, чи розпізнаються властивості, чи типи інтерпретуються очікувано і чи мають сенс ваші вкладені структури.

Саме тут можна виявити такі помилки:

• publishingDate замість datePublished
• imageUrl там, де очікується image
• розмітка Product на сторінці категорії, яка не є товаром
• AggregateRating без змістовного об’єкта оцінювання
• Person, використаний для брендового акаунта

Будьте обережні з попередженнями. Schema.org навмисно гнучкий. Валідатор може дозволяти властивість, яка не є корисною для вашого сценарію, або попереджати про щось необов’язкове. Сприймайте перевірку як свідчення, а не як вирок.

Практичне правило: якщо властивість допомагає машині точніше зрозуміти сторінку, залишайте її. Якщо вона існує лише тому, що хтось скопіював її з генератора фрагментів, поставте її під сумнів.

Крок 4: Порівняйте розмітку з видимим контентом

Пошукові системи та інші споживачі даних схильні не довіряти розмітці, яка не відповідає сторінці. Ще важливіше — користувачі заслуговують на узгодженість.

Для кожного типу структурованих даних порівняйте розмітку з видимою сторінкою:

Article і BlogPosting

Перевірте, що заголовок, автор, дата публікації, дата зміни, зображення й видавець є видимими або принаймні обґрунтовано виводяться зі сторінки. Якщо ви публікуєте контент за допомогою AI, ваші структуровані дані не мають використовуватися для відмивання нечіткого авторства. Ми окремо писали про чесне розкриття використання AI на невеликому сайті, і тут діє той самий принцип: метадані мають прояснювати, а не приховувати.

Product

Перевірте назву, ціну, наявність, валюту, варіанти, рейтинги й кількість відгуків. Структуровані дані товарів особливо схильні застарівати, бо ціни та статус наявності змінюються поза CMS.

LocalBusiness

Перевірте назву, адресу, номер телефону, години роботи й зону обслуговування. Якщо футер говорить одне, а ваш JSON-LD — інше, JSON-LD не є “кращим”. Він суперечливий.

BreadcrumbList

Перевірте, що позиції хлібних крихт відповідають видимому ланцюжку навігації, а URL є canonical, доступними для сканування й не перенаправляються без потреби.

Це не гламурна робота. Але саме тут знаходять багато проблем зі структурованими даними.

Крок 5: Перевіряйте відрендерену сторінку, а не шаблон

Багато сайтів генерують JSON-LD через JavaScript, tag managers, шари персоналізації або гідратацію компонентів. Це означає, що файл шаблону може не відображати того, що насправді бачить сканер або браузер.

Перевіряйте відрендерений HTML щонайменше у трьох станах:

• локальна збірка для розробки
• staging або preview URL
• production URL

Використовуйте browser DevTools, щоб оглянути фінальний DOM. Знайдіть application/ld+json і скопіюйте точний вміст script, який існує після рендерингу. Якщо server-rendered розмітка відрізняється від hydrated розмітки, вирішіть, яку версію мають читати споживачі.

Також перевірте, чи не дублюються структуровані дані. Дубльовані блоки Article або Product часто з’являються, коли CMS-плагін і кастомний компонент одночасно виводять schema. Дублювання не завжди фатальне, але суперечливе дублювання є проблемою: дві ціни, два автори, дві дати публікації або два canonical URL.

Це схоже на читання звітів про продуктивність і діагностику: перше завдання — не панікувати, а відділити сигнал від шуму. Та сама звичка допомагає, коли ви читаєте звіт Lighthouse без паніки — хоча самі структуровані дані не варто зводити до одного бала.

Крок 6: Перевірте продакшен-деталі передавання

Структуровані дані можуть бути ідеальними у вашому вихідному коді й усе одно не спрацювати у продакшені, якщо сторінка недоступна так, як ви припускаєте.

Перевірте:

• фінальний код статусу — 200, а не soft 404
• canonical URL відповідає сторінці, яку ви перевіряєте
• редиректи навмисні й стабільні
• директиви robots не блокують індексацію там, де вона очікується
• HTML не замінюється сторінкою помилки для деяких user agents
• кешовані сторінки не віддають застарілий JSON-LD

Саме тут важлива HTTP-інспекція. Якщо сторінка товару проходить через три URL перед тим, як дістатися canonical-призначення, перевіряйте фінальну сторінку, а не перший URL, скопійований із CMS. Для базової механіки корисним супутником буде наш гайд із налагодження редиректів і HTTP-заголовків у продакшені.

Структуровані дані не існують у вакуумі. Вони рухаються разом із заголовками, редиректами, кешуванням, canonical-тегами й директивами robots.

Крок 7: Додайте тести структурованих даних до процесу релізу

Ручна перевірка підходить для однієї сторінки. Вона не масштабується на сотні чи тисячі URL.

Простий набір автоматизованих тестів може виявити найдорожчі помилки:

• отримувати репрезентативні URL для кожного типу шаблону
• витягувати всі блоки JSON-LD
• розбирати їх за допомогою JSON.parse
• перевіряти обов’язкові поля для кожного типу сторінки
• перевіряти, що дати є коректними рядками ISO 8601
• перевіряти, що URL абсолютні й canonical
• перевіряти, що ціни й наявність існують для сторінок товарів
• перевіряти, що дубльовані сутності не конфліктують

Ви можете запускати це в CI для шаблонів і за розкладом для production URL. Мета не в тому, щоб довести, що кожна функція розширених результатів з’явиться. Ніхто поза пошуковою системою не може цього пообіцяти. Мета — підтримувати власні дані точними, придатними до розбору й узгодженими.

<!-- tool-cta:start -->

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

<!-- tool-cta:end -->

Чекліст перевірки з опорою на стандарти

Скористайтеся цим коротким чеклістом, перш ніж питати, чи подобається сторінка пошуковій системі:

• Чи кожен блок JSON-LD є коректним JSON?
• Чи кожен блок містить правильні @context і @type?
• Чи властивості Schema.org написані правильно?
• Чи відповідає розмітка видимому контенту?
• Чи актуальні дати, ціни, рейтинги й наявність?
• Чи URL абсолютні, canonical і досяжні?
• Чи відрендерена продакшен-сторінка є тією самою сторінкою, яку ви тестували?
• Чи дубльовані сутності навмисні й неконфліктні?

Якщо ви можете відповісти “так” на ці запитання, ви виконали стійку частину роботи зі структурованими даними. Пошуково-специфічне тестування все ще може бути корисним пізніше, але воно має бути фінальною перевіркою сумісності, а не основою вашого процесу валідації.