Мобільний застосунок і ШІ-пошук: чому рушії цитують сайт, а не стор
ШІ-рушії майже не беруть сторінки App Store і Google Play як джерело. У нашому трекері серед приблизно 23 650 посилань у відповідях ChatGPT, Perplexity і Google сторінки сторів трапились 18 разів. Навіть коли людина прямо питає, який застосунок обрати, 86% джерел у відповідях це звичайні сайти. Тому все, що застосунок робить і чим відрізняється, має бути на відкритих вебсторінках. Інакше рушій про це не дізнається.
Чому вміст застосунку не бачить ніхто, крім користувача
Екрани застосунку живуть на телефоні. Каталог, тарифи, відповіді на питання, умови часто доступні лише після входу. Пошуковий робот і ШІ-рушій читають відкритий веб, тому для них цього вмісту немає.
Google пробував це обійти. Firebase App Indexing мав індексувати вміст застосунків для пошуку. Тепер у документації Firebase прямо сказано, що це більше не рекомендований спосіб, а пошуковий застосунок Google для Android не використовує локальний вміст, проіндексований таким способом. Замість цього Google радить Android App Links і Universal Links для iOS.
Обидва варіанти працюють лише тоді, коли є сайт. Посилання прив'язується до домену, а домен підтверджує зв'язок із застосунком службовим файлом. Без вебсторінки за адресою нема на що вести людину з пошуку.
Що ми побачили в даних
Ми перевірили відповіді за останні 30 днів у всіх проєктах нашого трекера ШІ-відповідей. Це вісім сайтів у різних нішах і приблизно 3 550 відповідей.
| Що рахували | Значення |
|---|---|
| Посилань-джерел у відповідях | близько 23 650 |
| З них сторінок App Store | 7 |
| З них сторінок Google Play | 11 |
| Частка сторів серед усіх джерел | 0,08% |
| Відповідей, де є хоча б одна сторінка стору | 8 із 3 550 |
Gemini ми з цього підрахунку прибрали. Через API він віддає джерела як переадресації Google, і домену з них не видно.
Майже всі ці випадки знайшлись в одному проєкті. Це сервіс у ніші ремонту, і десять промптів там прямо питають, яким застосунком рахувати кошторис чи вести ремонт. Тридцять відповідей трьох рушіїв на ці десять промптів дали 115 джерел:
- 16 сторінок сторів, тобто 14%.
- 99 звичайних сайтів, тобто 86%. Серед них сайти студій ремонту, каталоги, калькулятори.
- Сайт самого сервісу процитовано 10 разів. Більше, ніж будь-яку сторінку в сторі.
Навіть у найбільш «застосунковій» темі рушій шукає відповідь на сайтах. Стор він бере як доказ, що застосунок існує, а не як опис того, що він уміє.
Що має бути на сайті, а не лише в застосунку
Сторінка в сторі обмежена. Опис у Google Play і в App Store вміщує до 4 000 знаків, без таблиць і без окремих адрес для кожної функції. Рушію, який відповідає на конкретне питання, потрібна конкретна сторінка.
| Що є в застосунку | Що потрібно на сайті |
|---|---|
| Функція чи сценарій | окрема сторінка з адресою, описом і скриншотами |
| Тарифи й обмеження | сторінка цін, яку видно без входу |
| Довідка й питання користувачів | база знань із відкритими статтями |
| Оновлення | журнал змін з датами |
| Порівняння з аналогами | чесна сторінка порівняння за функціями |
| Відкриття з посилання | App Links і Universal Links на ті самі адреси |
Останній рядок важливий для розробки. Якщо адреси сайту і екрани застосунку відповідають одне одному, одне посилання веде людину в застосунок, коли він встановлений, і на сторінку, коли ні. А рушій бачить ту саму сторінку і може її процитувати.
Що закладати на етапі розробки
- Схему адрес до першого релізу. Кожен публічний екран застосунку отримує відповідну вебадресу.
- Службові файли для App Links і Universal Links на домені сайту, з перевіркою після кожного релізу.
- Публічну частину без входу. Каталог, ціни, довідку не ховати за реєстрацією, якщо в цьому немає бізнес-причини.
- Розмітку сторінки застосунку з назвою, платформами, ціною і посиланнями на стори.
- Одне джерело правди для текстів. Описи функцій у сторі й на сайті беруться з одного місця, щоб не розходились після оновлень.
Чого ми не стверджуємо
Вісім проєктів нашого трекера не є вибіркою всього ринку. Ніш, де люди здебільшого шукають застосунки, у нас одна.
Ми рахували лише посилання-джерела. Рушій може знати про застосунок із пам'яті моделі і назвати його без посилання.
І ми не кажемо, що оптимізація сторінки в сторі зайва. Вона працює в самому сторі. Але для ШІ-пошуку її замало.
Часті питання
Чи цитують ШІ-рушії сторінки App Store і Google Play? Рідко. У нашому трекері 18 разів на приблизно 23 650 джерел, і майже всі випадки в темі, де прямо питали про застосунки.
Чи індексує Google вміст усередині застосунку? Firebase App Indexing більше не рекомендований. Google радить App Links і Universal Links, а вони потребують сайту.
Що робити, якщо в застосунку все за входом? Винести на сайт публічну частину: функції, ціни, довідку, порівняння. Особисті дані користувачів лишаються в застосунку.
Чи потрібна окрема сторінка під кожну функцію? Так, якщо функцію шукають окремо. Рушій відповідає на конкретне питання і цитує конкретну адресу.
Підсумок
ШІ-рушії бачать застосунок через сайт. Серед приблизно 23 650 джерел у відповідях сторінки сторів трапились 18 разів, а в темі, де люди прямо питали про застосунки, 86% джерел були звичайними сайтами. Google сам відмовився від індексації вмісту застосунків і радить посилання, які працюють лише з доменом.
Тому вебчастину варто проєктувати разом із застосунком: адреси під екрани, публічні ціни й довідка, службові файли для посилань і одне джерело текстів.
Матеріал підготували Євгеній Чиж, засновник Chyzh Agency, і Сергій Колодинський, Head of Mobile Development.
У каталозі 1700+ діджитал-агентств, які готові допомогти в реалізації ваших завдань. Вибирайте та економте до 30% свого часу та бюджету! Це безкоштовно та займе менше 3-х хвилин.