挑战
如果你的团队正在构建排名追踪器、SEO 仪表盘或竞品情报工具，2026 年彻底打破了你的单体经济模型。Google 今年悄然停用了 Google 搜索上的 num=100 URL 参数，而这正是每个 SERP 爬虫过去用来单次请求拉取 100 条结果的技巧。现在，获得相同的覆盖量需要发起十次请求，而不是一次。
这是显而易见的成本。隐藏成本则更为棘手。
排名追踪只有在能够呈现目标国家、地区和城市中真实搜索用户所见 SERP 时才有效。一个在伦敦排名第 4 的关键词，在爱丁堡可能排名第 11，而在贝尔法斯特可能排到第 19。本地三包（3-packs）、购物轮播、新闻模块、知识面板、AI Overviews。每个 SERP 功能模块都会随地理位置和设备发生变化。（Scrape.do 测得在 2026 年初，约有 36% 的查询中出现了 AI Overview 文本。）如果你的爬虫通过错误城市的 proxy 进行路由，你的排名数据就成了看似确凿的虚假信息。
因此，在 2026 年，一个具备竞争壁垒的 SERP 产品需要三者协同工作：在网络传输层表现得如同真实浏览器的 request、精准位于目标监控城市的 proxy，以及在 Google 决定在客户端加载一半结果时渲染 JavaScript 的能力。缺少其中任何一项，你的数据质量都会在无声无息中下降。
FourA 解决方案
大规模 SERP 抓取的瓶颈不在于 request，而在于路由。
大多数自建流水线从固定的 proxy 池开始，并将查询视为变量。但面对 Google 的地理定位机制，逻辑恰恰相反。查询是已知的，proxy 才是必须确保准确的变量。
我们看到很多团队在 FourA 基础之上构建了大致如下的模式：
Proxy Finder 维护一个经过最新可用性检查验证并带有国家、地区、城市和 ASN 标签的有效 proxy 池。当一个 request 需要来自曼彻斯特、波士顿或圣保罗时，Proxy Finder 会挑选一个实际位于该地且在最近一次检查中处于存活状态的节点。挑选发生在抓取之前，而不是抓取过程中。关于该路由层为何如此重要的更多信息，请参阅我们关于 Smart Proxy Routing 的文章。
Single 负责处理 SERP 抓取本身。对于标准自然搜索结果，原始 HTML 就足够了。设置
unblocker: true后，request 就会携带最新的浏览器签名，无需你去关注 Google 该周正在校验哪种签名。我们在 Web Unblocker post 中详细拆解了该标志在网络层的作用。Browser 负责处理关键内容在 JavaScript 运行后才呈现的 SERP。AI Overviews、展开的购物卡片包、知识面板内容、固定位置的本地三包。相同的 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 Finder)、请求本身 (Single)，以及按需启用的 JavaScript 渲染 (Browser)。你的代码无需承载代理健康状态检测逻辑，也不必在凌晨三点去猜测哪个 IP 仍然存活。这些都成了别人的问题。
同时，将每个响应以 (keyword, location, device, timestamp) 为键进行存储。这是排名追踪中真正的事实单元。不是“我们今天这个关键词排在这里”，而是“我们在这一分钟、从这个城市、在这台设备上，该关键词排在这里”。缺少这种级别的属性归因，两天的数据可能会在暗中产生矛盾，而你根本无从得知哪一个是正确的。监控受保护垂直领域的 SEO 团队已经面临这种情况。我们之前也写过关于 Bot 检测如何演变为基于行为分析的文章，对于那些关注请求序列而非单次请求信号的网站，这增加了第四个维度（会话连续性）。
结果
在旧的 num=100 机制下，一个每天两次跨 12 个城市监控 5,000 个关键词的排名追踪器，每天大约需要 120,000 次请求。按照简单的分页计算，现在这个数字已接近 120 万次（基于行业基准的示例场景）。
将该架构迁移到这套三产品栈的团队通常反馈：
- 单次请求成本降低 40% 到 60%（相比运行自建代理池），这主要是因为他们不再需要为代理流失、失效 IP 以及维护轮换机制的工时买单。
- 城市级位置准确率从约 70% 提升至 95% 以上，因为 Proxy Finder 会按城市过滤，并在交付代理前的最后一次检查中验证其存活性。
- 无需为 AI Overviews 开辟特殊路径。 通过 Single 获取的关键词可以直接升级到 Browser 处理，无需重写流水线。接口契约完全一致：输入 URL，输出响应。
如果只是在笔记本电脑上监控十个关键词，你根本不需要这些。但一旦流水线需要在多国监控数万个关键词，且客户在周一上午 9 点刷新仪表板并要求排名数据绝对真实时，你就必须依赖它。
核心要点
SERP 监控的难点早已不再是请求本身。难点一直都在于路由。你从哪个城市发起请求？该 IP 是否存活？Google 返回的是该位置真实搜索者实际看到的布局，还是识别出爬虫后给出的空白页面？
如果你是一个使用自建技术栈进行排名追踪的 SEO 团队，2026 年的核心问题不是要不要抓取 Google。你们已经在这么做了。真正的问题是，当规则在毫无预警的情况下发生变化时，你的基础设施能否持续产出可信的排名数据，以及你愿意投入多少工程人力来维持这一状态。