app-ads.txt 是一个体积很小、地位很高的纯文本文件。它替广告平台回答一个问题：谁有权出售你的应用里的广告库存？它是网页端 ads.txt 在应用生态里的对应标准，AdMob 与绝大多数主流广告网络都用它把一款已上架的应用，重新绑回真正拥有这份库存的发布商账号。把文件发布出去，是一个十分钟的活；让它真正通过验证，才是卡住大多数开发者的地方——因为它的失败是静默的：没有报错、没有邮件，只是你的应用始终拿不到那份本该属于它的「已验证」状态。
这份清单按真实操作顺序展开，全部基于 Google 官方 AdMob 帮助文档：搭好开发者网站、在商店列表里把它关联上、把 app-ads.txt 发布到域名根目录、用浏览器确认这个 URL 能打开、让 AdMob 爬虫找到它、读懂验证状态，并在卖家名单变化时保持文件最新。贯穿始终的只有一条规则：域名、商店列表与发布商 ID，必须指向同一个真实的发布商。
一、app-ads.txt 到底是什么，以及它为什么存在
这份文件由 IAB Tech Lab 定义，是 ads.txt 在应用生态里的延伸。它的用意既简单又偏防守：与其让买方去相信一条自称来自你应用的竞价请求，不如让买方去核对一份由发布商自己掌控的公开授权名单。不在这份名单上的卖家，出价请求就可以被过滤掉——这正是伪装应用与未授权转售难以变现的原因。
对 AdMob 而言，这份文件是 Google 确认「申请变现的发布商账号」与「商店列表背后的开发者」是同一个人的方式。文件发布正确，你的 AdMob 账号里会得到已验证状态；文件缺失或格式不对，应用即便还在出广告，也始终处于未验证状态。这个落差，就是这份清单存在的理由。
二、前提：一个与商店列表关联的开发者网站
AdMob 不会去猜你的域名。它读取的是你应用商店列表里的开发者网站，并从中推导出主机名。如果这个字段是空的，或者指向一个社交主页、一个占位域名、一个表单搭建器的链接，那么爬虫就无处可查——此时无论你怎么发文件都无济于事。
- Google Play。把开发者网站 URL 填进开发者联系信息。要确认生效，检查应用商店页的「应用支持」处是否已显示 Developer Website URL。
- App Store。把 URL 填进应用列表的 marketing URL（营销网址）字段（App 信息），并确认它出现在产品页上。
- 时间。如果你刚刚新增或修改了列表里的网站，请给 AdMob 最多 24 小时去感知这处变化，再期待它去抓取。
如果你目前还没有一个能在根目录上传文件的网站，这并不是死结——Firebase Hosting 是官方给出的可选做法之一，可以用来托管你的 app-ads.txt 文件。
三、第一步：把文件发布在域名根目录
文件必须能通过列表推导出的主机名、以根目录形式访问，也就是：
https://<hostname>/app-ads.txt
http://<hostname>/app-ads.txt所谓「根目录」，指的是紧跟顶级域名之后的位置——对 example.com 而言，文件要放在 example.com/app-ads.txt，而不是某个项目子目录里。在做别的任何事之前，先用浏览器把这个 URL 打开：如果文件内容能直接显示，爬虫大概率就能找到它；如果浏览器弹的是登录墙、需要 JavaScript 才渲染、或者直接变成下载，那先解决这些，再谈验证。
四、第二步：发布商 ID 与那一行的确切格式
文件里每一行代表一个授权卖家，格式由 IAB 规范固定：
<广告系统域名>, <发布商账号 ID>, <关系>, <认证机构 ID>Google 那一行用你的 AdMob 发布商 ID（账号里的 pub-… 值）作为账号 ID，关系写 DIRECT，认证机构 ID 用 Google 的 TAG 编号：
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0这一行不需要你手敲。AdMob 会提供一段已经嵌好你发布商 ID 的个性化代码片段；而「发布商 ID 必须包含且格式正确」是官方明确的验证前提。用纯文本编辑器（记事本、TextEdit，或任意文本编辑器，不要用富文本文档）新建文件，粘贴这段片段，再为你合作的每一个其他广告网络各加一行——每个网络都会公布自己的 app-ads.txt 信息。文件若不符合 IAB 格式，无论你的 ID 多正确都不会通过验证。
五、第三步：搞清 AdMob 爬虫是怎么找文件的
爬虫根据你列表里开发者网站的主机名来构造 URL，并遵循一套固定顺序。先弄懂规则，能挡掉一整类「文件明明就在那儿」的困惑。
- 协议顺序。它先查 HTTPS，再查 HTTP。
- 子域名。爬虫最多只探测一级子域。若列表指向
support.help.example.com，它会去help.example.com，再去example.com，而绝不会去看二级子域support.help.example.com。 - 被排除的子域。规范把
www.与m.排除在检查位置之外——所以列表指向www.example.com，最终仍会解析到example.com。 - 跳转。你的服务器可以把爬虫重定向到托管在别处的文件，包括
www.子域、静态托管或 CDN——跳转是允许的。不过，能直接返回内容的文件，少一个可能悄悄出错的环节。 - robots.txt。在
robots.txt里放行 AdMob 爬虫。把它挡住，是「文件找不到」里一类很常见的、自己造成的原因。
六、第四步：等待抓取，必要时手动请求一次
AdMob 会例行抓取你最新的文件，而完成抓取与验证最多可能需要 24 小时。如果你正等着一份刚发布的文件，可以请求它更快地看一眼：
- 登录 AdMob，打开 应用（Apps），再点 查看所有应用。
- 打开 app-ads.txt 页，展开你想检查的那款应用所在行。
- 点击 检查更新（Check for updates）。
两个细节能让等待更省心。手动重新抓取会更新所有共用同一份 app-ads.txt 文件的应用状态，所以你基本不需要逐款请求。另外，这个按钮有时会不可用——此时例行抓取仍在进行，请老老实实等满 24 小时，而不是反复去改文件。
七、第五步：读懂验证状态，并从状态反推问题
AdMob 里的 app-ads.txt 页会显示每款应用的状态与抓取详情。请把它当作唯一的事实来源，而不是上周的一张截图。如果文件没被找到或未通过验证，状态详情会指向原因，Google 也提供了专门的排障路径。
最常见的原因，按出现频率排序：商店列表的开发者网站字段为空或不可用；文件放在某个路径里而不是根目录；发布商 ID 缺失或格式错误；robots.txt 挡住了爬虫；或者列表刚改过，AdMob 还没来得及重新读取。
八、十二项 app-ads.txt 验证清单
按顺序跑完下面十二项。每一项都对应上文的一条规则，也都是爬虫会默默替你打分的点。
- 存在一个开发者网站，且你掌控着它的域名。
- 该 URL 已写进商店列表——Play 的开发者网站，或 App Store 的营销网址——并能在应用的支持区看到。
app-ads.txt位于域名根目录，即https://<hostname>/app-ads.txt。- 这个 URL 能在浏览器里直接显示文件内容。
- 文件是纯文本，而不是排版文档或图片。
- 你的 AdMob 发布商 ID 已在其中，且符合 IAB 的行格式，包含 Google 那一行。
- 你使用的每个其他广告网络，都各有一行。
- 文件在爬虫真正检查的根域或一级子域上可达——而不是只在更深的子域上可达。
robots.txt放行 AdMob 爬虫。- 若你改过列表里的网站，已给 AdMob 留足最多 24 小时去感知。
- 需要更快抓取时，已点过 检查更新，并等满了 24 小时窗口。
- 卖家名单变化时，你重新核对状态并保持文件最新。
九、KappS 的协助范围
app-ads.txt 只是决定一款变现应用能否真正拿到钱的那条长链上的一环：开发者账号、付款资料、税务信息与发布商身份，必须彼此对上。KappS 帮开发者在这条链上准备并提交合规材料，好让某一处验证——无论是 app-ads.txt、身份还是税务——不会在日后悄悄把钱卡住。落到实处，就是检查商店列表、域名与发布商 ID 是否描述着同一个真实发布商，并在爬虫或审核人员发现之前，把对不上的地方修好。
我们不做的事，是凭空制造授权。app-ads.txt 存在的意义，恰恰是曝光那些并非自己所声称身份的发布商；把一个你无权代表的卖家列进去属于造假，它会把账号和收款一起置于风险之中，也不是我们提供的服务。唯一能长久通过验证的方式，就是真的成为这款应用背后的发布商。
资料来源（Google 官方帮助）：AdMob Help — Set up an app-ads.txt file for your app；Understand app-ads.txt file statuses；Troubleshoot app-ads.txt issues；About the content crawler（support.google.com/admob）。IAB Tech Lab — app-ads.txt 规范。