Як підготувати фід товарів для ChatGPT Shopping (вересень 2026)

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

Що змінилося і яке єдине рішення це нав'язує

OpenAI випустила моделі ChatGPT 5.6 9 липня 2026 року. Наступного дня частка рекомендацій ChatGPT Shopping, узятих із фідів товарів продавців, а не з відкритого вебпошуку, стрибнула з 8,26% до 61,54%, згідно з дослідженням, опублікованим Profound, яке відстежило 1 757 723 запити на покупки в ChatGPT протягом липня 2026 року. За один день вибірка на основі фідів перетворилася з другорядного джерела на домінантне.

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

Те, що нав'язує цей напрямок, це єдина зміна рамки: дані про товари тепер мають бути правильними як дані, а не лише як контент. Гарно написана сторінка товару з відсутньою контрольною цифрою GTIN для рекомендаційної системи на основі фідів це рядок, який не пройшов перевірку.

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

Визначте, у якій ви смузі

Робочий процес розділяється на дві смуги, і вам потрібно знати свою до початку, бо це змінює те, що означає «готово» для вас. Смуга A може довести вибірку. Смуга B може довести лише готовність. Обидві створюють той самий файл.

Тест доступу з чотирьох пунктів

Дайте відповідь на кожен чесно.

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

Смуга A: доступ до фіду підтверджено

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

Смуга B: доступу немає, і ось що не втрачено

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

Якщо ви на Shopify, дані про товари потрапляють у ChatGPT через Shopify Catalog без додаткової роботи з боку продавця. Прямий фід потрібен для свіжості та для полів, яких не несе типове налаштування. Одне застереження: другорядне джерело датує цю синдикацію березнем 2026 року, і дата не підтверджена, тож ставтеся до неї як до теми для розмови, а не як до факту для планування.

Відчиніть двері для сканера, який читає ваші товари

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

Відкрийте свій robots.txt і перевірте директиви для агентів OpenAI. OAI-SearchBot це той, що має значення для видимості товарів. Якщо його заблоковано, ваш контент не з'явиться в результатах товарів ChatGPT, яким би чистим не був ваш фід. Він не використовується для навчання моделей, тож блокування нічого не захищає.

Чотири імені агентів, щодо яких варто ухвалити явне рішення:

Найважливіша перевірка якості тут не `robots.txt`. А те, чи може дозволений сканер справді щось прочитати, коли прийде. Отримайте показовий URL товару з користувацьким агентом цього сканера й огляньте тіло відповіді. Якщо ви отримуєте оболонку застосунку без заголовка, ціни, наявності чи опису, згенерованих на сервері, сканування вдається і не повертає нічого корисного. Багато вітрин генерують дані про товари лише на клієнті, і ці магазини невидимі для виявлення без фіду, хоч би що казав їхній файл robots.

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

Шлях відновлення. Якщо robots.txt заблокований вашою платформою чи агенцією, зафіксуйте запит на зміну з датою і рухайтеся далі. Крок стає доказом для вашого запису в смузі B, а не перешкодою.

Зробіть сторінки товарів машинозчитуваними

Фід це не єдиний шлях до рекомендацій щодо покупок, і для продавців у смузі B він зараз недоступний узагалі. Структуровані дані на сторінці доступні.

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

Додайте щонайменше name, description, image, SKU, brand і блок offers, що несе price, валюту ціни та наявність. Віддзеркалюйте значення, які ви поклали б у фід. Там, де у вашому каталозі є GTIN, condition, material, color, size або розміри, додайте і їх, бо саме ці атрибути справді використовують розмовні запити.

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

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

Перепишіть описи під розмовні запити

Це крок, на якому SEO-дисципліна активно шкодить вам.

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

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

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

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

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

Складіть контракт полів, перш ніж торкатися рядка

Тепер до самого фіду. Перш ніж щось експортувати, запишіть один раз, що означає «правильно». Це перетворює аудит на механічний прохід, а не на суперечку.

Дев'ять обов'язкових полів і де кожне ламається

Кожному рядку потрібні ці дев'ять. Ця таблиця і є контрактом.

Два пункти заслуговують наголосу, бо вони тихо зазнають невдачі й забирають із собою цілі товарні лінійки.

Поле availability приймає рівно п'ять значень. Пропущені, порожні або нерозпізнані значення відхиляють рядок. Якщо ваша платформа експортує IN STOCK, або available, або 1, усі ці рядки зазнають невдачі. Зіставте свій внутрішній словник із п'ятьма прийнятними значеннями явно, а все, що не вдається зіставити, спрямуйте в ручну чергу, а не ставте типово unknown. unknown це законне значення, але це свідомий стан, а не смітник.

Поле price це сума, пробіл, а потім код валюти великими літерами. Тобто 79.99 USD, не 79,99 $, не 79,99 USD і не 7.999e1. Без розділювачів тисяч, без експоненційного запису.

Правила, які тихо відхиляють рядки

Ще чотири обмеження, які варто вписати у ваші перевірки валідації:

GTIN. Рівно 8, 12, 13 або 14 цифр, включно з правильною контрольною цифрою. ISBN-10 не приймається. Зберігайте провідні нулі, а це означає тримати стовпець текстовим усюди, де він проходить. Це найпоширеніший тихий руйнівник у всій специфікації, бо електронні таблиці й експорти CSV типово зрізають провідні нулі.

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

Довжина заголовка. Орієнтуйтеся на 150 символів або менше. Коли обрізаєте, обрізайте на межі слова.

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

Свідомо визначте прапорці відповідності

Три прапорці контролюють те, що станеться з рядком після валідації.

Ви також можете зустріти їх як enable_search, enable_checkout і is_eligible_ads. Це псевдоніми, тож не вважайте шаблон зі старішим написанням іншим полем.

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

Які необов'язкові групи вмикати і в якому порядку

Існує приблизно п'ятдесят необов'язкових полів. У порядку віддачі на годину роботи, а не в порядку специфікації:

1. Варіанти (group_id, listing_has_variations, variant_dict, offer_id, gtin, mpn). Найвищий пріоритет, якщо ви продаєте одяг, взуття, товари для дому або будь-що з розміром чи кольором.
2. Інформація про товар (condition, product_category, material, color, size, gender, age_group, а також поля розмірів і ваги). Саме це змушує працювати розмовне зіставлення.
3. Медіа (additional_image_urls).
4. Повернення (accepts_returns, return_deadline_in_days, return_policy).
5. Відгуки (review_count, star_rating), а також store_review_count і store_star_rating на рівні магазину.
6. Виконання, продавець і географія (shipping_price, shipping, seller_url, target_countries, store_country).
7. Поля, що потребують налаштування. marketplace_seller, size_system, accepts_exchanges, is_digital, пара для реклами (is_ads_eligible, ads_metadata) і пара для оформлення замовлення (is_eligible_checkout, seller_privacy_policy, seller_tos) усі потребують підтвердження під час онбордингу. Вони не самообслуговувані. Залиште їх поза першим проходом.

Перевірка якості. Кожне з дев'яти обов'язкових полів має зіставлятися зі стовпцем каталогу, який дає реальні дані щонайменше на 95% ваших SKU. Поля нижче цього порогу це не завдання зіставлення, а рішення про джерело даних.

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

Який формат файлу вам насправді дозволено надсилати

Використовуйте формат, який OpenAI підтверджує для вашого зареєстрованого фіду під час онбордингу. Крім цього, існує шлях, сумісний із Google, який приймає файли .txt або .tsv з розділенням табуляцією в UTF-8, або .csv з розділенням комою, з підтримкою gzip для .txt.gz, .txt.gzip, .tsv.gz і .csv.gz.

JSON, електронні таблиці, XML, RSS і Atom на цьому шляху сумісності не підтримуються. Використовуйте один формат для всього завантаження, а не змішуйте формати рядок за рядком.

Нормалізуйте чотири поля, які ламають найбільше рядків

Візьміть один заморожений експорт

Експортуйте один раз, поставте на файл мітку часу й обчисліть хеш. Кожен наступний крок виконується на цьому замороженому файлі. Відтворюваність це те, що робить аудит захищеним через три тижні, коли хтось запитає, чому бракує SKU.

Чотири нормалізації

Провідні нулі GTIN. Експортуйте стовпець як текст, потім перевірте, що кількість цифр 8, 12, 13 або 14, і перевірте контрольну цифру. Саме тут живе більшість тихих збоїв.

Форматування ціни. Приберіть розділювачі тисяч, збережіть десяткову крапку, видаліть будь-який експоненційний запис і додайте код валюти окремим токеном. Пропустіть результат через регулярний вираз, який приймає лише ^\d+\.\d{2} [A-Z]{3}$, а решту поставте в чергу.

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

Очищення заголовків і описів. Обрізайте заголовки на 150 символах на межі слова. Приберіть розмітку з описів і обмежте 5 000 символами звичайного тексту.

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

Шлях відновлення. Якщо ці нормалізації виконує ваша платформа фідів або PIM, провалідуйте її вихід тими самими перевірками, а не довіряйте її повідомленню про успіх.

Перевірте кожен рядок і ведіть список винятків

Тепер запустіть перевірки по всьому файлу. Це крок, який перетворює каталог на план роботи.

Дев'ять механічних перевірок, які можна зробити без валідатора

Для кожного рядка: усі дев'ять обов'язкових полів наявні й непорожні; availability у межах переліку з п'яти значень; кількість цифр і контрольна цифра gtin правильні; price відповідає формі сума-і-валюта; sale_price строго менша за price і більша за нуль, у тій самій валюті; title 150 символів або менше; description звичайний текст 5 000 символів або менше; url повертає 200 і рендерить дані товару на сервері; image_url веде до справжнього зображення, а не до заповнювача.

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

Створіть файл винятків, а не ідеальний каталог

Два стовпці й відповідальний: item_id, перешкода й хто це виправляє.

Перевірка якості. На досить чистому каталозі файл винятків має бути меншим за 10% рядків. Якщо він понад 30%, проблема в управлінні даними вище за потоком, і чесний крок це виправити систему-джерело, а не латати файл.

Шлях відновлення. Якщо обов'язкове поле відсутнє в цілій категорії, а не в розкиданих SKU, ставтеся до цього як до рішення про джерело даних разом із власником бізнесу. Не позначайте ці рядки як unknown, щоб очистити аудит, бо unknown це законне значення, яке означає щось конкретне, і використання його для проходження перевірки забруднює ваші власні дані.

Одне чесне зауваження щодо оновлення: специфікація не вказує жодної періодичності оновлення і не каже, чи фіди це повні знімки, чи інкрементальні оновлення. Опубліковані розповіді постачальників упевнено стверджують і те, і те, чого немає в документації OpenAI. Що специфікація справді каже робити, це надсилати поточну ціну, оновлювати, коли акція починається чи закінчується, і оновлювати наявність, коли товар розпродано чи повернувся. Будуйте конвеєр навколо цих двох подій і з'ясуйте питання періодичності під час онбордингу.

Провалідуйте файл так, як це зробить платформа

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

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

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

Шлях відновлення. Збої кодування майже завжди вирішуються повторним експортом у UTF-8. Збої лапок майже завжди це неекрановані розділювачі або зайві розриви рядків в описах.

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

Переконайтеся, що це спрацювало

Те, що ви можете довести, залежить від вашої смуги, і варто бути точним щодо різниці, а не розмивати її.

Смуга A може довести вибірку. Смуга B може довести готовність. Ні смуга, ні розгалуження не змінюють файл, і саме в цьому сенс створення його до того, як у вас з'явиться доступ.

Якщо доступ є (смуга A)

Чотири перевірки. Ваше надсилання підтверджено. Звіт про відхилення на рівні рядків прочитано, і кожне відхилення вирішено або зафіксовано. Приклад запиту на покупку тепер показує один із ваших товарів. Логи вашого сервера показують, як агент вибірки отримує URL товарів.

Якщо доступу немає (смуга B)

Чотири перевірки. Запит robots.txt повертає URL товару для OAI-SearchBot. Отримана з рендерингом на сервері версія цього URL містить заголовок, ціну, наявність і опис. Аудит із дев'яти перевірок проходить. Заморожений експорт і запуск перевірок збережено там, де наступна людина зможе їх відтворити.

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

Одне число, яке має значення наприкінці

Вихідні посилання з ChatGPT автоматично несуть utm_source=chatgpt.com. Це робить вашу власну аналітику єдиним доказом від першої сторони, що клік відбувся. Налаштуйте фільтр зараз, перш ніж дані знадобляться.

І будьте ясними щодо того, що він вимірює. Це атрибуція трафіку від кліку, а не метрика видимості. Товар може бути рекомендований багато разів і клікнутий нуль разів, а товар, який не відповідає вимогам, не може бути клікнутий узагалі.

Чого цей робочий процес не контролює

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

Числа від 10 липня є спостережними й походять від одного постачальника. Вони описують панель відстежуваних запитів Profound, а не реальні сеанси покупців чи шляхи покупки. OpenAI не підтвердила зміну й не розкрила жодного розподілу вибірки. Розгортання GPT-6 Astra почалося 3 вересня 2026 року, що перекривається з пізнішим вікном вимірювання в тому дослідженні й є справжнім фактором, що заплутує.

Показники концентрації несуть ті самі обмеження. Зростання посилань на магазини з топ-10 із 22,5% до 41,8% і падіння кількості унікальних продавців із 13 524 до 10 607 походять із тієї самої панелі. А висновок, що зміни джерела вибірки пояснюють 83% варіації видимості серед 517 клієнтів, які зрушили, це пояснювальна частка всередині панелі, а не причинний коефіцієнт для планування.

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

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

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

Чи можу я надіслати фід товарів у ChatGPT сьогодні?

Не на вимогу. Доступ підтверджується для кожного продавця окремо, оформлення замовлення потребує окремо ввімкненої інтеграції, а стандартне завантаження наразі орієнтоване на США. Реєстрація надає лише відображуване ім'я продавця, і ви можете бути зареєстровані без активного доступу до завантаження. Виконайте наведений вище тест доступу з чотирьох пунктів, щоб визначити свою позицію.

Як часто оновлювати фід?

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

Надсилати повний файл чи лише рядки, що змінилися?

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

Чи реальна вимога зразка зі 100 товарів?

Довідковий текст OpenAI згадує надсилання початкового зразка або повного фіду без жодної кількості. Число 100 товарів походить із блогів постачальників. Якщо ви готуєте зразок, зробіть його репрезентативним, охопивши кожен випадок необов'язкової групи, а не ганяючись за конкретною кількістю.

Чи підніме хороший фід мої товари вище в результатах покупок ChatGPT?

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

Чи потрібно мені щось із цього, якщо я продаю на Shopify?

Не для базової синдикації, бо дані про товари потрапляють у ChatGPT через Shopify Catalog без роботи з боку продавця. Прямий фід потрібен для свіжості та для полів, яких не несе типове налаштування.

Автор: Ева Лоран, стратег із пошуку в e-commerce для понад 10 000 сторінок товарів в Auspia. Ева пише про пошук в e-commerce, виявлення товарів і про те, як дані про товари потрапляють на поверхні покупок на базі ШІ.