ウェブサイトがないときの app-ads.txt のホスティング
クローラーが本当に必要とするもの、サイトを作らずにホストを用意する 3 つの方法、それぞれのリダイレクトの落とし穴、動作の確認方法。
ウェブサイトは必要ありません。必要なのは、/app-ads.txt をプレーンテキストで、HTTP 200、リダイレクトなしで配信する、自分で管理できるホスト名だけです。そのアドレスをストアの掲載情報のデベロッパーウェブサイト項目(App Store では Marketing URL)に入れれば、クローラーはそこでファイルを読み取ります。AdMob は Firebase Hosting を許容できるものとして挙げています。
数分で済ませる方法もあります
AppFoyer は、このガイドで扱っているページ(プライバシーポリシー、利用規約、サポート、アカウント削除、そして app-ads.txt)を、専用のサブドメインでホストします。自分のドメインもサーバーも要りません。アプリ 1 つまでは無料で、ストアが求めるものが有料プランの壁の向こうに置かれることは決してありません。
2026年10月12日 に確認。 ストアのポリシーは、予告なく変わることもあります。以下の内容はすべて公式ドキュメントにリンクしており、拠り所となるのはこのページではなくそちらです。両者が食い違う場合は、ストアが正しいものとしてください。 このガイドは英語からの翻訳です。ストアのドキュメントからの引用は原文の英語のまま掲載しています。
ウェブサイトは必要ありません。必要なのは、/app-ads.txt をプレーンテキストで、HTTP 200、リダイレクトなしで配信する、自分で管理できるホスト名だけです。 そのアドレスをストアの掲載情報のデベロッパーウェブサイト項目— App Store では Marketing URL、Google Play では Store listing contact details の Website — に入れれば、クローラーはそこでファイルを読み取ります。
AdMob ははっきりとこう述べています。“If you don’t have a suitable website that allows the uploading of an app-ads.txt file at the root level, you can use Firebase Hosting to host your app-ads.txt file.”(訳:ルートレベルに app-ads.txt ファイルをアップロードできる適切なウェブサイトがない場合は、Firebase Hosting を使って app-ads.txt ファイルをホストできます。)プラットフォームのホスティングは回避策ではなく、想定された答えです。
クローラーが本当に必要とするもの
クローラーはパッケージ名でアプリを調べるわけではありません。ストアの掲載情報からデベロッパーのウェブサイトを取り出し、ホスト名だけを残して、そのルートにある /app-ads.txt を取得します。AdMob のルールは次のとおりです。
- パスではなくルート。
example.com/myappを指す掲載情報は、example.com/app-ads.txtで確認されます。 - サブドメインは 1 階層まで。 クローラーは “probe[s] up to one subdomain level from the developer
website”(訳:デベロッパーのウェブサイトから 1 階層までのサブドメインを調べます)。
www.とm.はドメインそのものとして扱われます。 - 素直に配信されること。
200 OK、Content-Type: text/plain、リダイレクトなし、ログインなし、robots.txtでのブロックなし。
つまりやるべきことは、移動しない 1 つのアドレスで、1 つのテキストファイルを、正しく、何年も配信し続けることです。以下の 3 つの方法はどれもそれを実現できます。違いは、どれだけ自分で保守するかです。
方法 1:Firebase Hosting
AdMob が名前を挙げている方法です。無料の Firebase プロジェクトで your-project.web.app のようなホスト名が得られます。
- Firebase コンソールでプロジェクトを作成し、Firebase CLI をインストールします。
- 空のフォルダで
firebase init hostingを実行し、デフォルトのpublicディレクトリのままにします。 - 生成された
index.htmlの隣、public/にapp-ads.txtを置きます。 firebase deploy --only hostingを実行します。- 各ストアの掲載情報で、
https://your-project.web.appをデベロッパーのウェブサイトとして設定します。
落とし穴:後でカスタムドメインを接続し、web.app のアドレスをそこへリダイレクトするよう選ぶと、掲載情報のアドレスはリダイレクトを返すようになります。掲載情報を、ファイルを直接配信するアドレスのままにするか、掲載情報を新しいドメインに更新してください。
方法 2:GitHub Pages などの静的ホスト
宣言するホスト名のルートにファイルが置かれるなら、どの静的ホストでも使えます。
GitHub Pages ではこの点が重要です。プロジェクトサイトは username.github.io/repo/ にありますが、クローラーが確認するのは username.github.io/app-ads.txt だけです。ファイルはユーザーサイト — username.github.io という名前のリポジトリ — に置くか、プロジェクトに独自のカスタムドメインを設定する必要があります。
同じリダイレクトの落とし穴がここにもあります。カスタムドメインを設定すると、GitHub Pages は github.io のアドレスをそこへリダイレクトします。経由なしでファイルを配信するほうのアドレスを宣言してください。
方法 3:ホスト型のコンプライアンスページ
プライバシーポリシー、サポートページ、アカウント削除の URL も必要なら — そして広告のあるアプリには、ほぼ必ず最初のものが必要です — 同じホストでそれらすべてを配信できます。AppFoyer が行っているのはそれです。各アプリに専用のサブドメインが割り当てられ、ストアが求めるページと並んで app-ads.txt をプレーンテキスト、リダイレクトなしで配信します。デベロッパーのウェブサイトが AppFoyer のアドレスである両ストアのアプリについて、AdMob は “app-ads.txt file found and verified” と報告しています(2026 年 10 月確認)。ほかの広告ネットワークについては、まだ当社独自のクロール結果はありません。
クローラーより先に確認する
curl -i https://your-host.example/app-ads.txt
期待する結果は、HTTP/2 200(または HTTP/1.1 200 OK)、content-type: text/plain、location: ヘッダーがないこと、本文にあなたの行があることです。ここでの 301 や 302 は、最もよくある見えない失敗です。
それから待ちます。AdMob によれば “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files”(訳:AdMob が app-ads.txt ファイルをクロールして確認するまでに最大 24 時間かかることがあります)。ステータスは Apps → View all apps → app-ads.txt にあります。1 日経ってもまだ not found なら、not found のガイドで原因を順に確認してください。
公式の情報源
- Set up app-ads.txt — AdMob ヘルプ。Firebase Hosting についての一文、ルートとサブドメインのルール、24 時間という数字はこのページによります。
- Understand app-ads.txt file statuses — AdMobヘルプ。ステータスの確認場所とそれぞれの意味。
- ads.txt / app-ads.txt specification — IAB Tech Lab。