app-ads.txt 是什麼，以及它必須放在哪裡
用一段話說明這個檔案、逐欄解說每行的格式、決定一切能否運作的那條擺放位置規則，以及沒有網站時該怎麼辦。
app-ads.txt 是一個純文字檔，列出獲准銷售你應用程式廣告空間的廣告公司。它位於你商店資訊頁上所列網站的 /app-ads.txt，廣告聯播網會擷取它來確認賣方是否經過授權。平台子網域也可以：AdMob 會驗證 AppFoyer 子網域上的檔案。沒有廣告就不需要這個檔案。
改用幾分鐘完成這件事
AppFoyer 託管這篇指南所談的頁面：隱私權政策、服務條款、支援、帳戶刪除和 app-ads.txt，放在各自的子網域上，你不需要自己的網域或伺服器。一個應用程式免費，而且商店要求的任何內容都不會放在付費牆後面。
查核日期：2026年10月12日。 商店政策會變動，有時不會事先通知。以下所有內容都附上官方文件的連結，具有權威的是那個頁面，而不是本頁。如果兩者不一致，以商店為準。 本指南譯自英文；引用的商店文件保留英文原文。
app-ads.txt 是一個純文字檔，列出獲准銷售你應用程式廣告空間的廣告公司。它位於你在商店資訊頁中申報之網站的 /app-ads.txt，廣告聯播網會擷取它，確認提供你廣告空間的一方確實獲得你的授權。沒有它，買方就無法確認這一點，而這正是這項標準存在的全部理由。
如果你的應用程式不顯示廣告，就完全不需要這個檔案。如果有顯示，大約只需要十分鐘——其中九分鐘花在把位置弄對，這也是唯一經常出錯的部分。
它解決什麼問題
廣告空間會被轉售。在你的應用程式和廣告主之間，有交易平台、轉售商和各種中間商，而在 ads.txt 及其應用程式版的兄弟標準出現之前，買方沒有便宜的方法分辨「這確實是那個應用程式的廣告空間」和「有人聲稱在銷售它」。詐騙之所以行得通，是因為這種聲稱無法驗證。
解決方法刻意採用低技術：發布商在只有自己能掌控的位址上，公布允許代為銷售的對象清單。買方擷取這個檔案並加以比對。這就是整套機制，也是為什麼位址比內容更重要——一個任何人都能放上去的檔案，什麼也證明不了。
每行的格式
每行一個獲授權的賣方，三個必填欄位和一個選填欄位，以逗號分隔：
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
| 欄位 | 意義 |
|---|---|
google.com | 廣告系統的網域——廣告聯播網自己的標準網域，而不是你的。 |
pub-0000000000000000 | 你在該廣告聯播網的發布商 ID。從它們的資訊主頁複製。 |
DIRECT 或 RESELLER | 如果你與它們有直接合約就用 DIRECT；如果你授權它們轉售則用 RESELLER。 |
f08c47fec0942fa0 | 選填的認證機構 ID，在廣告聯播網有公布時使用。 |
# 之後的任何內容都是註解。以 contact=、subdomain=、inventorypartnerdomain= 等開頭的行是變數，不是賣方紀錄，會被略過。
大多數損壞的檔案都出自兩種錯誤：少了一個逗號，導致整行無法解析；以及從支援論壇貼上別人的發布商 ID，等於授權一個陌生人銷售你的廣告空間。每個廣告聯播網的資訊主頁都會顯示它要的確切那一行——請使用它，而不是範本。
它必須放在哪裡：決定一切的部分
爬蟲不知道你的套件名稱，也不會依應用程式查找你。它會讀取你商店資訊頁上的開發人員網站網址，然後在該網域的根目錄擷取 /app-ads.txt。商店資訊頁上的網址一旦弄錯，一個完全正確的檔案也會變得看不見。
AdMob 有記載它的探測規則，值得讀一次，而不是用猜的：
- 根目錄的意思是 “the directory following the top level domain”（譯文：頂層網域之後的目錄）——是
example.com/app-ads.txt，而不是example.com/some/path/app-ads.txt。 - 爬蟲會 “probe up to one subdomain level from the developer website when constructing an app-ads.txt URL”（譯文：在建構 app-ads.txt 網址時，從開發人員網站往下最多探測一層子網域）。對於指向
support.help.example.com/game的商店資訊頁，AdMob 自己的範例顯示它會嘗試help.example.com/app-ads.txt和example.com/app-ads.txt。 www.和m.不算子網域位置，因此會視同網域本身。
除了位址之外，提供檔案的方式也必須平凡而正確：HTTP 200、Content-Type: text/plain、前面沒有重新導向、不需要登入、不靠 JavaScript 呈現，而且 robots.txt 中沒有任何東西封鎖它。一個只有在從 http 重新導向到 https，或從根網域重新導向到 www 之後才出現的檔案，是一種常見而且完全看不出來的失敗。
用爬蟲的方式檢查它：
curl -i https://your-domain.example/app-ads.txt
你要的是 200 OK、text/plain、沒有 Location: 標頭，而且內容中有你的那幾行。
「可是我沒有網站」
這是獨立開發者的常態，也是為什麼這麼多應用程式根本沒有這個檔案。
這項要求是一個你能掌控、能提供檔案的主機名稱——而不是要求你擁有行銷網站、公司網域或到達網頁。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 檔案。）平台託管是預期中的做法，而不是權宜之計。沒有網站的指南逐一說明了各種選項。
無論你用什麼，有兩件事必須在上線那一週之後長期成立：位址必須維持不變，因為它印在一個你不會再去想的商店資訊頁上；而且它必須持續提供純文字，不能在第一次有人「改善」設定時，悄悄在前面多出一個重新導向。
你修改之後，不會立刻生效
廣告聯播網會依自己的排程重新爬取。AdMob 表示 “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files”（譯文：AdMob 可能需要最多 24 小時來爬取並驗證你的 app-ads.txt 檔案），其他廣告聯播網則更慢。一個小時前才上傳、看起來仍然找不到的檔案，幾乎總是只是時間還太早——在修改其他任何東西之前，請先參閱找不到檔案的指南。
AppFoyer 在這裡做什麼
你應用程式的頁面會在它自己的子網域上提供 app-ads.txt——純文字、200、沒有重新導向，並附上規格要求的標頭——而編輯器會在你輸入時驗證每一行，所以少了逗號會在爬蟲看到之前就被發現。你把這個子網域設為商店資訊頁中的開發人員網站，它位於 appfoyer.page 之下一層。
AdMob 會在那裡驗證它：2026 年 10 月，對於開發人員網站為 AppFoyer 網址的應用程式，AdMob 回報了 “app-ads.txt file found and verified”（譯文：已找到並驗證 app-ads.txt 檔案）。我們目前還沒有來自其他廣告聯播網、由我們自己取得的爬取結果。
權威來源
- Set up app-ads.txt：AdMob 說明。上文引述的爬蟲規則和子網域範例出自此頁。
- ads.txt / app-ads.txt specification：IAB Tech Lab。規格本身，也是每行語法的權威來源。