Головна·Блог·Schema.org для SEO і GEO — 7 типів, реальні факти.

Експерт-гайд·6 хв читання

Schema.org для SEO і GEO — 7 типів, реальні факти.

Джерела й текст перевірено 11 жовтня 2026.

6 хв читання· ~1288 слів· опубліковано 26 травня 2026

Структуровані дані описують зміст сторінки: компанію, статтю, товар або застосунок. Вони можуть допомогти пошуку зрозуміти ці факти, але не гарантують позицій, розширеного результату чи AI-цитування. Почніть із типу сторінки, а не з найбільшого списку schema.

UPLIFY team

Performance & AI Marketing Agency

Опубліковано

26 травня 2026

tldr.json guide

коротка відповідь

Обирайте Schema.org за змістом сторінки. JSON-LD має повторювати видимі факти. Окремо перевіряйте словник і вимоги Google до розширених результатів; валідність не гарантує AI-цитування.

01Оберіть тип за задачею сторінки.

02Звірте JSON-LD з видимими фактами.

03Не перетворюйте команду на Person.

04FAQ rich results у Google припинено.

05Не додавайте сім типів усюди.

06Не вигадуйте ціну, рейтинг чи автора.

07Розрізняйте словник і вимоги Google.

$ _

Які 7 типів Schema.org розмітки потрібні для GEO?

Оберіть тип за задачею сторінки.
Звірте JSON-LD з видимими фактами.
Не перетворюйте команду на Person.
FAQ rich results у Google припинено.
Не додавайте сім типів усюди.
Не вигадуйте ціну, рейтинг чи автора.
Розрізняйте словник і вимоги Google.

Schema.orgJSON-LDBlogPostingFAQPageOrganizationProductSoftwareApplicationPersonBreadcrumbListWikidata

Зміст статті 13

Що таке Schema.org і де закінчуються обіцянки GEO

Schema.org — словник типів і властивостей для опису сутностей. JSON-LD — один із форматів цього опису; Google також підтримує Microdata та RDFa. Мікророзмітка не замінює доступний HTML, індексацію чи корисну відповідь покупцю.

Розрізняйте три питання: чи коректний JSON, чи правильний тип Schema.org і чи виконує сторінка вимоги конкретної функції Google. Навіть позитивний результат усіх перевірок не гарантує показу. Окремого обов’язкового AI-schema-стека для Google AI Overviews немає.

Сторінка	Доречний тип	Що звірити
Компанія	Organization	Назва, URL, контакти
Стаття	Article / BlogPosting	Автор, заголовок, дати
Питання й відповіді	FAQPage	Видимі питання та відповіді
Товар	Product + Offer	Ціна, валюта, наявність
Застосунок	SoftwareApplication	Функція, середовище, умови
Профіль експерта	Person	Реальна людина та роль
Шлях сторінки	BreadcrumbList	Назви, URL, порядок

Organization: компанія, а не набір ключів

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

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

Article і BlogPosting: автор та чесні дати

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

dateModified відповідає суттєвій зміні, а datePublished не переписують під кожний реліз. Посилання на автора допомагає його ідентифікувати. Не додавайте reviewedBy, сертифікації чи dateReviewed без реального підтвердження; це не спосіб автоматично отримати довіру.

FAQPage: питання для читача, не гарантований сніпет

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

Google припинив показ FAQ rich results 7 травня 2026. Тип FAQPage залишається у Schema.org, але обіцяти FAQ-блок у Google не можна. Немає універсального правила «від п’яти питань» або «50–70 слів»: кількість і довжину визначає задача читача.

Product і Offer: товар та умови продажу

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

SKU, GTIN або MPN додають із реальних даних, не вигадують. Відгуки й рейтинги повинні бути справжніми та відповідати правилам типу. Заборона self-serving ratings для Organization/LocalBusiness не означає, що всі товарні відгуки обов’язково мають походити з іншого сайту.

SoftwareApplication: застосунок, а не будь-яка послуга

Для вебзастосунку описуйте його фактичну функцію, назву, категорію й підтримуване середовище. SoftwareApplication походить від CreativeWork, а не є підтипом Product. Послуга команди з налаштування магазину не стає програмою лише через автоматизацію.

Для Google software-app rich result потрібні name, offers.price та справжній рейтинг або відгук за його правилами. Без них не фабрикуйте дані заради зеленого тесту. Коректний семантичний опис застосунку може не відповідати вимогам цього розширеного результату.

Person: реальна людина та перевірені ролі

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

Сертифікацію можна вказати лише за підтвердженням. Колектив чи компанію описують як Organization. Наявність Person сама по собі не підтверджує досвід, перевірку матеріалу або пріоритет у відповідях AI.

BreadcrumbList: зрозумілий шлях сторінки

Хлібні крихти показують місце сторінки у структурі: головна, блог, матеріал. Узгодьте назви й URL з реальною навігацією, використовуйте послідовні position. Не додавайте неіснуючі розділи лише для ключів.

Мовна версія має свої назви та доступні URL. Перевірте canonical і взаємні hreflang окремо: BreadcrumbList не замінює ці сигнали. На сторінці статті немає потреби описувати всі платформи магазину як товарні сутності.

sameAs і Wikidata: перевіряйте ідентичність

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

Не створюйте Wikidata-запис лише як SEO-посилання й не обіцяйте AI-цитування після його появи. Критерії Wikidata визначає сама спільнота; кількість публікацій у ЗМІ не є універсальним порогом. Редакційні вимоги UPLIFY наведено в політиці за посиланням нижче.

Як зібрати й перевірити розмітку без дублів

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

Перевірте JSON, словник у Schema.org Validator і підтримувані Google-функції в Rich Results Test. Потім звірте HTML та відрендерений DOM, зокрема дані з JavaScript, і URL Inspection. Запишіть URL, мову, тип, помилку, відповідального та дату повторної перевірки. Після зміни цін або шаблону перевіряйте знову.

Навчальний приклад JSON-LD

Приклад нижче — вигадана навчальна стаття на example.com, не дані клієнта й не готова розмітка для вашого сайту. Замініть факти на видимий зміст своєї сторінки; не вставляйте приклад без перевірки.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/guides/structured-data/#article",
  "headline": "Teaching example: structured data",
  "url": "https://example.com/guides/structured-data/",
  "author": {
    "@type": "Organization",
    "name": "Example editorial team",
    "url": "https://example.com/"
  }
}

Питання про Schema.org і JSON-LD

Що таке мікророзмітка Schema.org?

Це опис сутностей сторінки через стандартні типи й властивості. Наприклад, Product називає товар, Offer — умови продажу, Article — матеріал. JSON-LD є форматом цього опису, а не окремим набором SEO-правил.

Чи гарантує schema кращі позиції або GEO-цитування?

Ні. Розмітка допомагає описати зміст і може створити придатність до підтримуваних пошукових функцій. Правильний код не гарантує їх показу, підвищення позицій або згадки в ChatGPT, Perplexity чи Google AI Overviews.

Чим відрізняються Schema.org Validator і Rich Results Test?

Перший перевіряє структуровані дані за словником Schema.org. Другий орієнтується на підтримувані Google розширені результати. Тип може бути семантично коректним, але не мати такої функції. Жоден тест не перевіряє автоматично правдивість усіх фактів.

Чи потрібно розмічати всі сім типів?

Ні. Статті потрібні дані про статтю, авторів і її шлях; товарній сторінці — актуальний товар та пропозиція. FAQ додають за наявності видимих питань. Компанію й людей пов’язують за потребою, без дублювання сутностей.

Чи можна додати aggregateRating без відгуків?

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

Чи можна додавати JSON-LD через JavaScript?

Так, Google може обробляти динамічно додані структуровані дані. Перевірте відрендерену сторінку й URL Inspection, а не лише початковий HTML. Доступність для інших систем потрібно перевіряти окремо; їхні можливості не слід прирівнювати до Google.

Практичні перевірки поруч

Джерела й правила перевірки

Перевірити розмітку вашого сайту

Надішліть адресу сайту, пріоритетний ринок і завдання. Працюємо з магазинами, послугами, B2B та SaaS; погодимо склад перевірки й робіт без обіцянки цитувань.