Безкоштовно · без реєстрації · миттєвий результат
Валідатор schema-розмітки — перевірте свій JSON-LD
Вставте URL будь-якої сторінки. Валідатор витягує кожен блок JSON-LD, відновлює граф сутностей і показує, що зламано — відсутні обовʼязкові властивості, автори, записані рядком, сутності, продубльовані замість звʼязування, одруківки в @type — із точним фіксом до кожної.
Читає серверний HTML однієї сторінки. Нічого не зберігається. Лише JSON-LD — розмітка, яку вставляє клієнтський JavaScript чи тег-менеджер, для цієї перевірки невидима.
Що саме перевіряє цей валідатор schema
Інструмент читає одну сторінку і оцінює структуровані дані на ній. Він не може перевірити, чи правда те, що розмітка стверджує, і ніколи не прогнозує rich result чи AI-цитування — ці рішення ухвалюють в іншому місці.
- Кожен блок
application/ld+jsonі чи він парситься - Обовʼязкові властивості за типами schema.org
- Рекомендовані властивості — окремим пунктом
- Ідентичність видавця — Organization, LocalBusiness або Person
- Звʼязки
sameAs, що підтверджують сутність - Адресацію через
@idі тихі дублі сутностей - Авторів і видавців, вказаних рядком замість сутності
- Одруківки і нерозпізнані значення
@type - Повноту BreadcrumbList
- Відносні URL у
url,@id,logo,image,sameAs - Які з наявних типів досі дають rich result у Google
- Чи відповідає розмітка видимій сторінці (це має оцінити людина)
- Schema, вставлену через JavaScript чи GTM (лише серверний HTML)
- Microdata і RDFa (виявляються, не валідуються)
- Чи зʼявиться rich result (Google вирішує щодо кожного запиту)
- Чи використовують вашу розмітку AI-двигуни (вендори цього не публікують)
- Покриття всього сайту (одна сторінка за запуск — див. повний аудит)
Як рахується оцінка
Десять зважених перевірок. Сторінка без придатного JSON-LD обмежується 10 балами, а будь-яка структурна помилка — 49, тож прохідне число ніколи не приховає зламаний граф. Довідкові нотатки — згорнуті rich-result типи, рекомендовані властивості — ваги не мають.
| Бали | Перевірка | Що має бути правдою |
|---|---|---|
| 18 | JSON-LD присутній і парситься | Щонайменше один блок application/ld+json із валідним JSON. Блок, який не парситься, не рахується взагалі. |
| 12 | Ідентичність видавця | Сутність Organization, LocalBusiness або Person із name, url і logo. |
| 12 | Звʼязки sameAs | Зовнішні профілі, що підтверджують, ким є сутність — для повного заліку два і більше. |
| 12 | Сутність рівня сторінки | Тип, який описує, про що ця сторінка. Загальні контейнерні типи дають частковий залік. |
| 12 | Обовʼязкові властивості | Кожна розпізнана сутність має все, чого вимагає її власний тип. |
| 10 | Автори як сутності | author і publisher — типізовані обʼєкти або посилання @id, а не голі рядки. |
| 8 | Адресація через @id | Повторювані сутності мають стабільні ідентифікатори і не дублюються мовчки. |
| 6 | BreadcrumbList | Присутній, із position, name та item на кожному рівні. |
| 6 | Розпізнані значення @type | Без одруківок — одруківка тихо знецінює сутність, на якій стоїть. |
| 4 | Абсолютні URL | url, @id, logo, image і sameAs містять схему і хост. |
Що структуровані дані справді роблять — і чого не роблять
Структуровані дані описують сторінку у формі, яку машина читає без здогадок. Вони повідомляють, хто опублікував сторінку, хто її написав, про що вона і як повʼязана з іншим, — словником schema.org, який споживачі вже розуміють. Google використовує їх, щоб розуміти сторінки і давати їм право претендувати на rich results, і прямо каже, що валідна розмітка не гарантує rich result і що структуровані дані самі по собі не є фактором ранжування. Жоден великий вендор AI-пошуку не заявляв про них як про вхід для ретривалу чи цитування, тож будь-яке твердження, що schema приносить AI-цитування, непідтверджене. Чесне формулювання вужче — і все одно вартісне: коректна розмітка усуває неоднозначність щодо ідентичності й авторства для кожного, хто захоче її прочитати, і зробити її правильно нічого не коштує.
Типи структурованих даних, які більше не дають rich results
Більшість порад про schema-розмітку старші за фічі, які вони рекомендують. Два широко поширені типи більше нічого не створюють у Google Пошуку — розмітка лишається валідною, прибирати її необовʼязково, але очікувати від неї пошукової фічі нереалістично.
| Тип | Статус | Чи варто лишати? |
|---|---|---|
| FAQPage | Rich result прибрано з Google Пошуку 7 травня 2026; документацію згорнуто 15 червня 2026 | Нешкідливо і досі валідна schema.org. Віддає чисті пари «питання-відповідь» будь-якому парсеру, тож лишається корисною як машиночитний контент — просто не як пошукова фіча. |
| HowTo | Прибрано з мобільної і десктопної видачі у 2023; rich result відсутній на всіх поверхнях | Та сама позиція: валідна розмітка, пошукової фічі немає. |
Валідатор показує обидва як нотатки і не знижує за них оцінку. Типи, які досі дають rich results — Article, Breadcrumb, Product, Review, Event, JobPosting, LocalBusiness, Organization, Recipe, Video та інші — перелічуються у вашому результаті, якщо присутні.
Типові помилки schema-розмітки і як їх виправити
Приблизно за частотою на реальних сайтах. Перші три пояснюють більшість зламаних графів сутностей.
- Автор — простий рядок. author: "Олена Ковальчук" називає людину, але не ідентифікує її — рядок не може нести ні URL, ні sameAs, ні ідентифікатора. Фікс: Використовуйте вкладений обʼєкт Person із url і sameAs або посилання @id на сутність Person, визначену один раз.
- Кома в кінці ламає весь блок. Один некоректний символ робить JSON нерозбірним, а блок, який не парситься, ігнорується повністю. Усі сутності всередині губляться тихо. Фікс: Перевіряйте блок як звичайний JSON на кожному деплої. Шаблонізатори додають зайві коми, коли цикл завершується раніше.
- Та сама Organization на кожній сторінці без @id. Без спільного ідентифікатора та сама компанія читається як новий непов’язаний обʼєкт на кожному URL, а не як одна сутність, згадана багато разів. Фікс: Оголосіть її один раз із @id виду https://example.com/#organization і скрізь далі посилайтесь на цей @id.
- Одруківка в @type. «Blogposting» чи «FAQpage» не є типами schema.org. Назви типів чутливі до регістру, і одруківка знецінює сутність без жодної видимої помилки. Фікс: Звіряйте кожен @type зі schema.org. Цей валідатор позначає все, чого не розпізнає.
- Відносні URL усередині розмітки. Структуровані дані споживаються поза сторінкою, тож «/logo.png» немає до чого резолвити. Фікс: Використовуйте абсолютні URL зі схемою і хостом для url, @id, logo, image і sameAs.
- Розмітка суперечить видимій сторінці. Рейтинг, ціна чи кількість відгуків у розмітці, яких немає на сторінці, — це порушення політики, а не лайфхак. Ризик ручних санкцій. Фікс: Розмічайте лише те, що відвідувач бачить на сторінці.
- Schema, яку вставляє тег-менеджер. Розмітка, додана клієнтським JavaScript, відсутня в серверному HTML, який читає багато парсерів, тож її можуть не побачити взагалі. Фікс: Віддавайте структуровані дані серверно. Якщо не можете — перевіряйте окремо в інструменті, що рендерить сторінку.
- sameAs на сторінки, які вам не належать. sameAs має звʼязувати сутність із профілями, що доказово є тією самою сутністю. Випадкові згадки радше послаблюють сигнал, ніж підсилюють. Фікс: Перелічуйте лише офіційні профілі: власні акаунти та авторитетні бази, де запис справді ваш.
Шаблони JSON-LD, які можна скопіювати
Пʼять відправних точок, усі структурно валідні. Замініть значення на власні — ніколи не лишайте заглушки в проді — і перезапустіть валідатор вище, щоб підтвердити, що блок парситься і звʼязується коректно.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Назва Компанії",
"url": "https://example.com/",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png",
"caption": "Назва Компанії"
},
"description": "Одне речення про те, що робить компанія і для кого.",
"foundingDate": "2019-03-01",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://github.com/example",
"https://www.crunchbase.com/organization/example"
]
}{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Заголовок статті, до 110 символів",
"description": "Одне-два речення, що підсумовують статтю.",
"datePublished": "2026-07-22",
"dateModified": "2026-07-22",
"image": "https://example.com/images/article.jpg",
"author": {
"@type": "Person",
"name": "Олена Ковальчук",
"url": "https://example.com/team/olena-kovalchuk/",
"jobTitle": "Керівниця досліджень",
"sameAs": ["https://www.linkedin.com/in/olena"]
},
"publisher": { "@id": "https://example.com/#organization" },
"mainEntityOfPage": "https://example.com/blog/the-article/"
}{
"@context": "https://schema.org",
"@type": "Product",
"name": "Назва товару",
"image": ["https://example.com/images/product.jpg"],
"description": "Що це за товар і для кого він.",
"sku": "EX-1001",
"brand": { "@type": "Brand", "name": "Example" },
"offers": {
"@type": "Offer",
"url": "https://example.com/products/example/",
"price": "149.00",
"priceCurrency": "UAH",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2026-12-31"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "127"
}
}{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Головна", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "Блог", "item": "https://example.com/blog/" },
{ "@type": "ListItem", "position": 3, "name": "Ця стаття" }
]
}{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"@id": "https://example.com/#business",
"name": "Студія Example",
"url": "https://example.com/",
"telephone": "+380441234567",
"address": {
"@type": "PostalAddress",
"streetAddress": "вул. Хрещатик, 12",
"addressLocality": "Київ",
"postalCode": "01001",
"addressCountry": "UA"
},
"geo": { "@type": "GeoCoordinates", "latitude": 50.4501, "longitude": 30.5234 },
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "09:00", "closes": "18:00"
}],
"sameAs": ["https://www.facebook.com/example", "https://www.instagram.com/example"]
}Чи гарантує валідна schema rich results або AI-цитування?
Ні в обох випадках. Google каже, що структуровані дані дають сторінці право претендувати на rich result і що це право не є гарантією — показ залежить від запиту і рішення Google. Для AI-двигунів позиція ще слабша: жоден вендор не заявляв про структуровані дані як про вхід для ретривалу чи цитування. Ідеальна оцінка тут означає, що ваш граф сутностей повний і внутрішньо узгоджений. Це цінно саме по собі — і це не механізм видимості. Розрив між коректною розміткою і реальним цитуванням вимірює AI Visibility Audit, і над ним працюють AEO і GEO.
Валідатор schema — FAQ
Що таке валідатор schema-розмітки?
Валідатор schema-розмітки завантажує сторінку, витягує її JSON-LD і перевіряє його на відповідність визначенням типів schema.org — чи є обовʼязкові властивості, чи сутності повʼязані замість дублювання, чи значення мають правильну форму. Цей також оцінює повноту від 0 до 100 і дає фікс до кожної знахідки. Він перевіряє розмітку, а не правдивість того, що вона стверджує.
Що таке JSON-LD?
JSON-LD — формат на основі JSON для вбудовування структурованих даних у сторінку, всередині тега script із type "application/ld+json". Саме його рекомендує Google, бо він лежить одним блоком окремо від видимого HTML, а не вплітається в розмітку, як microdata чи RDFa.
Чим це відрізняється від Rich Results Test від Google?
Rich Results Test відповідає на одне питання: чи претендує ця сторінка на rich result у Google. Цей валідатор відповідає на ширше: чи повний і внутрішньо узгоджений граф сутностей — ідентичність видавця, звʼязки sameAs, адресація через @id, автори як реальні сутності. Це важливо для машиночитності незалежно від того, чи існує rich result. Використовуйте обидва: вони перевіряють різне.
Чи покращує schema-розмітка позиції?
Google заявляв, що структуровані дані самі по собі не є фактором ранжування. Що вони справді роблять — усувають неоднозначність для парсера і дають сторінці право претендувати на rich results, а це може змінити вигляд сніпета і частоту кліків. Будь-яку заяву про прямий приріст позицій від schema вважайте непідтвердженою.
Чи гарантує schema-розмітка rich results?
Ні. Google прямо каже, що валідні структуровані дані дають сторінці право претендувати на rich result, але не гарантують його. Чи зʼявиться rich result, залежить від запиту, якості сторінки та рішення Google. Ви контролюєте право претендувати, а не показ.
Чи показуються ще FAQPage rich results у Google?
Ні. Google прибрав FAQ rich result із Пошуку 7 травня 2026 року і згорнув документацію 15 червня 2026. FAQPage лишається валідною schema.org, залишати розмітку не шкідливо, і вона далі віддає чисті пари «питання-відповідь» будь-якому парсеру — але пошукової фічі з неї не буде. Цей валідатор позначає це як нотатку, а не дефект.
Чи корисна ще розмітка HowTo?
HowTo більше не дає rich result на жодній поверхні Google — його прибрали з мобільної і десктопної видачі у 2023 році. Тип лишається валідним schema.org і далі описує процедуру машиночитно, тож тримати його не помилка, але пошукової фічі очікувати не варто.
Для чого потрібен sameAs?
sameAs звʼязує вашу сутність із зовнішніми сторінками, що описують ту саму сутність: офіційна сторінка компанії в LinkedIn, організація в GitHub, запис у Crunchbase чи Wikidata. Саме ця властивість перетворює назву й URL на щось, що парсер може звірити з уже відомими йому джерелами. Це найкорисніша окрема властивість для дисамбігації сутностей.
Що робить @id у JSON-LD?
@id дає сутності стабільний ідентифікатор, щоб на неї можна було посилатись замість повторювати. Оголосіть Organization один раз із "@id": "https://example.com/#organization", а далі скрізь пишіть "publisher": {"@id": "https://example.com/#organization"}. Без цього та сама компанія, описана на 200 сторінках, може читатись як 200 окремих обʼєктів.
Автор має бути рядком чи обʼєктом?
Обʼєктом. Рядок називає автора; обʼєкт його ідентифікує. Person із name, url, jobTitle і sameAs можна звести до реальної перевірюваної людини — саме це потрібно сигналу експертизи. Голий рядок не несе нічого, крім самих символів.
Скільки блоків JSON-LD має бути на сторінці?
Обмежень немає, кілька блоків — валідно. Важливо, щоб сутності між ними були звʼязані через @id, а не повторені в трохи різних формах. Багато сайтів роблять по блоку на кожну задачу — Organization, WebSite, сутність сторінки, хлібні крихти — і це нормально, доки посилання @id їх звʼязують.
Чи бачить цей валідатор schema, додану через Google Tag Manager?
Ні. Він читає серверний HTML, тож структуровані дані, які вставляє клієнтський JavaScript або тег-менеджер, для нього невидимі — як і для будь-якого парсера, що не виконує JavaScript. Якщо ви вставляєте розмітку так, перевіряйте її окремо в інструменті з рендерингом.
Чи перевіряє він microdata і RDFa?
Він виявляє їх і повідомляє про наявність, але валідує лише JSON-LD. JSON-LD — формат, який рекомендує Google і який реально перевіряти надійно. Змішувати формати на одній сторінці можна, але складніше тримати їх узгодженими.
Чи може некоректна schema нашкодити сайту?
Некоректну розмітку зазвичай ігнорують, а не карають — блок, який не парситься, просто не рахується. Нашкодити може розмітка, яка спотворює сторінку: рейтинги, ціни чи відгуки, яких відвідувач не бачить, порушують політику структурованих даних і можуть призвести до ручних санкцій.
Чи читають AI-двигуни структуровані дані?
Жоден великий вендор AI-пошуку не заявляв про структуровані дані як про вхід для ретривалу чи цитування, тож будь-яке конкретне твердження про це непідтверджене. Що можна сказати чесно: структуровані дані однозначно і машиночитно повідомляють, хто опублікував сторінку, хто її написав і про що вона, — і це прибирає здогадки для будь-якого споживача, який захоче їх прочитати. Це привід зробити їх правильно, а не доказ приросту цитувань.
Schema — одна з 47 перевірок.
Повний AI Visibility Audit оцінює доступ краулерів, llms.txt, entity-сигнали і живі AI-цитування поряд зі структурованими даними — звіт 0–100 на пошту менш ніж за хвилину.
Запустити безкоштовний AI Visibility Audit