ads.txt 驗證工具
貼上 ads.txt 內容即可立即檢測語法錯誤。逐行驗證 DOMAIN、PUBLISHER_ID、RELATIONSHIP（DIRECT/RESELLER）等欄位，幫助您正確設定這份用於防止廣告位被盜用轉售（域名偽裝）的必備檔案。
什麼是 ads.txt
ads.txt（Authorized Digital Sellers）是網站經營者用來聲明「哪些廣告系統有權銷售本站廣告版位」的文字檔案，由 IAB Tech Lab 制定為業界標準，須部署在網域根目錄（https://example.com/ads.txt）。規範要求每一行以逗號分隔 DOMAIN（廣告系統網域）、PUBLISHER_ID（帳戶 ID）、RELATIONSHIP（DIRECT 或 RESELLER）共 3～4 個欄位，哪怕只寫錯一個字元，廣告系統核對時也會判定失敗，使原本應正常售出的廣告版位被視為「未授權」。
本工具會逐行解析貼上的 ads.txt 內容，檢測欄位數量不符、空欄位、DOMAIN 格式錯誤、RELATIONSHIP 拼寫有誤（非 DIRECT/RESELLER 的值）等問題，同時能正確辨識以 # 開頭的註解行，以及 CONTACT=、SUBDOMAIN=、OWNERDOMAIN= 等變數指令，並與一般記錄行分開顯示。也支援直接輸入網址，抓取現有網站的 ads.txt 進行驗證。
ads.txt 驗證工具的使用方法
- 準備 ads.txt 內容 整理好您網站目前使用的檔案內容，或即將發布的新內容。
- 貼到輸入框，或透過網址取得 可直接貼到文字框，也可以在「從 URL 獲取」欄輸入網域讀取現有的 ads.txt。
- 查看驗證結果 逐行確認每一行被判定為正確、錯誤、變數還是註解。
- 修正有誤的行 依照備註欄中列出的具體原因（如欄位數量不足、DOMAIN 格式錯誤）改寫對應的行。
-
確認無誤後部署到網域根目錄
全部顯示為正確後，將檔案發布為
https://yourdomain.com/ads.txt。
用好本工具的小技巧
- 基本格式包含 DOMAIN、PUBLISHER_ID、RELATIONSHIP 三個欄位，第 4 個欄位（認證機構 ID）可省略。請數一數逗號數量，確認沒有多餘或缺失。
- RELATIONSHIP 只能是
DIRECT（網站運營方直接簽約）或RESELLER（通過轉售商銷售）之一。規範上不區分大小寫，但慣例使用大寫書寫。 - 以
#開頭的行會被當作註釋忽略。同時寫入CONTACT=、OWNERDOMAIN=等變數指令，有助於廣告系統進行核對。 - ads.txt 必須託管在域名根目錄（
https://example.com/ads.txt）。放在子目錄中廣告系統和爬蟲將無法識別。 - 面向移動應用還有一個名為
app-ads.txt的獨立規範。如果您同時在網站和移動應用上銷售廣告位，兩個檔案都需要設定。
這些場景派得上用場
Google AdSense 審核前的自我檢查
為了順利通過 AdSense 審核或消除廣告投放警示，事先檢查已部署的 ads.txt 是否存在語法錯誤。
導入新的廣告系統（SSP）時
在新增新的 SSP 或廣告聯播網提供的一行內容時，當場確認逗號數量與欄位寫法是否正確。
CMS 遷移或網站改版後的確認
透過網址獲取功能直接驗證正式環境，檢查 WordPress 遷移或伺服器搬遷是否導致 ads.txt 亂碼或換行錯亂。
多網域、多站點的統一盤點
廣告代理商或媒體經營者在對旗下多個網站的 ads.txt 進行集中盤點時，可作為標準化驗證步驟使用。
驗證外部提供的程式碼片段
在把廣告聯播網寄來的 ads.txt 追加片段正式併入自家檔案之前，先單獨做語法檢查。
詞彙表
- ads.txt
- IAB Tech Lab 制定的規範，用於聲明廣告版位的正規銷售方，須部署在網域根目錄。
- DIRECT
- 表示網站經營方與廣告系統直接簽約，自行擁有該廣告版位銷售許可權的 RELATIONSHIP 值。
- RESELLER
- 當經營方將銷售許可權委託給轉售商（如廣告聯播網）代為銷售廣告版位時使用的 RELATIONSHIP 值。
- 認證機構 ID（Certification Authority ID）
- 第 4 個可省略的欄位，指 TAG（Trustworthy Accountability Group）等機構核發的廣告系統識別碼。
- 網域偽裝
- 第三方未經授權複製、轉賣正規廣告版位，誘導廣告主的廣告投放到其他網站上的詐欺行為。ads.txt 正是為了防止這種情況而誕生的。
- Authorized Digital Sellers
- ads.txt 的正式名稱，意為「已獲授權的數位銷售方」，體現了整套規範的核心理念。
- PUBLISHER_ID
- 各廣告系統為每個帳戶核發的識別碼。AdSense 使用的 ID 以「pub-」開頭。
- SSP（Supply-Side Platform）
- 將發布商一方的廣告版位對接給廣告主競價系統的中介平台。ads.txt 的 DOMAIN 欄位中填寫的正是 SSP 的網域。
常見問題
DIRECT 表示網站運營方與廣告系統直接簽約，擁有該廣告位的銷售許可權。RESELLER 用於運營方將許可權委託給轉售商（如廣告聯盟）代為銷售廣告位的情形。若同一廣告位通過多個廣告系統銷售，需要分別正確標註各自的關係。subdomain= 宣告；未宣告的子網域的 ads.txt 不會被爬蟲讀取。
閒話 ― 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。結合使用這些規範，廣告主便能在整條供應鏈中驗證「誰」以「何種關係」銷售「哪個廣告位」。