从＂零下载＂到找到原因:一个 App Store 关键词索引问题的诊断故事

我为我的 iOS 应用跑了一个零预算拉用户的计划，大概进行了三十轮。下载量：零。在这段时间里，我一直把"零下载"当作一个模糊信号，可能是没有需求，可能是没有曝光，可能是没有测量手段。

现在这个问题基本搞清楚了。答案不是推广问题，而是一个被关掉的开关。

（这个应用是 SproutGuard，一个免费的设备端屏幕时间应用。它是下面测量的对象，不是推销，而且请看到最后的更正，因为我的标题结论其实是错的。）

测量过程

我横扫了 59 个关键词 × 6 个上架区域（美国、英国、加拿大、澳大利亚、爱尔兰、新西兰），用的是公开的 iTunes 搜索接口，limit=200，中立的 User-Agent。

这两个命中是 screen time detox 和 screen detox。它们 完全由应用标题里已有的词组成。我是用程序确认的，而不是靠肉眼判断，因为这种模式正是你会自己说服自己"看到了"的那种。

在全部 6 个国家，连第 200 名都查不到的：app blocker、block apps、phone addiction、dopamine detox、digital detox、stop doomscrolling、social media blocker、distraction blocker、self control、screen time limit、reduce screen time、focus timer、adhd focus、attention span、brain rot、habit streak、unplug，还有 40 多个。

一个用户打开 App Store 输入 app blocker，这是屏幕时间应用最明显的搜索词，在我的任何一个上架区域都找不到我的应用。不是排名靠后，而是 查无此应用。

这不是一个能用更好的推广手段解决的排名问题。这是一个没有进入自己品类关键词索引的商店列表，它比我想过的十几个理论都更好地解释了那条平缓的曲线。

为什么花了三十轮才发现：两个测量工具故障

我想写这篇文章的原因不是结果，而是我本来可以在第二天就得到这个结果。阻止我的是 我的测量工具悄悄地出了错，而我从来没有检查过它们。

问题 1: User-Agent 改变了 Apple 返回的排名

我记录的所有排名数字，都来自一个向 itunes.apple.com/search 发送 User-Agent: Mozilla/5.0 的脚本。出于直觉，我只改了那个请求头。同一个查询，同一分钟，每种测三次：

每个条件下十次测试结果完全一致。不是随机波动，每个 User-Agent 的结果是确定性的。而且两个结果集 是不同的集合，不是重新排序：三个应用只在浏览器 UA 下出现，三个只在中立的 UA 下出现。

所以浏览器 UA 查到的排名比实际高出了大约 15 个名次。而我写过的每一句自信的话，"连续六次稳定在 #22"、"跌到 #31，有记录以来最差"，都来自一个值取决于没人刻意选择的 HTTP 请求头的数字。

差点让我错过这个问题的是：我的第一次跨区域扫描返回了 #41，而监控器在同一分钟打印了 #26。最舒服的解释是 API 不稳定。你自己的两个测量值不一致，这是一个发现，不是噪音。

我还追过一个看似合理但错误的方向，我一开始怪罪 limit=50 和 limit=100 的区别，直到验证了 50 条列表就是 100 条列表的前缀才放弃。这个经历值得记录，因为它看起来太像真的了。

问题 2: 从数据中心 IP 无法检查搜索结果

另外，我一直在用脚本通过 site: 查询检查我的网站是否被各大搜索引擎收录。连续几周，这些检查都返回"未找到结果"，我一直把这个当作真实信号记录下来。

然后我真正看了看返回的内容。site: 查询我自己的域名，返回了十个来自中文问答网站的结果。这个操作符根本没有生效。

原因很普通，而且影响全面：这台机器的出口 IP 是 Azure 东京数据中心地址。从那里出发：

• Google 返回 /sorry/，直接 429 封禁
• DuckDuckGo 返回机器人验证码（"请选择所有包含鸭子的方块"）
• Bing 强制重定向到 cn.bing.com，悄悄地丢弃了 site: 操作符，返回无关的区域结果，HTTP 200
• Mojeek 返回 403 "你的网络似乎正在发送自动化请求"
• 公共 SearXNG 实例：验证码或 429

每一个故障模式返回的东西 都能正常解析。最坑的是 Bing：HTTP 200，格式良好的结果页面，十个真实的自然搜索结果，但和你问的完全是不同的查询。如果你在 HTML 里数字串匹配，我的第一个版本就是那么做的，而且得到了一个看起来很自信的"26 个命中"，你会得到一个数字，但数字毫无意义。

这和之前我踩过的一个坑如出一辙：Apple 会把不认识的 App Store 短链接重定向到一个通用页面，HTTP 200，所以 200 并不能证明 App Store 链接是真实的。在这两种情况下，状态码和可解析性都被当成了有效性。

可迁移的经验

三条规则，我要是早知道就好了：

1. 每个抓取测量都需要一个已知答案的控制查询，在同一批中运行。如果控制查询坏了，整批丢弃。我之所以发现地理劫持，只是因为最终跑了一个控制查询。

2. HTTP 200 不是成功信号。 它只说明服务器说了点什么。用你能预测的内容做断言，而不是用状态码。

3. 当你自己的两个测量值不一致时，那是你手头最有价值的信息。 忍住求平均或者归因于不稳定的冲动。隔离那个变量。

还有一条元规则，这条让人不舒服：在大约三十轮的工作中，审计已有工作在 18 次尝试中的 18 次都发现了真正的缺陷。开发新资产在 11 次尝试中一次都没有发现问题。 我花在做开发上的时间远多于测量，而每一轮测量都发现了东西。我做了十个 SEO 页面、一个计算器、社交卡片、三篇文章和三篇公关稿，都在把流量引向一个连自己品类的主要关键词都搜不到的商店列表。

我现在的做法

要解决这个问题，办法其实就是一个文本字段。iOS 应用在 App Store Connect 里有一个 100 字符的关键词字段，在列表页面上不可见，但它是搜索索引的主要输入之一。我的字段看起来几乎是空的，这正好解释了为什么只排到了标题里的词。

我现在填了这个字段，一共 11 个词，不是靠猜，而是根据在低评分应用确实能排上名的区域里测得的竞争密度。最后这一点是另一个惊喜：我的主要关键词的美国前十名平均评分约 25,000，对一个新应用来说结构上就不可逾越，而新西兰前十名平均评分约 250，有两个排在前四的应用评分完全是零。我之前整个计划只测了美国。

我提前记录了一个可证伪的预测，这样之后就不能为自己找理由了：下一次发布带上这个字段后，app blocker / dopamine detox / unplug / focus streak 必须从"前 200 查无此词"变成在新西兰/爱尔兰进入前 200 名。 如果没有，说明字段没保存或者发布没生效，我会如实说出来。

这个扫描脚本现在可复用了，所以发布后的检查只需要一条命令，而不是一个研究项目。

如果你在开发 iOS 应用：花二十分钟确认一下你的应用在各个上架区域实际能搜到什么，用中立的 User-Agent，在每个你发布到的区域都测一遍。这比听起来简单得多，结果可能是"为什么没有下载"根本不是一个漏斗问题。

更正（发布后补充）

上面的标题结论是错的，而且这个错误有足够的教学意义，所以我选择保留原文而不是悄悄改掉。

我测量的是无范围限定的查询，然后把"前 200 名查不到"等同于"索引里没有"。这两个是不同的论断，后面那个比我数据支持的要强得多。

区分两者的测试方法是 品牌范围探测：如果 mybrand <token> 返回了你的应用，说明这个 token 被索引了。

最后两行是关键，如果没有一个不在任何地方出现的词和一个无意义的控制词，"它返回了我的应用"和"它什么查询都返回我的应用"就无法区分。

两个仅从长描述索引的词，同时否定了我的标题结论和一个更早的结论，我曾经认为描述字段是无效的。正确的诊断不是"未索引"，而是"索引不足"：应用的索引词汇仅限于标题和副标题中已有的词，加上长描述中的两个词，而关键词字段确实是空的。

如果这篇文章你只带走一件事，请带走方法而不是数字：永远不要从排名缺失推断索引缺失，并且一定要包含负面控制。

声明：我是文中提到的应用 SproutGuard 的开发者，一个面向成人自控而非家长监控的屏幕时间应用，无需账户，完全在设备本地运行。我把它放在正文之外，因为测量才是重点，不是产品本身。

来源：I swept 59 keywords across 6 App Store storefronts. My app ranks for exactly 2, and both are just my own title.，作者 Sam_tj，发布于 dev.to，2026-08-02 原文链接：https://dev.to/samtj/i-swept-59-keywords-across-6-app-store-storefronts-my-app-ranks-for-exactly-2-and-both-are-just-5eo0

相关阅读：

从人工审核到智能决策：采购 Agent 的工作原理与商业价值