Як просувати PWA: SEO, індексація й установка

Коли ви публікуєте нативний додаток, шлях користувача простий: він відкриває App Store або Google Play, вводить назву чи запит і натискає «Установити». Сам стор виконує роль пошуковика, вітрини, платіжної системи й каналу оновлень.

З PWA все інакше. Каталогу, який складається сам, немає. Користувач має спершу дізнатися, що продукт існує, потім знайти його в пошуку, перейти за посиланням або отримати QR-код, і лише після цього подумати про установку. Усе це лягає на розробника, і саме про це ця стаття.

Я запускав PWA у проєкті Kazki AI (сервіс генерації дитячих казок), налаштовував push для блогу психолога, а зараз інтегрую PWA в ще один проєкт. На старті для мене було важливо не лише зробити сервіс доступним за посиланням, а й пояснити потенційним користувачам, що він пропонує та яку проблему вирішує. Саме тому я розглядаю PWA не лише як технологію, а й як продукт, якому потрібна зрозуміла публічна сторінка для залучення аудиторії. Якщо ви ще вибираєте між PWA та нативом, спершу прочитайте PWA vs Native у 2026: порівняння та реальний кейс.

📚 Зміст статті

• 📌 Чим обнаружуваність PWA відрізняється від нативного додатка
• 📌 Як зробити PWA видимим у Google
• 📌 Рендеринг, роутинг, індексація: чому PWA «не видно»
• 📌 Core Web Vitals для PWA
• 📌 Як користувачі знаходять PWA за назвою
• 💼 Каталоги веб-застосунків
• 💼 Google Play, App Store, Microsoft Store
• 💼 Просування поза пошуком
• 💼 Від відвідувача до встановлення
• 💼 Push: як повернути користувача
• 💼 Як вимірювати результат
• 💼 Чи потрібна розмітка SoftwareApplication
• ✅ Чек-лист SEO та дистрибуції PWA
• ❓ Часті питання (FAQ)

🎯 Розділ 1. Чим обнаружуваність PWA відрізняється від нативного додатка

Коротка відповідь: у нативного додатка пошук, довіра й установка зосереджені в одному місці (сторі), а PWA розподілений по вебу. Кожен канал, який у сторі працює «з коробки», для PWA доводиться будувати окремо.

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

Канали обнаружуваності: що працює для нативу, а що для PWA

Коли відсутність у сторі — проблема, а коли ні

Я рекомендую враховувати тип продукту й поведінку аудиторії. Відсутність у сторі критична для масових споживчих застосунків, де значна частина користувачів звикла шукати «назва + App Store». Для SaaS, інструментів, контентних і B2B-продуктів, де користувачі приходять із Google у пошуках рішення або переходять за прямим посиланням, цього зазвичай достатньо. Водночас я не раджу сприймати це як універсальне правило: спочатку перевірте у власній аналітиці, звідки приходять користувачі, а вже потім вирішуйте, чи потрібна присутність у сторах.

🎯 Розділ 2. Як зробити PWA видимим у Google

Користувач Google шукає не «PWA», а рішення своєї задачі: «застосунок для генерації казок», «онлайн-планувальник завдань». Якщо єдиний вхід у ваш продукт — екран логіну, у пошуку нема за що зачепитися. З моєї практики, є проєкти, де клієнти вимагають обов’язкової авторизації, через що більшість сторінок залишаються закритими для пошукових роботів. У такому випадку я рекомендую створити окремі публічні сторінки з описом продукту, його можливостей і сценаріїв використання, щоб потенційні користувачі могли знаходити його через Google ще до реєстрації.

Що має бути на публічній сторінці

• Окремий URL для кожного важливого «екрана»: головна, функції, ціни, статті. Не один URL на весь застосунок.
• Реальний контент в HTML: опис продукту, функції, зображення з alt, зрозумілий заклик до дії.
• Унікальні title і meta description на кожній сторінці. Google може переписати їх у видачі, а description не є фактором ранжування, але від нього залежить, чи клікнуть по сніпету.
• Звичайні посилання <a href>. Googlebot переходить за посиланнями з атрибутом href, а не за обробниками кліку в JavaScript.
• sitemap.xml: допомагає знайти сторінки, але не гарантує індексацію.
• Не блокуйте в robots.txt скрипти й стилі, потрібні для рендеринга сторінки.

<head>
  <title>Kazki AI — генератор дитячих казок за промптом</title>
  <meta name="description" content="Створюйте персональні казки для дітей за кілька секунд.">
  <link rel="canonical" href="https://example.com/">
  <link rel="manifest" href="/manifest.json">
</head>

Search Console: перевірка замість припущень

Якщо ви новачок , я рекомендую почати з Google Search Console. Зареєструйте сайт і використовуйте інструмент «Перевірка URL». Він показує, чи проіндексована сторінка, який HTML побачив Google після рендерингу та як виглядає скриншот сторінки. Для PWA це найшвидший спосіб дізнатися, що саме бачить пошуковий робот, а не лише те, що ви бачите у своєму браузері. Звіт «Індексація сторінок» допоможе з'ясувати, чому окремі URL не потрапили до індексу. Якщо у вас виникнуть труднощі з налаштуванням або перевіркою індексації, напишіть мені — я допоможу розібратися.

Bing та IndexNow

Я рекомендую не ігнорувати Bing лише через його меншу частку ринку порівняно з Google. У деяких країнах і серед окремих аудиторій ним користуються частіше, тому варто враховувати географію вашого трафіку. Додайте сайт у Bing Webmaster Tools і налаштуйте IndexNow для сповіщення підтримуваних пошукових систем про нові та оновлені URL. Це додатковий канал виявлення сторінок, який нескладно налаштувати. Навіть якщо зараз більшість відвідувачів приходить із Google, я вважаю таку інтеграцію доцільною: вона розширює можливості пошукової видимості без необхідності змінювати основну SEO-стратегію. Водночас IndexNow не гарантує індексацію сторінок. Google цей протокол не використовує, тому для нього продовжуйте працювати з sitemap і Google Search Console.

Запити про задачу, а не про технологію

Користувачі рідко шукають «PWA». Формулюйте сторінки навколо того, що людина хоче зробити, а слово «PWA» зберігайте для статей для розробників. Приклади й порядок дій для нового бренду розглядаємо в розділі 5.

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

🔗 Читайте також

• PWA vs Native у 2026: порівняння та реальний кейс
• 8 критичних помилок при інтеграції PWA

🎯 Розділ 3. Рендеринг, роутинг, індексація: чому PWA «не видно»

З моєї практики, більшість проблем PWA з пошуковою видимістю пов'язані з технічною реалізацією. Контент може з'являтися лише після виконання JavaScript, усі внутрішні сторінки можуть використовувати один URL, а неіснуючі адреси — повертати статус 200 замість 404. Сам по собі маніфест або Service Worker цих проблем не вирішує: важливо правильно налаштувати маршрутизацію, HTTP-статуси та доступність контенту для пошукових роботів.

Google обробляє JavaScript-сторінки у три етапи: сканування, рендеринг і індексація. Для рендеринга використовується актуальна версія Chromium, але вона працює в черзі, тож контент, який з'являється лише після виконання скриптів, може потрапити в індекс пізніше, ніж звичайний HTML. Крім того, робот не клікає, не скролить і не логіниться. Усе, що з'являється тільки після дії користувача, у пошук не потрапить. [Google: JavaScript SEO]

Проблема 1. Клієнтський рендеринг (CSR)

У класичному SPA сервер віддає порожню оболонку, а контент з'являється після завантаження скриптів. Є три підходи, і вибирати слід за типом сторінки:

Зі своєї практики рекомендую розділяти публічну та закриту частини PWA. Лендінги, сторінки функцій, ціни й статті варто віддавати як готовий HTML, а інтерфейс авторизованого застосунку можна залишити клієнтським. У своїх проєктах я також розглядаю окремий DTO для централізованого формування SEO-даних і sitemap: публічних URL, дат оновлення та інших необхідних метаданих. Це спрощує керування індексацією, але не замінює правильного формування HTML, налаштування HTTP-статусів і доступності сторінок для пошукових роботів. Google раніше описував dynamic rendering — надання окремої версії сторінки ботам — як обхідний шлях, але не рекомендує його як довгострокове рішення.

Проблема 2. Один URL на весь застосунок

Якщо розділи перемикаються без зміни адреси, або адреса виглядає як /#/pricing, для Google це одна сторінка. Фрагмент після # не розглядається як окремий URL. Використовуйте History API, щоб кожен публічний розділ мав чисту адресу:

// Чисті URL замість hash-роутів
history.pushState({}, '', '/pricing');

// У React Router: BrowserRouter, а не HashRouter
// У Vue Router: createWebHistory(), а не createWebHashHistory()

Сервер при цьому має вміти віддати потрібну сторінку за прямим запитом на /pricing, а не лише після завантаження SPA.

Проблема 3. «М'які» 404

Типова пастка SPA: сервер на будь-який невідомий шлях віддає index.html зі статусом 200, а повідомлення «Сторінку не знайдено» відображає JavaScript. Для пошукової системи така адреса може виглядати як успішно завантажена сторінка, а не як помилка 404, що створює ризик появи в індексі неіснуючих URL. Рішення: на рівні сервера повертайте справжній статус 404 для неіснуючих маршрутів, а для видалених сторінок використовуйте 410 або 301 на релевантну актуальну адресу. Зі своєї практики я рекомендую перевіряти це не лише з погляду SEO, а й у контексті GEO: коректна маршрутизація допомагає системам отримувати правильні відповіді сервера, хоча сама по собі не гарантує згадок або цитувань у відповідях ШІ.

Проблема 4. Мета-дані та посилання з JavaScript

• title, description і canonical краще віддавати вже в HTML від сервера, а не підставляти скриптом після завантаження.
• Навігація має бути на звичайних <a href="/path">, а не на onclick без href.
• Контент, який підвантажується лише після кліку чи скролу, робот не побачить.

Що маніфест і Service Worker дають SEO, а що ні

Окремо про Service Worker: агресивне кешування HTML може віддавати користувачам застарілі сторінки, а помилки в обробці fetch ламають роутинг. Типові помилки й виправлення я розбирав у статті 8 критичних помилок при інтеграції PWA. Для SEO головне правило таке: те, що має бути проіндексоване, сервер повинен віддавати як є, незалежно від того, що робить Service Worker.

Як перевірити, що бачить Google

1. Я відкриваю в Google Search Console розділ «Перевірка URL» і запускаю живу перевірку публічної сторінки.
2. Переглядаю відрендерений HTML і скриншот. Якщо сторінка порожня або в HTML немає ключового тексту, я перевіряю, чи правильно працює рендеринг.
3. Порівнюю початкову відповідь сервера (curl -s https://example.com/) із тим, що показує браузер. Якщо в результаті curl немає основного контенту, це означає, що він може залежати від виконання JavaScript.
4. У звіті «Індексація сторінок» перевіряю статуси «Виявлено, наразі не проіндексовано» та «Мʼяка помилка 404», щоб зрозуміти, чому сторінки не потрапляють до індексу.

🎯 Розділ 4. Core Web Vitals для PWA

Коротка відповідь: швидкість для PWA важлива двічі — як сигнал якості сторінки для Google і як частина самого продукту. Але це допоміжний чинник, а не заміна релевантного контенту. У своїй практиці я рекомендую враховувати не лише швидкість завантаження, а й те, як вона впливає на взаємодію користувачів із сайтом. Детальніше про це я розповідаю у статті Core Web Vitals: три метрики, які впливають на конверсію сайту.

Google використовує Core Web Vitals для оцінювання користувацького досвіду. Основні метрики та порогові значення «Good»:

• LCP (швидкість відображення основного контенту): до 2,5 с;
• INP (відгук на взаємодію): до 200 мс;
• CLS (стабільність макета): до 0,1.

Для PWA є специфічні ризики. Важкий JavaScript-бандл затягує LCP, особливо коли контент формується на клієнті. Service Worker може пришвидшити повторні візити, але не обов'язково допомагає під час першого відкриття. Тому я рекомендую оптимізувати початкове завантаження: розбивати JavaScript-бандл на частини, відкладати завантаження другорядних скриптів, задавати розміри зображень для зменшення CLS і не блокувати відображення сторінки важкими ресурсами.

Я перевіряю реальні показники у звіті Core Web Vitals у Google Search Console та в PageSpeed Insights. Якщо сайт має достатньо польових даних, PageSpeed Insights показує результати реального використання за попередні 28 днів. Лабораторні показники Lighthouse корисні для діагностики, але не замінюють польових даних. Покроково про перевірку швидкості та оптимізацію я розповідаю у статті Google PageSpeed Insights: як досягти 90 балів.

🎯 Розділ 5. Як користувачі знаходять PWA за назвою

Коротка відповідь: у сторі пошук за назвою працює сам. У вебі за назвою знайдуть лише той продукт, про який Google вже «знає», а для нового бренду без згадок це не гарантовано.

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

Що допомагає, чому це важливо і що буде, якщо цим знехтувати

• Унікальна назва. Перевірте видачу за нею до запуску. Якщо топ займають інші продукти, подумайте про зміну назви або додавання уточнення («Назва + категорія»).

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

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

• Однакове написання скрізь: домен, title, name у маніфесті, профілі в соцмережах і каталогах.

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

  Якщо знехтувати: згадки розпорошуються між варіантами («Kazki AI», «KazkiAI», «Казки AI»), а Google складніше повʼязати їх з одним сайтом. Користувачі вводять різні написання й не завжди знаходять продукт, а розбіжність між назвою на сайті та на іконці підриває довіру до застосунку.

• Публічна сторінка продукту з точною назвою в заголовку й тексті.

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

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

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

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

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

• Розмітка назви сайту (WebSite з name) допомагає Google правильно показувати назву у видачі, але на позиції за брендовим запитом не впливає.

  Чому важливо: це підказка для Google, яку назву показувати над сніпетом. Вона недорога у впровадженні й особливо корисна, коли назва складна або домен не збігається з брендом.

  Якщо знехтувати: Google обере назву сам за іншими сигналами (заголовки, title, згадки), і у видачі може показатись домен або невдале написання. Це не шкодить позиціям, але псує перше враження від сніпета. Розмітка не дає жодних гарантій, а Google може показати іншу назву.

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

Новий бренд vs бренд з попитом

Коли я працюю над просуванням нового продукту, то рекомендую на початку зосередитися на задачах користувачів, а не лише на назві бренду. Наприклад, замість того щоб розраховувати на пошукові запити з назвою нового сервісу, варто опрацьовувати запити на кшталт «застосунок для казок на ніч». На старті про продукт можуть ще не знати, тому важливо дати потенційним користувачам можливість знайти його через конкретну потребу. Брендовий попит може з'явитися в міру поширення продукту, але це не гарантований етап для кожного проєкту.

У проєкті Kazki AI я також робив акцент на практичному застосуванні сервісу — генерації дитячих казок, а не лише на його назві. Це один із підходів, який я рекомендую розглянути для нового бренду, але не універсальне правило: стратегія залежить від ніші, аудиторії та наявного попиту. Щоб оцінити результат, я раджу стежити за брендовими запитами в Google Search Console. Коли користувачі починають шукати продукт за назвою, це може свідчити про зростання впізнаваності.

💼 Розділ 6. Каталоги веб-застосунків

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

Каталоги бувають двох типів, і мета в них різна:

• Джерела користувачів: майданчики запусків (на кшталт Product Hunt), тематичні каталоги SaaS та інструментів, де люди реально шукають нові продукти.
• Джерела посилань і згадок: каталоги, які допомагають Google зв'язати назву з вашим сайтом. Багато каталогів ставлять на посилання nofollow, тому не очікуйте від них SEO-ефекту.

Як оцінювати каталог

Додавайте продукт у кілька справді релевантних каталогів, а не в сотню випадкових. Для кожного ставте окрему UTM-мітку, щоб потім бачити в аналітиці, який канал дав переходи, а не лише «referral».

💼 Розділ 7. Google Play, App Store, Microsoft Store

Коротка відповідь: PWA можна опублікувати в сторах, але автоматично й без доробок це не відбувається. Кожен стор має свою обгортку та вимоги, а Apple найсуворіша до «просто сайтів у обгортці».

Чи варто це робити

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

Про те, коли нативний підхід виправданий, читайте в статті PWA vs Native у 2026.

💼 Розділ 8. Просування поза пошуком

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

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

QR-код, що веде на PWA, особливо зручний, коли продукт використовується в конкретному місці: людина відскановувала й одразу відкрила застосунок без стору. Для всіх каналів ставте UTM-мітки, інакше в аналітиці все зіллється в «direct».

💼 Розділ 9. Від відвідувача до встановлення

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

Android і десктоп (Chromium)

Chrome та інші Chromium-браузери підтримують подію beforeinstallprompt. Ви можете перехопити її й показати власну кнопку «Встановити» у потрібний момент, а не одразу при вході:

let deferredPrompt;

window.addEventListener('beforeinstallprompt', (e) => {
  e.preventDefault();          // не показуємо стандартний банер одразу
  deferredPrompt = e;
  showInstallButton();         // показуємо свою кнопку
});

installBtn.addEventListener('click', async () => {
  if (!deferredPrompt) return;
  deferredPrompt.prompt();
  const { outcome } = await deferredPrompt.userChoice; // 'accepted' | 'dismissed'
  deferredPrompt = null;
  hideInstallButton();
});

window.addEventListener('appinstalled', () => {
  // подія установки, лише в браузерах, що її підтримують
});

Ця подія доступна не в усіх браузерах: наприклад, в iOS Safari її немає. Тому вона не підходить як єдиний спосіб показати підказку.

iOS

На iPhone немає автоматичного запиту на установку. Користувач має вручну пройти «Поділитися → На екран Домівка». Тому підказку потрібно показувати самому: коротку інструкцію зі скриншотом у момент, коли людина вже побачила цінність продукту. З iOS 16.4 «На екран Домівка» можуть пропонувати й сторонні браузери, але наявність пункту залежить від браузера, тому в інструкції надійніше писати універсальний шлях. Чому це важливо для push, я розбирав у статті PWA Push-сповіщення на iOS у 2026: без установки на домашній екран на iOS підписатись на push не можна.

Коли пропонувати установку

• Після першої корисної дії (створив казку, зберіг налаштування), а не при першому завантаженні сторінки.
• З поясненням користі: швидший запуск, сповіщення, іконка на екрані. Не «Встановіть наш застосунок», а що саме людина отримає.
• Не показуйте підказку, якщо застосунок уже відкрито в режимі standalone, і не мучте тих, хто відхилив її: запамʼятайте вибір на кілька днів.

💼 Розділ 10. Push: як повернути користувача

Коротка відповідь: пошук приводить людину один раз, а повернути її допомагає push. Тому для PWA він є частиною стратегії залучення, а не додатковою функцією.

Користувач прийшов з Google, подивився продукт і закрив вкладку. Без каналу повернення ви втрачаєте його. Push вирішує це: «нова казка готова» повертає людину в застосунок без стору й без розсилки.

Що я налаштовував на практиці

У Kazki AI push повідомляв користувачів про нові казки й нагадував про підписку. У блозі практикуючого психолога сповіщення інформували підписників про нові курси й публікації. Обидва проєкти показали, що для інформаційних сповіщень технологія працює достатньо надійно, а критичні повідомлення краще дублювати email. Деталі з кодом (підписка, manifest, Service Worker, push handler, 7 причин, чому пуші не доходять) є в статті PWA Push-сповіщення на iOS у 2026: що реально працює.

Що важливо для обнаружуваності й повернення

• Просіть дозвіл після цінності, а не при першому завантаженні. На iOS запит можливий лише по кліку на кнопці.
• Не покладайтесь лише на push. На iOS підписки можуть ставати недійсними, а частина користувачів просто не встановить PWA. Додайте email, in-app стрічку та лічильник на іконці.
• Сервіс чи власний бекенд. Якщо сценарій простий, власної відправки достатньо. Якщо потрібні сегментація й кампанії, розгляньте готові сервіси. Порівняння: Push-сервіси для PWA: OneSignal, FCM, Pushwoosh, WonderPush і Braze.

💼 Розділ 11. Як вимірювати результат

Будуйте воронку від показу в пошуку до повторного візиту, але не очікуйте однакового виміру установок у всіх браузерах. Метрики пошуку й метрики продукту беріть з різних інструментів.

Воронка виглядає так:

1. Показ у пошуку (Search Console: покази, середня позиція);
2. Перехід (Search Console: кліки; аналітика: сесії за джерелом);
3. Перший запуск (аналітика: подія першої цільової дії);
4. Установка, якщо її можна виміряти;
5. Повторні візити (аналітика: повернення за 7/30 днів);
6. Цільова дія (реєстрація, покупка, підписка).

Що можна виміряти, а що ні

Практичний спосіб відрізнити сесії інстальованого застосунку від звичайних вкладок:

const isStandalone =
  window.matchMedia('(display-mode: standalone)').matches ||
  window.navigator.standalone === true;

// Приклад для GA4: передаємо режим як параметр події
gtag('event', 'app_open', {
  display_mode: isStandalone ? 'standalone' : 'browser'
});

window.addEventListener('appinstalled', () => {
  gtag('event', 'pwa_installed');
});

Щоб бачити параметр display_mode у звітах GA4, зареєструйте його як користувацький вимір. Ще один прийом: додайте мітку до start_url у маніфесті (наприклад, /?source=pwa), щоб запуски з домашнього екрана було видно в джерелах трафіку.

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

💼 Розділ 12. Чи потрібна розмітка SoftwareApplication

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

Я рекомендую розглянути використання SoftwareApplication або WebApplication зі Schema.org для публічної сторінки продукту. Така розмітка допомагає пошуковим системам краще зрозуміти, що саме пропонує сервіс. Водночас її впровадження не є обов’язковою умовою індексації чи видимості сторінки в пошуку. Якщо ви хочете отримати розширений результат для застосунку в Google, перевірте актуальні вимоги в офіційній документації: вони можуть змінюватися. Важливо, щоб розмітка відповідала реальному вмісту сторінки. Не додавайте вигадані ціни, оцінки чи відгуки — це суперечить правилам Google і може призвести до втрати розширених результатів.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Назва застосунку",
  "applicationCategory": "BusinessApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/",
  "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }
}
</script>

Це мінімальний приклад. Оцінки (aggregateRating) додавайте лише тоді, коли у вас є справжні відгуки, видимі на сторінці. Розмітка потрібна для ясності, а не як спосіб просування, тому основну ставку робіть на розділи 2-5.

✅ Розділ 13. Чек-лист SEO та дистрибуції PWA

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

Сценарій A. Новий продукт без бренду

• Публічна сторінка продукту з контентом у HTML (SSG/SSR/prerendering).
• Чисті URL, правильні статуси 404/410, відсутність hash-роутів.
• Унікальні title і description, sitemap.xml, robots.txt без блокування скриптів і стилів.
• Search Console й Bing Webmaster Tools, перевірка живого URL.
• Сторінки під запити про задачу користувача, а не під назву.
• 2-3 релевантні каталоги й тематичні спільноти з UTM-мітками.
• Кнопка установки (Chromium), підказка для iOS, push після першої цінності.
• Аналітика з параметром display_mode і подією appinstalled.

Сценарій B. Існуючий продукт зі сформованим попитом

• Перевірка брендових запитів у Search Console та їх сніпетів (title, назва сайту).
• Аудит рендерингу й «м'яких» 404 для сторінок, що вже мають покази.
• Core Web Vitals для сторінок з найбільшим трафіком.
• Розгляд публікації в сторах, якщо аудиторія шукає застосунок саме там.
• Push і email для повернення наявних користувачів.

План перших 7 днів після релізу

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

❓ Часті питання (FAQ)

Чи можна знайти PWA в App Store?

Лише якщо його опубліковано в сторі через нативну обгортку. Звичайний PWA в App Store не з'являється: користувачі знаходять його через пошук, посилання чи каталоги, а на iPhone додають на домашній екран вручну.

Як Google індексує PWA?

Google сканує публічні URL, рендерить їх у Chromium і додає в індекс. Контент, який з'являється лише після виконання JavaScript, може індексуватись із затримкою, а закритий авторизацією контент не індексується зовсім. Надійніше віддавати публічні сторінки як готовий HTML (SSG, SSR або prerendering).

Чи потрібен PWA окремий сайт?

PWA і є сайтом, але публічну частину (лендінг, функції, ціни, статті) варто робити окремими індексованими сторінками. Закрита частина застосунку за логіном у пошук не потрапляє.

Чи може PWA ранжуватись у Google?

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

Чи можна опублікувати PWA в Google Play?

Так, через Trusted Web Activity: PWA запаковується в Android-пакет і підтверджується зв'язок із доменом. Актуальні вимоги до акаунтів розробників і застосунків перевіряйте в Play Console, бо вони змінюються.

Як встановити PWA на iPhone?

Відкрийте сайт у Safari (або в іншому браузері, що має цей пункт), натисніть «Поділитися» і виберіть «На екран Домівка». Автоматичного запиту на установку в iOS немає, тому підказку потрібно показувати в інтерфейсі. Push на iPhone доступний лише для застосунків, доданих на домашній екран.

✅ Висновки

Нативний додаток знаходять у сторі, а PWA доводиться «розповсюджувати» самому. Пошук, правильний рендеринг, каталоги, повернення через push і вимірювання складають єдину систему, і кожна ланка потрібна.

• Технічна основа: публічні сторінки як готовий HTML, чисті URL, правильні статуси.
• Обнаружуваність: запити про задачу на старті, брендовий попит пізніше.
• Дистрибуція: 2-3 релевантні каталоги, спільноти, за потреби стори.
• Повернення: push + email + in-app, з урахуванням обмежень iOS.
• Виміри: воронка від показу до повторного візиту.

🔗 Читайте також

• PWA vs Native у 2026: порівняння та реальний кейс
• PWA Push-сповіщення на iOS у 2026: що реально працює
• 8 критичних помилок при інтеграції PWA
• Push-сервіси для PWA: OneSignal, FCM, Pushwoosh, WonderPush і Braze

📖 Джерела

• Google Search Central: JavaScript SEO basics
• Google Search Central: Make your links crawlable
• Google Search Central: Build and submit a sitemap
• Google Search Central: Software app structured data
• web.dev: Web Vitals
• web.dev: Customize the install experience
• Chrome for Developers: Trusted Web Activity
• Apple: App Store Review Guidelines (розділ 4.2)
• PWABuilder
• IndexNow