为什么 AdMob 说找不到你的 app-ads.txt

当广告网络报告 app-ads.txt 未找到时，几乎总是以下六个机械性原因之一： 商店详情中没有开发者网站、网站 URL 指向的位置没有该文件、文件前面有重定向、内容类型错误、某一行格式有误，或者抓取根本还没有运行。它们都与你的应用、你的账号或你的广告单元无关。

app-ads.txt 是一项 IAB 标准，让广告网络能够确认销售你应用广告资源的一方确实获得了授权。广告网络通过 商店详情中显示的网站 URL 找到它——这就是为什么上面的原因都与这个 URL 有关，而不是与应用本身有关。

爬虫如何找到这个文件

这条链有三个环节，任何一环断开都会产生同样的提示：

1. 广告网络从你的商店详情中读取开发者网站 URL。
2. 它在该域名的根目录抓取 /app-ads.txt。
3. 它查找一行同时写有该广告网络和你的发布商 ID 的记录。

所以，这个文件不是通过你的应用、你的包名或你的 AdMob 账号找到的，而是通过商店详情中显示的网站 URL 找到的。这一步错了，其他一切都无关紧要。

六个常见原因

列表中没有网站 URL。 最常见的情况。如果商店详情没有开发者网站，爬虫就无从下手。在 App Store 上，这个字段是可选的 Marketing URL，而不是必填的 Support URL——参见 iOS 应用的 app-ads.txt。

URL 指向的位置没有该文件。 列表写的是 example.com，但文件在 www.example.com 上，或者放在某个页面路径下而不是域名根目录。

重定向。 规范要求文件被直接提供。一连串重定向——哪怕只是 http → https，或根域名 → www——都是常见的失败原因。请在列表所写的地址上以 200 提供该文件。

内容类型错误。 它必须以纯文本形式提供。以 text/html 提供的文件，或者被托管平台包装进页面的文件，都无法被解析。

行本身有拼写错误。 格式很严格——domain, publisher id, relationship, certification id——少一个逗号或多一个空格都会让这一行失效。

抓取根本还没有运行。 广告网络按自己的时间表重新抓取，通常以天计而不是以分钟计。一个小时前上传的文件显示为缺失，通常只是还太早。

十秒钟自己检查

curl -i https://your-domain.example/app-ads.txt

你需要看到 200 OK、Content-Type: text/plain、没有 Location: 头，并且正文中有你的那些行。如果 curl 一切正常而广告网络仍然不认，问题就在上游：列表中的 URL，或者抓取时间表。

关于子域名

规范所指的是商店详情中声明的域名的根目录，而子域名有它自己的根目录。因此，当列表声明的正是 yourapp.example.page/app-ads.txt 这个地址时，从这里提供文件是符合规范的。

AdMob 记录了这一做法所依赖的规则：它的爬虫会 “probe[s] up to one subdomain level from the developer website”（译文：从开发者网站起最多探测一级子域名），并且它把 Firebase Hosting 这类平台托管列为可以存放该文件的地方。

AdMob 会验证 AppFoyer 子域名上的文件。 2026 年 10 月，对于开发者网站为 AppFoyer 地址的两个商店上的应用，AdMob 报告了 “app-ads.txt file found and verified”（已找到并验证 app-ads.txt 文件）。更早的一次抓取，即 2026 年 9 月 23 日那次，曾将其中一个应用报告为未找到；现在它已通过，而我们这边没有做任何改动。如果 AdMob 对你的 AppFoyer 地址显示“未找到”，请逐一排查上面的原因，并给抓取留出 24 小时。我们目前还没有来自其他广告网络的抓取结果。

AppFoyer 在这里做什么

我们以纯文本、无重定向、带有规范所要求的头的方式提供该文件，为常见的广告网络提供预设，并在你输入时逐行验证。我们不承诺某个特定的广告网络一定会接受它——参见上一段。

权威来源

• Set up app-ads.txt — AdMob 帮助中心
• app-ads.txt / ads.txt specification — IAB Tech Lab