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