SERP API 的定价看起来很简单：每千次搜索一个价格，再加上几种月度套餐。但实际收到的账单很少符合团队的预期，因为一个项目需要的搜索次数，是若干决策相乘的结果，而这些决策的成本很容易在不知不觉中被忽略。多跟踪几个城市、加上移动端、多深入一页、把每周检查改成每日检查，数量就会成倍增长。
本指南将把一份 SERP API 账单拆解成各个组成部分，解释是什么变化让深度排名跟踪在 2025 年的成本提高了十倍，并展示如何规划工作量，让你只为所需的数据付费，而不为用不到的数据付费。文中附有一个小型计算器，你可以用自己的数据和任意供应商的价目表来运行它。
关键要点
- 每月搜索次数等于关键词数乘以页数乘以地点数乘以设备数乘以引擎数乘以每月检查次数。每个因素都会与其他因素相乘。
- 深度现在是最昂贵的因素。自 2025 年 9 月 Google 停止支持那个能在一页内返回 100 条结果的参数以来，跟踪前 100 名需要十次请求，而不是一次。
- 通常最划算的节省点是频率：对波动大、价值高的关键词每日检查，对长尾关键词每周检查。
- 比较供应商时应看你实际被收费的内容，而不仅仅是标价：失败和缓存的请求是否计费，是否包含所有引擎，以及超额部分如何计费。
- 先规划工作量，再选择套餐。在我们的示例中，分层排程让优先关键词获得前 100 名的覆盖，所用的量约为每日跟踪所有关键词到第 100 名所需量的八分之一。
你实际付费的内容是什么
大多数 SERP API，包括我们的，都是按搜索请求计费。一个请求是指：在某一时刻，针对某一查询，在某一地点，使用某一设备，从某一引擎获取的一页结果。其他一切都由此单位衍生：
| 因素 | 含义 | 典型范围 |
|---|---|---|
| 关键词 | 你跟踪的查询 | 几十到数十万 |
| 深度 | 你需要多少个排名位置；每 10 条结果为一页，每一页为一次请求 | 10 到 100 |
| 地点 | 你单独跟踪的国家、地区或城市 | 1 到数百 |
| 设备 | 桌面端和移动端结果不同，因此同时跟踪两者会使数量翻倍 | 1 或 2 |
| 引擎 | Google、Bing、Yandex 等，每个都是单独的请求 | 1 到 3 |
| 频率 | 每种组合被检查的频次 | 每月一次到每日多次 |
把它们相乘，规模就一目了然了。500 个关键词、两种设备、五个城市、每日检查一次，在还没超过第一页之前，就已经是每月 150,000 次请求。
为什么深度跟踪的成本提高了十倍
多年来，排名跟踪工具通过一个 URL 参数 num=100，向 Google 请求在单页内返回 100 条结果。一次请求即可返回整个前 100 名。2025 年 9 月中旬，Google 停止支持该参数，依赖它的工具开始出现数据缺口，直到它们改为每次十条地翻页获取结果。
这对成本的影响是直接的。现在跟踪一个关键词的前 100 名需要十次请求，因此同样的深度成本提高了十倍。对许多团队来说，问题从”我们能跟踪多深？“变成了”我们究竟需要跟踪多深，针对哪些关键词？“大多数点击都发生在第一页，而对大多数关键词而言，知道是否出现在第一页、以及大致排在什么位置，才是与决策相关的事实。
一个适用于你自己工作量的计算器
下面的模块可以为一个或多个跟踪排程计算每月请求数。将结果乘以任意供应商每千次的价格，即可比较不同套餐。
import math
from dataclasses import dataclass
RESULTS_PER_PAGE = 10 # Google stopped honouring num=100 in September 2025, so every 10 results is a call
@dataclass
class Workload:
keywords: int
depth: int # how many positions you need: 10, 20, 100...
locations: int = 1
devices: int = 1 # 2 if you track desktop and mobile separately
engines: int = 1
checks_per_month: float = 30.0
def calls_per_month(self):
pages = math.ceil(self.depth / RESULTS_PER_PAGE)
return math.ceil(self.keywords * pages * self.locations * self.devices * self.engines * self.checks_per_month)
def summarise(name, workloads):
calls = sum(w.calls_per_month() for w in workloads)
return f"{name}: {calls:,} calls a month"针对四种典型工作量运行：
from serpcost import Workload, summarise
WEEKLY = 52 / 12 # checks per month for a weekly schedule
print(summarise("500 keywords, top 10, daily", [Workload(500, 10)]))
print(summarise("500 keywords, top 100, daily", [Workload(500, 100)]))
print(summarise("Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords",
[Workload(500, 10), Workload(100, 100, checks_per_month=WEEKLY)]))
print(summarise("200 local keywords, 5 cities, desktop and mobile, weekly",
[Workload(200, 10, locations=5, devices=2, checks_per_month=WEEKLY)]))500 keywords, top 10, daily: 15,000 calls a month
500 keywords, top 100, daily: 150,000 calls a month
Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords: 19,334 calls a month
200 local keywords, 5 cities, desktop and mobile, weekly: 8,667 calls a month第二行和第三行才是关键所在。每日将 500 个关键词跟踪到前 100 名，需要每月 150,000 次请求。而每日跟踪所有关键词的第一页，再对其中最重要的 100 个每周跟踪到前 100 名，只需要 19,334 次，约为前者的八分之一，却仍能回答排名报告所需解答的几乎所有问题。
七种降低成本的方法
- **让深度与决策相匹配。**大多数关键词只需跟踪到第一页，只有当排名从第 40 位变为第 15 位会改变你的行动时，才需要跟踪得更深。
- **分层设置频率。**对高价值、波动大的关键词每日检查，对稳定的长尾关键词每周检查。我们关于检测 SERP 波动性的指南展示了如何从自己的数据中判断哪些属于哪一类。
- **只增加有差异的地点。**城市级跟踪对本地意图查询很重要，但对信息类查询则重要得多；城市级定位何时重要解释了如何做出判断。
- **只在两种设备结果存在差异时才同时跟踪。**先对一个样本测量桌面端和移动端；如果排名高度一致，就只跟踪其中一种，并对另一种做抽查。
- **跨客户和团队去重。**代理机构常常为多个客户跟踪同一地点的同一关键词。获取一次并共享结果即可。
- **在当日内做缓存。**如果多个系统需要同一页结果，存储首次响应并复用，而不是再次请求。
- **为结果付费，而不是为尝试付费。**检查失败的请求、重试以及缓存的响应是否计费，因为失败部分是每份账单中隐藏的一大块。
公平地比较供应商
每千次的标价只有在单位一致时才具有可比性。在比较 SERP API 时，应询问：
| 问题 | 为什么重要 |
|---|---|
| ”一次搜索”是指一页结果，还是更深的分页会消耗额外的额度？ | 决定了深度的真实成本 |
| 失败、空结果或重试的请求是否计费？ | 失败是每份账单中隐藏的一大块 |
| 是否包含所有引擎和结果类型，还是单独计价？ | 决定了跟踪 Google 网页结果之外内容的成本 |
| 地点和设备定位是否以相同费率包含在内？ | 决定了城市级或移动端跟踪是否会改变费率 |
| 超出套餐后会发生什么：硬性停止、超额费率，还是自动升级？ | 决定了繁忙月份的真实成本 |
| 结果是实时的还是来自缓存，是否有标注？ | 决定了数据的新鲜程度 |
每条干净记录的成本这一原则在这里同样适用：真正有意义的数字，是你在扣除失败、重试和重复之后，每一页可用结果所花费的成本，而不是每次请求的标价。
自建还是购买
在非常高的量级下，通过代理自行采集可能更便宜，但这会带来解析、维护，以及像 num=100 失效这样的变化需要持续跟进的工作。SERP API 把这部分工作转移给了供应商。SEO 平台如何使用 SERP API 探讨了这条界限通常落在哪里，自动化每日关键词排名监控 则展示了一个基于此构建的完整流程。
结论
一份 SERP API 账单是关键词数、深度、地点数、设备数、引擎数和频率相乘的结果，而自从 Google 停止每页返回 100 条结果以来，深度是增长最快的那个因素。降低成本的方法不是去寻找每千次最低的费率，而是只购买会影响决策的请求：大多数关键词只需第一页，少数重要的关键词跟踪得更深，排名变动大的每日跟踪，不变动的每周跟踪。
在选择套餐之前，先用自己的工作量运行这个计算器，再乘以各供应商的费率，以便进行同口径的比较。
来源与参考
- Search Engine Journal，Google 修改搜索结果参数，影响 SEO 工具，2025 年 9 月。