GEO для українського ecommerce: чесний плейбук замість міфів

Для інтернет-магазину «оптимізація під AI-відповіді» на практиці зводиться до чотирьох перевірних речей: сторінку можна просканувати, вона проіндексована, вона придатна до показу сніпета, а дані про товар і компанію машиночитні й збігаються з видимим текстом. Google прямо зазначає, що для появи в AI Overviews та AI Mode немає додаткових вимог чи спеціальних оптимізацій: сторінка має бути в індексі та мати право на показ фрагмента, при цьому ані індексація, ані показ не є обіцянкою платформи. Усе інше — звичайна робота з якістю сайту, фідом і структурою, яку варто робити незалежно від того, як зараз називається тренд.

Нижче — робочий порядок дій для власника або маркетинг-ліда: що перевірити, у якій послідовності впроваджувати, як міряти і що чесно сказати про межі вимірювання.

Коротко: що магазин реально контролює

Під вашим контролем:

• доступ роботів до потрібних розділів і відсутність випадкових заборон у robots.txt чи на рівні захисту від ботів;
• індексованість карток товарів і категорій, а не лише головної та блогу;
• превʼю-контролі nosnippet, data-nosnippet, max-snippet і noindex — Google описує їх саме як інструменти керування показом фрагментів;
• текстовий шар: ключова інформація має бути текстом, а не лише на банері чи у віджеті, який підвантажується скриптом;
• відповідність структурованих даних тому, що бачить людина на сторінці;
• актуальність даних у Merchant Center.

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

Міфи і що робити натомість

Багато бюджетів зараз витрачають на речі, які пошукова система відкрито називає непотрібними. У посібнику Google з оптимізації під генеративні функції пошуку сказано, що з погляду Google робота на GEO/AEO — це та сама SEO-робота, а низка популярних «AI-практик» не використовується взагалі.

Поширене твердження	Що відомо з документації	Що робити
Треба додати llms.txt	Google Search його не використовує	Не витрачати на це ресурс; тримати robots.txt і карту сайту в порядку
Потрібна спеціальна AI-схема розмітки	Окремої AI-схеми немає, структуровані дані не є вимогою для генеративних функцій	Використовувати звичайні типи Product та Organization там, де вони доречні
Текст треба різати на мікрочанки	Дрібне чанкування не є вимогою	Писати зрозумілими блоками з чесними підзаголовками
Контент треба переписати «під AI»	Переписування виключно заради AI зайве	Покращувати змістовність для людини
Корисно накрутити згадки бренду	Неавтентичні згадки не допомагають	Працювати з реальними майданчиками та відгуками
Треба згенерувати сторінку під кожен варіант запиту	Масштабовані сторінки під усі можливі варіації запитів названі проблемною практикою	Робити менше сторінок, але з унікальною, не типовою інформацією

Окремо про останній пункт. Google описує механіку query fan-out — коли один запит користувача розкладається на кілька пошукових підзапитів, а відповідь будується на витягнутих документах. Спокуса зробити по сторінці на кожен уявний підзапит зрозуміла, але саме такі масові тонкі сторінки документація й називає небажаними. Для магазину практичніший шлях — посилити наявні картки та категорії тим, чого немає в конкурентів: реальні розміри, сумісність, умови повернення, терміни доставки по Україні, обмеження гарантії виробника.

Послідовність аудиту

Порядок має значення: немає сенсу писати контент, якщо половина карток не в індексі.

1. Сканування

Перевірте, чи не заблоковані фасети, пагінація категорій і сторінки товарів. Окрема українська специфіка — захист від ботів і антифрод-стіни: вони часто налаштовані під людський трафік з України і можуть віддавати помилки роботам. Bing у своєму блозі зазначає, що robots.txt поважається, тож будь-яке зайве правило може прибрати сторінку з поля зору системи.

2. Індексація

Візьміть вивантаження всіх активних SKU і зіставте з покриттям індексу. Типові витоки: дублі під фільтрами, некоректна обробка відсутніх товарів та окремі мовні версії, що канонікалізуються самі на себе неправильно. Для тимчасово відсутнього товару зазвичай доцільно зберегти сторінку з відповіддю 200 і чесно показати статус. Для остаточно видаленого SKU рішення залежить від ситуації: 404 або 410, а за наявності справжньої заміни — релевантне перенаправлення.

3. Придатність до сніпета

Знайдіть шаблони, де колись поставили nosnippet або надто жорсткий max-snippet. Якщо сторінка не має права показати фрагмент, вона випадає з базової умови участі в AI-функціях.

4. Текстовий шар

Вимкніть JavaScript і подивіться на картку товару. Якщо характеристики, ціна, наявність і умови доставки зникають — це ризик. Google радить тримати важливий вміст у текстовій формі та підкріплювати його корисними зображеннями й відео, а не навпаки.

5. Дані фіду

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

Product: коли допомагає і де межа

Документація Google про структуровані дані для товарів формулює це стримано: розмітка Product робить інформацію про товар придатною до багатших варіантів показу в пошуку. Разом із фідом Merchant Center вона допомагає Google зрозуміти й звірити дані, а сніпети товарів і лістинги продавців можуть містити ціну, наявність, рейтинги, умови доставки та повернення.

Що це означає для магазину:

• розмітка й актуальний фід разом розширюють придатність до підтримуваних форматів і допомагають Google звіряти дані, але не обіцяють показу;
• дані в розмітці мають бути узгоджені з видимим вмістом — вигадана «стара ціна» або рейтинг без реальних відгуків створює ризик, а не перевагу;
• це не є свідченням того, що вас процитує AI-відповідь. Придатність до формату показу і факт показу — різні речі.

Практичне правило: спершу довести до ладу ціну, наявність, ідентифікатори та умови доставки й повернення, і лише потім розширювати розмітку додатковими властивостями.

Organization: одна сторінка, а не кожна

Рекомендації щодо розмітки Organization кажуть, що вона допомагає Google зрозуміти й розрізнити адміністративні дані компанії. Google радить розміщувати її на головній або на одній сторінці про компанію, а не дублювати на кожній, і брати найбільш конкретний відповідний тип — для магазину зазвичай OnlineStore.

Робочий набір властивостей добирають за фактичними даними компанії: name, alternateName, url, logo, contactPoint, sameAs, а address і telephone — лише коли вони справді існують, оприлюднені та доречні. Нічого не слід додумувати заради повнішої схеми. Для українських брендів alternateName корисний, коли назву пишуть і кирилицею, і латиницею, а sameAs — коли бренд має офіційні профілі в соцмережах чи на маркетплейсах. Водночас Google не обіцяє, що функції, які споживають структуровані дані, зʼявляться. Розмітка Organization не створює панель знань і не є кнопкою «зробити бренд відомим» — вона лише знижує двозначність там, де система вже намагається вас ідентифікувати.

Контент навколо реальних питань покупця

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

Дві межі, які варто тримати:

1. Унікальність, а не обсяг. Документація прямо радить унікальний, не типовий вміст — тобто те, що ви знаєте як продавець і чого немає в описі від постачальника.
2. Жодних дорвеїв. Сторінка «купити X у місті N» без реального відмінного змісту — це рівно та практика, від якої застерігають.

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

Внутрішні посилання та архітектура

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

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

Вимірювання: що видно, а що ні

Тут потрібна максимальна чесність із замовником.

Джерело	Що показує	Обмеження
Search Console	Трафік із AI-функцій включено у звітність	Немає окремого розрізу «скільки разів нас процитували»
Bing Webmaster Tools, AI Performance	Кількість цитувань, середню кількість цитованих сторінок, вибірку grounding-запитів, цитування по сторінках	Публічна попередня версія; стосується лише Bing/Copilot
Аналітика сайту	Поведінку й продажі	Не розділяє джерела AI-відповідей надійно

Google зазначає, що трафік із AI-функцій уже враховується у звітності Search Console. Bing пішов далі: панель AI Performance у публічній попередній версії показує, коли сайт цитують у відповідях Bing і Copilot, включно з вибіркою запитів та цитуваннями на рівні сторінок. Важлива обмовка від самого Bing: ці метрики не означають ранжування, авторитетність чи позицію. Для українського магазину Bing може бути не основним каналом, тож розглядайте цю панель як додаткову оглядову поверхню — місце, де можна побачити напрямок, а не як систему атрибуції для всього ринку.

Практичний висновок: ставте цілі в термінах, які реально вимірюються — індексоване покриття каталогу, частка карток із валідною розміткою та збігом із фідом, органічний трафік і виручка з нього. Кількість AI-цитувань у Google як KPI сьогодні не операціоналізується.

Дослідницький контекст

Поза документацією платформ існує академічна робота: GEO: Generative Engine Optimization, прийнята на KDD 2024. Автори пропонують дослідницьку рамку типу «чорна скринька» та власний бенчмарк GEO-bench, і фіксують, що вплив різних прийомів на видимість відрізнявся залежно від домену. Це корисний орієнтир для розуміння самої постановки задачі, але не опис того, як комерційні продукти ранжують чи цитують сторінки сьогодні. Використовувати її як обґрунтування конкретних правок на сайті клієнта без додаткової перевірки не варто.

Чого не варто обіцяти

• що розмітка Product або Organization забезпечить цитування, позиції, видимість в AI чи панель знань;
• що існують обовʼязкові «AI-файли» чи спеціальна схема;
• що можна назвати частку відповідей, у яких зʼявиться бренд;
• що індексація сама по собі означає показ.

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

Пріоритетний чекліст

1. Прибрати блокування сканування, зокрема на рівні захисту від ботів.
2. Звірити список активних SKU з індексованими сторінками, закрити витоки дублів і фасетів.
3. Перевірити превʼю-контролі: nosnippet, data-nosnippet, max-snippet, noindex — і зняти зайві.
4. Винести ключову інформацію картки в текст, доступний без виконання скриптів.
5. Синхронізувати ціну, наявність і назву між сайтом, розміткою та Merchant Center.
6. Впровадити коректну розмітку Product на всіх картках; жодних даних, яких немає на сторінці.
7. Додати Organization (тип OnlineStore) на одну сторінку — головну або «Про компанію» — з фактичними доречними властивостями; address і telephone не вигадувати, якщо таких публічних даних немає.
8. Зібрати реальні питання покупців і закрити їх на наявних сторінках замість створення нових масових.
9. Полагодити внутрішню перелінковку: категорія → товар, товар → доставка/повернення, матеріали → картки.
10. Налаштувати звітність: Search Console як основа, Bing AI Performance як додаткове спостереження, з письмово зафіксованими обмеженнями метрик.

Після проходження цього списку магазин матиме базову технічну придатність, узгоджені товарні дані та зрозумілі сторінки. Саме ці результати можна перевірити; факт і формат появи в AI-відповіді визначає платформа.

Пов’язані матеріали UPLIFY

• Послуга GEO-просування
• SEO/GEO-аудит
• Усі playbooks
• Редакційна політика