ads.txt 驗證工具
貼上 ads.txt 內容即可立即檢測語法錯誤。逐行驗證 DOMAIN、PUBLISHER_ID、RELATIONSHIP（DIRECT/RESELLER）等欄位，幫助您正確設定這份用於防止廣告位被盜用轉售（域名偽裝）的必備檔案。
使用提示
- 基本格式包含 DOMAIN、PUBLISHER_ID、RELATIONSHIP 三個欄位，第 4 個欄位（認證機構 ID）可省略。請數一數逗號數量，確認沒有多餘或缺失。
- RELATIONSHIP 只能是
DIRECT（網站運營方直接簽約）或RESELLER（通過轉售商銷售）之一。規範上不區分大小寫，但慣例使用大寫書寫。 - 以
#開頭的行會被當作註釋忽略。同時寫入CONTACT=、OWNERDOMAIN=等變數指令，有助於廣告系統進行核對。 - ads.txt 必須託管在域名根目錄（
https://example.com/ads.txt）。放在子目錄中廣告系統和爬蟲將無法識別。 - 面向移動應用還有一個名為
app-ads.txt的獨立規範。如果您同時在網站和移動應用上銷售廣告位，兩個檔案都需要設定。
常見問題
廣告投放不會立即完全停止，但 Google 會對未正確設定的網站發出警告，若長期放任不管，部分廣告庫存可能無法售出。建議在 AdSense 管理後臺確認您網站專屬的 ads.txt 程式碼片段，並將其部署到域名根目錄。
DIRECT 表示網站運營方與廣告系統直接簽約，擁有該廣告位的銷售許可權。RESELLER 用於運營方將許可權委託給轉售商（如廣告聯盟）代為銷售廣告位的情形。若同一廣告位通過多個廣告系統銷售，需要分別正確標註各自的關係。這是各廣告系統（Google AdSense、Google Ad Manager、其他 SSP 等）為賬戶簽發的專屬 ID。AdSense 的 ID 以「pub-」開頭，可在管理後臺的設定頁面或 ads.txt 程式碼片段功能中檢視。
因廣告系統和爬蟲而異，但通常會在 24 小時內重新抓取。剛更新檔案後可能需要一段時間才能生效，即使更改後廣告投放情況沒有立即變化也無需擔心。
原則上 ads.txt 是按域名獨立設定的，子域名不會繼承主域名的配置。不過 IAB 規範中提供了
SUBDOMAIN= 指令，可以為特定子域名指定另一份檔案的位置。
閒話 ― ads.txt 誕生的原因 ― 防止廣告位被「冒名轉售」的行業標準
ads.txt（Authorized Digital Sellers）是廣告業界組織 IAB Tech Lab 於 2017 年制定的規範。當時程式化廣告領域盛行一種稱為「域名偽裝」的廣告欺詐行為：第三方未經授權複製並轉售正規釋出商的廣告位。廣告主原本想在優質網站上投放廣告，實際卻出現在毫不相關的低質量網站上，嚴重損害了廣告主與釋出商雙方的信任。
ads.txt 的機制非常簡單：釋出商在自己域名的根目錄下，以純文本檔案形式公開自己授權哪些廣告系統銷售其廣告位。廣告採購系統會讀取這份檔案，驗證要競價的廣告位是否真的通過該域名正式許可的渠道進行交易。由於機制簡單，匯入成本低，釋出後短短幾年內就被大多數主要廣告系統和釋出商採納為行業標準。
Google AdSense 自 2019 年起也在推動 ads.txt 的普及，未正確設定的網站可能會有部分廣告投放受限。對於依靠廣告收入運營的網站而言，ads.txt 並非單純的建議，而是保護收入的實質性必備設定。
IAB Tech Lab 還制定了 ads.txt 的姊妹規範：面向移動應用的 app-ads.txt，以及公開廣告系統方銷售者資訊的 sellers.json。結合使用這些規範，廣告主便能在整條供應鏈中驗證「誰」以「何種關係」銷售「哪個廣告位」。