Zmiana adresu URL, który jest już na opublikowanej stronie aplikacji w sklepie

Prędzej czy później się przenosisz: darmowy hosting jest zamykany, domena wygasła, firma zmieniła nazwę albo zbudowałeś w końcu prawdziwą witrynę, którą zawsze planowałeś. Pola są edytowalne, więc sama zmiana jest banalna. Ludzi zaskakuje cała reszta, która po cichu wskazuje na stary adres.

Kolejność, która niczego nie psuje

1. Opublikuj nowy adres i sprawdź go bez logowania. Musi działać zanim cokolwiek na niego wskaże.
2. Ustaw przekierowanie ze starego adresu na nowy. Nie usuwaj — przekieruj. Ten krok ludzie pomijają, a to on Cię ratuje.
3. Zaktualizuj pola w konsolach. Play Console → App content w przypadku adresów polityki prywatności i usuwania danych; App Store Connect w przypadku polityki prywatności i Support URL. Google Play wymaga, aby polityka „is available on an active URL” (była dostępna pod aktywnym adresem URL) — więc pole nigdy nie może wskazywać czegoś martwego, nawet na chwilę.
4. Zaktualizuj linki w swojej aplikacji. Zasady Play dotyczące danych użytkownika (User Data) wymagają linku do polityki prywatności w Play Console oraz w samej aplikacji, a ten w aplikacji jest zwykle wpisany na sztywno w build, który wydałeś kilka miesięcy temu. Użytkownicy starej wersji trafiają na stary adres, dopóki nie zaktualizują aplikacji, a niektórzy nigdy tego nie zrobią.
5. Zostaw przekierowanie na miejscu. Nie na tydzień — na zawsze, jeśli możesz.

Zrobienie tego w odwrotnej kolejności — najpierw zmiana pola albo najpierw usunięcie starego hostingu — to sposób, by skończyć z opublikowaną stroną w sklepie wskazującą na 404 w trakcie recenzji.

Dlaczego stary adres musi nadal odpowiadać

Pole w konsoli to adres, który kontrolujesz. Nie jest to jedyne miejsce, w którym istnieje stary adres:

• Wydane pliki binarne aplikacji. Każda zainstalowana kopia każdej poprzedniej wersji linkuje do starego adresu. Nie możesz ich zaktualizować; użytkownicy w końcu to robią, a niektórzy nigdy.
• Pamięć podręczna sklepu i serwisy agregujące, które pobrały Twoją stronę w sklepie.
• E-maile i potwierdzenia, które już wysłałeś.
• Rekordy sieci reklamowych, jeśli stary host był Twoją zadeklarowaną witryną dewelopera.

Zatem „stary adres nie działa, ale pole jest zaktualizowane” jest prawdą tylko z Twojej strony.

Wyjątek: app-ads.txt nie może być przekierowany

Jeden szczególny przypadek, i to ten, który po cichu kosztuje pieniądze. Sieci reklamowe pobierają /app-ads.txt z katalogu głównego witryny podanej na stronie aplikacji w sklepie, a specyfikacja zakłada, że plik jest udostępniany bezpośrednio. Przekierowanie przed nim to częsta przyczyna wyniku „nie znaleziono”, nawet gdy sam plik jest całkowicie poprawny.

Jeśli więc stary host był Twoją zadeklarowaną witryną dewelopera i zostawiasz go jako przekierowanie, /app-ads.txt na tym hoście powinien być udostępniany z kodem 200, a nie przekierowywany, tak długo, jak stary adres może być jeszcze pobierany. Wszystko inne może zwracać 301; ta jedna ścieżka nie.

Co sprawdzić po przeniesieniu

Uruchom te polecenia bez logowania, w oknie prywatnym:

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

Potem w konsolach: każde pole z adresem otwiera właściwą stronę, a odpowiedzi w Data safety / App Privacy nadal zgadzają się z tym, co mówią nowe strony. Przenoszenie strony to dobry moment, żeby zauważyć, że polityka zdezaktualizowała się dwa SDK temu.

Zmiana, której nie cofniesz łatwo

Adres URL to tożsamość, a nie ustawienie. Gdy raz trafił na stronę aplikacji w sklepie, istnieje w miejscach, których nie kontrolujesz — dlatego przeniesienie warto zrobić raz, świadomie, na adres, który zamierzasz zachować. Pytanie, które warto zadać o każdy hosting, zanim wkleisz jego adres w pole konsoli, to nie „czy jest darmowy”, ale „czy dokładnie ten adres będzie nadal odpowiadał za dwa lata, a jeśli nie, czy mogę go przekierować”.

Co robi tutaj AppFoyer

Dwie rzeczy są zbudowane dokładnie wokół tego problemu.

Losowy adres Twojej aplikacji jest stały. Każda aplikacja dostaje przy tworzeniu app-xxxxxx.appfoyer.page i ten adres nigdy się nie zmienia — nawet jeśli później zajmiesz własną subdomenę w płatnym planie, pierwotny adres nadal odpowiada tą samą witryną — bez przekierowania i bez daty wygaśnięcia. Adres, który rok temu wkleiłeś w pole konsoli, nie przestaje działać dlatego, że coś przemianowałeś.

Zastąpiona własna subdomena jest zwalniana od razu. Gdy ją zastąpisz, stary adres natychmiast przestaje odpowiadać — bez przekierowania — i każdy może go zająć, także inne konto. Dlatego nigdy nie umieszczaj własnej subdomeny na stronie w sklepie, którą możesz później zmienić: to stały adres opisany wyżej ma gwarancję, że będzie działał.

A ponieważ stały adres udostępnia samą witrynę, zamiast przekierowywać, /app-ads.txt odpowiada tam kodem 200, tak samo jak pod bieżącym adresem — powyższa zasada jest spełniona bez żadnej konfiguracji.

Źródła oficjalne

• Privacy policy requirements — Pomoc Google Play, źródło sformułowania „available on an active URL”.
• User Data policy — Pomoc Google Play, źródło zasady „konsola plus aplikacja”.
• Set up app-ads.txt — Pomoc AdMob, o tym, jak plik jest wyszukiwany.
• App Store Connect — app information — Apple, gdzie znajdują się poszczególne pola.