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

Посібники Після запуску

Як змінити URL, який уже вказано на опублікованій сторінці в магазині

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

Поля URL у Play Console та App Store Connect можна редагувати будь-коли. Ризик не в самому редагуванні, а в проміжку, коли старий URL уже не працює, а сторінка в магазині ще на нього вказує. Спершу опублікуйте нову адресу, потім оновіть сторінку в магазині, а стару залиште з переспрямуванням.

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

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

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

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

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

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

Порядок, який нічого не ламає

  1. Опублікуйте новий URL і перевірте його без входу в обліковий запис. Він має працювати до того, як щось на нього вказуватиме.
  2. Налаштуйте переспрямування зі старої адреси на нову. Не видаляйте — переспрямуйте. Саме цей крок пропускають, і саме він вас рятує.
  3. Оновіть поля в консолях. Play Console → App content для URL політики конфіденційності й видалення даних; App Store Connect для політики конфіденційності й Support URL. Google Play вимагає, щоб політика “is available on an active URL” (була доступна за активним URL), — тож поле ніколи не повинне вказувати на щось мертве, навіть ненадовго.
  4. Оновіть посилання всередині застосунку. Політика Play User Data вимагає посилання на політику конфіденційності в Play Console і в самому застосунку, а посилання в застосунку зазвичай жорстко прописане у збірці, яку ви випустили кілька місяців тому. Користувачі старої версії потрапляють на старий URL, доки не оновляться, а дехто не оновиться ніколи.
  5. Залиште переспрямування на місці. Не на тиждень — безстроково, якщо можете.

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

Чому стара адреса має й далі відповідати

Поле в консолі — це адреса, яку ви контролюєте. Але це не єдине місце, де існує старий URL:

  • Випущені двійкові файли застосунку. Кожна встановлена копія кожної попередньої версії містить посилання на старий URL. Оновити їх ви не можете; це роблять користувачі — колись, а дехто ніколи.
  • Кеш сторінки в магазині й сайти-агрегатори, які зібрали дані з вашої сторінки.
  • Листи й квитанції, які ви вже надіслали.
  • Записи рекламних мереж, якщо старий хост був вашим заявленим вебсайтом розробника.

Тож «старий URL не працює, але поле оновлено» — правда лише з вашого боку.

Виняток: app-ads.txt не можна переспрямовувати

Один особливий випадок, і саме він непомітно коштує грошей. Рекламні мережі завантажують /app-ads.txt із кореня вебсайту, вказаного на сторінці застосунку в магазині, а специфікація передбачає, що файл віддається напряму. Переспрямування перед ним часто спричиняє результат «not found», навіть коли сам файл цілком правильний.

Тож якщо старий хост був вашим заявленим вебсайтом розробника і ви залишаєте його як переспрямування, /app-ads.txt на цьому хості має віддаватися з кодом 200, а не переспрямовуватися, доки стару адресу ще можуть сканувати. Усе інше може віддавати 301; цей один шлях — ні.

Що перевірити після переїзду

Виконайте це без входу в обліковий запис, у приватному вікні:

curl -i https://old-host.example/privacy        # expect 301 to the new URL
curl -i https://new-host.example/privacy        # expect 200
curl -i https://old-host.example/app-ads.txt    # expect 200 text/plain, NOT a redirect

Потім у консолях: кожне поле URL відкриває правильну сторінку, а відповіді в Data safety / App Privacy досі збігаються з тим, що написано на нових сторінках. Перенесення сторінки — добрий момент помітити, що політика застаріла ще два SDK тому.

Зміна, яку непросто скасувати

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

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

Дві речі побудовано саме навколо цієї проблеми.

Випадкова адреса вашого застосунку постійна. Кожен застосунок під час створення отримує app-xxxxxx.appfoyer.page, і ця адреса ніколи не змінюється — навіть якщо згодом на платному тарифі ви займете власний піддомен, початкова адреса й далі відповідає тим самим сайтом — без переспрямування і без терміну дії. Адреса, яку ви рік тому вставили в поле консолі, не перестане працювати через те, що ви щось перейменували.

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

А оскільки постійна адреса віддає сам сайт, а не переспрямовує, /app-ads.txt відповідає з кодом 200 і там, і на поточній адресі — правило вище виконується без жодного налаштування.

Першоджерела