Google почав підтримувати запити про місцеві компанії у двох блоках видачі для користувачів у Європейській економічній зоні: aggregator unit показує каталоги й сервіси порівняння, а supplier unit — компанії, які самі надають послугу.
Це не новий бейдж і не швидкий спосіб підняти позиції. За документацією Google, прямий постачальник може потрапити в блок завдяки даним, які робот уже бачить на сайті. Отже, бізнесу варто зробити зрозумілими й узгодженими реальні філії, послуги та шлях до запису, а не штампувати сотні порожніх сторінок міст.
Коротка відповідь: у локальній видачі ЄЕЗ можуть з’явитися два паралельні блоки
18 вересня 2026 року Google додав запити про місцеві компанії до документації про aggregator unit і supplier unit. Функція стосується користувачів у країнах ЄЕЗ. Блок прямих постачальників показується поруч із блоком агрегатора й не з’являється без нього.
| Роль | Типовий бізнес | Шлях до участі |
|---|---|---|
| Прямий постачальник | Окремий готель, клініка, ресторан, майстерня, магазин або виїзний сервіс | Окремий фід не обов’язковий: достатньо доступних для сканування даних сайту; фід постачальника може доповнити результат |
| Агрегатор | Каталог, маркетплейс, OTA, порівняльник або вертикальний пошук із багатьма виконавцями | Подати заявку як Vertical Search Service, пройти вимоги до якості й передати прямий фід або API |
| Лідогенератор | Сайт показує різних виконавців, але не виконує роботу сам | Не називати себе supplier автоматично; з’ясувати, хто укладає договір із клієнтом, і перевірити шлях агрегатора |
Google не обіцяє показ цих блоків за кожним локальним запитом, не гарантує включення й не називає спеціальної властивості schema. Важливе й місце користувача: компанія має обслуговувати аудиторію ЄЕЗ. Сам переклад сторінки чи згадка міста в ЄС не створюють реальної присутності.
Спочатку визначте комерційну роль, а вже потім змінюйте SEO
Маркетплейсу й компаніям у його каталозі потрібні різні системи. Агрегатор керує даними багатьох постачальників, свіжістю, дублями та якістю сторінок. Прямий постачальник відповідає за власну послугу, локацію, доступність і запис. Якщо змішати ролі, сайт даватиме хибні сигнали, а команда реалізує не той процес.
Для кожного домену й локації дайте відповідь на п’ять запитань:
- Хто приймає замовлення або укладає договір із клієнтом?
- Хто фактично виконує роботу й відповідає за ліцензію, страхування чи професійний результат?
- Сайт представляє одного постачальника, мережу під одним брендом чи незалежні компанії?
- Ціни, години та доступність контролює сам бізнес чи партнери через імпорт?
- Які країни ЄЕЗ і мови компанія справді обслуговує?
Якщо один бренд має кілька відділень, опишіть кожну справжню філію як локацію прямого постачальника. Якщо платформа порівнює незалежні компанії, дослідіть заявку для агрегатора та Local Point of Interest Feed. Не копіюйте каталог у псевдолокальні сторінки постачальника.
Зіставте докази на сайті, у Профілі компанії та в операційних системах
Новий supplier unit підсилює значення власного сайту, але не скасовує Профіль компанії в Google. В офіційній довідці основними чинниками місцевого рейтингу лишаються релевантність, відстань і помітність. Перевіряйте обидві поверхні як одну систему.
| Доказ | Умова проходження | Типова помилка |
|---|---|---|
| Ідентичність | Назва, основна категорія, телефон і сайт не суперечать одне одному | Ключові слова в назві профілю або різні бренди в каталогах |
| Локація | Справжня адреса чи зона обслуговування, країна й філія вказані точно | Віртуальний офіс, вигадана адреса або масові сторінки міст |
| Послуга | Пріоритетна послуга має змістовну сторінку з межами, винятками й процесом | Одна загальна сторінка або заміна лише назви міста |
| Години й доступність | Звичайний, святковий та аварійний графік відповідає реальній роботі | Статус «відчинено» суперечить календарю чи телефонній лінії |
| Конверсія | Дзвінок, форма, запис, маршрут і запит ціни працюють на мобільному | JS-кнопка без посилання, зламаний календар або форма без підтвердження |
| Довіра | Відгуки, ліцензії, команда, правила й ціни мають джерело та дату | Власні рекомендації позначені як оцінки клієнтів |
Створіть одне канонічне джерело для назви філії, адреси, зони, телефону, годин і URL запису. З нього оновлюйте сайт, профілі, CRM і перевірені каталоги. Йдеться не про однакову пунктуацію всюди, а про єдині факти без застарілих суперечностей.
Локальна сторінка має допомогти клієнту прийняти рішення
Прямому постачальнику зазвичай потрібна окрема індексована сторінка для кожної реальної локації. Сторінки послуг варто розділяти тоді, коли суттєво різняться потреба, докази чи шлях до замовлення. Корисна сторінка відповідає: що доступно саме тут, хто надає послугу, де межа виїзду, коли є вільний час, як формується ціна і що буде після звернення.
Для фізичної філії додайте повну адресу, маршрут, дані про безбар’єрний вхід чи паркування, якщо це доречно, локальний графік, телефон, власні фото, послуги, запис і місцеві правила. Для виїзного сервісу чесно назвіть зону роботи без фіктивного офісу. Поясніть доплату за дорогу, строк реагування й винятки.
Покажіть ці дані у видимому контенті та звичайних HTML-посиланнях. За правилами Google, доступне для сканування посилання зазвичай є елементом <a> з атрибутом href. Точка на мапі, вкладка чи JavaScript-обробник не повинні бути єдиним шляхом до сторінки. Кожна важлива URL має отримувати внутрішнє посилання, бути в sitemap, повертати стабільний статус 200 і відкриватися без авторизації.
Не підмінюйте роботу трьома короткими шляхами:
- Doorway pages: не створюйте «послуга в місті», якщо між сторінками змінюється лише топонім, а окремої операції немає.
- Непідтверджені заяви: слова «найкращий» чи «номер один» і вигадана доступність не допомагають ідентифікувати бізнес.
- Автопереклад без підтримки: публікуйте локаль лише тоді, коли команда може відповісти цією мовою й синхронізувати ключові факти. Використовуйте окремі URL та коректні мовні альтернативи.
Профіль компанії та LocalBusiness мають підтверджувати видимі факти
Підтвердьте кожен доречний Профіль компанії, оберіть найточнішу правдиву основну категорію та оновлюйте години, контакти, зону, фото й посилання на запис. Google прямо зазначає: повні й точні дані підвищують імовірність показу за релевантними місцевими запитами; купити кращу органічну позицію неможливо.
Додайте розмітку LocalBusiness на сторінку, де користувач бачить опис конкретної локації. Виберіть найточніший підтримуваний підтип, укажіть address лише для місця, куди справді можуть прийти клієнти, а також telephone, url, координати за потреби й openingHoursSpecification. Послідовно зв’яжіть локацію з материнською Organization. Перевірте відрендерений код і зіставте його з текстом сторінки.
Schema підтверджує контент, а не дозволяє додавати приховані твердження. Google радить використовувати review та aggregateRating для сайтів, які збирають відгуки про інші місцеві компанії, а не для власних рекомендацій бізнесу. Не додавайте поштову адресу до сторінки виїзного сервісу, якщо клієнтів там не приймають.
Вимірюйте зміни, не вигадуючи окремий звіт supplier unit
У документації Google немає оголошення про окремий фільтр Search Console для supplier unit. Тому зафіксуйте базову лінію й не приписуйте кожен рух одній функції.
- Збережіть 28 днів кліків, показів, CTR і landing pages для небрендових локальних запитів.
- Розділіть дані за країною ЄЕЗ, пристроєм, URL локації та групами запитів: послуга + місто, послуга + «поруч», бренд + філія.
- Окремо від органічних сесій сайту відстежуйте дзвінки, переходи, маршрути й записи з Профілю компанії.
- Передавайте ідентифікатор філії та послуги у форми й календар; зв’язуйте кваліфікований лід і дохід у CRM.
- Позначайте дати змін профілю, сторінки, schema й фіда. Порівнюйте однакові періоди з урахуванням сезонності.
Search Console приховує частину анонімних запитів, а average position не є сталою позицією для кожної людини. Результат залежить від часу, місця, пристрою та історії пошуку. Важливіші тренди кваліфікованих кліків, дзвінків і записів, а не один скриншот видачі.
План впровадження на 14 днів
- Дні 1–2 — роль і ринок: визначте supplier чи aggregator, реальні країни ЄЕЗ, філії, зони й мови.
- Дні 3–4 — джерело правди: звірте сайт, Профіль компанії, календар, CRM і каталоги; призначте власника й частоту оновлення.
- Дні 5–7 — сторінки: виправте або створіть справжні сторінки локацій і послуг із доступною навігацією, чіткими межами й робочою конверсією.
- Дні 8–9 — дані сутності: підтвердьте профілі, додайте LocalBusiness для кожної локації та перевірте відрендерований HTML.
- Дні 10–11 — якість: протестуйте мобільний контакт, доступність, мови, графік, свята та підтвердження запису.
- Дні 12–14 — вимірювання: створіть базову лінію Search Console, маркуйте ліди за філією й ведіть журнал змін.
Агрегатору потрібен окремий процес роботи з продуктом і даними: підтвердити відповідність VSS, подати форму Google, підготувати Local Point of Interest Feed, описати оновлення й видалення записів та вести кожен результат на змістовну сторінку компанії. Це не одноразове SEO-завдання.
Поширені запитання
Чи потрібен місцевій компанії окремий фід?
Не обов’язково. Для прямого постачальника Google не вимагає даних понад ті, що доступні пошуковому роботу на сайті, хоча supplier feed може доповнити результат. Агрегатор проходить заявку та інтеграцію фіда або API.
Чи гарантує LocalBusiness показ у supplier unit?
Ні. Розмітка допомагає зрозуміти видимі факти, але Google не гарантує включення й не описує спеціальної властивості для цього блока.
Чи достатньо Профілю компанії в Google?
Ні. Профіль має бути точним, але supplier unit може використовувати дані доступного для сканування сайту. Це дві поверхні однієї операції.
Чи може потрапити українська компанія?
Так, потенційно, якщо вона справді обслуговує користувачів у ЄЕЗ як прямий постачальник. Українська адреса чи переклад самі по собі не доводять цього — потрібна реальна філія або сервісна операція.
Чи варто створити сторінку для кожного міста?
Лише коли послуга, команда, локація, докази або шлях клієнта справді відрізняються. Масові сторінки з підставленою назвою міста не є корисним доказом.
Джерела й дата перевірки
Перевірено 24 вересня 2026 року за офіційними матеріалами Google: журнал оновлень Search, вимоги supplier unit, вимоги aggregator unit, поради для місцевого рейтингу, довідник LocalBusiness, вимоги до посилань і звіт ефективності Search Console. Стратегічний контекст звірено зі звітом McKinsey B2B Pulse 2026, де сайти постачальників і вебпошук входять до провідних каналів вибору.
Rendframe може провести аудит на рівні філій: дані сутності, доступність для сканування, локальні сторінки, schema, мультимовні маршрути та вимірювання лідів в одному плані релізу. Почніть з аудиту schema в початковому HTML, скористайтеся SEO-чеклістом міграції при зміні URL або надішліть домен і список локацій у ЄЕЗ, які ви справді обслуговуєте.