四つ目のサイトで AdSense の審査を出しました。審査待ちの状態で ads.txt を置こうとしたところで止まりました。
既存サイトに同じファイルがあります。中身は一行です。コピーして置けば終わりに見えました。
google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0
この pub- で始まる部分がパブリッシャー ID です。ここが合っているかどうかが全てで、そして合っているかは中身を見ても分かりません。
ads.txt が何をしているか
広告枠を買う側から見ると、「このドメインの枠を売る権限を持っているのは誰か」が分かりません。ドメインを騙って他人の枠を売る手口があるからです。
ads.txt はその宣言です。ドメインの持ち主が「この ID の業者に販売を許可している」と書いておく。買う側はそれを読んで、一致しない出品を弾きます。
だから ID が違うと、こうなります。
- そのドメインの枠が認証されていない出品として扱われる
- 一部の広告主が入札から降りる
- 結果として単価が落ちる
広告が完全に止まるわけではありません。静かに減ります。気づきにくいのはそのためです。
複数サイトを持つと、二通りある
| 状況 | ads.txt の中身 |
|---|---|
| 一つの AdSense アカウントに複数サイトを登録 | 全サイト同じ。ID が一つだから |
| サイトごとに別アカウント | それぞれ違う。コピーすると事故になる |
実務では前者が普通です。AdSense は一つのアカウントに複数サイトを登録して運用する設計になっています。
ただし「普通はそうだから」で進めてはいけないのがこの作業です。後者だった場合、他サイトの ID を書くことは「自分のドメインの販売権を他人に渡す」宣言になります。
確認方法を間違えた
ここからが本題です。
同じアカウントかどうかを確かめようとして、両サイトのページソースから pub- を含む文字列を拾って比較しました。審査申請時に広告コードを入れてあるのだから、そこに ID があるはずだという理屈です。
curl -s "https://existing-site.example/ads.txt" | grep -Eo 'pub-[0-9]+' curl -s "https://new-site.example/" | grep -Eo 'pub-[0-9]+' | head -1
結果は不一致。「別アカウントです」と判定しました。
間違いでした。同じアカウントです。
なぜ外したのか
ページソースに出てくる pub- はパブリッシャー ID とは限りません。プラグインが埋め込む識別子、広告プレビュー用のパラメータ、計測タグの一部——形が似ているだけの別物が混ざります。
head -1 で最初の一件を取ったのも悪手でした。出現順に意味はありません。
そして根本的な問題として、この方法は「一致しなかった」ときに何も証明していません。拾った値が ID でなければ、一致しなくて当たり前です。
正しい確認方法
推測の要らない場所が一つあります。
AdSense 管理画面の「サイト」一覧です。そこに新しいドメインが載っていれば、同じアカウントに登録されているということです。それ以上の確認は要りません。
| 確認したいこと | 見る場所 |
|---|---|
| 同じアカウントか | AdSense →「サイト」一覧にドメインがあるか |
| パブリッシャー ID | AdSense →「アカウント」→「アカウント情報」 |
| ads.txt の状態 | 「サイト」一覧の ads.txt のステータス 列 |
一覧を開いて数秒で終わる話でした。ページソースを漁って三十分使ったうえに、間違った結論まで出しています。
審査中に置いていいのか
「不明」というステータスが出ますが、審査中はそれが正常です。
先に置いておく利点があります。承認された瞬間から広告が出るので、そのときファイルが無いと、認証されない出品として扱われる期間が発生します。反映には最大 24 時間かかるので、後追いだとその分だけ取りこぼします。
ID さえ正しければ、置いて損はありません。
アプリを出しているなら app-ads.txt も
アプリ内広告には別のファイルが要ります。app-ads.txt です。
| ads.txt | app-ads.txt | |
|---|---|---|
| 対象 | サイトの広告枠 | アプリの広告枠 |
| 置く場所 | そのドメインの直下 | ストアに登録した開発者サイトの直下 |
| 確認元 | 広告の買い手 | ストア掲載情報から辿られる |
置き場所がアプリ側ではなくサイト側なのが分かりにくいところです。ストアの開発者情報に書いたサイトが参照されるので、そこに無いと紐付きません。
クロールの反映にも時間がかかります。アプリを出す予定があるなら、リリース前に置いておくのが順序として正しいです。
置き場所で気をつけること
どちらもドメイン直下に置きます。下位フォルダに入れると読まれません。
そしてもう一つ。デプロイで消えないかを先に確かめます。
rsync --delete でドキュメントルートを配信していると、手で置いたファイルは次の配信で消えます。ビルド成果物に含まれていないからです。同じサーバーに別プロジェクトが同居している場合はさらに気づきにくくなります。
今回は WordPress のドメインで、そこを対象にした配信スクリプトが存在しないことを確認したうえで手動配置しました。この確認をせずに置くと、いつの間にか消えていて、しかも消えたことに気づきません。
手順
- AdSense の「サイト」一覧で、そのドメインが載っているか見る
- 載っていれば既存サイトと同じ内容。載っていなければ ID を確認する
- ドメイン直下に
ads.txtを置く - 配信スクリプトの対象外か、exclude に入っているかを確認する
- ブラウザで
https://ドメイン/ads.txtを開いて 200 が返るか見る
ステータスが変わるまで最大 24 時間です。置いた直後に「不明」のままでも異常ではありません。
この件で残ったこと
作業自体は五分で終わる種類のものでした。時間を使ったのは確認方法の選び方です。
ページソースから拾う方法を選んだ時点で、答えが出ない道に入っていました。しかも一致しなかったので「別アカウントだ」と結論まで出しています。間違った方法は、間違った答えを自信を持って返します。
管理画面という推測の要らない一次情報が最初からありました。手元で完結する方法を先に試したくなるのが、たぶん罠でした。
この記事について
複数サイトを運用する中で ads.txt を追加した際の記録です。掲載した仕様は 2026 年 8 月時点で確認したものです。
認証されていない出品がどの程度単価に影響するかは公開されておらず、実測もしていません。ステータス反映の所要時間は環境によって変わります。AdSense の仕様は変更されることがあるため、実際の作業前には公式のヘルプをご確認ください。
コメント