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（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。结合使用这些规范，广告主便能在整条供应链中验证「谁」以「何种关系」销售「哪个广告位」。