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

**Summary:** Google 将于 2027 年 1 月 1 日停用 Custom Search JSON API。匹配其 JSON 格式虽可节省代码，但我认为只有经过供应商对比测试才能信任替代方案。

- Canonical: https://markhuang.ai/zh/news/google-search-api-deadline-is-a-dependency-test
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-17
- Section: News
- Tags: Google 搜索, API 迁移, 开发者工具, 搜索基础设施, 供应商评估
- Source: [The Next Gen Nexus](https://thenextgennexus.com/2026/05/14/google-kills-custom-search-api-on-jan-1-2027-you-have-9-months/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一位卡通开发者看着多彩的搜索桥梁断裂，下方网络中分出多条替代道路](https://cdn.markhuang.ai/news/google-search-api-deadline-is-a-dependency-test/hero.webp)

*Google 给通往搜索结果的这座桥定下了拆除日期。截止日期很清楚，但下一步往哪走还没人说得准。*

[The Next Gen Nexus 报道了 Google Custom Search JSON API 即将关闭的消息](https://thenextgennexus.com/2026/05/14/google-kills-custom-search-api-on-jan-1-2027-you-have-9-months/)，同时推荐了一个 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 博文](https://programmablesearchengine.googleblog.com/2026/01/updates-to-our-web-search-products.html)说得很直接：新建的搜索引擎只能用"Sites to search"功能。老引擎的"Search the entire web"可以续用到 2027 年 1 月 1 日，到期之后得另找方案。

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

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

![一位卡通机械师比较着连接到完全不同搜索设备上的匹配管道接头](https://cdn.markhuang.ai/news/google-search-api-deadline-is-a-dependency-test/schema-is-not-the-service.webp)

*接口对得上是好事，但真正决定结果质量的是背后的搜索引擎。*

## 接口兼容不等于服务等效

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

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

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

> **Info:**
>
> 我的建议是在每个供应商适配器前面加一层应用自己控制的搜索抽象层。这样结果归一化、策略执行、质量评估都收拢到一个地方，以后想换供应商也方便。

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

迁移倒计时不是唯一让人不安的东西。在 [Reddit 的 Google Cloud 讨论区](https://www.reddit.com/r/googlecloud/comments/1qilhrg/is_googles_custom_search_api_being_discontinued/)，好几个开发者说在确认哪些项目还算"现有客户"时碰上了 `403` 错误。[Google 开发者论坛](https://discuss.google.dev/t/custom-search-json-api-returns-403-despite-enabled-api-valid-key-billing-metrics-and-nonzero-quota/378030)七月份也有帖子说，一个老项目 API 开着、计费正常、配额看得到、请求也确实到了服务端，结果还是返回权限错误。

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

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

![卡通工程师通过标有目标、时钟、地球、盾牌和链接符号的闸门比较四股搜索结果流](https://cdn.markhuang.ai/news/google-search-api-deadline-is-a-dependency-test/provider-bakeoff.webp)

*一场有用的对比测试要看结果质量和实际运行表现，不只是看谁返回了合法 JSON。*

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

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

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

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

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

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

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

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

![一个卡通团队将老化的搜索管道通过受监控的调车场导向多个提供商，同时保留回滚杠杆](https://cdn.markhuang.ai/news/google-search-api-deadline-is-a-dependency-test/migration-switchyard.webp)

*并行流量、供应商适配器、监控和回滚能力——这些把截止日期变成一次可控的迁移。*

## 最后说一句

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

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