Google посилив правила відгуків: чи безпечні зірки вашого інтернет-магазину

24 липня 2026 року Google доповнив офіційну документацію Review snippet новою вимогою: на сторінках і в структурованих даних не повинно бути фальшивих або приховано стимульованих відгуків. Для власників інтернет-магазинів це означає, що перевіряти потрібно не лише тексти покупців, а й джерело середньої оцінки, кількість відгуків, статуси модерації, кеш і JSON-LD, який генерує тема або SEO-модуль.

Головне за одну хвилину

• Google не оголошував окремий апдейт алгоритму ранжування — було оновлено правила участі у review rich results.

• ratingValue, ratingCount і reviewCount повинні формуватися з реальних даних.

• Рейтинг із розмітки має бути помітним і доступним користувачеві на сторінці.

• Не можна переносити у власний AggregateRating оцінки з Google Maps, маркетплейсів або сайтів виробників.

• Бонус за відгук на власному сайті потрібно чітко розкривати біля конкретного відгуку.

• У Google Business Profile будь-яке стимулювання відгуків заборонене.

• Rich Results Test перевіряє код, але не підтверджує справжність відгуків.

Що саме змінив Google 24 липня 2026 року

Google додав до документації для структурованих даних Review і AggregateRating окрему вимогу щодо фальшивих та нерозкритих стимульованих відгуків. Під порушення потрапляють два основні типи контенту:

• відгуки, які не ґрунтуються на реальному досвіді використання товару або послуги;

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

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

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

Важливе уточнення

Наявність валідного JSON-LD ще не означає, що сторінка відповідає правилам Google. Код може пройти Rich Results Test, але містити вигаданий рейтинг, приховані відгуки або неправильне джерело даних.

Чому ця вимога важлива майже для кожного інтернет-магазину

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

Тема магазину може показувати одну кількість відгуків, стандартний модуль OpenCart — іншу, а SEO-розширення — формувати третє значення в JSON-LD. Якщо додати до цього кеш Journal, модифікатори OCMOD, мультимовність і декілька модулів мікророзмітки, на сторінці легко виникають суперечливі дані.

Наприклад, покупець бачить:

• середню оцінку 4,3;

• 12 опублікованих відгуків;

• два негативні коментарі.

А в JSON-LD Google отримує:

• ratingValue: 4.9;

• reviewCount: 47;

• лише п’ятизіркові відгуки.

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

Найнебезпечніші сценарії для магазину

1. Фіксований рейтинг 4,7–5,0 для всіх товарів

Деякі SEO-модулі мають налаштування на кшталт «рейтинг за замовчуванням» або «показувати зірки для товарів без відгуків». У результаті новий товар, який ще ніхто не оцінював, отримує в коді рейтинг 4,9 та умовні 20–30 відгуків.

Такий рейтинг не є середнім значенням реальних оцінок. Він створений програмно й не відповідає фактичному контенту сторінки.

Небезпечний приклад

{


"@type": "Product",
"name": "Новий товар без відгуків",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": 4.9,
"reviewCount": 27
}
}

Якщо товар не має реальних оцінок, безпечніше взагалі не додавати до нього блок aggregateRating.

2. Підрахунок неопублікованих відгуків

У базі даних можуть зберігатися:

• відгуки, які ще очікують модерації;

• тестові записи розробників;

• спам;

• дублікати;

• відхилені коментарі;

• відгуки, приховані через персональні дані або порушення правил.

Якщо SEO-модуль виконує підрахунок без перевірки статусу публікації, середня оцінка та кількість відгуків у JSON-LD не збігатимуться з видимим блоком.

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

Спрощений приклад перевірки для OpenCart

SELECT
product_id,
COUNT(*) AS review_count,
ROUND(AVG(rating), 2) AS rating_value


FROM oc_review
WHERE status = 1
GROUP BY product_id;

Цей запит не потрібно копіювати в робочу базу без перевірки структури. Він лише показує головний принцип: рейтинг має формуватися з опублікованих записів, а не з усієї таблиці.

3. Рейтинг є в коді, але відсутній на сторінці

Google вимагає, щоб розмічений контент був доступний користувачеві. Якщо в JSON-LD зазначено середню оцінку 4,6 на основі 18 відгуків, покупець повинен мати можливість побачити цей рейтинг і перейти до відповідних відгуків.

Проблемою можуть бути ситуації, коли:

• блок відгуків прихований через CSS;

• відгуки завантажуються лише після дії, яку Google не може відтворити;

• мобільна версія не містить рейтингу;

• відгуки доступні лише авторизованим користувачам;

• розмітка залишилася після вимкнення модуля відгуків;

• рейтинг видно лише в каталозі, але не на самій сторінці товару.

Вкладка, акордеон або кнопка «Показати відгуки» самі по собі не є проблемою, якщо користувач дійсно може відкрити контент на цій сторінці.

4. Загальний рейтинг магазину підставляється в усі товари

Оцінка компанії та оцінка конкретного товару — різні сутності. Не можна взяти середній рейтинг магазину, наприклад 4,8, і додати його до кожної картки каталогу як Product.aggregateRating.

Так само не слід використовувати:

• середню оцінку категорії як рейтинг кожного товару;

• рейтинг бренду як рейтинг усіх моделей бренду;

• загальну кількість відгуків магазину в кожній картці;

• рейтинг сервісу доставки як рейтинг товару.

Розмітка повинна стосуватися конкретного об’єкта, який користувач бачить на сторінці.

5. Імпорт оцінок з інших сайтів

Google прямо не рекомендує агрегувати у власному review snippet відгуки та рейтинги з інших вебсайтів. Це стосується оцінок із:

• Google Maps і Google Business Profile;

• Facebook;

• маркетплейсів;

• сайтів виробників;

• постачальницьких каталогів;

• сторонніх сервісів відгуків.

Сторонній віджет можна показувати користувачеві, якщо це дозволено правилами його власника. Але не варто включати ці оцінки до власного Product.aggregateRating і подавати їх як відгуки, зібрані вашим магазином.

6. Застарілий кеш після модерації

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

• сторінка товару;

• шаблон Journal;

• результат SEO-модуля;

• Redis або файловий кеш;

• CDN;

• модифікатори OpenCart.

Модерація відгуку повинна інвалідовувати всі кеші, які впливають на видиму оцінку та структуровані дані товару.

7. Два модулі одночасно генерують Product JSON-LD

У магазині нерідко працюють тема, SEO-модуль і окремий модуль мікророзмітки. Кожен із них може створювати власний об’єкт Product.

У результаті Google знаходить на одній сторінці:

• один товар із рейтингом 4,2;

• другий товар із рейтингом 4,9;

• різні значення ціни та наявності;

• різні назви або ідентифікатори товару.

Тому перевіряти потрібно весь вихідний HTML, а не лише налаштування одного модуля.

8. Плутанина між ratingCount і reviewCount

ratingCount доцільно використовувати для загальної кількості оцінок, зокрема оцінок без текстового коментаря. reviewCount описує кількість повноцінних відгуків.

Наприклад, товар може мати 35 оцінок, але лише 12 текстових відгуків. У такому разі передавати reviewCount: 35 буде неточно.

Приклад узгодженого AggregateRating

{


"@type": "Product",
"name": "Назва товару",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": 4.4,
"ratingCount": 35,
"reviewCount": 12,
"bestRating": 5,
"worstRating": 1
}
}

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

9. Відгуки варіантів автоматично розмножуються

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

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

Модуль повинен однозначно розуміти, чи належить оцінка:

• конкретній варіації;

• батьківському товару;

• усій сумісній товарній сім’ї.

Те саме правило має використовуватися у видимому інтерфейсі, базі даних і JSON-LD.

Бонус за відгук: коли виникає ризик

Нова вимога Google Search не формулює повну заборону будь-якої винагороди за відгук на власному сайті. Вона забороняє фальшиві та нерозкриті стимульовані відгуки.

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

Приклад зрозумілого розкриття

Автор отримав бонус за публікацію відгуку

Згадка дрібним шрифтом у загальних умовах акції не дає користувачеві достатнього контексту під час читання самого відгуку.

Безпечна механіка має відповідати декільком принципам:

• бонус надається за чесний відгук, а не за п’ять зірок;

• негативна оцінка не позбавляє покупця винагороди;

• магазин не вимагає змінити або видалити критичний коментар;

• факт стимулювання видно біля відгуку;

• відгук ґрунтується на реальному досвіді;

• правила акції пояснюють, як модерується контент.

Не плутайте відгуки на сайті з Google Business Profile

Для Google Maps і Google Business Profile діють суворіші правила. Там не можна пропонувати гроші, знижки, безкоштовні товари або послуги в обмін на будь-який відгук.

Тому небезпечно надсилати клієнтові повідомлення на кшталт:

Залиште відгук у Google і отримайте знижку 10% на наступне замовлення.

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

Що перевірити в OpenCart і PrestaShop

Окремо для OpenCart

У стандартних версіях OpenCart відгуки зазвичай зберігаються в таблиці review із прив’язкою до product_id та статусом публікації. Але встановлені модулі можуть використовувати окремі таблиці, додаткові поля або власну систему оцінювання.

Під час аудиту потрібно знайти:

1. контролер або модель, яка обчислює середню оцінку;

2. шаблон, що показує рейтинг покупцеві;

3. модуль, який генерує JSON-LD;

4. подію або механізм очищення кешу після модерації;

5. усі OCMOD-зміни, пов’язані з Product, Review та AggregateRating.

Окремо для PrestaShop

У PrestaShop структура залежить від модуля відгуків. Часто окремо зберігаються коментарі, оцінки, критерії оцінювання та статуси модерації. SEO-модуль може брати значення не з того джерела, яке використовується фронтендом.

Необхідно порівняти:

• дані модуля product comments;

• видиму оцінку в шаблоні товару;

• JSON-LD теми;

• розмітку стороннього SEO-модуля;

• кеш Smarty та кеш самої платформи.

Практичний технічний аудит сторінки товару

Крок 1. Перевірте товар без жодного відгуку

На такій сторінці не повинно з’являтися вигадане середнє значення. Знайдіть у вихідному коді:

• AggregateRating;

• ratingValue;

• ratingCount;

• reviewCount.

Якщо магазин не має оцінок цього товару, блок aggregateRating краще не генерувати.

Крок 2. Перевірте товар з одним негативним відгуком

Один опублікований відгук із оцінкою 2 повинен давати середню оцінку 2, а не мінімальне значення 4 або 4,5, задане SEO-модулем.

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

Крок 3. Змініть статус відгуку

1. Опублікуйте тестовий відгук.

2. Перевірте видимий рейтинг і JSON-LD.

3. Приховайте відгук через адмінку.

4. Очистьте або дочекайтеся автоматичного оновлення кешу.

5. Повторно перевірте сторінку.

Якщо відгук зник із фронтенду, але продовжує впливати на JSON-LD, логіка розмітки потребує виправлення.

Крок 4. Перевірте мобільну й десктопну версії

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

Крок 5. Порівняйте чотири джерела

• База даних: скільки реально опублікованих оцінок має товар.

• Сторінка: яку середню оцінку й кількість бачить покупець.

• JSON-LD: які значення отримує пошукова система.

• Search Console: чи немає помилок або ручних заходів.

Усі чотири джерела повинні описувати одну й ту саму реальність.

Крок 6. Перевірте сторінку в Rich Results Test

Інструмент допоможе знайти синтаксичні помилки, неправильні типи даних, відсутні обов’язкові поля та конфлікти розмітки.

Але він не визначить:

• чи справжній автор;

• чи купував він товар;

• чи був відгук написаний за гроші;

• чи приховує магазин негативні оцінки;

• чи вигадано значення 4,9;

• чи імпортовано рейтинг з іншого сайту.

Тому зелений результат тесту — це лише підтвердження технічної валідності, а не гарантія відповідності всім правилам.

Як правильно збирати більше відгуків

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

Надсилайте запит після виконання замовлення

Лист або повідомлення краще відправляти після того, як клієнт отримав товар і мав час ним скористатися. Текст має бути нейтральним:

Розкажіть, будь ласка, про свій досвід використання товару. Ваш відгук допоможе іншим покупцям зробити вибір, а нам — покращити асортимент і сервіс.

Не варто просити поставити п’ять зірок або звертатися лише до покупців, які вже повідомили, що задоволені замовленням.

Використовуйте токен доступу

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

Додайте позначку «Перевірена покупка»

Ця позначка не є обов’язковою вимогою для review snippet, але підвищує довіру та допомагає відрізнити реального покупця від спаму.

Дозвольте додавати корисні деталі

Хороша форма відгуку може містити:

• загальну оцінку;

• текстовий коментар;

• переваги й недоліки;

• фотографії;

• обрану модель, колір або розмір;

• строк використання;

• позначку підтвердженої покупки.

Такі відгуки корисні не лише для Google. Вони відповідають на реальні запитання покупців, зменшують сумніви й допомагають прийняти рішення про замовлення.

Поясніть правила модерації

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

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

Що зробити після виправлення модуля

1. Очистити кеш OpenCart або PrestaShop.

2. Оновити кеш модифікаторів OCMOD.

3. Очистити кеш теми Journal або Smarty.

4. Перевірити Redis, файловий кеш і CDN.

5. Відкрити сторінку в режимі інкогніто.

6. Переглянути вихідний HTML, а не лише DOM у DevTools.

7. Перевірити JSON-LD через Rich Results Test.

8. Перевірити URL через інструмент перевірки сторінок у Search Console.

9. Переглянути звіти про структуровані дані та ручні заходи.

10. Дочекатися повторного сканування сторінки Google.

Зміни у видачі не обов’язково з’являться одразу після виправлення. Google повинен повторно просканувати й обробити сторінку. Навіть повністю правильна розмітка не гарантує постійного показу зірок — пошукова система самостійно вирішує, коли використовувати розширений результат.

П’ятихвилинна перевірка для власника магазину

1. Знайдіть товар без відгуків.

2. Перевірте, чи немає в коді вигаданого AggregateRating.

3. Відкрийте товар із реальними відгуками.

4. Порівняйте видиму оцінку з ratingValue.

5. Порівняйте кількість відгуків із ratingCount і reviewCount.

6. Перевірте, чи не дублюється об’єкт Product.

7. Переконайтеся, що після модерації значення оновлюються.

Що це означає для власника інтернет-магазину

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

Аудит потрібен, якщо:

• SEO-модуль установлювали багато років тому;

• магазин не знає, звідки береться ratingValue;

• товари без відгуків уже мають зірки;

• оцінки імпортуються з маркетплейсів;

• відгуки модеруються, але рейтинг не змінюється;

• працює декілька модулів мікророзмітки;

• на різних мовах або магазинах показуються різні значення;

• у Search Console зникли review snippets або з’явилися попередження.

Головний принцип простий: користувач, база даних і пошукова система повинні бачити одну й ту саму оцінку, сформовану з одних і тих самих реальних відгуків.

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

Технічний аудит

Не знаєте, звідки ваш модуль бере рейтинг 4,9?

SiteZilla може перевірити модуль відгуків і мікророзмітку інтернет-магазину на OpenCart або PrestaShop. Знайдемо фіктивні значення, дублікати Product JSON-LD, неправильний підрахунок, проблеми зі статусами модерації та застарілий кеш.

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

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

Джерела

• Google Search Central — Latest documentation updates

• Google Search Central — Review snippet structured data

• Google Business Profile — Tips to get more reviews

• Google Maps — Incentivized or Biased Reviews

• EUR-Lex — Directive (EU) 2019/2161