Mengubah URL yang sudah ada di listingan toko yang aktif

Cepat atau lambat Anda akan pindah: host gratis ditutup, domain kedaluwarsa, perusahaan berganti nama, atau Anda akhirnya membuat situs sungguhan yang selama ini Anda rencanakan. Kolom-kolomnya bisa diedit, jadi perubahannya sendiri sepele. Yang menjebak adalah semua hal lain yang diam-diam masih mengarah ke alamat lama.

Urutan yang tidak merusak apa pun

1. Publikasikan URL baru dan periksa dalam keadaan tidak login. URL itu harus sudah tayang sebelum ada apa pun yang mengarah ke sana.
2. Buat alamat lama mengalihkan (redirect) ke alamat baru. Bukan dihapus — dialihkan. Inilah langkah yang sering dilewati, dan justru langkah inilah yang menyelamatkan Anda.
3. Perbarui kolom di konsol. Play Console → App content untuk URL kebijakan privasi dan penghapusan data; App Store Connect untuk kebijakan privasi dan Support URL. Google Play meminta agar kebijakan “is available on an active URL” (tersedia di URL yang aktif) — jadi kolom itu tidak boleh mengarah ke sesuatu yang mati, bahkan sebentar.
4. Perbarui tautan di dalam aplikasi Anda. Kebijakan User Data milik Play mewajibkan tautan kebijakan privasi di Play Console dan di dalam aplikasi itu sendiri, dan tautan di dalam aplikasi biasanya tertanam di build yang Anda rilis berbulan-bulan lalu. Pengguna versi lama terus membuka URL lama sampai mereka memperbarui, dan sebagian tidak akan pernah memperbarui.
5. Biarkan pengalihan tetap ada. Bukan selama seminggu — selamanya, jika bisa.

Melakukannya dengan urutan sebaliknya — mengubah kolom terlebih dahulu, atau menghapus host lama terlebih dahulu — adalah cara Anda berakhir dengan listingan aktif yang mengarah ke 404 saat tinjauan sedang berjalan.

Mengapa alamat lama harus tetap menjawab

Kolom di konsol adalah alamat yang Anda kendalikan. Itu bukan satu-satunya tempat URL lama berada:

• Binary aplikasi yang sudah dirilis. Setiap salinan terinstal dari setiap versi sebelumnya menautkan URL lama. Anda tidak bisa memperbaruinya; pengguna yang memperbaruinya, pada akhirnya, dan sebagian tidak akan pernah.
• Cache listingan toko dan situs agregator yang menyalin listingan Anda.
• Email dan tanda terima yang sudah Anda kirim.
• Catatan jaringan iklan, jika host lama adalah situs web developer yang Anda deklarasikan.

Jadi “URL lama mati tetapi kolomnya sudah diperbarui” hanya benar dari sisi Anda.

Pengecualiannya: app-ads.txt tidak boleh dialihkan

Satu kasus khusus, dan inilah yang diam-diam merugikan secara finansial. Jaringan iklan mengambil /app-ads.txt di root situs web yang ada di listingan toko Anda, dan spesifikasi mengharapkannya disajikan secara langsung. Pengalihan di depannya adalah penyebab umum hasil “not found” meskipun filenya sepenuhnya benar.

Jadi jika host lama adalah situs web developer yang Anda deklarasikan, dan Anda mempertahankannya sebagai pengalihan, /app-ads.txt di host itu sebaiknya disajikan dengan 200, bukan dialihkan, selama alamat lama mungkin masih di-crawl. Semua yang lain boleh 301; satu path itu tidak boleh.

Apa yang perlu diperiksa setelah pindah

Jalankan ini dalam keadaan tidak login, di jendela pribadi:

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

Lalu di konsol: setiap kolom URL membuka halaman yang benar, dan jawaban Data safety / App Privacy masih sesuai dengan isi halaman baru. Memindahkan halaman adalah momen yang tepat untuk menyadari bahwa kebijakan sudah usang sejak dua SDK yang lalu.

Perubahan yang tidak mudah dibatalkan

URL adalah identitas, bukan pengaturan. Begitu pernah ada di listingan toko, URL itu ada di tempat-tempat yang tidak Anda kendalikan, karena itulah perpindahan ini layak dilakukan sekali, dengan sengaja, ke alamat yang Anda harapkan akan dipertahankan. Pertanyaan yang perlu diajukan tentang host mana pun sebelum Anda menempelkan URL-nya ke kolom konsol bukanlah “apakah gratis”, melainkan “apakah alamat persis ini masih akan menjawab dua tahun lagi, dan bisakah saya mengalihkannya jika tidak”.

Apa yang dilakukan AppFoyer di sini

Dua hal dibangun tepat untuk masalah ini.

Alamat acak aplikasi Anda bersifat permanen. Setiap aplikasi mendapat app-xxxxxx.appfoyer.page saat dibuat dan alamat itu tidak pernah berubah — bahkan jika nanti Anda mengklaim subdomain kustom di paket berbayar, alamat aslinya tetap menjawab dengan situs yang sama — tanpa pengalihan, dan tanpa masa kedaluwarsa. Alamat yang Anda tempelkan ke kolom konsol setahun lalu tidak berhenti berfungsi karena Anda mengganti nama sesuatu.

Subdomain kustom yang Anda ganti langsung dilepaskan. Ganti satu, dan alamat lamanya langsung berhenti menjawab — tanpa pengalihan — dan siapa pun bisa mengklaimnya, termasuk akun lain. Jadi jangan pernah memasang subdomain kustom di listingan yang mungkin akan Anda ubah nanti: alamat permanen di atas adalah alamat yang dijamin tetap berfungsi.

Dan karena alamat permanen menyajikan situs itu sendiri alih-alih mengalihkan, /app-ads.txt menjawab dengan 200 di sana maupun di alamat saat ini — aturan di atas terpenuhi tanpa ada yang perlu disiapkan.

Sumber resmi

• Privacy policy requirements — Bantuan Google Play, untuk kata-kata “available on an active URL”.
• User Data policy — Bantuan Google Play, untuk aturan konsol plus di dalam aplikasi.
• Set up app-ads.txt — Bantuan AdMob, untuk cara file ditemukan.
• App Store Connect — app information — Apple, untuk letak kolom-kolomnya.