Google 自定义搜索 API 替代方案：规划你的 2027 年迁移

摘要：

• 现有的 Custom Search JSON API 客户必须在 2027 年 1 月 1 日前完成迁移。 新客户已无法再采用该服务。
• Google Custom Search API 的替代方案必须匹配应用的搜索范围。 仅限站点的发现与更广泛的公共搜索是截然不同的需求。
• Scrapeless Google Search API 是结构化公共 Google 结果的候选方案。 应将其作为一个新的采集层进行评估，而不是假定为可直接替换的解决方案。
• 迁移需要一个由应用拥有的结果契约。 在切换流量前，要保留目标地址、定义可选字段，并审查查询行为。

引言：替代方案取决于你的应用在搜索什么

搜索迁移会改变应用返回给用户的证据。即使在更换服务提供商后，页面标题、目标地址和摘要片段看起来相似，搜索范围和选择行为也可能已经在底层发生变化。

Google 已对新客户关闭 Custom Search JSON API，并要求现有客户在 2027 年 1 月 1 日前完成迁移。Custom Search JSON API 迁移公告明确说明了这一截止日期。为 2027 年寻找 Google Custom Search API 替代方案的团队应从其应用的搜索需求入手。

将站内搜索与公共搜索情报区分开来

替代方案应仍然解答应用最初被设计用来回答的用户问题。针对已知站点集合的文档搜索框，与用于监测公共搜索可见性或在整个网络上发现来源的工具，其需求截然不同。

现有需求	迁移优先级	需要解决的问题
搜索经批准的站点集合	范围控制	替代方案能否强制执行预期语料？
为研究发现公共页面	来源相关性	目标地址是否支持用户的问题？
监控 Google 可见性	可比的搜索环境	应用能否保留市场与查询环境？
将搜索结果输入助手	可溯源证据	用户能否审查被选中的来源？

在比较供应商之前先写下这些需求。一个看起来熟悉的响应字段并不能证明行为等价，而更宽泛的搜索结果集，可能并不适用于承诺只在受限语料中搜索的应用。

Scrapeless 在替代方案规划中的定位

Scrapeless Google Search API 为需要公共搜索观测数据的应用提供结构化的 Google 搜索数据。它是用于来源发现、监控或其他围绕 Google 结果数据构建的工作流的候选方案。

面向产品团队的搜索工作流将这一采集层与业务决策连接起来。当这些决策需要结构化的公共搜索结果时，可以选择它，然后再针对你的应用确认其具体支持的搜索范围和请求行为。

不要假定现有的 Programmable Search Engine 配置、自定义引擎标识符、结果推广或站点选择规则会自动迁移。盘点当前应用所依赖的功能，并为每项功能指定明确的替代方案或记录在案的限制。

在映射提供商字段前，先梳理应用契约

由应用拥有的搜索契约可以把迁移缩减到一个可管理的边界。在映射新旧响应结构之前，先决定 UI 和下游服务需要什么。

应用字段	含义	迁移规则
title	可读的结果标签	明确处理缺失值
destination	用户可以打开的页面	保留返回的 URL
summary	简短的发现性描述	将其视为可选上下文
order	呈现给用户的顺序	为每个提供商定义其含义
query context	提问与请求的市场	在采集时一并保留
capture status	是否采集到可用结果	将其与“无匹配”区分开来

JSON 值定义有助于区分 null 和缺失成员。在提供商特定的响应到达 UI 之前，先决定你的契约如何处理这两者。

使用 Scrapeless 开始抓取

使用 Scrapeless 强化你的网页抓取与自动化工作流！
立即注册即可获得 5 美元免费额度 — 无需信用卡。
现在就在 Scrapeless 控制面板 领取你的免费额度。

使用具有代表性的一组查询来审查行为

一组具有代表性的查询应覆盖对用户重要的任务，包括那些错误范围会被看见的情况。应包含精确实体查询、宽泛类别问题，以及依赖你当前站点选择规则的搜索。

审查相关落地点、来源范围、结果排序、可选描述和无结果时的处理方式。目标是判断新的工作流是否满足应用需求，而不是要求不同搜索产品给出完全相同的结果排序。

在审查期间保留原始落地点。URI 组件规则 解释了为什么主机匹配与页面匹配不同。来自同一域名的两个结果仍然可能回答完全不同的问题。

将任何已知差异记录为产品决策：接受它、更改应用，或选择另一种受支持的方案。避免把一个已不再受支持的特性藏在一个沿用旧名称的字段后面。

以清晰的验收规则迁移流量

当切换有明确条件时，迁移更易于审查。为搜索契约、查询审查、部署变更以及面向客户的行为分别指定负责人。

保持服务提供方边界可配置。在代表性查询审查通过后，先迁移一小部分流量，观察应用结果，并在旧服务仍可用时保留恢复至以前配置的能力。

用有用的输出定义成功：相关的落地点、正确的范围、可读的呈现方式，以及对无可用结果的可见处理。如果项目还在构建排名追踪器，应为变化后的收集环境建立新的基线，而不是把互不兼容的历史记录拼接在一起。

比较完整迁移成本

迁移预算包括工程工作量和持续的采集规模。预估映射工作、结果展示修改、范围控制、数据保留以及计划中的请求负载。

将 Scrapeless 的定价与选定的工作负载和方案进行对照。针对相关使用量确认商业条款，而不是假设页面上展示的折扣适用于每个账户。还要为任何 API 提供商都无法替代的应用工作预留预算：权限、来源审查以及产品特定的报表。

使用更广义的 Google 搜索 API 解决方案来识别你的应用所需的采集场景。搜索可见性监测、公开研究和检索可以共享同一个 API 来源，同时保持不同的验收规则。

结论：用明确定义的契约替换依赖

要为 2027 年选择一个 Google Custom Search API 替代方案，应从搜索范围和应用的输出契约出发。当工作流需要结构化的公开 Google 结果时，Scrapeless 是一个候选项；请根据你的实际需求来评估这种匹配度。

下一步的实际行动是盘点当前依赖关系并进行一轮具有代表性的查询审查。尽早完成这些决策，以便在现有服务到期前从容完成迁移。

准备好构建你的搜索工作流了吗？

加入在 Discord 和 Telegram 上构建搜索产品的开发者社区。从一组聚焦的查询开始，把你的需求带给团队。

创建你的 Scrapeless 账户，把采集计划变成你的首个 Google Search API 工作流。

常见问题

问：现有 Custom Search JSON API 客户必须在什么时候完成迁移？

现有 Custom Search JSON API 客户必须在 2027 年 1 月 1 日前迁移到替代方案。该服务也已不再接纳新客户。

问：Scrapeless 是 Custom Search Engine 的即插即用替代品吗？

Scrapeless 应被评估为一个替代的采集层，而不是被假定为即插即用的替代品。请分别确认搜索范围、请求行为以及依赖的各项功能。

问：站点受限应用是否应该切换到不受限搜索？
站点受限的应用应当保持其承诺的搜索范围。只有当更广泛的公共搜索与产品需求相符，或应用能够强制执行所需的限制时，才适合使用更广泛的公共搜索。

问：迁移过程中应比较什么？

比较相关的目标位置、搜索范围、结果呈现方式、可选字段以及无结果时的处理方式。结果排序完全一致既不是迁移验收的充分条件，也不是必要条件。