Google 搜索 API 终止倒计时：接口兼容不等于服务等效

The Next Gen Nexus 报道了 Google Custom Search JSON API 即将关闭的消息，同时推荐了一个 schema 兼容的 Apify actor 作为"无缝替代"。截止日期确实不假——Google 官方文档已经写明该 API 不再接受新用户注册，2027 年 1 月 1 日是现有用户的服务终止日。

我同意这件事确实紧迫，但不同意原文那种"只要 JSON 结构不变就万事大吉"的乐观。排名质量、覆盖范围、时效性、过滤能力、延迟、成本、使用条款、故障行为——这些全都藏在那个 payload 背后。如果搜索在给你的产品、研究工作流或 AI agent 喂数据，换一家提供商就等于换了系统看到的证据。

快速概览

问题	我的看法
要关的是什么？	Google 要求现有 Custom Search JSON API 用户在 2027 年 1 月 1 日前完成迁移，新注册通道已经关闭。
谁会受影响？	用 Google JSON 搜索结果做站内搜索、全网信息检索、研究工具、引文查找，或者给 AI agent 接搜索功能的团队。
Google 给了什么替代方案？	50 个域名以内的场景，Google 推荐 Vertex AI Search；全网搜索需求需要填意向表申请独立方案。站内搜索还有免费的 Search Element 可用（限 50 个域名）。
我的核心判断	响应结构兼容能减少代码改动量，但证明不了结果质量和生产环境的安全性。这次迁移需要做对比测试，不能直接换端点就完事。
现在该做什么？	盘点使用情况、收集典型查询、对比供应商、加一层内部适配、跑并行流量、在截止日期前保留回滚能力。

截止日期很清楚，替代方案很模糊

Google 在 2026 年 1 月 20 日发了公告。Programmable Search Engine 博文说得很直接：新建的搜索引擎只能用"Sites to search"功能。老引擎的"Search the entire web"可以续用到 2027 年 1 月 1 日，到期之后得另找方案。

Custom Search JSON API 文档说得更干脆。1 月 1 日就是服务终止日，新客户已经用不了了，老客户在终止日之前还能按原来的价格走：每天 100 次免费查询，超出部分每 1,000 次 5 美元，日上限 10,000 次。

问题是，这些公开页面并没有给出一个范围和条款都对等的直接替代方案。50 个域名以内的场景，Google 让你去用 Vertex AI Search；全网搜索需求则需要单独填表申请，功能和定价都不透明。当初小团队选 Custom Search，就是因为它能自助开通、边界清楚、接入简单——现在这批人反而面临最不确定的迁移路径。

接口兼容不等于服务等效

原文推荐的方案是一个 Apify actor，输出和 Custom Search 一样的字段结构——items[].title、items[].link、items[].snippet、searchInformation.totalResults 这些。保留这套结构确实能省掉下游代码的大规模重写，这一步本身没问题。

但原文说"两行代码就能搞定"就过了。看看它自己的示例：原来直接请求 Google 端点，现在换成 Apify 客户端，启动 actor 运行，读取 dataset，然后才进入原来的 item 循环。字段解析层看着眼熟，可请求路径、认证方式、执行模型、计费关系、运维依赖全变了。

所以这类宣传里的每一个强断言，我都会当成待验证的假设。替代品能不能对同样的查询返回有用的结果？排序、分页、语言和地区过滤、图片搜索、安全搜索、错误响应——这些够不够接近产品需求？新页面多久能被收录？流量突增、被提供商限流、上游封禁的时候怎么办？一个名叫 totalResults 的字段回答不了这些问题。

社区反馈说明提前动手是对的

迁移倒计时不是唯一让人不安的东西。在 Reddit 的 Google Cloud 讨论区，好几个开发者说在确认哪些项目还算"现有客户"时碰上了 403 错误。Google 开发者论坛七月份也有帖子说，一个老项目 API 开着、计费正常、配额看得到、请求也确实到了服务端，结果还是返回权限错误。

这些是用户反馈，不能拿来证明 Google 提前了停服时间——我不会那么说。但它们至少说明一件事：拖到十二月再动是有风险的。权限问题可能伪装成密钥失效、配额异常，或者干脆是迁移策略没讲清楚。

Hacker News 上的讨论还带出了一个我更在意的深层问题。不少开发者拿这个 API 做垂直搜索产品，或者当 LLM 工作流的联网搜索入口。一旦搜索依赖嵌进了 agent，它的输出直接影响 agent 写东西或做决策之前看到的信息源。所以换供应商不只是看可用性，还得评估内容质量。

做一场真正的对比测试，别跑个 demo 就完事

第一步拿真实流量来测，脱敏之后用。准备一组查询：高频的、冷门的、时效性强的、名字有歧义的、非英语的（如果你的产品支持的话），还有当前系统本身就表现差的。对有明确正确答案的用例，记下预期该出现的域名或页面。

测试维度	具体看什么
结果有没有用	第一页能不能给出用户或下游系统真正需要的来源，重点查询的排名差异有多大
覆盖和时效	小众域名、刚发布的页面，在你的场景下能不能搜到
功能对不对得上	分页、本地化、过滤、图片搜索、安全搜索、元数据，以及你的应用现在用到的各种操作符
运维表现	延迟分布、超时率、限流策略、错误格式、重试行为、配额、技术支持、故障恢复
成本和政策	常态和突发流量下的费用、缓存权限、数据处理方式、可接受使用条款，以及依赖另一家供应商的上游索引带来的风险

别急着把这些压成一个综合评分。适合站内搜索的供应商，做开放网络检索可能很弱。适合人类浏览链接的排序，在 agent 只打开前几个结果的情况下，可能反而带偏引用质量。先搞清楚哪些失败你承受不起，再让基准测试去选赢家。

用剩下的时间给自己留条后路

我会搭一个适配层，分阶段切。先把现有的 Google 集成包在一个内部接口后面，然后把候选供应商接进来。拿一部分安全的查询样本跑并行，对比输出，记录供应商、延迟、状态码、成本、结果质量信号。在老路径还能当后备的时候，先切一小部分流量过去。

如果只是在自己控制的少量域名里做站内搜索，Google 的 Search Element 或者专注站点的索引可能就够了。如果 agent 需要广泛的全网发现能力，独立的搜索 API 或 SERP 供应商可能更合适。垂直产品可以考虑自建或买一个窄域索引，少依赖通用网页排名。选什么取决于你的工作负载——这也是为什么我对原文那种"即插即用"的说法不太放心。

我还会把应用其他地方跟供应商绑定的字段都清理掉。政策允许的话，原始响应留着调试用，但对外只暴露产品真正需要的东西。在引用和日志里加上供应商标识。让空结果、部分失败、过期数据都能被看到。下一次搜索迁移应该是个配置和评估问题，而不是又一次紧急重写。

最后说一句

The Next Gen Nexus 把日期标大是对的。2027 年 1 月 1 日已经近在眼前，任何还在生产环境里跑 Custom Search JSON API 的项目，现在就该动起来。但原文对某个特定替代方案的那份自信，我不会原样搬进架构决策——没有证据的事不能拍板。

另一家服务可以把 Google 的字段名抄得一模一样，结果照样不对路。它得在你产品真实的查询量、预算、合规要求和故障场景下交出过得去的搜索结果。兼容的 schema 能省时间就留着，但省下来的时间要拿去测 schema 覆盖不了的那些东西。