搜索 Google 排名 API 的团队，想要的通常是同一件东西：一个能返回某个页面在某个关键词下排第几的调用。Google 并不提供。
Google 提供的，是一组描述你自己表现、你自己的索引状态、你自己的抓取情况的 API。它们确实有用，而且全部免费。但它们在结构上无法回答大多数人带着来搜索的那个问题。
我们花了一天，在一个真实站点上测量这些 API 实际返回什么，包括那些容易被误读的部分。有三个发现格外突出：数据晚到三天；那个位置数字是平均值，拿去和实时结果对照复现不出来；而听起来最像排名查询的那个 API，返回的判定单独看什么也说明不了。
Google 实际提供了什么
有四个接口常被误认为排名 API。按 Google 自己的文档，各自用途如下。
Search Analytics API 返回已验证站点的点击、展示、CTR 和平均排名。它是 Google 提供的、最接近排名数据的东西，也是 Search Console 里每一个「平均排名」数字的来源。
URL Inspection API 返回单个 URL 的索引状态：Google 是否知道它、是否已收录，如果没有又是为什么。
Indexing API 听起来像是用来提交页面收录的。Google 的文档把支持类型限定为 JobPosting 和 BroadcastEvent 结构化数据，这是个很窄的用途，不是通用的收录提交。
Custom Search JSON API 返回某个查询的网页结果。它搜索的是你自己配置的索引，不会告诉你你的站点在 Google 主搜索结果里排第几。
它们都不返回「你这个关键词的排名」。这件事不存在于 Google 的产品线里，而它的缺席是刻意的，不是疏忽。Google 没有商业理由大规模发放竞争对手的排名数据。
测量结果：数据晚三天
2026 年 9 月 12 日，我们拉取了自己站点的按日明细。有数据的最新日期是 9 月 9 日。
可用日期 | 返回行数 |
|---|---|
2026-09-02 | 有 |
2026-09-03 | 有 |
2026-09-04 | 有 |
2026-09-05 | 有 |
2026-09-06 | 有 |
2026-09-07 | 有 |
2026-09-08 | 有 |
2026-09-09 | 有（最新） |
稳定滞后三天。window 参数是从可用的最新日期往前数，而不是从今天往前数，这里有个小陷阱：请求七天，返回的是以 9 月 9 日结尾的八个日期，不是 9 月 12 日。
对月度报告来说这无关紧要。对「我昨天的页面改动是不是弄坏了什么」这个问题，它是致命的。没有任何配置能修复它。延迟在 Google 那一侧的线路上。
测量结果：平均排名不是排名
这是更重要的发现，也是让人相信 Google 排名 API 存在、只是藏着不肯给的原因。
平均排名是你的 URL 在该周期内所有展示中的平均位置，按国家、设备、查询变体加权。实时排名检查返回的是一个位置、一台设备、一个瞬间的一个数字。它们是共享了同一个名字的两种不同测量。
我们从自己的 Search Console 数据里抽出 25 个查询验证这个差距，然后把这 25 个关键词拿去对美国、英语、桌面端的实时 SERP 做深度 100 的检查。
结果 | 数量 |
|---|---|
两组里都能用的查询 | 23 |
出现在实时前 100 | 14（61%） |
有 Search Console 展示但复现不出实时结果 | 9（39%） |
两者都存在时绝对差距的中位数 | 7.4 位 |
绝对差距的平均值 | 8.5 位 |
最大差距 | 36.6 位 |
彼此相差在 3 位以内 | 14 个中有 4 个 |
相差超过 10 位 | 14 个中有 4 个 |
在两种测量都存在的地方，它们的中位数差距是 7.4 位。
有两个细节比平均值更重要。
第一，23 个查询里有 9 个给出了 Search Console 位置，但在美国、英语、桌面端的检查里完全没有实时结果。这不是 bug。展示会从其他国家、其他语言、其他设备，以及图片和视频界面累积而来。单一地区的检查不可能复现它们；把两个数字当成同一种测量的团队，会花一整周去追一个纯粹是方法产物的差异。
第二，方向并不一致。多数实时位置落在 Search Console 平均值之下，这符合预期，因为平均值包含了表现更好的界面。但有一个查询朝反方向移动了 36.6 位，从 73.6 变成 37。没有任何修正系数可用。
差距朝两个方向跑，所以没有可用的修正系数。
对正在挑 Google 排名 API 的人来说，实际后果是：免费数据不会告诉你排名，付费数据又和它对不上。两者都在正确地测量不同的东西。把任何一方当成另一方的替代品，报告就是从那里开始出错的。
第一方数据真正不可替代的地方是覆盖率，我们在另一篇文章里单独做了对比测量。
URL Inspection API 返回的其实是别的东西
URL Inspection API 是 Google 这些接口里唯一感觉像排名检查的，因为你给它一个不含关键词的 URL，它会返回一个状态。我们测了两个 URL。
URL 状态 | 判定 | 覆盖率状态 | 上次抓取时间 |
|---|---|---|---|
约一小时前发布 | NEUTRAL | Google 不认识此 URL | 未知 |
约九小时前发布 | NEUTRAL | 已发现，当前未收录 | 未知 |
两者返回了相同的判定。真正区分这两种情况的字段是覆盖率状态字符串，它是一句话，不是枚举值。对 Google 从未见过的 URL，和对它已发现但未收录的 URL，判定字段都返回 NEUTRAL。
这是个能用的 API，单独作为监控信号却很糟。如果你想在页面未被收录时收到告警，请解析覆盖率状态而不是判定字段，并且要预期：恰恰是你最在意的那些 URL，上次抓取时间会缺席。
四个接口，以及没有一个在做的事
问题 | Google 的接口 | 回答 |
|---|---|---|
上周我这个查询表现如何 | Search Analytics API | 能答。晚三天，且是平均值 |
这个 URL 收录了吗 | URL Inspection API | 能答。按 URL，需主动请求 |
我现在任意关键词排第几 | 无 | 不能 |
我的竞争对手排第几 | 无 | 不能 |
我没排名的关键词的 SERP 长什么样 | 无 | 不能 |
模式是一致的。Google 的 API 从内部描述你的站点。而排名问题是从外部、针对一个结果页提出的，Google 不提供这个。
怎样在不花冤枉钱的前提下补上缺口
实际可行的配置是两个各司其职的数据源，而不是让一个数据源既干这又干那。
用 Google 的 API 做自己站点的基准事实。 点击、展示和索引状态是你在别处拿不到的第一方事实，而且免费。按计划拉取，把三天延迟当作这个测量工具本身的属性。
用 SERP 数据源看外部视角。 实时排名、竞争对手排名，以及你还没排名的关键词。这部分要付费，但比多数团队以为的便宜：在我们的测试里，按深度 100 检查 23 个关键词花了 $0.2975，也就是每次检查 $0.0129。
不要去调和这两个数字。 它们测的是不同的东西。有用的做法是把它们并排读：Search Console 告诉你发生过什么，实时检查告诉你正在发生什么。两者不一致时，先看那个查询的国家和设备构成，再下任何结论。
把两者跑在同一个脚本里的机制在我们的双数据源追踪器搭建里，实时那一半的成本在批量检查测试里算过。
常见问题
Google 有官方的排名 API 吗？ 没有。Google 提供的是你自己搜索表现（Search Analytics）、索引状态（URL Inspection），以及两种很窄的提交类型（Indexing）。没有任何一个返回关键词排名。
既然没有排名 API，为什么 Search Console 会显示位置？ 因为平均排名是从你的展示中算出来的表现指标，不是排名查询。它是该周期内所有展示的平均位置，跨国家、设备和界面再取平均。
Search Console 的数据滞后多久？ 我们在 2026 年 9 月 12 日测到的是三天，可用的最新日期是 9 月 9 日。window 参数从那个日期往前数，所以请求七天会返回以最新可用日期结尾的八个日期。
URL Inspection API 能告诉我页面是否被收录吗？ 能，而且它就是干这个的合适工具。请读覆盖率状态字符串，而不是判定字段，因为对未知 URL 和已发现但未收录的 URL，判定都会返回 NEUTRAL。
Custom Search JSON API 是排名 API 吗？ 不是。它返回的是你自己配置的搜索引擎的结果，不是你在 Google 主搜索结果中的位置。
拿到真实排名数据最便宜的方式是什么？ 只检查你真正会动手处理的那一小批关键词，深度选在和你排名位置相称的档位。在我们的测试里，深度 10 每次检查 $0.002，深度 100 是 $0.014，也就是说深度设置对账单的影响比关键词数量大七倍。
Auspia 观点：「有没有 Google 排名 API」这个问题，诚实的答案是没有，而真正有用的下一步是别再找了。Google 的 API 很好地回答第一方问题，却完全无法回答排名问题。给外部视角留一小笔预算，把剩下的力气花在 Google 不会替你做的部分上——当两个数字打架时，决定要改什么。
作者：Gabriel Finch，Auspia 搜索检索研究员，已审核 1,200 多个 AI 回答。他撰写关于搜索基础设施、检索系统，以及每个数据源实际能看到什么的内容。
