跳到正文
AppFoyer
免费开始

指南 app-ads.txt

app-ads.txt 是什么，以及它必须放在哪里

一段话讲清这个文件，逐字段讲解行格式，决定一切能否生效的那条位置规则，以及没有网站时该怎么办。

app-ads.txt 是一个纯文本文件，列出获准销售你应用广告资源的广告公司。它位于你商店页面中所填网站的 /app-ads.txt，广告网络会抓取它来核实卖方是否获得授权。平台子域名也可以：AdMob 会验证 AppFoyer 子域名上的文件。不展示广告就不需要这个文件。

1:22
1:22 视频 · 在 YouTube 上打开

几分钟就能搞定

AppFoyer 托管本指南所讲的页面——隐私政策、服务条款、支持、账号删除和 app-ads.txt——放在它们自己的子域名上，你无需自己的域名或服务器。一个应用免费，而且商店要求的任何内容都绝不放在付费墙后面。

免费开始 查看在线示例

核查于 2026年10月12日。 商店政策会变，有时不会事先通知。下文所有内容都链接到官方文档，以那个页面为准，而不是本页。如果两者不一致，以商店为准。 本指南译自英文；引用的商店文档保留英文原文。

app-ads.txt 是一个纯文本文件，列出获准销售你应用广告资源的广告公司。它位于你在商店页面中声明的网站的 /app-ads.txt，广告网络会抓取它，以核实提供你广告资源的一方确实获得了你的授权。没有它，买方就无法确认这一点，而这正是这项标准存在的全部理由。

如果你的应用不展示广告，你根本不需要这个文件。如果展示，它大约需要十分钟——其中九分钟花在把位置弄对上，这也是唯一经常出错的部分。

它解决什么问题

广告资源会被转售。在你的应用和广告主之间，有交易平台、转售商和各种中间方；在 ads.txt 及其面向应用的姊妹标准出现之前，买方没有低成本的办法分辨“这确实是那个应用的广告资源”和“有人声称在销售它”。欺诈之所以奏效，是因为这种声称无法核实。

解决办法刻意做得很简单：发布者在一个只有发布者自己能控制的地址上，公布允许为其销售的名单。买方抓取文件并进行比对。这就是全部机制，也是为什么地址比内容更重要——一个任何人都能放上去的文件证明不了任何东西。

行格式

每行一个授权卖方，三个必填字段和一个可选字段，用逗号分隔：

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
字段含义
google.com广告系统的域名——广告网络自己的规范域名，而不是你的。
pub-0000000000000000你在该广告网络的发布商 ID。从它们的控制台复制。
DIRECT 或 RESELLER如果你与它们有直接合同，用 DIRECT；如果你授权它们转售，用 RESELLER。
f08c47fec0942fa0可选的认证机构 ID，在广告网络公布了该 ID 时填写。

# 之后的任何内容都是注释。以 contact=、subdomain=、inventorypartnerdomain= 等开头的行是变量，而不是卖方记录，保持原样即可。

大多数损坏的文件源于两个错误：漏了一个逗号，导致整行无法解析；以及从支持论坛上粘贴了别人的发布商 ID，等于授权一个陌生人销售你的广告资源。每个广告网络的控制台都会显示它需要的确切那一行——用那一行，而不是模板。

它必须放在哪里——决定一切的部分

爬虫不知道你的包名，也不会按应用来查找你。它读取你商店页面中的开发者网站 URL，然后在该域名的根目录抓取 /app-ads.txt。商店页面的 URL 填错了，一个完全正确的文件也会无从被发现。

AdMob 公布了探测规则，值得读一遍，而不是靠猜：

  • 根目录指的是 “the directory following the top level domain”（译：顶级域名之后的那一级目录）——即 example.com/app-ads.txt，而不是 example.com/some/path/app-ads.txt。
  • 爬虫会 “probe up to one subdomain level from the developer website when constructing an app-ads.txt URL”（译：在构造 app-ads.txt URL 时，从开发者网站最多向上探测一级子域名）。对于指向 support.help.example.com/game 的商店页面，AdMob 自己的示例显示它会尝试 help.example.com/app-ads.txt 和 example.com/app-ads.txt。
  • www. 和 m. 不作为子域名位置，它们会被归并为域名本身。

除了地址之外，返回方式也必须中规中矩地正确：HTTP 200、Content-Type: text/plain，前面没有重定向，不需要登录，不靠 JavaScript 渲染，robots.txt 中也没有任何东西阻止它。一个只有在从 http 重定向到 https、或从根域名重定向到 www 之后才出现的文件，是一种常见且完全看不见的失败。

像爬虫那样检查它：

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

你希望看到 200 OK、text/plain，没有 Location: 头，并且响应正文里是你的那些行。

“可是我没有网站”

对独立开发者来说，这是常态，也是为什么那么多应用根本没有这个文件。

要求的是一个你能控制、并能返回文件的主机名——而不是要求你有营销网站、公司域名或落地页。AdMob 直接说明了这一点：“If you don’t have a suitable website that allows the uploading of an app-ads.txt file at the root level, you can use Firebase Hosting to host your app-ads.txt file.”（译：如果你没有合适的网站可以在根目录上传 app-ads.txt 文件，可以使用 Firebase Hosting 来托管你的 app-ads.txt 文件。）平台托管是被预期的做法，而不是变通手段。无网站指南逐一介绍了可选方案。

无论你用什么，有两件事必须在上线那一周之后也一直成立：地址必须保持不变，因为它印在一个你以后不会再去想的商店页面里；它必须持续以纯文本返回，不能在有人第一次“改进”配置时让一个重定向悄悄挡在前面。

你改了什么，不会立刻生效

广告网络按自己的节奏重新抓取。AdMob 表示 “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files”（译：AdMob 抓取并验证你的 app-ads.txt 文件可能需要最多 24 小时），而其他广告网络更慢。一个一小时前上传、仍显示为缺失的文件，几乎总是只是还没到时候——在改动其他任何东西之前，请先看未找到问题指南。

AppFoyer 在这里做什么

你应用的页面在其自己的子域名上提供 app-ads.txt——纯文本、200、无重定向，并带有规范要求的响应头——而且编辑器会在你输入时逐行校验，所以漏掉的逗号会在爬虫看到之前就被发现。你把这个子域名设为商店页面中的开发者网站，它位于 appfoyer.page 下一级。

AdMob 会在那里验证它：2026 年 10 月，对于开发者网站是 AppFoyer 地址的应用，AdMob 报告了 “app-ads.txt file found and verified”（译：已找到并验证 app-ads.txt 文件）。我们目前还没有来自其他广告网络的抓取结果。

权威来源