公開中のストア掲載情報にある URL を変更する

いずれは移転のときが来ます。無料のホストがサービスを終える、ドメインが失効する、会社名が変わる、あるいはずっと作るつもりだった本物のサイトを作った、など。項目は編集可能なので、変更そのものは簡単です。つまずくのは、古いアドレスを黙って指し続けているほかのすべてです。

何も壊さない手順

1. 新しい URL を公開し、サインアウト状態で確認する。 何かがそれを指す前に、公開されていなければなりません。
2. 古いアドレスを新しいアドレスへリダイレクトさせる。 削除ではなくリダイレクトです。これは飛ばされがちな手順で、あなたを救う手順でもあります。
3. コンソールの項目を更新する。 プライバシーポリシーとデータ削除の URL は Play Console → App content、プライバシーポリシーと Support URL は App Store Connect です。Google Play はポリシーが “is available on an active URL”（訳：有効な URL で利用できること）を求めています。そのため、項目はたとえ一瞬でも死んだものを指してはいけません。
4. アプリ内のリンクを更新する。 Play の User Data ポリシーは、プライバシーポリシーへのリンクを Play Console とアプリ自体の中の両方に求めています。アプリ内のリンクは通常、何か月も前に出荷したビルドにハードコードされています。古いバージョンのユーザーはアップデートするまで古い URL を開き続け、アップデートしない人もいます。
5. リダイレクトを残しておく。 1 週間ではなく、できれば無期限に。

逆の順番で行うと — 先に項目を変える、あるいは先に古いホストを削除する — 審査の最中に公開中の掲載情報が 404 を指している、という事態になります。

古いアドレスが応答し続けなければならない理由

コンソールの項目はあなたが管理できるアドレスです。しかし古い URL が存在する場所はそこだけではありません。

• 出荷済みのアプリバイナリ。 これまでのすべてのバージョンの、インストール済みのすべてのコピーが古い URL にリンクしています。あなたはそれを更新できません。ユーザーがいずれ更新しますが、しない人もいます。
• ストアの掲載情報のキャッシュと、掲載情報を収集したアグリゲーターサイト。
• すでに送信したメールや領収書。
• 広告ネットワークの記録（古いホストが申告済みのデベロッパーウェブサイトだった場合）。

つまり「古い URL は死んでいるが項目は更新済み」というのは、あなた側から見た場合にしか成り立ちません。

例外：app-ads.txt はリダイレクトしてはいけない

特別なケースが 1 つあり、それは黙ってお金を失わせるものです。広告ネットワークはストアの掲載情報にあるウェブサイトのルートで /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 の回答が新しいページの内容とまだ一致していることを確認します。ページを移すのは、ポリシーが 2 つ前の SDK のときから古くなっていたことに気づく良い機会です。

簡単には元に戻せない変更

URL は設定ではなくアイデンティティです。一度ストアの掲載情報に載れば、あなたが管理できない場所に存在することになります。だからこそ移転は、使い続けるつもりのアドレスで、意図的に、一度だけ行う価値があります。あるホストの URL をコンソールの項目に貼り付ける前に問うべきは「無料かどうか」ではなく、「この正確なアドレスは 2 年後も応答するか、そうでなければリダイレクトできるか」です。

AppFoyer がここで行うこと

まさにこの問題を中心に、2 つのことが設計されています。

アプリのランダムなアドレスは永続的です。 すべてのアプリは作成時に app-xxxxxx.appfoyer.page を受け取り、そのアドレスは変わりません。後で有料プランでカスタムサブドメインを取得しても、元のアドレスは同じサイトで応答し続けます。リダイレクトはなく、期限もありません。1 年前にコンソールの項目に貼り付けたアドレスが、何かの名前を変えたせいで動かなくなることはありません。

置き換えたカスタムサブドメインはすぐに解放されます。 置き換えると古いアドレスは即座に応答しなくなり — リダイレクトもありません — 別のアカウントを含め誰でも取得できます。ですから、後で変えるかもしれない掲載情報にカスタムサブドメインを載せないでください。動き続けることが保証されているのは、上の永続的なアドレスです。

そして永続的なアドレスはリダイレクトせずにサイトそのものを配信するため、/app-ads.txt は現在のアドレスだけでなく永続的なアドレスでも 200 で応答します。上のルールは、何も設定せずに満たされます。

公式の情報源

• Privacy policy requirements — Google Play ヘルプ。“available on an active URL” という文言について。
• User Data policy — Google Play ヘルプ。コンソールとアプリ内の両方というルールについて。
• Set up app-ads.txt — AdMob ヘルプ。ファイルの探され方について。
• App Store Connect — app information — Apple。各項目の場所について。