Structured data допомагають пошуковій системі точніше інтерпретувати сутності та тип контенту на сторінці.
Schema не замінює якісний контент і не гарантує розширений результат у Google, але створює більш зрозумілу машинну структуру сторінки.
Organization
На сайті компанії можна описати організацію:
- назва;
- URL;
- логотип;
- контакти;
- social profiles.
Бажано використовувати стабільний @id, щоб різні сторінки посилалися на одну сутність компанії.
Service
Для сторінок послуг можна використовувати тип Service.
Наприклад:
- розробка сайтів;
- UI/UX design;
- CRM integration;
- e-commerce development.
Service можна пов’язувати з Organization через provider.
BreadcrumbList
Для багаторівневої структури використовується BreadcrumbList.
Наприклад:
Головна → Послуги → Розробка сайтів.
Article / BlogPosting
Статті блогу можна описувати як Article або більш специфічний BlogPosting.
Типові поля:
- headline;
- image;
- datePublished;
- dateModified;
- author;
- publisher.
FAQPage
FAQ schema варто використовувати тільки тоді, коли питання та відповіді реально присутні на сторінці.
Не потрібно створювати прихований FAQ виключно заради structured data.
Не використовуйте нерелевантні типи
Не потрібно додавати:
- Product, якщо сторінка не є товаром;
- Review без реальних відгуків;
- LocalBusiness, якщо це не відповідає моделі бізнесу;
- Offer без реальної пропозиції.
Structured data повинні відповідати видимому контенту сторінки.
Перевірка
Після впровадження schema бажано перевіряти:
- синтаксис JSON-LD;
- правильність URL;
- @id;
- зв’язки між сутностями;
- помилки у валідаторах.
Поширені запитання
Чи покращує schema позиції напряму?
Schema сама по собі не є гарантією підвищення позицій.
Який формат краще використовувати?
Для більшості сайтів зручно використовувати JSON-LD.
Чи потрібно додавати schema на кожну сторінку?
Тільки ті типи, які реально відповідають змісту конкретної сторінки.