Home·Blog·GEO (AI-SEO) для інтернет-магазинів: Prom.ua, Horoshop, Shopify

Pillar — поглиблений розбір·26 хв читання

GEO (AI-SEO) для інтернет-магазинів: Prom.ua, Horoshop, Shopify

26 хв читання· ~5222 слів· опубліковано 12 травня 2026

Як підготувати каталог товарів до AI-пошуку: атрибути, Schema.org, FAQ, фід і перевірка citations для Prom.ua, Horoshop і Shopify. UPLIFY

UPLIFY team

Performance & AI Marketing Agency

Опубліковано

12 травня 2026

Як підготувати каталог товарів до AI-пошуку: атрибути, Schema.org, FAQ, фід і перевірка citations для Prom.ua, Horoshop і Shopify. UPLIFY

uplify.agency / geo-ai-seo-dlia-internet-mahazyniv-prom-ua-horoshop-shopify / tldr.json live

[01]chatgpt:: SEO-текст у картці не гарантує цитування в ChatGPT, Perplexity і AI Overviews.

[02]schema:: AI-пошук краще читає атрибути, Schema.org, FAQ і чіткі сутності.

[03]catalog:: Починайте не з усього каталогу, а з 5–10 SKU з попитом і маржею.

[04]feed:: Для Prom.ua важлива чистота імпорту, фіда й полів товару без дублювання.

[05]shopify:: Для Horoshop і Shopify критичні модифікації, варіанти й стабільні атрибути.

[06]citations:: Результат перевіряйте через citations, відповіді AI і зміни у видачі за 2–3 тижні.

[07]geo:: GEO не варто запускати там, де картки порожні, хаотичні або без реального попиту.

›_

Визначення

GEO — оптимізація контенту й даних магазину так, щоб AI-пошук міг коректно згадувати, порівнювати й цитувати товари.

AI-citation — згадка магазину, категорії або конкретного товару у відповіді ChatGPT, Perplexity, Gemini чи AI Overviews.

Schema.org — структурована розмітка сторінки, яка пояснює пошуковим системам тип сутності: товар, FAQ, інструкція, варіант товару.

FAQPage — тип розмітки для питань і відповідей, який допомагає AI витягувати короткі, перевірні фрагменти з картки або категорії.

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

Entity-проникання — закріплення бренду, категорії або товарної групи в зовнішніх джерелах і графах знань, зокрема Wikidata.

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

GEO для товарного каталогу — це підготовка даних так, щоб магазин міг потрапити у відповідь AI-пошуку: ChatGPT, Perplexity, Google AI Overviews та інших систем, які збирають відповідь із джерел, а не просто показують список посилань. Ціль тут не «підняти картку на 3 позиції». Ціль — зробити товар зрозумілим, перевіреним і структурованим, щоб AI мав підставу згадати його у відповіді.

Класична SEO-картка зазвичай тримається на title, description, H1, тексті категорії, внутрішніх посиланнях і комерційних ключах. Це все ще потрібно. Google Merchant Center вимагає якісні, точні й актуальні дані про товар, зокрема назву, опис, ціну, наявність, посилання та зображення: Google Merchant Center Help. Але для AI-citation цього мало.

AI-системі не потрібен «красивий» абзац про те, що рюкзак «ідеально підходить для активного способу життя». Їй потрібні факти, які можна розпізнати, порівняти й прив’язати до сутності:

атрибути: бренд, модель, матеріал, розмір, колір, вага;
характеристики: об’єм, сумісність, сезонність, гарантія;
сутності: бренд, категорія, серія, виробник, країна;
відповіді на типові питання: кому підходить, як обрати розмір, чим відрізняється від іншої моделі;

розмітка Product, Offer, AggregateRating, FAQPage, а для варіантів — коректна структура ProductGroup / Product, яку Google описує в документації для product variant structured data: Google Search Central.

Для магазину на Prom.ua, Horoshop або Shopify проблема зазвичай не в тому, що описи «недостатньо SEO». Проблема в тому, що каталог не має єдиної логіки даних. Частина характеристик живе в описі, частина — у фіді, частина — в модифікаціях, частина — у таблиці імпорту, яку заповнювали різні менеджери в різні роки.

У практиці UPLIFY ми бачимо це постійно: власник уже інвестував у SEO-тексти, категорії й мета-теги, але AI-пошук не цитує магазин, бо картка не дає стабільної структури. Для GEO важливі не красиві формулювання, а повторювані атрибути, однакові назви полів, нормальна розмітка й відповіді на реальні питання покупців. Це менш ефектно за «переписати весь каталог під AI». Зате саме з цього починається видимість у відповідях AI-пошуку.

SEO-текст може допомогти Google зрозуміти сторінку. GEO має допомогти AI зрозуміти товар як об’єкт: що це, кому підходить, чим відрізняється, які має параметри, які питання закриває. Для каталогу з 1000+ SKU це вже не копірайтинг. Це нормалізація даних.

Тому GEO не замінює SEO. Воно закриває інший шар роботи. title і description залишаються базою для пошуку, реклами й Merchant Center. Але AI-citation частіше з’являється там, де каталог має чисту структуру, стабільні сутності й машинно зрозумілі відповіді. Цього тижня варто не переписувати весь каталог, а взяти 5–10 товарів, вирівняти атрибути, FAQ і розмітку, а потім перевірити, чи починають ChatGPT або Perplexity підтягувати ці сторінки у відповідях.

Як AI-пошук читає товарні сторінки Prom.ua, Horoshop і Shopify

AI-пошук читає товарну картку не як покупець. Він витягує сутності: товар, бренд, категорію, характеристики, ціну, наявність, варіанти, рейтинг, питання й відповіді. Якщо ці дані є в структурованих полях або Schema.org, моделі простіше використати сторінку у відповіді. Якщо все заховано в абзаці на 900 знаків, шанс на цитування нижчий.

Класична SEO-картка зазвичай зроблена під індексацію: ключ у title, ключ у першому абзаці, ще кілька входжень у тексті. Для GEO цього мало. ChatGPT, Perplexity і AI Overviews легше беруть сторінку, де відповідь на запит покупця вже розкладена по полях:

brand: хто виробник;
category: до якої категорії належить товар;
material, size, color, weight: характеристики без рекламного шуму;
price і availability: актуальна комерційна інформація;
aggregateRating або відгуки: сигнал довіри, якщо вони реальні;
FAQPage: короткі відповіді на типові питання покупця;
HowTo: інструкція для вибору, монтажу, використання або догляду.

Google описує, що структуровані дані Product можуть передавати ціну, наявність, рейтинг, варіанти товару й інші властивості для пошуку. Для товарів із модифікаціями Google окремо рекомендує розмітку ProductGroup і Product, щоб зв’язати варіанти в одну товарну групу, а не плодити дублікати (Google Search Central: Product structured data, Google Search Central: Product variants).

Платформа впливає на те, де саме ламається структура. На Prom.ua магазин часто працює через масовий імпорт і фід, тому слабке місце — заповнення характеристик у правильних колонках, а не красивий опис. Prom.ua окремо описує імпорт товарів і вивантаження фіда для Google Merchant Center, тобто частина структури вже зав’язана на табличні дані, а не на текст картки (Prom.ua: імпорт товарів, Prom.ua: фід для Merchant Center).

Horoshop зручніший для роботи з каталогом, модифікаціями й шаблонами, але там теж потрібна дисципліна. Атрибути мають бути нормалізовані, а не записані в різних форматах на кожному SKU. Shopify дає більше технічної свободи через теми, метаполя, додатки та CSV-імпорт. Це плюс, поки є єдина модель атрибутів. Без неї свобода швидко перетворюється на хаос у даних.

У практиці UPLIFY ми не починаємо GEO з переписування всіх описів у каталозі. Спершу беремо 5-10 SKU, приводимо до ладу атрибути, Product schema, FAQPage або HowTo, а вже потім дивимося, чи сторінки з’являються в AI-відповідях. За нашим підходом перша AI-citation має з’явитися в межах 2-3 тижнів після структурування карток і роботи з entity-присутністю. Якщо цього немає, масштабувати зміни на 1000+ SKU зарано.

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

Діагностика каталогу: чому AI не цитує навіть сильний SEO-магазин

Сильний SEO-магазин може мати нормальні title, метаописи, тексти категорій і стабільний органічний трафік. Але для AI-пошуку цього мало. Якщо характеристики товару живуть тільки в абзаці опису, а не в полях, фіді або розмітці, модель бачить сторінку, але не отримує достатньо чіткий сигнал, що саме можна цитувати.

Аудит не треба починати з переписування 1000 карток. Почніть з питання: чи має каталог машинно читабельну структуру. Google у специфікації товарних даних описує обов’язкові й рекомендовані атрибути для товарів, бо пошукові системи працюють не тільки з текстом сторінки, а й з даними про товар: ціною, наявністю, брендом, ідентифікаторами, посиланням, зображенням, станом і категорією ^[1].

Перевірте 20–30 карток з різних категорій і випишіть, де факти про товар існують лише в описі:
матеріал;
розмір, вага, об’єм;
сумісність з моделями або серіями;
призначення;
гарантія;
комплектація;
виробник, бренд, серія, модель;
тип товару;
країна виробництва, якщо це впливає на вибір.

Якщо ці дані є в тексті, але відсутні як атрибути, фільтри, параметри, Product schema або фідові поля, для AI це слабкий сигнал. Особливо на Prom.ua і Horoshop: частина даних може бути заведена в адмінці, але не потрапляти нормально у вивантаження, шаблон картки або мікророзмітку.

Другий блок діагностики — сутності. AI-пошук краще цитує сторінки, де зрозуміло, що товар належить до конкретного бренду, категорії, серії, моделі й типу. Якщо в одній картці написано «насос», у другій «помпа», у третій «водяний агрегат», а в атрибутах немає стабільного типу товару, ви самі розмиваєте entity-сигнал.

Технічна частина не менш важлива. Перевірте, чи пілотні сторінки індексуються, не закриті в robots.txt, не мають конфліктного canonical, не дублюються через параметри URL і не віддають різну інформацію для користувача та краулера. Для товарів із варіантами окремо перевірте, чи не злипаються розміри, кольори або модифікації в одну сторінку без зрозумілої структури. Google окремо описує розмітку ProductGroup і Product для варіантів товару, бо різні модифікації мають бути пов’язані, але не змішані в одній картці без логіки ^[3].

У нашій практиці найкращий старт — контрольований пілот, а не великий редизайн каталогу. Беремо 5–10 SKU, чистимо атрибути, вирівнюємо назви сутностей, додаємо коректну мікророзмітку, перевіряємо індексацію й тільки потім дивимося, чи з’являються згадки в ChatGPT, Perplexity або AI Overviews. Якщо пілот не дає сигналу, масштабування лише розмножить помилку.

Як реструктурувати 5–10 пілотних SKU під AI-citation

Не починайте з усього каталогу. Для AI-пошуку це майже завжди слабкий старт: команда витрачає тижні на масове переписування 1000+ SKU, але потім не розуміє, які зміни вплинули на цитування. Краще взяти 5–10 товарів і зробити з них тестову групу. У кожній картці мають бути чіткі атрибути, корисні відповіді й контекст, який AI-системи можуть прочитати без здогадок.

Пілотні SKU не мають бути просто «популярними». Вибирайте товари, де є попит, маржа і реальний сценарій вибору. Не «будь-який стілець для кухні», а модель, яку порівнюють за матеріалом, висотою, навантаженням, сумісністю зі столом або стилем інтер’єру. AI частіше підхоплює сторінки, де є конкретні факти для відповіді, а не однаковий SEO-текст на 2000 символів.

Далі перепишіть характеристики у форматі фактів. Не «якісний матеріал і сучасний дизайн», а «підходить для теплої підлоги», «сумісний із кріпленням X», «не рекомендований для вулиці без накриття», «витримує навантаження до 120 кг». Google вимагає надавати точні й повні дані про товар у Merchant Center: ціну, наявність, ідентифікатори та властивості товару. Це описано у специфікації даних про товари Google Merchant Center.

FAQ-блок не варто писати з голови. Джерела поруч: питання з Prom.ua, чати менеджерів, коментарі в Instagram, пошукові запити, заперечення у дзвінках. Для одного SKU достатньо 4–6 питань. Формулювання мають звучати так, як питає покупець: «Чи підійде для ванної?», «Чим відрізняється 20 мм від 30 мм?», «Чи можна різати під розмір?». Такі відповіді AI може використати як фрагмент для рекомендації.

Для товарів, де є процес використання, додайте HowTo: підбір, монтаж, налаштування або догляд. Це не потрібно для кожної футболки чи чашки. Але для EVA-матів, фільтрів, будматеріалів, меблів, техніки, інструментів або запчастин HowTo-структура часто дає AI більше контексту, ніж класичний опис. Google Search Central описує Product structured data як спосіб передавати пошуку дані про товар, зокрема ціну, наявність, рейтинги й варіанти.

Після цього SEO-текст має стати коротшим. Не потрібні п’ять абзаців про «широкий асортимент» і «вигідну покупку». Залиште 600–1000 знаків, але зробіть їх корисними: що це за товар, для кого він, у яких сценаріях підходить, де є обмеження. Для AI-citation одна точна фраза про сумісність корисніша за десять речень про «ідеальне рішення для дому та бізнесу».

У нашій практиці з GEO-проєктами на Prom.ua і Horoshop найкращий темп такий: один тиждень на вибір і реструктурування 5–10 SKU, другий — на перевірку індексації, Schema.org, feed.xml і відповідей у ChatGPT та Perplexity. Якщо тестова група не дає ознак цитування, масштабувати зміни на весь каталог зарано. Спочатку треба зрозуміти, що саме AI не може прочитати: атрибути, FAQ, сутність бренду чи саму сторінку.

Як налаштувати Schema.org на Prom.ua, Horoshop і Shopify без ручного хаосу

Schema.org для каталогу на 1000+ SKU не має жити в полі «Опис товару». Це перший маркер хаосу: сьогодні менеджер вставив FAQPage у 20 карток, завтра інший менеджер змінив формулювання, післязавтра в половині товарів лишився старий блок із неактуальною гарантією. AI-пошук погано читає такі сторінки, а команда швидко втрачає контроль над даними.

Правильна логіка інша: Product schema має підтягуватися з атрибутів товару, варіантів, ціни, наявності, бренду, GTIN, MPN, фото й URL. Так її можна підтримувати на рівні каталогу, а не редагувати вручну в кожній картці. Google описує товарну розмітку як спосіб передавати структуровані дані про продукт: ціну, доступність, рейтинги, варіанти та інші властивості, а не як довільний SEO-текст у HTML-описі: https://developers.google.com/search/docs/appearance/structured-data/product

Для Horoshop і Shopify базове впровадження має йти через шаблони, метаполя і структуровані блоки. У Shopify додаткові поля під material, size, compatibility, use_case, faq_question, faq_answer краще винести окремо, а потім збирати з них JSON-LD у шаблоні товару. CSV-імпорт Shopify підтримує масове оновлення товарних даних, тому ці поля можна готувати пакетно, без відкривання кожної картки вручну: https://help.shopify.com/en/manual/products/import-export/using-csv

FAQPage краще генерувати з контрольованих блоків. Не з копірайтерського тексту в описі, а з окремих полів або модулів: питання, відповідь, група товарів, мова, статус публікації. Так ви не отримаєте 300 SKU з однаковим питанням «Як замовити?», коли AI-пошук шукає відповідь про сумісність, монтаж, розмір, матеріал або сценарій використання.

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

На Prom.ua свободи менше. Там не завжди можна точно керувати JSON-LD на рівні шаблону, тому опора має бути на те, що платформа реально дає масштабувати: коректні характеристики, групування товарів, FAQ у картках, чисту категорійну логіку, якісний імпорт і зовнішнє посилення сутностей. Якщо бренд, категорія або товарна лінійка не мають зрозумілих entity-сигналів поза Prom.ua, одна розмітка в картці не витягне GEO.

У практиці UPLIFY ми не починаємо з «додайте Schema.org на все». Це поганий план для великого каталогу. Спочатку нормалізуємо атрибути, потім збираємо Product, після цього додаємо FAQPage для пілотних SKU і лише в кінці тестуємо HowTo. Ручні правки в описах лишаємо для винятків. У великому каталозі винятки не масштабуються. Цього тижня достатньо вибрати 5–10 SKU, зібрати для них таблицю відповідності полів і перевірити, чи JSON-LD збирається з даних, а не з ручного тексту в описі.

Де GEO дає результат, а де краще не витрачати бюджет

GEO для каталогу має сенс там, де покупець не бере перший товар із полиці, а порівнює варіанти. AI-пошук добре працює із запитами на кшталт «який мат EVA вибрати для дитячої кімнати», «який генератор підійде для будинку 120 м²», «чим відрізняється керамограніт R9 від R11». У таких сценаріях модель шукає не красивий title, а зрозумілі характеристики, контекст застосування, обмеження, варіанти й підтвердження, що магазин справді пов’язаний із темою.

Найкращі кандидати для GEO — категорії, де є різниця в атрибутах:
техніка, інструменти, будматеріали, меблі, спортивне спорядження;
товари з модифікаціями: розмір, товщина, потужність, матеріал, сумісність;
продукти, де покупець ставить уточнювальні питання перед покупкою;
категорії з частими запитами «що краще», «як вибрати», «для чого підходить»;
товари, де Product, ProductGroup, Offer, FAQPage і HowTo можуть описати реальну різницю між SKU.

Google у документації Product structured data прив’язує розмітку до товарних сторінок, цін, наявності, рейтингів і варіантів, а не до SEO-тексту внизу картки: https://developers.google.com/search/docs/appearance/structured-data/product . Для варіативних товарів окремо описана логіка ProductGroup і Product, тобто групування модифікацій має бути машинно зрозумілим: https://developers.google.com/search/docs/appearance/structured-data/product-variants .

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

У висококонкурентних нішах одних карток теж мало. Якщо магазин продає генератори, автотовари, косметику, медичні товари або електроніку, AI має побачити entity-сигнали за межами сайту. Потрібні згадки бренду, категорійні гайди, огляди, профілі компанії, коректні дані в каталогах і, де доречно, прив’язка до Wikidata. Це не магія. Модель легше цитує магазин, який пов’язаний із темою в кількох незалежних місцях, а не тільки у власному feed.xml.

У практиці UPLIFY ми спершу дивимося не на обсяг каталогу, а на якість даних у пілотній групі SKU. Якщо атрибути порожні, FAQ виглядає вигаданим, а модифікації зведені до кольору в назві, GEO не треба запускати. Спочатку картки, структура категорій, Merchant Center і базова довіра до магазину. Тільки після цього має сенс говорити про AI-citations.

GEO не замінює SEO, Shopping Ads і Merchant Center. І не має замінювати. SEO приводить органічний попит, Shopping Ads ловить покупця в момент вибору, Merchant Center тримає товарні дані в рекламній екосистемі. GEO додає інший шар: допомагає магазину потрапляти у відповіді ChatGPT, Perplexity і AI Overviews, де класична позиція в SERP уже не є єдиною точкою входу.

Ми б не продавали GEO магазину, який не має нормального каталогу, чистого Merchant Center і базової структури категорій. Це дорогий спосіб замаскувати хаос. Але для магазинів із 1000+ SKU, сильними характеристиками й нішами, де покупець довго порівнює, GEO вже має комерційний сенс. Не як «нова SEO-кнопка», а як робота з даними, сутностями й довірою до каталогу.

Як перевіряти результат: citations, видимість і помилки після запуску

GEO-пілот не можна оцінювати за відчуттям «стало краще». Через 2–3 тижні після змін у 5–10 SKU треба дивитися не на загальний органічний трафік, а на конкретні citation-сигнали: чи згадує AI ваш товар, категорію, бренд або сторінку у відповіді, і в якому контексті.

Перевірка починається з набору запитів. Не беріть тільки очевидне «купити X». AI-пошук частіше відповідає на змішані запити, де користувач ще порівнює, уточнює характеристики або шукає критерії вибору.

Тестуйте мінімум 4 групи:
інформаційні запити: «як вибрати дитячий мат для спорту», «яка товщина EVA мату краща для дзюдо»;
комерційні запити: «де купити EVA татамі 20 мм в Україні», «найкращі мати для спортзалу 1×1 м»;
порівняльні запити: «Prom.ua чи окремий магазин для купівлі татамі», «EVA мат 20 мм чи 30 мм»;
entity-запити: бренд + товар, категорія + місто, виробник + матеріал.

Фіксуйте не тільки факт citation. Важливіше, яку роль отримала сторінка. AI може згадати магазин як продавця, джерело характеристик, приклад категорії або випадковий URL поруч із сильнішими конкурентами. Це різні сигнали. Перша згадка в списку рекомендацій і посилання внизу відповіді без контексту — не той самий результат.

Паралельно потрібна контрольна група. Візьміть 5–10 схожих SKU, де структура картки не змінювалась: ті самі категорії, близька ціна, схожий попит. Якщо пілотні SKU почали зʼявлятися в AI-відповідях, а контрольні — ні, це вже сигнал. Не доказ, що «GEO переміг», але достатня підстава масштабувати обережно.

Ми не радимо переносити GEO-зміни на весь каталог після одного вдалого прикладу. У нашій практиці спершу треба зрозуміти, що саме дало citation: атрибути, Schema.org, FAQ-блок, entity-зв’язки чи комбінація цих елементів. Інакше команда не масштабує рішення. Вона масштабує здогадку.

Технічну частину теж перевіряємо без романтики. Google описує, що структуровані дані Product мають передавати конкретні властивості товару, а для варіантів потрібна коректна модель ProductGroup / Product, а не хаотичне дублювання однієї картки під різними URL: Product structured data, Product Variant Structured Data. Для каталогу це критично: AI погано читає сторінки, де колір, розмір, матеріал і наявність лежать у різних місцях без стабільної структури.

Окремо звіряйте дані в картці з фідом. Google Merchant Center вимагає точних і актуальних даних про товари, зокрема ціну, наявність, посилання, зображення й атрибути ідентифікації: специфікація даних про товари. Якщо в feed.xml один матеріал, у картці інший, а в Schema.org третій, AI не буде здогадуватися, яка версія правильна.

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

Поганий результат — коли команда не може пояснити, що саме спрацювало або зламалось, і все одно запускає зміни на весь каталог. Цього тижня достатньо зробити просту річ: зібрати таблицю перевірки, прогнати 4 групи запитів і порівняти пілотні SKU з контрольною групою.

Погляд UPLIFY

Ми бачимо одну повторювану помилку: магазин переписує title і description, але лишає атрибути, модифікації, FAQ і Schema.org у стані «як вийшло після імпорту». У нашій практиці на 40+ запущених GEO-проектах на Prom.ua і Horoshop перша AI-citation часто з’являється за 2–3 тижні після правильного структурування карток і entity-проникання у Wikidata.

Не після SEO-тексту заради SEO-тексту. Після того, як AI може розібратися, що саме продає магазин, чим один SKU відрізняється від сусіднього і чому цьому джерелу можна довіряти.

Чек-лист дій

Виберіть 5–10 пілотних SKU.
Так ви перевірите гіпотезу без переробки всього каталогу на 1000+ товарів.
Приберіть дублікати назв, кольорів і розмірів у картках.
AI погано порівнює товари, коли один атрибут захований у трьох різних полях.
Звірте базові атрибути: бренд, модель, матеріал, розмір, колір, призначення.
Саме ці поля найчастіше стають опорою для відповіді AI-пошуку.
Перевірте GTIN, MPN і identifier_exists=false.
Помилки в ідентифікаторах ламають не лише Merchant Center, а й довіру до даних товару.
Оновіть короткі описи без рекламного шуму.
Потрібні факти: кому підходить, які параметри, які обмеження, як обрати.
Додайте FAQ до пілотних SKU або категорій.
Питання покупців дають AI готові фрагменти для цитування.
Налаштуйте Product, ProductGroup, FAQPage і, де доречно, HowTo.
Розмітка має відповідати реальному контенту сторінки, а не існувати окремо.
Перевірте імпорт і фід: feed.xml, CSV або платформний експорт.
Якщо джерело даних хаотичне, розмітка лише підсвітить хаос.
Додайте trust-сигнали поруч із товаром.
AI-пошук оцінює не тільки параметри товару, а й ознаки надійності магазину.
Протестуйте запити в ChatGPT, Perplexity і Google AI Overviews.
Перевіряйте не позиції, а те, чи згадується магазин у відповіді й поруч із якими конкурентами.
Зафіксуйте результат через 2–3 тижні.
GEO має сенс масштабувати тільки після появи citations або зрозумілої діагностики, чому їх немає.

FAQ

Чому магазин має SEO-трафік, але AI його не цитує?

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

Якщо в картці є довгий опис, але немає стабільних атрибутів, FAQ, коректної Product schema і зрозумілих модифікацій, AI може взяти конкурента з гіршим SEO, але чистішими даними. Тому GEO починається не з переписування тексту, а з діагностики структури каталогу. Цього тижня варто взяти кілька карток і перевірити, чи може людина без контексту швидко зрозуміти товар за характеристиками, а не за рекламним абзацом.

Чи треба переробляти весь каталог одразу?

Ні. Для магазину з 1000+ SKU це майже завжди зайвий ризик і зайвий бюджет на старті. Краще взяти 5–10 пілотних товарів: маржинальні, з попитом, зрозумілою різницею від конкурентів і достатньою кількістю питань від покупців.

На цих SKU можна перевірити атрибути, FAQ, Schema.org, фід, модифікації й перші AI-citations. Якщо за 2–3 тижні видно рух, шаблони масштабують на категорію або групу товарів. Якщо руху немає, причину простіше знайти на 10 SKU, а не в хаосі з 5000 карток. Практичний крок: вибрати пілотну групу й одразу зафіксувати, які запити, відповіді та citations будете перевіряти.

Що важливіше для GEO: текст опису чи характеристики?

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

Якщо ці дані винесені в атрибути, фід і Product schema, машина читає їх стабільніше. Добрий опис пояснює вибір і обмеження товару. Поганий опис повторює «якісний, надійний, зручний» і не додає факту. Для GEO такий опис майже марний. Цього тижня варто прибрати з пілотних карток порожні прикметники й винести фактичні параметри в поля характеристик.

Чи можна зробити GEO на Prom.ua без доступу до коду?

Можна почати, але з обмеженнями. На Prom.ua основний контроль часто йде через картку товару, атрибути, імпорт, групи характеристик і фід для Google Merchant Center. Якщо ці поля заповнені чисто, каталог уже стає зрозумілішим для AI й пошуку.

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

Чим відрізняється підхід для Horoshop і Shopify?

У Horoshop сильна сторона зазвичай у структурованій роботі з каталогом, модифікаціями, імпортом і товарними групами. Там важливо не зламати логіку варіантів і не дублювати атрибути в різних полях. У Shopify більше свободи через теми, apps, метафілди, CSV і кастомну розмітку, але саме через цю свободу легше створити хаос.

Для GEO різниця не в тому, яка платформа «краща». Різниця в доступі до полів, стабільності імпорту й можливості масштабувати Schema.org без ручної правки кожної картки. У нашій практиці найчастіше виграють не магазини з найбільш гнучкою платформою, а ті, де структура товарних даних не розвалюється після кожного імпорту. Цього тижня варто перевірити одну категорію: чи однаково названі атрибути, чи правильно зібрані варіанти, чи не живе частина важливих даних тільки в описі.

Як зрозуміти, що GEO вже дає результат?

Перший сигнал — магазин починає з’являтися у відповідях AI за комерційними або порівняльними запитами: «який товар обрати», «де купити», «порівняння моделей», «найкращий варіант для…». Другий сигнал — AI правильно називає категорію, товарні параметри й переваги без вигаданих деталей.

Ще один сильний сигнал — Perplexity або AI Overviews підтягують сторінку як джерело. Не варто оцінювати GEO лише через позиції в Google Search Console. Це інший шар видимості, тому потрібна окрема таблиця запитів, дат перевірки, відповідей і citations. Практичний мінімум: створити список із 20–30 запитів для пілотних SKU й перевіряти їх за однаковим сценарієм раз на тиждень.

Коли GEO для каталогу не має сенсу?

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

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

Чи треба додавати Wikidata для кожного магазину?

Не для кожного. Wikidata і зовнішні сутності доречні, коли бренд, виробник, товарна лінійка або категорія мають достатньо підстав для окремої сутності. Для невеликого магазину без публічної історії краще почати з чистого каталогу, сторінки «Про нас», контактів, політик, Merchant Center, структурованих даних і згадок у релевантних джерелах.

Entity-проникання не замінює якість картки. Воно підсилює її, коли AI вже має що читати на сайті. У практичному сенсі це означає просту послідовність: спершу навести лад у товарних даних, потім працювати із зовнішніми сутностями. Інакше Wikidata стає дорогим шаром поверх слабкого каталогу.

Джерела

Потрібна допомога?

Якщо потрібно не «додати SEO-текст», а підготувати каталог до AI-пошуку, UPLIFY може взяти на себе GEO-аудит, доопрацювання Horoshop і AI-контент для пілотних SKU. Починаємо з 5–10 товарів, а масштабуємо тільки після перевірки citations.