Мікророзмітка AggregateRating – як отримати зірочки у видачі

Я називаю зірочки у видачі найкоротшим шляхом до зростання довіри до кліку. AggregateRating – це структура зі schema.org, яка описує агреговану оцінку об’єкта: товару, послуги, місця. По суті, це спосіб передати пошуковику формулу «скільки оцінок + який середній», щоб отримати rich snippets рейтинг – візуальні зірочки поруч із вашим сніпетом у пошуку.

Типові сценарії використання прості:

• товари в інтернет-магазині (Product): картки й сторінки колекцій.
• Послуги (Service) та цифрові продукти (SoftwareApplication).
• LocalBusiness: сторінки філій, меню, прайс-сторінки. При цьому Google обмежує показ зірок для самих локальних сутностей: нижче розберу, як використовувати це з користю.
• Контент із колекцій: підкатегорії та плейлисти (якщо кожен елемент має власний об’єкт з відгуками).

Як Google відображає рейтинг у видачі

Розширені результати Google дотримуються чітких вимог. По-перше, тип сутності має підтримувати рейтинг (Product, Recipe, SoftwareApplication, Book, Movie та ряд інших). По-друге, дані мають бути достовірними: ratingValue — реальне середнє, reviewCount — реальна кількість відгуків, а самі відгуки доступні на сторінці або за кліком. По-третє, джерело має викликати довіру: унікальні, перевірні відгуки та прозора політика модерації.

Google частіше показує зірочки, коли:

• Тип сторінки — Product або рецепт, є зрозумілий блок відгуків, ratingValue і reviewCount узгоджені.
• Відгуки оновлюються регулярно й не виглядають синтетичними (надходять із crm, Prom.ua/Розетка, Google Business Profile, Trustpilot).
• Сторінка рендериться швидко, Googlebot бачить JSON-LD без тривалого очікування.

Агрегований рейтинг: кількість відгуків, значення рейтингу

Ключові поля schema.org AggregateRating:

• ratingValue, середня оцінка (десяткове число, наприклад 4.6). Рекомендується задавати точність до одного знака після коми.
• reviewCount – кількість оцінок (ціле число). Слід синхронізувати з реєстром відгуків.
• bestRating: максимальне значення шкали (часто 5). Якщо не вказати, частина валідаторів припускає 5.
• worstRating: мінімальне значення шкали (зазвичай 1).
• itemReviewed: посилання на об’єкт (Product, Service, LocalBusiness, SoftwareApplication тощо), до якого відноситься рейтинг.

Приклад AggregateRating у JSON-LD

Нижче — мінімальний валідний приклад для продукту з відгуками. Я використовую формат JSON-LD за його стійкість до змін верстки та підтримку Google.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Антисептичний гель для рук, 250 мл",
  "sku": "SKU-AG-250",
  "brand": {
    "@type": "Brand",
    "name": "CleanCare"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "author": {
        "@type": "Person",
        "name": "Олена"
      },
      "datePublished": "2025-01-18",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5",
        "worstRating": "1"
      },
      "reviewBody": "Зручний дозатор, запах нейтральний. Доставка Новою поштою прийшла на наступний день."
    }
  ]
}

Приклад схеми товару з агрегованим рейтингом

Продукт із AggregateRating вже розглянуто. Для LocalBusiness логіка інша: Google не заохочує self-serving відгуки для організацій та локального бізнесу на їхніх власних сайтах. На практиці це означає: рейтинг на сторінці філії часто залишається без зірок у видачі. Тому я застосовую стратегію розмітки рейтингів на рівні послуг/пропозицій, а не організації.

Приклад для сторінки послуги локального бізнесу:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "УЗД-діагностика",
  "provider": {
    "@type": "LocalBusiness",
    "name": "Медичний центр на Печерську"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "86",
    "bestRating": "5",
    "worstRating": "1"
  }
}

JSON-LD, Microdata або RDFa для зірок

Я рекомендую JSON-LD для AggregateRating з трьох причин:

• Простота впровадження та підтримки: не прив’язаний до HTML-структури, можна генерувати на сервері, через headless CMS або Shopify/WordPress плагіни.
• Підтримка Google: Rich Results Test стабільно зчитує JSON-LD навіть при динамічному рендерингу.
• Кешування та CDN: незалежний блок легко версіонувати, кешувати на рівні шаблону та CI/CD.

Як отримати зірочки у видачі

Крок 1. Джерело оцінок. Я починаю з інвентаризації: де зберігаються відгуки — CRM, інтернет-магазин, Prom.ua, Розетка, Google Business Profile, Trustpilot, власні форми? Маркетинг погоджує політику модерації й критерії якості даних, розробка налаштовує антифрод-тригери: верифікація e-mail/телефону, ліміти запитів (rate-limits), базова сигнатура кліків.

Крок 2. Генерація JSON-LD. Ми проєктуємо схему для Product/Service/SoftwareApplication, нормалізуємо ratingValue і reviewCount, додаємо об’єкти review. Для великих каталогів корисна автоматизація генерації AggregateRating через pipeline з БД і API маркетплейсів. Вставка: на рівні шаблонів сторінки, з версіонуванням.

Крок 3. Тестування. Я проганяю кожен шаблон через Rich Results Test і Schema Markup Validator, добиваюся відсутності критичних помилок. Попередження трактую зі здоровим глуздом: якщо поле опціональне, ми додамо його в наступному релізі.

Крок 4. Деплой і моніторинг. У CI/CD ми включаємо unit-тести для JSON-LD (снапшоти, регулярні вирази) і e2e-перевірки, а також логування помилок мікророзмітки. Після релізу відстежую появу зірочок у SERP і кореляцію CTR/CR.

Впровадження під час динамічного рендерингу

У проєктах на React/Vue я надаю перевагу server-side JSON-LD. У SSR-фреймворках (Next.js, Nuxt) ми вставляємо розмітку на сервері, щоб Googlebot бачив її без очікування рендерингу. При client-side рендерингу допомагає pre-rendering або динамічний рендеринг з видачею пререндереного снапшота для бота.

Мікророзмітка: перевірка та чек-листи

Я спираюся на чотири інструменти: Rich Results Test, Schema Markup Validator, застарілий Structured Data Testing Tool (для швидкої локальної перевірки) та звіт Structured Data у Google Search Console. Помилки валідації трактуються буквально: невідповідність типів, недопустимі значення, відсутність обов’язкових полів. Попередження: підказки щодо покращень.

Як виправити мікророзмітку рейтингу

причини відсутності зірок: мало відгуків (особливо 1–2, без реальних текстів), непідтримуваний тип, приховані відгуки, слабкий рендеринг для Googlebot. Для запобігання допомагає сувора валідація, моніторинг і чіткі правила агрегації. У кейсах з manual action ми чистили джерела, видаляли сумнівні відгуки, документували політику модерації: відновлення видимості повертало нормальний CTR протягом 2–8 тижнів.

Інтеграція відгуків і агрегація оцінок

Робоча архітектура виглядає так: прийом відгуків із форм і зовнішніх джерел (Google Business Profile, Trustpilot, Facebook Reviews, TripAdvisor, відгуки з Prom.ua/Розетка), нормалізація (єдина шкала 1–5), зберігання з аудитом змін і агрегація для schema. Фахівці BUSINESS SITE радять зберігати “сирі” дані та обчислювати агрегати на льоту або за розкладом для прозорості.

Масштабування та автоматизація каталогу

Архітектурно допомагає кешування (in-memory/Redis), CDN для статики та версіювання структурованих даних. Якщо даних немає – вмикаємо fallback-логіку: не відображаємо AggregateRating і пропонуємо альтернативні CTA (підписка на відгук/питання про товар). Для Shopify/WordPress використовуємо плагіни як базу, додаючи кастомні хуки для синхронізації та нормалізації.

Резервна логіка при відсутності відгуків

Коли відгуків немає, я рекомендую:

• Не відображати AggregateRating, натомість показувати соціальне підтвердження: «Оцініть товар першим», гарантії ПриватБанку/Монобанку, швидкість доставки Новою поштою.
• Вести версіювання схеми: зберігати попередню валідну версію та можливість відкату при помилках агрегації.
• Планувати тригер для сповіщення маркетингу: «товари без відгуків» і пріоритети збору.

Моніторинг зірок у результатах пошуку та аналітика

Я налаштував три рівні моніторингу:

• Google Search Console: відстежую розширені результати та помилки структурованих даних.
• Сторонні SERP-трекери та періодичні сканування Screaming Frog з експортом JSON-LD.
• Логи змін: коли, для яких SKU оновився reviewCount/ratingValue.

Google не показує зірки після схеми

Моя послідовність перевірки така:

• Валідатор структурованих даних і Rich Results Test, відсутність помилок.
• Відповідність правилам Google: підтримуваний тип, відсутність self-serving для LocalBusiness.
• Достатня кількість реальних відгуків і збіг reviewCount з інтерфейсом.
• Відсутність дублів та конфліктів з canonical.

Діагностика через Google Search Console Structured Data швидко вкаже, у яких шаблонах проблема. Поширені рішення: прибрати другу розмітку (Microdata), вирівняти ratingValue із фактичним середнім, видалити непідтримувані поля, синхронізувати дати та джерела, очистити розмітку від відгуків, які порушують політики. Якщо отримано manual action, я готую документ з виправленнями, політикою модерації і прошу перегляду: практика BUSINESS SITE показує, що чітка, чесна аргументація прискорює зняття санкцій.

Безпека даних і шахрайство

Організація робіт у компанії

Карта ролей:

• Маркетинг: збір та стимулювання відгуків, політика модерації, комунікація з платформами (Prom.ua, Розетка, Google Business Profile).
• Розробка – генерація та валідація JSON-LD, CI/CD, логування помилок розмітки.
• SEO – стратегія типів schema, пріоритизація сторінок, моніторинг rich results.
• Юридична служба: відповідність законам про рекламу та захист даних.
• Служба підтримки: первинна верифікація відгуків.

Шаблони для розробників і маркетингу

Шаблон JSON-LD для продукту:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Назва товару",
  "sku": "SKU-XXXX",
  "brand": { "@type": "Brand", "name": "Бренд" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "57",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Шаблон JSON-LD для сторінки послуги локального бізнесу:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Назва послуги",
  "provider": { "@type": "LocalBusiness", "name": "Назва філії" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "93",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Приклад виправлення помилки «різні ratingValue у розмітці та інтерфейсі»: ми перенесли розрахунок середнього в один модуль, синхронізували округлення до одного знака та прибрали Microdata, залишивши JSON-LD, зірки з’явилися через 5–10 днів.

Часті запитання

Висновок і заклик до дії