修改已在上线商店详情中的 URL

在应用发布后迁移隐私政策或删除页面：按照绝不留下失效链接的顺序进行，以及为什么旧地址应当继续响应。

你随时都可以编辑 Play Console 和 App Store Connect 中的 URL 字段。风险不在于编辑本身——而在于旧 URL 已经失效、商店详情却仍然指向它的那段空档。先发布新地址，再更新商店详情，并让旧地址保持重定向。

1:11

1:11 视频 · 在 YouTube 上打开

几分钟就能搞定

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

免费开始查看在线示例

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

迟早有一天你会迁移：免费主机要关闭了，域名过期了，公司改名了，或者你终于做好了一直想做的正式网站。这些字段都可以编辑，所以修改本身微不足道。让人栽跟头的，是其他所有悄悄指向旧地址的东西。

不会弄坏任何东西的顺序

发布新 URL，并在未登录状态下检查。 它必须在任何东西指向它之前就已上线。
让旧地址重定向到新地址。 不是删除——是重定向。这是人们会跳过的一步，也正是能救你的一步。
更新控制台字段。 隐私政策和数据删除 URL 在 Play Console → App content 中；隐私政策和 Support URL 在 App Store Connect 中。Google Play 要求政策 “is available on an active URL”（译文：可通过一个有效的 URL 访问）——所以该字段绝不能指向失效的内容，哪怕只是短暂的。
更新应用内的链接。 Play 的 User Data（用户数据）政策要求在 Play Console 以及应用内都提供隐私政策链接，而应用内的那个链接通常硬编码在你几个月前发布的构建中。使用旧版本的用户在更新之前会一直访问旧 URL，而有些人永远不会更新。
保留重定向。 不是保留一周——如果可以的话，无限期保留。

如果按其他顺序来——先改字段，或者先删掉旧主机——你最终就会在审核进行期间，让一个上线中的商店详情指向一个 404。

为什么旧地址必须继续响应

控制台字段是你能控制的地址。但它不是旧 URL 唯一存在的地方：

已发布的应用二进制文件。 每个旧版本的每一份已安装副本都链接着旧 URL。你无法更新它们；用户最终会更新，而有些人永远不会。
商店详情缓存以及抓取了你列表的聚合网站。
你已经发出的电子邮件和收据。
广告网络的记录，如果旧主机是你声明的开发者网站。

所以，“旧 URL 失效了但字段已更新”只是从你这一侧来看才成立。

例外：`app-ads.txt` 不能被重定向

有一个特殊情况，而它恰恰会悄无声息地让你损失收入。广告网络在你商店详情中网站的根目录抓取 /app-ads.txt，规范要求它被直接提供。即使文件完全正确，它前面的重定向也是导致“未找到”结果的常见原因。

所以，如果旧主机是你声明的开发者网站，而你把它保留下来做重定向，那么只要旧地址仍可能被抓取，该主机上的 /app-ads.txt 就应该以 200 提供，而不是被重定向。其他一切都可以 301；唯独这一个路径不行。

迁移后要检查什么

在无痕窗口中、未登录状态下运行这些命令：

curl -i https://old-host.example/privacy        # expect 301 to the new URL
curl -i https://new-host.example/privacy        # expect 200
curl -i https://old-host.example/app-ads.txt    # expect 200 text/plain, NOT a redirect

然后在各个控制台中确认：每个 URL 字段都能打开正确的页面，并且 Data safety / App Privacy 的回答仍然与新页面的内容一致。迁移页面正是发现政策早在两个 SDK 之前就已过时的好时机。

难以撤销的改动

URL 是一种身份，而不是一项设置。一旦它出现在商店详情中，它就存在于你无法控制的地方，这就是为什么迁移值得只做一次、经过深思熟虑、迁到一个你打算长期保留的地址上。在把任何主机的 URL 粘贴到控制台字段之前，要问的问题不是“它是否免费”，而是“这个确切的地址两年后是否仍会响应，如果不会，我能否重定向它”。

AppFoyer 在这里做什么

有两项设计正是围绕这个问题构建的。

你应用的随机地址是永久的。 每个应用在创建时都会获得 app-xxxxxx.appfoyer.page，而且这个地址永远不会改变——即使你之后在付费套餐上申请了自定义子域名，原地址也会继续以同一个网站响应——不重定向，也没有期限。你一年前粘贴到控制台字段中的地址，不会因为你改了某个名字而失效。

你替换掉的自定义子域名会立即释放。 替换一个之后，旧地址会立刻停止响应——没有重定向——任何人都可以申请它，包括其他账号。所以，绝不要把一个你以后可能会更改的自定义子域名放进商店详情：上面提到的永久地址才是保证持续有效的那个。

而且由于永久地址直接提供网站本身而不是重定向，/app-ads.txt 在永久地址和当前地址上都以 200 响应——上面那条规则无需任何设置即可满足。

权威来源

Privacy policy requirements — Google Play 帮助中心，“available on an active URL”这一措辞的出处。
User Data policy — Google Play 帮助中心，关于控制台加应用内的规则。
Set up app-ads.txt — AdMob 帮助中心，关于如何定位该文件。
App Store Connect — app information — Apple，说明各字段的位置。