定义
Ads.txt（网页用）和 app-ads.txt（移动应用与 CTV 用）是 IAB Tech Lab 制定的标准：发行商在固定路径托管一个简单文本文件，列出被授权销售其库存的交易平台、广告网络和转售方账户 ID。买方和交易平台抓取这些文件，以验证竞价请求确实来自授权卖家。
所在链路
发行商在 ads.txt 中声明卖家 → 交易平台与 DSP 抓取并比对文件 → 未授权库存被从竞价流中过滤
为什么重要
没有授权卖家文件，欺诈者就能冒充优质域名和应用骗取广告预算，因此 ads.txt 是保护发行商收入和买方预算的基础信任信号。
Ads.txt 及其移动端的同胞 app-ads.txt，是程序化广告中最廉价、杠杆率最高的信任机制之一。两者都是发行商托管在固定位置的纯文本文件，都为每个买家回答一个直白的问题：「提供这次展示机会的公司，真的有权出售它吗？」如果答案是否定的，这条竞价就该被忽略。把这个是/否判断应用到每天数十亿次请求上，就能把很大一部分域名和应用冒充挡在公开竞价之外。
文件里到底有什么
Ads.txt 文件位于 yourdomain.com/ads.txt。每一行写明一个销售系统（交易平台或 SSP 的规范域名）、发行商在该系统上的卖家账户 ID、DIRECT（直接）或 RESELLER（转售）关系类型，以及一个可选的认证机构 ID。App-ads.txt 工作方式相同，但面向移动应用和联网电视——那里没有网站可供抓取。应用商店列表会指向一个开发者域名，抓取程序就去查找 developerdomain.com/app-ads.txt。格式刻意做得很「无聊」：没有 JSON、没有 API，只有机器能解析、人也能读的若干行。
当交易平台收到一条声称代表某发行商的竞价请求时，它可以把请求中的卖家账户与发行商声明的文件比对。来自未列入账户的请求，按定义就是未授权的，正规买家会将其过滤掉。这正是该标准与广告交易平台和 SSP 的底层管道天然契合的原因——文件之所以有意义，是因为这些系统会读取并执行它们。
为什么发行商和买家都在意
对发行商而言，文件保护收入。在 ads.txt 出现之前，欺诈者可以声称在某优质新闻域名上出售展示、压低真正发行商的价格，从而截走本不该离开合法供应链的预算。声明授权卖家让这种套利可被检测。对买家而言，文件是更干净买量的基础：它让每一笔花费都能追溯到获批卖家，并能剪除那些只增费用、不增价值的间接路径——这正是供应路径优化的目标。
该标准还与需求的收集方式相互作用。在头部竞价架构中，发行商可能同时与十几个伙伴合作，而其中每个伙伴——以及他们经手的任何转售方——都必须出现在文件里，否则那部分需求会悄悄消失。保持完整而不仅是正确，才能让填充率不受损。
把它做对
最常见的失误是文件不完整。每个直接伙伴和链条中的每个转售方都需要一行，交易平台会发布官方条目，你应原样复制而非凭记忆输入。第二常见的失误是把 app-ads.txt 托管在与应用商店列表声明域名不符的域名上，这会让抓取程序完全忽略它。把文件当作活的基础设施：在增减伙伴的当天就更新，并重新校验，以免一个笔误悄悄掐断合法需求。
如果你正在搭建程序化技术栈，请走一遍完整的程序化路径，让授权卖家文件与它依赖的交易平台、SSP 和验证工具并列。
常见问题
Ads.txt 和 app-ads.txt 能阻止所有广告欺诈吗？ 不能。它们专门针对未授权转售以及域名或应用冒充，对无效流量、机器人或可见度问题毫无作用，那些需要单独的验证工具。
文件应该多久更新一次？ 销售伙伴变动时就更新，并至少每季度审查一次。已停止合作伙伴的过期条目会不必要地拓宽你的供应路径。
App-ads.txt 究竟放在哪里？
放在你应用商店条目中列出的开发者域名上的 /app-ads.txt——不是营销微站，也不是商店列表未引用的 URL。
新手常见误区
- 漏列某些转售方或中间商账户，导致合法需求从竞价流中掉线。
- 把 app-ads.txt 托管在错误的 URL 或与商店列表声明域名不符的开发者站点上。
- 把该文件当作一劳永逸，而不是在增减销售伙伴时及时更新。