Перейти до вмісту
AppFoyer
Почати

Посібники Перед поданням

Чи потрібен вашому застосунку вебсайт?

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

Як такий — ні: у жодному магазині немає поля, яке вимагає маркетинговий сайт. Але Google Play вимагає посилання на політику конфіденційності на сторінці застосунку в магазині, рекламні мережі шукають app-ads.txt у корені вебсайту, який ви вказуєте, і обидва магазини хочуть доступних URL-адрес. На практиці вам потрібні сторінки, а не вебсайт.

1:04
Відео, 1:04 · відкривається на YouTube

Зробіть це за кілька хвилин

AppFoyer розміщує сторінки, про які цей посібник, — політику конфіденційності, умови, підтримку, видалення акаунта та app-ads.txt — на власному піддомені, без вашого домену й сервера. Один застосунок — безкоштовно, і ніщо з того, чого вимагає магазин, ніколи не буває за платним доступом.

Почати безкоштовно Переглянути живий приклад

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

Розробники ставлять це запитання, чекаючи «так» чи «ні», і отримують суперечливі відповіді, бо ті, хто відповідає, відповідають на різні запитання. Ось усі чотири, окремо.

1. Чи вимагає магазин маркетинговий вебсайт?

Ні. У консолі немає поля з назвою «вебсайт», без якого подання не пройде.

На сторінці застосунку в магазині Google Play є поле website у Store settings → Store listing contact details, поруч з електронною поштою і номером телефону. Електронна пошта обов’язкова для публікації; вебсайт — ні. В App Store Connect є Marketing URL, прямо позначена як необов’язкова.

Тож якщо запитання звучить як «чи мушу я зробити лендинг зі скриншотами і кнопкою завантаження» — ні.

2. Чи вимагає щось URL-адресу?

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

ВимогаПотрібна URL-адреса?
Політика конфіденційностіТак. User Data policy від Play: “All apps must post a privacy policy link in the designated field within Play Console, and a privacy policy link or text within the app itself.” (Переклад: «Усі застосунки мають розмістити посилання на політику конфіденційності у відповідному полі в Play Console, а також посилання на політику конфіденційності або її текст у самому застосунку».) Apple: обов’язкове поле Privacy Policy
Видалення облікового записуТак, якщо у вашому застосунку є облікові записи. Публічна вебадреса, вказана в Play Console у розділі App content → Data deletion
ПідтримкаТак, в Apple. Поле Support URL обов’язкове
app-ads.txtТак, якщо ви показуєте рекламу. Мережі отримують його з кореня вебсайту розробника, указаного на сторінці застосунку в магазині

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

3. То чому поле «вебсайт розробника» все одно важливе?

Через app-ads.txt. Цей файл знаходять не через ваш застосунок, не через назву пакета і не через ваш рекламний акаунт — його знаходять через URL-адресу вебсайту, указану на сторінці застосунку в магазині. Краулер читає це ім’я хоста й отримує /app-ads.txt з його кореня.

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

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

4. А домашня сторінка застосунку?

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

  • дає полю вебсайту на сторінці застосунку в магазині справжню адресу, на яку можна вказати;
  • дає рецензентові, який відкриває ваші URL-адреси, цілісну картину замість п’яти відірваних юридичних сторінок;
  • дає краулерові app-ads.txt ім’я хоста, яке контролюєте ви.

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

Без чого можна обійтися

  • Без домену, якщо ви його ще не хочете. Дивіться хостинг без домену.
  • Без маркетингового сайту, якщо ви не займаєтеся маркетингом.
  • Без блогу, прес-кіта, розсилки. Ніщо з цього не стосується відповідності вимогам.
  • Без сервера — для всього, крім видалення облікового запису, якому потрібне щось, що може приймати запит, а не лише віддавати файли.

У якому порядку це робити

  1. Оберіть одне ім’я хоста, яке обслуговуватиме все це.
  2. Опублікуйте на ньому сторінки політики конфіденційності, умов, підтримки і видалення облікового запису.
  3. Розмістіть у його корені просту домашню сторінку.
  4. Укажіть це ім’я хоста як вебсайт на сторінці застосунку в магазині.
  5. Додайте app-ads.txt у корінь, якщо показуєте рекламу.

Потім заповніть поля в консолі — не раніше, інакше ви вкажете в полі сторінку, якої ще не існує.

Що тут робить AppFoyer

Саме так і влаштований продукт: ваш застосунок отримує власний піддомен із домашньою сторінкою, сторінками політики конфіденційності, умов, підтримки і видалення облікового запису, плюс app-ads.txt у корені — без домену, без сервера, без власного бекенда. Ви вказуєте цей піддомен як вебсайт розробника на сторінці застосунку в магазині, і кожну з чотирьох вимог вище закриває одне й те саме ім’я хоста.

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

Авторитетні джерела