num=100 废弃后的规模化 SERP 监控

挑战

如果您的团队正在构建排名追踪器、SEO 仪表盘或竞争情报工具，2026 年将打破您的单体经济模型。Google 今年悄然退役了 Google Search 上的 num=100 URL 参数，而这是每个 SERP 爬虫过去用于在单个 request 中获取 100 个结果的技巧。现在，同样的覆盖范围需要 10 个 request，而不是 1 个。

这是显而易见的成本。而隐藏的成本则更加棘手。

排名追踪只有在您看到真实搜索者在正确的国家、地区和城市中所看到的 SERP 时才有效。一个在伦敦排名第 4 的关键词，在爱丁堡可能排名第 11，在贝尔法斯特可能排名第 19。本地商家三栏（Local 3-packs）、购物轮播、新闻框、知识面板、AI Overviews。每一个 SERP 功能都会随着地理位置和设备的变化而改变。（Scrape.do 测得，在 2026 年初，AI Overview 文本出现在大约 36% 的查询中。）如果您的爬虫通过错误城市的 proxy 进行路由，您的排名数据就成了言之凿凿的虚构故事。

因此，在 2026 年，一个站得住脚的 SERP 产品需要三者协同工作：在传输线缆层面上看起来像真实浏览器的 request、位于您要监控的确切城市的 proxy，以及在 Google 决定在客户端加载一半结果时渲染 JavaScript 的能力。缺少这三者中的任何一个，您的数据都会在无形中降级。

FourA 的方法

规模化 SERP 爬取的瓶颈不在于 request。而在于路由。

大多数自建的流水线都以固定的 proxy 池开始，并将查询视为变量。面对 Google 的地理位置定向，情况恰恰相反。查询是您已有的。而 proxy 才是您必须搞对的。

我们看到许多团队在 FourA 之上构建了大致如下的模型：

Proxy Finder 维护着一个可用的 proxies 池，这些 proxies 经过了最新的存活检查验证，并标记有国家、地区、城市和 ASN。当一个 request 需要来自曼彻斯特、波士顿或圣保罗时，Proxy Finder 会选择一个实际存在于该地且在上次检查中存活的 proxy。这种选择发生在 fetch 之前，而不是在 fetch 期间。欲了解为什么该路由层至关重要的更多信息，请参阅我们关于 Smart Proxy 路由的文章。
Single 处理 SERP fetch 本身。对于标准的自然搜索结果，原始 HTML 就足够了。设置 unblocker: true，request 即可穿透握手级别的反爬虫墙，而无需您了解 Google 当周正在检测哪种签名。我们在 Web Unblocker 文章一文中详细分析了该标志在传输线缆上的作用。
Browser 处理在 JavaScript 运行后才显示关键内容的 SERP。AI Overviews、展开的购物包、知识面板内容、固定的本地商家三栏（local 3-packs）。相同的 URL，相同的目标，request 只需通过完整的浏览器会话运行，并返回完全渲染的页面。（外加屏幕截图，这能在 SEO 主管问起为什么您的仪表盘显示排名第 3，而他们在浏览器中却看到第 6 时，为您化解尴尬。）

针对 proxy 路由 API 的单次调用：

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

这清晰地分离了三个关注点：地理位置正确的 proxy 工作（Proxy Finder）、request 本身（Single），以及在需要时进行 JavaScript 渲染（Browser）。您的代码不需要承载 proxy 健康逻辑，也不需要猜测凌晨 3 点哪个 IP 依然存活。那是别人的问题。

并且存储每一个以 (keyword, location, device, timestamp) 为键的 response。这是排名追踪的实际真实单元。不是“我们今天在这个关键词上排名如此”，而是“我们在这一分钟、在这个设备上、从这个城市出发，在这个关键词上排名如此”。如果没有这种级别的归因，两天的数据可能会悄然相互矛盾，而您将无法判断哪一个是正确的。监控受保护垂直领域的 SEO 团队已经面临这种情况。我们还撰写过关于机器人检测转向行为分析的文章，这为那些关注 request 顺序而非单次 request 信号的网站增加了第四个维度（会话连续性）。

结果

在旧的 num=100 机制下，一个每天两次监控 12 个城市、5,000 个关键词的排名追踪器每天大约产生 120,000 个 requests。根据简单的分页计算，现在这一数字接近 120 万（基于行业基准的说明性场景）。

将此模式移植到三产品技术栈的团队通常会反馈：

单次 request 成本降低 40-60%（相比于运行自己的 proxy 池），这主要是因为他们不再需要为 proxy 流失、失效 IP 以及维护轮换的工程时间付费。
城市级定位准确率从 ~70% 提升至 95% 以上，因为 Proxy Finder 会按城市进行过滤，并在交付 proxy 之前进行最后的存活检查验证。
无需为 AI Overviews 设置特殊路径。 通过 Single 获取的关键词可以直接升级到 Browser，而无需重写流水线。契约完全相同：输入 URL，输出 response。

如果只有十个关键词和一台笔记本电脑，您不需要这些。但一旦流水线开始监控跨国的数万个关键词，且您的客户在周一早上 9 点刷新仪表盘，并且排名必须真实可靠时，您就需要它。

核心要点

很久以前，SERP 监控的难点就不再是 request 本身了。难点一直在于路由。您是从谁的城市进行 fetch 的？该 IP 是否存活？Google 返回的是该位置真实搜索者实际会看到的布局，还是在察觉到爬虫时提供的空白布局？

如果您是一个在自建技术栈上运行排名追踪的 SEO 团队，2026 年的问题不是要不要爬取 Google。您已经在这么做了。问题在于，当规则毫无预警地发生变化时，您的基础设施能否继续产生值得信赖的排名，以及您愿意投入多少工程团队精力来维持这种状态。