Перейти до основного вмісту

Опубліковано: 24 лип. 2026 р.

·

Оновлено: 5 жовт. 2026 р.

· 9 хв читання
Інші мовні версії: Deutsch · English · Русский

Schema і JSON-LD для AI-пошуку: що розмічати та як перевіряти

Вісім груп Schema, відомості про компанію й автора, FAQ, товари та дані: впровадження в Astro, WordPress і Shopify без гарантій AI-цитування.

ON
Oleksandr Nikitin
Історія оновлень

Повний український переклад від 2026-10-05 поточної RU-редакції від 27 вересня 2026; збережено приклади, джерела та обмеження.

Schema і JSON-LD для AI-пошуку: що розмічати та як перевіряти

В описі послуги зазначений один фахівець, у коді — інший. Ціна товару вже змінилася, а розмітка зберігає стару. На око сайт має нормальний вигляд, але машина отримує суперечливі відомості. Додавання ще одного Schema-плагіна може посилити плутанину, якщо спочатку не знайти джерела даних.

Коротко: Schema описує об’єкти та їхні зв’язки, а JSON-LD — один зі способів записати ці відомості. Почніть із правдивого змісту й узгодженості даних. Валідна розмітка допомагає технічній інтерпретації, але не підтверджує компетенції автора та не гарантує цитати в AI-відповіді.

Canem Errant звіряє видимий матеріал із розміткою: хто надає послугу, хто написав статтю, коли змінився зміст і які умови діють. Результат такої перевірки — список конкретних розбіжностей та обмежена правка. Прогноз зростання видимості потребує окремого спостереження.

Що Schema повідомляє пошуковій системі

Звичайний текст розповідає про компанію та продукт. Структуровані дані позначають тип об’єкта й властивості: назву організації, автора статті, ціну пропозиції, адресу бізнесу. Кілька об’єктів можна зв’язати через сталі ідентифікатори @id, щоб не описувати одну компанію як різні сутності.

JSON-LD записує відомості окремо від візуальної верстки. Google підтримує його разом із Microdata та RDFa і зазвичай рекомендує JSON-LD за зручність реалізації та підтримки. Це вибір формату, а не доказ того, що будь-який AI-парсер обов’язково читає саме його. Як Google використовує структуровані дані.

RAG-система отримує відповідні документи перед складанням відповіді. Відомості про автора, компанію та період допомагають зрозуміти матеріал, але заявлена в коді кваліфікація залишається твердженням самого сайту. E-E-A-T не можна отримати, просто додавши посаду чи університет у поле JSON-LD.

Для AI-функцій Google спеціальна Schema не потрібна. Корисний зміст, доступність і звичайні вимоги Search продовжують діяти. Посібник Google з AI-пошуку. Ширший процес описаний у посібнику з GEO.

Вісім груп розмітки за змістом сайту

Вибирайте тип за фактичним об’єктом. Не потрібно додавати весь перелік на кожну сторінку: велика кількість JSON-LD не означає кращої якості інформації.

Organization: хто надає послугу

Укажіть правильну назву, сайт, логотип і підтверджені відомості про компанію. Один і той самий бізнес не має перетворюватися на різні організації в шаблоні через випадкові суфікси або стару правову форму. Джерело цих відомостей має бути зрозумілим редактору.

sameAs зв’язує об’єкт з адресою, яка однозначно позначає ту саму сутність. Це може бути чинний офіційний профіль. Посилання на будь-який відомий майданчик або чужу публікацію не стає підтвердженням ідентичності. Призначення sameAs у Schema.org.

Person: хто відповідає за матеріал

Ім’я, jobTitle, професійний профіль, hasCredential та alumniOf корисні, якщо відповідають реальним відомостям. Університет і сертифікат не заповнюють заради декоративної «авторитетності». Особливо уважно перевіряйте матеріал, який впливає на медичні, правові або фінансові рішення.

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

Article, BlogPosting і NewsArticle: що опубліковано

Розмітка статті зв’язує заголовок, автора, видавця та дати. datePublished відображає публікацію, dateModified — дійсну зміну. Щоденне оновлення дати без редагування створює хибне враження свіжості.

BlogPosting підходить для статті блогу; NewsArticle — для відповідного новинного матеріалу. Правильна категорія важливіша за спробу оголосити будь-який рекламний текст новиною. Перевірте, що автор і заголовок у розмітці збігаються з видимим матеріалом.

FAQPage: справжні запитання та відповіді

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

Google припинив показ FAQ rich results із 7 травня 2026 року. Наявність типу FAQPage у словнику не означає наявності колишньої функції видачі й не гарантує переваги в Perplexity або ChatGPT. Зміна Google Search.

HowTo: послідовність дій

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

Не перетворюйте список переваг послуги на інструкцію заради типу Schema. Семантичний опис процесу й підтримка конкретного rich result — різні питання. Зображення біля кожного кроку також не дає встановленого пріоритету в AI-відповідях.

Product і Offer: що продається та на яких умовах

Для каталогу перевірте назву товару, бренд, пропозицію, ціну, валюту й наявність. Кілька варіантів або ринків можуть мати різні умови; не можна передавати єдину ціну, яка не діє для вибраного товару.

aggregateRating допустимий лише за наявності відповідних реальних оцінок і дотримання правил використовуваної пошукової функції. Не можна вигадувати рейтинг заради зірок. Для магазину особливо важлива синхронізація: картка й розмітка мають отримувати актуальні умови з узгодженого джерела.

LocalBusiness: локальні відомості

Адреса, телефон, години роботи й назва мають відповідати реальному бізнесу. Порівняйте сайт, розмітку та фактичну картку Google Business Profile. Знайдену розбіжність потрібно спочатку з’ясувати: вона може відображати переїзд або різні підрозділи.

Мова власника бізнесу не визначає мови його покупців. Локальні відомості описують конкретне місце роботи, а не умовну географію, додану заради списку країн. Розмітка не створює офісу там, де його немає.

Dataset: власні дані

Dataset описує набір структурованої інформації. Для дослідження корисні метод, період, авторство й доступний експорт, якщо його можна публікувати. Один відсоток у рекламному абзаці не слід оформляти як великий дослідницький набір. Опис Dataset.

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

Три помилки, які варто виправити першими

Різна ідентичність компанії. Один шаблон використовує назву бренду, інший додає неіснуючу правову форму. Звірте фактичну назву та @id, потім виправте джерело генерації. Копіювання одного блока на всі URL без розуміння зв’язків може лише розмножити помилку.

Невідповідні sameAs. До списку потрапив закритий, чужий або видалений обліковий запис. Залиште адреси, які позначають саме компанію чи автора. Обов’язкової мінімальної кількості з трьох посилань немає.

Вигадана біографія автора. Посаду або освіту взяли з демонстраційного прикладу. Видаліть непідтверджене й оформіть реальну інформацію. Приклад коду — не дозвіл переносити чужу кваліфікацію в production.

Google вимагає актуальних відомостей і відповідності видимому змісту. Правильний синтаксис не виправдовує неправдивої ціни або рейтингу. Загальні правила структурованих даних.

Впровадження в Astro, WordPress і Shopify

Astro та інші системи з генерацією HTML

Розмітку можна формувати з даних статті або каталогу під час збірки, серіалізуючи її в JSON-LD. Перевіряйте отриманий HTML, а не лише об’єкт у вихідному коді. Збірка може підтвердити синтаксис, але не знає, чи правильна ціна та чи справді автор має сертифікат.

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

WordPress

Спочатку з’ясуйте, що вже виводять тема та встановлені плагіни, наприклад Yoast або Rank Math. Додатковий плагін, Schema Pro чи власний код через передбачений механізм сайту вибирають після перевірки прогалини, вартості та підтримки.

Custom JSON-LD не стає якіснішим автоматично. Якщо поточний плагін коректно описує матеріал, друге джерело може створити дублікати. Пряма зміна functions.php також потребує розуміння оновлень теми та способу відкату.

Shopify

Перевірте дані теми, застосунку та Liquid-шаблону в підсумковій картці товару. Зіставте варіанти, валюту, наявність і реальні оцінки. Застосунок може допомагати підтримці, але до купівлі потрібно зрозуміти, який конкретний недолік він усуває.

У разі зміни товару перевіряють і розмітку, і видимий інтерфейс. Сама наявність Product не підтверджує правильного передавання кожної пропозиції. Вартість рішення охоплює підтримку та ризик розбіжності джерел, а не лише підписку на застосунок.

Як виміряти результат

Почніть із початкового стану: які URL і запитання перевіряються, які об’єкти розмічені, де є розбіжності. Після обмеженої правки повторіть ту саму перевірку. Окремо фіксуйте згадку бренду, посилання на документ, перехід і відповідну заявку.

Серверний журнал показує звернення до URL, але не доводить читання JSON-LD, довіри моделі чи використання документа у відповіді. User-Agent можна підробити. Серверний менеджер рекламних тегів також не замінює журналу вебсервера; його завдання та дані відрізняються.

Server-side tracking допомагає організувати вимірювання подій за відповідного налаштування та згоди. Він не відновлює автоматично відсутнього джерела переходу й не встановлює ROI розмітки. Якщо одночасно змінилися текст, ціни та посилання, ефект не можна впевнено приписати лише Schema.

Короткий висновок, таблиця й цитата можуть полегшити читання матеріалу. Немає підтвердженого універсального «Fact Density Score», який нараховує Perplexity бали за жирні відсотки чи blockquote. Замість форматування заради передбачуваного алгоритму дайте читачеві метод, умови та джерело.

Два навчальні сценарії перевірки

Консультаційна послуга. На сайті є фахівець, організація та FAQ. Перевіряють відповідність авторства й відповідей; потім спостерігають посилання в однаковому наборі запитань. Завдання — усунути помилки та оцінити поведінку, без обіцянки цитування через три тижні.

Каталог меблів. Перевіряють варіант товару, валюту, поточну ціну, наявність і походження відгуків. Розмітка має описувати пропозицію, яку покупець справді може вибрати. Валідний Product не означає автоматичної рекомендації для покупця із зірками в AI-зведенні.

Три дії цього тижня

  1. Перевірити поточний HTML. Використати Schema Validator для словника та зв’язків, Rich Results Test — для підтримуваних Google функцій. Це різні перевірки; жодна не прогнозує AI-цитування.
  2. Звірити зміст. На трьох важливих послугах перевірити справжні FAQ, автора та відомості про компанію. Вибрати одну розбіжність, яку можна виправити й повторно перевірити.
  3. Зв’язати реальні об’єкти. Уточнити @id та чинні sameAs. llms.txt оцінити окремо за споживачем; він не потрібний як обов’язкове доповнення до кожної Schema.

Поширені запитання

Чи замінює Schema звичайне SEO?

Ні. Матеріал має бути корисним і доступним. JSON-LD описує зміст; спеціальна розмітка не є умовою AI-функцій Google.

Чи можна використовувати Microdata або RDFa?

Так, Google підтримує ці формати. JSON-LD часто зручніше підтримувати окремо від верстки. Вибирайте за системою сайту й вимогами потрібної функції.

Які типи важливіші для B2B-компанії?

Зазвичай спочатку перевіряють Organization, Person та Article, потім реальні FAQ або інші об’єкти за змістом. Набір визначається матеріалом, а не обов’язковим списком для всіх сайтів.

За скільки часу AI побачить оновлення?

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

Чи достатньо WordPress-плагіна?

Якщо підсумкова розмітка повна, правдива й узгоджена, плагіна може бути достатньо. Власний код потрібний для підтвердженої прогалини; він додає витрати на супровід.

Чому Perplexity не цитує мої FAQ?

Відсутність цитати не встановлює причини. Перевірте доступність, релевантність відповіді, джерела й технічні помилки. Виправлення JSON-LD не гарантує вибору вашого документа.

Чи може цитування збігтися зі зниженням кліків?

Так, користувач може отримати відповідь без переходу. Зіставте покази, переходи та заявки; сам збіг не доводить причинності. Не приховуйте істотних відомостей заради вимушеного кліку: поясніть, чому людині корисно відкрити повний матеріал.


Попередня GEO-перевірка допомагає помітити зовнішній сигнал. Для звірки змісту, розмітки та повторюваних відповідей обговоріть GEO-діагностику: з конкретними URL, запитаннями й перевірюваним результатом.

Де маркетингові дані перестали відповідати реальності?

Опишіть ситуацію: що показує реклама, що відбувається після заявки та якого результату ви очікували.

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

Як проходить GEO-діагностика Обговорити ситуацію
schema-markupjson-ldGEOAIstructured-dataseo