Ваш бізнес живе в застосунку. Для ChatGPT його не існує

Мене звати Євгеній Чиж, я займаюся GEO/AEO. Простими словами, роблю так, щоб бізнеси з’являлися у відповідях ШІ-систем: ChatGPT, Perplexity, Gemini, Google AI Overviews. Останні пару років це моя основна робота: заміряти, де бренд видно, а де ні, і закривати пробіли.

Ця стаття для тих, у кого продукт живе в мобільному застосунку. Програми лояльності, необанки, delivery, marketplace, booking, будь-який app-first бізнес. Якщо ваш каталог, пропозиції й знання про клієнта сидять усередині застосунку, а не на сайті, вас чекає неприємне відкриття: для ШІ-систем вас майже не існує. Нижче розберу, чому так технічно, які заперечення я чую найчастіше (App Intents, MCP, конектори) і чому вони поки що не рятують, і що я з цим роблю на практиці.

Одразу чесно: офіційної заяви від OpenAI «ми не читаємо застосунки» немає. Усе, що нижче, це висновок з архітектури цих систем плюс один дуже показовий кейс від Google. Але висновок, у якому я впевнений, бо перевіряв руками.

Дзвінок, з якого все почалося

Кілька місяців тому я був на дзвінку із засновницею великої української програми лояльності. Мільйони користувачів, впізнаваний бренд, усе життя продукту в застосунку. І в якийсь момент вона сказала фразу, яку я потім довго крутив у голові:

ШІ не бачить, що є в застосунку у кожного з нас. Він черпає інформацію з сайту.

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

Я пішов перевіряти. І те, що я побачив, виявилося не багом конкретної системи, а тим, як влаштована вся генеративна видача.

Як я перевіряв (і що побачив)

Метод простий, можете повторити для свого продукту за годину.

Я взяв близько 40 запитів, які реальна людина поставила б перед вибором: «найкраща програма лояльності для [категорія]», «де вигідніше [дія]», «додатки для [задача] в Україні». Прогнав їх через чотири рушії окремо: ChatGPT з увімкненим пошуком, Perplexity, Gemini і Google AI Overviews. Для кожної відповіді я діставав список цитованих джерел і дивився дві речі: чи згадали бренд і на що саме послалися.

Два висновки, які мене відрізвили.

Перший: рушії поводяться по-різному, і екстраполювати не можна. Один і той самий бренд в іншому моєму проєкті (сонячні станції) цитувався 5 разів із 7 у Perplexity, двічі на першій позиції, і лише 1 раз із 7 у ChatGPT. Спільний бекенд не означає спільну відповідь. Тому «перевірив у ChatGPT» це не «перевірив у ШІ». Треба перевіряти кожен рушій.

Другий, головний для цієї статті: коли ШІ таки згадував app-first бренд, джерелом майже ніколи не був сам застосунок. Це були сторонні сайти: огляди, добірки, Reddit, іноді вікі. Тобто бренд існував у відповіді рівно настільки, наскільки про нього написав хтось інший у відкритому вебі. Власний контент застосунку (каталог, умови, пропозиції) не брав участі взагалі.

Це не випадковість. Це прямий наслідок того, як ці системи дістають інформацію.

Чому так: усі вони читають веб, а не застосунок

Під капотом у ChatGPT (у режимі пошуку), Perplexity, Gemini і AI Overviews та сама схема: retrieval-augmented generation. У момент запиту система не «згадує» відповідь із голови. Вона йде, дістає свіжий контент із зовнішнього джерела, вибирає релевантні шматки і будує з них відповідь із посиланнями.

Питання в тому, що це за джерело. І тут у всіх веб:

• ChatGPT Search класифікує, чи потрібен пошук, переписує запит, тягне кандидатів із веб-індексу (за описами 2025-2026, Bing-подібного), відкриває вибрані сторінки власним агентом ChatGPT-User, і синтезує відповідь із цитатами. Для побудови індексу OpenAI використовує краулер OAI-SearchBot. Обидва ходять по HTTP-сторінках.
• Perplexity робить живий пошук власним краулером, відкриває джерела й цитує саме ті сторінки, які використала.
• Gemini і AI Overviews ґрунтують відповідь через grounding with Google Search, тобто беруть докази з живого пошукового індексу Google.

Спільне в усіх трьох: на вході веб-сторінка, до якої можна дійти по URL і яку можна прочитати як HTML. Вміст, що рендериться всередині застосунку, у цей конвеєр не потрапляє ніяк. Немає URL, немає сторінки. Немає сторінки, немає чого цитувати. Застосунок для краулера це чорна скринька, до якої він фізично не має доступу.

Більше того, навіть на звичайних сайтах контент, що домальовується на клієнті через JavaScript після першого рендера, для частини цих систем невидимий. А екрани застосунку це і є суцільний динамічний рендер поверх API. Тобто проблема не лише «немає URL», а й «навіть якби був, там нема готового HTML для читання».

Як retrieval-augmented generation дістає джерела. Веб-сторінку рушій читає й цитує; застосунок для нього чорна скринька без URL і без HTML.

Найсильніший доказ: Google сам здався на цьому

Найпереконливіше тут не мої заміри, а історія. Індексувати вміст усередині застосунків настільки складно, що від цієї ідеї відмовився сам Google. Маючи прямий доступ до Android.

Хронологія коротка:

• 2015-2016. Google запускає App Indexing, потім консолідує його у Firebase App Indexing. Ідея була красива: показувати контент із застосунків прямо у пошуковій видачі, відкривати потрібний екран.
• 2019. Фактична смерть. В офіційних доксах Firebase з’являється формулювання: Firebase App Indexing «більше не є рекомендованим способом індексувати контент», а Google Search App для Android «більше не використовує локальний контент, проіндексований через Firebase App Indexing».
• Що лишилося. Тільки deep links: Android App Links та iOS Universal Links. І ось ключове: щоб deep link працював, потрібна верифікована веб-сторінка (домен із файлом assetlinks.json для Android або apple-app-site-association для iOS). Google веде на екран застосунку тільки там, де вже є веб-двійник контенту. Суто app-only вміст не з’являється ніде.

Перекладаю на людську: сучасна модель звучить як «є веб-сторінка, можу відкрити відповідний екран у застосунку». Немає веб-сторінки, немає видимості. Ані в пошуку, ані в AI Overviews.

Логіка проста до незручності. Якщо Google з усім його доступом до операційної системи Android не зміг витягнути app-контент у видачу і відкотився до «спочатку зробіть веб-сторінку», то LLM, у якої взагалі немає доступу до вашого застосунку, точно його не побачить.

«Але ж App Intents! Siri читає мій застосунок!»

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

Так, on-device асистенти справді читають ваш застосунок. На iOS через App Intents ви віддаєте системі свої дії (AppIntent), свій контент (AppEntity, IndexedEntity) і схеми. Викликаєте indexAppEntities, і ваші сутності потрапляють у семантичний індекс Spotlight. З доків Apple майже дослівно: «Apple Intelligence використовує можливості семантичного пошуку Spotlight, щоб знаходити контент вашого застосунку, навіть коли його описують розпливчасто». На Android аналогічно: App Actions і on-device Gemini маплять фразу користувача на оголошені вами intent-и та сутності.

Усе це працює. Siri справді розуміє «покажи цю фотографію» стосовно того, що зараз на екрані. Apple Intelligence справді може викликати вашу дію голосом.

А тепер межа. Усе це живе на пристрої користувача, всередині операційної системи, під приватними обмеженнями. Це не веб-ендпоінт. Семантичний індекс Spotlight це персональний індекс конкретного айфона, а не публічний пошуковий індекс. У доках Apple немає ані слова про те, що App Intents чи Spotlight стають crawlable-джерелом або що оголошення App Intents реєструє ваш контент у сторонніх ШІ-рушіях.

Тобто:

• App Intents дають видимість для Siri, Apple Intelligence, Spotlight, Shortcuts. У межах екосистеми Apple, для одного користувача, на його пристрої.
• App Intents не дорівнюють видимості для ChatGPT, Perplexity, Gemini web.

Це два різні світи. On-device асистент працює як оркестратор інструментів поверх вашого локального застосунку. Хмарна LLM працює як рушій відповідей поверх вебу й того, що їй явно надіслали. App Intents не будує міст між ними. Ви можете ідеально оптимізувати застосунок під Apple Intelligence і лишитися рівно так само невидимим для ChatGPT, як були.

On-device асистент (Siri, Apple Intelligence) читає застосунок на пристрої; хмарний рушій (ChatGPT, Perplexity, Gemini web) до нього доступу не має. App Intents моста між ними не будує.

«Тоді конектори, MCP, actions вони ж підключать застосунок»

Друге за популярністю заперечення, уже від бекендерів. Мовляв, є ж ChatGPT Actions, є Model Context Protocol, є Gemini extensions. Підключимо застосунок туди.

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

• Actions / function calling / MCP tools це переважно спосіб дати моделі викликати вашу функцію. Модель отримує схему й вирішує, коли смикнути create_order чи search_products. Ваш бекенд виконує сайд-ефект.
• Конектори / RAG-інтеграції це спосіб віддати моделі контент: каталог, профіль, документи, які модель бачить у своєму контексті й може використати у відповіді.

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

Але спільний знаменник у всіх цих механізмів один, і він вбиває наївну надію: модель бачить рівно те, що ви самі явно серіалізували й віддали через API. Немає магічної інтроспекції вашого застосунку. Жоден хмарний рушій не залазить у приватний стан застосунку на пристрої й не читає його сам. Ви пишете бекенд-ендпоінт, ви віддаєте туди дані, і тільки тоді модель їх «бачить».

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

Deep links у відповідях ШІ, до речі, з тієї ж опери: це чиста дія («відкрий екран»), а не контент. Модель не дізнається з deep link нічого про ваш каталог.

Чому це вже болить, а не «колись у майбутньому»

Можна було б сказати: ну не бачить ШІ застосунки, і що, у нас же є Google. Проблема в тому, що поведінка користувачів зсувається просто зараз.

Частка пошуків без переходу на сайт (zero-click) у США за 2025 перевалила за половину. ChatGPT за даними OpenAI влітку 2025 обробляв близько 2,5 млрд запитів на день. Дослідження Ahrefs на сотнях тисяч ключів показало відчутне падіння CTR першої позиції там, де вгорі стоїть AI Overview. Тобто верхня частина видачі, з якої люди звикли клікати, дедалі частіше «з’їдається» відповіддю ШІ, а всередині цієї відповіді app-first бренду немає.

Для бізнесу, чий продукт в застосунку, це подвійний удар. Класичного SEO-трафіку в цих ніш і так мало: люди не гуглять «програма лояльності», вони одразу питають асистента. А в новому, генеративному каналі їх не видно взагалі, бо читати нема чого.

Що я з цим роблю на практиці

Тепер конструктив. Не «купіть послугу», я тут не про це, а що конкретно робити, якщо ви прочитали все вище й упізнали свій продукт. Порядок від найважливішого.

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

Структуровані дані. На ці публічні сторінки додайте Schema.org: Product, Offer, FAQPage, Organization, і так, MobileApplication для самого застосунку. Сторінки з багатою розміткою за спостереженнями цитуються помітно частіше. Це дешево і це та мова, якою рушію найлегше вас зрозуміти.

Присутність на сторонніх сайтах. Пам’ятаєте мій замір, коли ШІ таки згадував app-бренд, а джерелом були чужі сайти? Це не баг, це важіль. За аналізом Semrush найчастіше цитовані ШІ домени це Reddit, Wikipedia, LinkedIn, YouTube. Тому реальні огляди, добірки, обговорення, у яких фігурує ваш продукт, працюють на видимість сильніше, ніж власний сайт. Off-site тут важить більше, ніж звикли думати.

On-page під цитованість. Дослідження Princeton (KDD 2024, близько 10 тисяч запитів) показало приземлену річ: додавання прямих цитат піднімало видимість у ШІ приблизно на 41%, статистики на 32%. Тобто конкретика, цифри, посилання на джерела прямо в тексті сторінки це не «вода для SEO», а те, що рушій любить витягувати в цитату.

Deep links як міст, а не як заміна. Зробіть App Links / Universal Links правильно, з верифікованими доменами. Це не дасть вам видимості саме по собі, але коли веб-сторінка вже є, deep link дозволяє з неї відкрити потрібний екран застосунку. Веб-шар і застосунок починають працювати в парі, а не окремо.

А тепер про те, чого не робити, бо на цьому легко втратити час і гроші.

Не покладайтеся на llms.txt як на важіль. Ідея гарна (файл-підказка для ботів ШІ), але Джон Мюллер із Google прямо сказав, що жоден із ШІ-сервісів його навіть не перевіряє, і спостереження показують, що переважна більшість розгорнутих llms.txt не отримує від AI-ботів жодного запиту. Як гігієна можна, як стратегія ні.

І не ведіться на страшилки з круглими цифрами на кшталт «пошук впаде на 25%» чи «90% контенту невидиме для ШІ». Перше не справдилося, друге це вендорська цифра без дослідження. Реальність і без перебільшень достатньо переконлива.

Порядок кроків від фундаменту вгору. Спочатку SSR веб-шар, потім структурні дані, off-site присутність і deep links. llms.txt і круглі страшилки не працюють.

Підсумок

Якщо коротко, для тих, хто дочитав:

1. Хмарні ШІ-рушії (ChatGPT, Perplexity, Gemini, AI Overviews) будують відповіді з відкритого вебу. Вміст усередині застосунку в цей конвеєр не потрапляє, бо там немає URL і немає готового HTML для читання.
2. Це не теорія: сам Google відмовився індексувати app-контент ще 2019-го й відкотився до моделі «спочатку зробіть веб-сторінку». Якщо не зміг Google з доступом до Android, то LLM тим паче.
3. App Intents / Apple Intelligence / Siri читають ваш застосунок, але на пристрої користувача, всередині екосистеми. Для ChatGPT це нічого не змінює. Не плутайте on-device асистента з хмарним рушієм відповідей.
4. Конектори, MCP, actions віддають моделі рівно те, що ви самі серіалізували в API, і тільки для вже підключеного користувача. На етапі «незнайомець питає ШІ» вони не працюють.
5. Що реально допомагає: винести ключовий app-контент у SSR-веб, накрити структурованими даними, наростити присутність на сторонніх цитованих сайтах, зробити deep links як міст. Що не допомагає: llms.txt і круглі цифри зі слайдів.

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

Тому найпростіша дія після цієї статті це витратити годину й перевірити свій продукт руками. Поставте у ChatGPT, Perplexity й Gemini десяток запитів, на які ваш застосунок мав би бути ідеальною відповіддю. Подивіться, чи вас там видно і на що система посилається. Якщо ви app-first, швидше за все, побачите те саме, що побачив я на тому дзвінку. І це вже привід почати будувати веб-шар, якого бракує.

Джерела

• OpenAI, огляд краулерів OAI-SearchBot / ChatGPT-User; Search Engine Land, розбір пайплайна ChatGPT Search
• Google, «Grounding with Google Search» (ai.google.dev); Google Search Central, App deep links (05.2025)
• Firebase App Indexing, офіційні доки про депрекейт (2019)
• Apple Developer: App Intents, Apple Intelligence and Siri, IndexedEntity / Spotlight semantic index (WWDC 2024-2026)
• Princeton GEO study, KDD 2024 (arXiv 2311.09735)
• Semrush, найчастіше цитовані ШІ домени (2025)
• Ahrefs, вплив AI Overviews на CTR (2025); Search Engine Journal, коментар Дж. Мюллера про llms.txt