Google全网搜索API只给合作方,新客户已进不去
本文目录
- 这个接口到底能拿到什么?
- 几个参数的形状,透露了它接下来想长成什么样
- 为什么响应里找不到排名位置?
- 必填终端用户的IP,把它的用途框死在哪?
- 谁能成为合作方,一次查询多少钱?
- 老的那个接口现在什么状态?
- 2027年1月1日之后,三条路各通向哪里?
- 文档里的XML痕迹说明了什么?
- 做排名监控的人会受影响吗?
- 自己写脚本查排名的:这条路基本走到头了
- 还有一个口径,不需要任何人授权
- 用商业排名工具的:短期不受影响,长期看数据商的上游
- 现在该做什么准备?
- 如果你有脚本或内部工具在用老接口
- 如果你在选排名或可见度工具
- 如果你在做需要搜索结果的产品
- 这件事不是Google要收费那么简单
- 到9月12日为止,哪些事还没定?
- 常见问题解答
- 这个接口和普通人能申请的Google Cloud接口有什么区别?
- 它的响应里真的没有排名位置吗?那怎么知道排第几?
- Custom Search JSON API现在还能申请吗?
- 我只是在自己网站上做个站内搜索,会受影响吗?
- 我用的排名工具会不会因为这件事断供或涨价?
- 那这套文档为什么现在才公开,之前不存在吗?
- 权威参考资料
摘要:2026年9月9日,Google更新了Web Search Service API的文档。这是一个只对合作方开放的全网搜索接口:响应里每条结果只有8个字段,没有排名位置;每个请求必须带终端用户的真实IP;一页最多20条。而老的那个Custom Search JSON API,官方概览页已经写明不对新客户开放,并且在2027年1月1日停服。想自己查Google的全网结果,从今年起先得有一份合作协议。
查排名这件事,做SEO的人每天都在做,很少有人想过那些数字是从哪儿来的。
排名工具后台跑的是爬虫还是接口,第三方数据商拿的是谁的授权,自己写个脚本能不能直接问Google要结果——这些问题平时不重要,因为总有办法拿到数据。今年开始不一样了。
Google把全网搜索结果做成了一个接口,然后在门上装了一把锁。这件事和同一周里另一桩变化是一个路数:ChatGPT购物推荐把取料口换成了商品feed,没接进去的店就不在候选集里。两边都是把入口从开放网络挪到了一份要申请的名单上。
这个接口到底能拿到什么?
先看它自己怎么说。接口参考页在2026年9月9日做了更新,把请求与响应的结构写全了。
端点只有一个,长这样:
GET https://websearchservice.googleapis.com/v1:search它同时支持REST和gRPC,返回JSON。请求体必须为空,所有参数都走查询串。方法名就叫Search,文档对它的定义是执行一次完整的全网搜索。
调它之前要备齐三样东西:一个活跃的Google Cloud项目、一个在Cloud Console里建的API密钥、以及一个与合作协议绑定的客户端标识。密钥通过X-Goog-Api-Key这个HTTP头发送,客户端标识则装在请求的clientContext里。
请求参数分成四组,必填的有三组。
| 参数 | 是否必填 | 内容 |
|---|---|---|
clientContext | 必填 | 只有一个clientId,格式固定为partner-[名称]-[产品]-[功能集] |
userContext | 必填 | ipAddress必填,要终端用户的IP;regionCode可选,两字母国家码 |
searchQuery | 必填 | query必填;另有界面语言、限定语言、限定国家、安全搜索开关、排序表达式 |
pageSize | 可选 | 取值1到20,默认10 |
pageToken | 可选 | 上一次响应给的翻页令牌 |
webSearch | 可选 | 搜索模式之一,而这个类型本身没有任何字段 |
searchQuery里还有一组互斥的时间窗参数:days、weeks、months、years,四个里最多能设一个,用来把结果限制在过去多少天或多少年之内。安全搜索是个枚举,只有未指定、关、开三档。
另外,文档提到很多搜索特性可以直接写在查询串里,靠的是搜索运算符那一套语法,而不是额外的接口参数。这一点和平时在搜索框里用高级运算符是一样的逻辑,站内整理过一份运算符做SEO情报的实战指令,那些写法在这里同样有效。
几个参数的形状,透露了它接下来想长成什么样
有三处细节值得单独看一眼,它们不影响今天怎么调,但能看出这个接口的规划。
第一处是webSearch。文档把它放在一组互斥的搜索模式里,明确写着这几个字段最多只会有一个被设置。而webSearch这个类型本身没有任何字段,是个空壳。为一个空类型专门开一组互斥字段,通常意味着后面还要往这一组里加东西——图片、新闻、视频这类模式如果要上,位置已经留好了。
第二处是四个时间窗参数:days、weeks、months、years,同样是互斥,最多设一个。它们做的是同一件事,只是粒度不同,这种设计来自老式搜索接口的习惯写法,不是现代接口会选的形状——现代接口更可能给一个起止时间戳。
第三处是sortExpression,文档给的例子是sort=date。注意这个例子的写法:它是把一个查询串片段当成参数值传进去,而不是给你一个枚举或结构化对象。这也是老接口的痕迹。
把这三处放在一起,能看出这套接口的骨架比它的外壳老得多。这个判断在后面那节还会用到。
为什么响应里找不到排名位置?
把字段表逐条核完,最意外的是这一条。
每条搜索结果的结构只有8个字段:title、htmlTitle、displayUrl、shortenedDisplayUrl、snippet、htmlSnippet、mimeType、fileFormat。
纯文本标题和HTML标题各一份,完整网址和缩短版网址各一份,纯文本摘要和HTML摘要各一份,再加上文件类型与格式。没有排名位置,没有规范网址,没有站点链接,没有任何富结果的结构。
换句话说,位置这个信息只隐含在数组顺序里。你拿到第一页10条,它们就是1到10名;要第11到20名,得带着翻页令牌再请求一次,而单页上限是20条。
| 它给你的 | 它不给你的 |
|---|---|
| 标题(纯文本与HTML各一份) | 排名位置字段 |
| 网址(完整与缩短各一份) | 规范网址与重定向链 |
| 摘要(纯文本与HTML各一份) | 站点链接、评分、价格这类富结果结构 |
| MIME类型与文件格式 | 精选摘要与AI概览的任何痕迹 |
| 耗时、结果总数估值、拼写纠正 | 是谁触发了纠正、纠正前后的排名差异 |
响应的另一半是searchInfo,里面是这次搜索的元信息:服务端耗时、结果总数的估值、按地区格式化后的总数、以及纠正后的查询词(同样纯文本与HTML各一份)。最后一个字段是nextPageToken,没有更多结果时它是空的。
这个字段表告诉你的是它的设计意图:这是一个给产品做搜索展示用的接口,不是给分析做数据采集用的接口。它交付的是一屏能直接渲染出来的东西,而不是一份能拿去做排名对账的数据。
顺带说一句,结果总数那个值是估值。这一点和搜索框里的数字一样不可靠,站内之前比过site运算符和后台收录数据到底该信谁,结论是两边口径不同,谁也不能当另一个的校准基准。
必填终端用户的IP,把它的用途框死在哪?
userContext.ipAddress是必填字段,文档写的是终端用户的IP地址。
这一条比字段表里任何一条都更能说明这个接口的定位。它的设计前提是:有一个真实的人,正在你的网站或应用里发起一次搜索,而你把这次搜索转给Google。
拿它去批量跑关键词表,你就得为每一次请求编造一个IP。编出来的IP还会影响结果,因为地理位置本来就是搜索结果的变量之一。
这个约束把两类用法分得很清楚。转发真实用户的搜索请求,是它想要的;把词表灌进去采集排名,是它不想要的——不是技术上做不到,是合约和字段设计两头都在挡。
做排名监测的人对这类约束应该不陌生。同一个词在不同设备、不同地点查出来的名次本来就不一样,站内拆过换台设备就全变的六个原因,IP和地理位置是其中最大的一个。现在这个变量从“要小心控制”变成了“必须提供,而且得是真的”。
谁能成为合作方,一次查询多少钱?
这是全篇最短的一节,因为答案是:官方没写。
三个页面都把使用者称为程序化合作方,说请求通过客户端标识与合作协议关联。参考页给出的标识示例是partner-example-wss-standard,格式是partner-名称-产品-功能集。
这个格式本身透露了一点信息。末尾那一段是功能集,示例值是standard——既然有标准档,就说明还有别的档。至于各档差什么、怎么申请、按什么计费、每天能查多少次,三个页面一个字都没写。
这和一个普通的Google Cloud接口完全不同。普通接口是在控制台里点一下启用,看着价目表自己算钱;这个接口是先谈一份协议,拿到一个标识,才能开始发请求。监控倒是提供了,走Cloud Console的接口面板,和其他Google Cloud服务一样。
也就是说,技术规格是公开的,能不能用是不公开的。文档写得越详细,这个反差越明显:请求怎么构造、字段什么含义、翻页怎么翻,全都清清楚楚;而“你能不能成为合作方”这个唯一决定性的问题,只能去填一张表。
老的那个接口现在什么状态?
要理解新接口为什么长这样,得看旧的那条路被怎么处理了。
Custom Search JSON API是Google做站内搜索与小范围全网搜索用了十几年的接口,很多工具、很多脚本、很多学术项目都靠它。它现在的官方概览页上,定价那一节开头是这么一句:
以下定价仅适用于现有的Custom Search JSON API客户,直至该服务在2027年1月1日停止提供。此接口不对新客户开放。
两件事要分开看。第一,官方用的词是停止提供,不是迁移、不是升级、不是重构。第二,也是更要紧的那一条:这个接口已经不接新客户了。
换句话说,今天一个想自建全网搜索查询的团队,不光走不了新路,连旧路也进不去。旧路只对已经在里面的人开到2027年1月1日。
它的额度和价格也值得记一下,因为这组数字说明它从来就不是为大规模采集设计的。
| 项目 | 数值 |
|---|---|
| 免费额度 | 每天100次查询 |
| 超额单价 | 每1000次查询5美元 |
| 每日硬上限 | 10000次查询 |
| 停服日期 | 2027年1月1日 |
| 新客户 | 不开放 |
每天一万次听着不少,但换算成排名监测就很局促:一万次查询,如果每个词只查一页,一天能覆盖一万个关键词,这对一个中型站的词库来说刚够;要是每个词查三页、或者要按国家分开查,能覆盖的词就掉到三千以下。而且这是硬上限,不是可以申请提额的软限。
这也是为什么市面上的排名工具大多不靠这个接口。它们各有各的数据来源,有的自建爬虫,有的买第三方数据,有的混着用。站内比过三家工具与后台数据对不上该怎么对账,那篇的结论放在这里正好:几家的数字从来就没对齐过,因为它们的取数管道根本不是一条。
2027年1月1日之后,三条路各通向哪里?
Google在2026年1月20日发过一篇产品更新公告,把使用场景分成了三条路。那篇公告是这次变化的总纲,九月更新的那套文档是其中一条路的说明书。
| 你的用法 | 去哪条路 | 域名上限 | 价格 |
|---|---|---|---|
| 在自己站内做搜索 | Programmable Search Element | 最多50个域名 | 免费 |
| 企业级对话式搜索与接地 | Google Vertex AI Search | 同样按50个域名以内推荐 | 按云服务计费 |
| 要查整个索引 | 填表申请全网方案 | 无 | 要谈,公告让你联系咨询 |
公告的原话是,理解有些合作方的用例需要查询超出指定域名子集的范围,需要整个索引的可以填表登记意向。至于超过50个域名、或者当初把配置设成搜索整个网络的老用户,公告写得很直接:联系我们了解更高级的全网搜索方案的能力与定价,并在2027年1月1日前完成迁移。
50个域名这条线,是这次分流的实际分水岭。线以内免费且继续支持,线以外要谈合同。对绝大多数做站内搜索的网站来说,50个域名够用;对做聚合、做监测、做研究的,这条线等于关门。
至于企业级那条路,公告推荐的是Vertex AI Search,它的定位是AI对话式搜索与企业级接地。顺着这条路还能看到整个格局的位置,站内梳理过全球搜索引擎的版图与多平台优化打法,Google之外的几家在这一层的策略并不相同。这里的接地指的是让模型的回答挂在可验证的资料上,站内讲过AI读取和引用网页的几个底层机制,接地是其中最关键的一环。它解决的是给自己的AI产品配一个搜索后端,不解决“我要看Google的自然结果长什么样”。
还有一个细节值得留意:截至2026年9月11日,一月那篇公告和九月更新的这套文档,互相都没有提到对方。公告里说的全网方案,和文档里写的Web Search Service API,在两个用例上完全吻合——都是全网搜索,都限定合作方——但Google没有把它们明确挂在一起。
文档里的XML痕迹说明了什么?
核字段表的时候还撞见一处很有意思的东西。
那几个语言与地区参数的取值表,文档给的链接不在当前这套文档里,而是指向/web-search-service/xml/web-search/reference/appendixes.html这样一个路径。
路径里那个xml和appendixes不是随便起的。那是Google当年企业搜索产品线的文档结构——搜索设备与站点搜索那一套,走的是XML接口,支持的界面语言、语言集合取值、国家码,全列在附录里。
所以这个2026年才公开文档的“新”接口,本质上是给一套存在很久的企业搜索能力,套了一层REST与gRPC的现代外壳。它不是新造的,是把一直存在但不对外的东西,重新包装出来对合作方开放。
这件事改变了对这次变化的解读。如果它是新建的服务,那叙事是“Google推出了一个新产品”;如果它是老企业接口的换壳,那叙事就变成“Google把一直卖给企业的东西,做成了唯一的公开全网通道,同时把原来那条便宜的公共通道关掉”。
两种叙事对应完全不同的预期。前者可以期待它慢慢变好、逐步开放;后者要做的准备是接受它一直贵、一直挑客户。
做排名监控的人会受影响吗?
分两种情况,结论完全相反。
自己写脚本查排名的:这条路基本走到头了
如果你现在还在用Custom Search JSON API跑自己的排名脚本,两件事要安排。一是2027年1月1日是硬截止,不是建议时间。二是别指望申请到新接口,因为它连价格都不公开,而且响应里没有排名位置,拿到手也还得自己数数组。
还有一层容易被忽略:新接口要终端用户的真实IP。批量跑词表这件事,在字段层面就不被支持。
站内之前写过怎么用Python配第三方接口批量抓关键词数据,那篇讲的方法在技术上依然可行,因为它走的是第三方数据商而不是Google官方接口。但这也正说明问题:官方通道关上之后,路只剩商业数据商这一条。
还有一个口径,不需要任何人授权
如果目的是知道自己排第几、被展示了多少次、点击涨没涨,那有一份数据从头到尾都不受这次变化影响:自己站的搜索后台。
它给的是真实查询的真实展示与点击,比任何第三方抓来的名次都准,代价是只能看到自己这一亩地,看不到竞品。它也有自己的上限——每次查询最多取一千行、低量词会被阈值过滤掉,绕开的办法后面那节会提。真正被低估的是它的查询能力,站内写过用正则从后台里挖AI搜索问法,那批词是任何第三方词库都给不了的。
换个角度说,这次被收紧的其实只有一件事:程序化地观察别人。观察自己的通道一直开着,而且免费。对多数团队来说,把自己那份数据用透,收益比补一个排名词库更大。
用商业排名工具的:短期不受影响,长期看数据商的上游
主流排名工具没有一家是靠Google这个公共接口拿数据的——一万次的日上限撑不起任何一家的业务。它们的上游各不相同,短期内不会因为这次变化断供。顺带说一句,工具好不好用和它报的数准不准是两件事,免费工具页反而常年稳定拿流量,站内分析过计算器与转换器这类工具页的做法,逻辑跟数据源无关。
另外值得留一眼的是索引侧的分层:Google内部对页面本来就不是一视同仁,站内拆过页面被丢进哪一层索引这件事,而接口给出的结果只是最上面那层的投影。要关注的是另一件事:当官方唯一的全网通道变成合约制,“谁有授权”就成了一个有价值的位置。拿到授权的数据商和没拿到的,交付质量和合规风险会拉开。这一层变化不会立刻显形,但会慢慢影响工具选型。
说到这里有个参照。免费或者极便宜的公共通道被收窄,在搜索这个行业不是第一次。站内写过一篇讲2013年那次围栏,结论是免费的窗口从来不会一直开着。当年被围起来的是搜索词数据,这次被围起来的是搜索结果本身。
现在该做什么准备?
按角色分开说,因为该做的事完全不同。
如果你有脚本或内部工具在用老接口
先盘一遍,别凭印象。去Cloud Console的接口面板看Custom Search JSON API的调用量,确认是哪个项目、哪个密钥、每天多少次、被哪些系统调用。很多团队的情况是:三年前某人写的一个脚本还在跑,而写它的人已经不在了。
盘完之后按用途分三类处理。站内搜索功能可以迁到Search Element,50个域名以内免费;给AI产品做后端的迁到Vertex AI Search;真需要全网结果的,现在就去填意向表,因为价格和准入都要谈,谈的周期不由你决定。
顺带提醒配额这件事。GSC那个URL检查接口的每日2000条配额怎么排管线,站内写过一份实操,那套思路在这里同样用得上:先算清一天能查多少、再决定查什么,而不是反过来。
如果你在选排名或可见度工具
多问一句上游。数据是自建爬虫、买第三方,还是走官方授权,问清楚之后再看它的报价与稳定性承诺。这个问题在2027年1月1日之前只是加分项,之后可能变成必答题。
同时别把任何单一工具的数字当真值。站内拆过审计工具号称95%准确率其实是自己划的及格线,也拆过估算工具那把尺子刻的是上一代口径,两件事的共同点是:工具报出来的数,先要问它是怎么量的。
如果你在做需要搜索结果的产品
这一类最该早动手,因为它的替代方案最少。除了Google这条要谈合约的路,可选的还有微软那套接口——站内介绍过给AI代理用的Bing接地接口是什么、对SEO意味着什么,它的定位与这次Google开放的这条路高度重叠。多准备一个上游,比等一张表的回音稳妥。
这件事不是Google要收费那么简单
看到停服和合作方这两个词,第一反应容易是“Google又要涨价了”。这个解读不完整。
真正变的是获取搜索结果的门槛形态。过去是按量付费:免费100次,超了每千次5美元,上限一万次。价格公开、规则公开,谁都能算出自己要花多少钱。现在变成准入制:先谈协议、拿标识,价格与配额都不在公开文档里。
从算得出来的价格,变成谈得下来的资格,这是两种完全不同的市场结构。前者对所有人一样,后者按你是谁来定。
这个变化对SEO的影响不在排名上,在观测能力上。你优化的对象还是那个搜索结果页,但“能不能大规模地、程序化地看到它”这件事,从一个技术问题变成了一个商务问题。
类似的转折在抓取这一侧已经发生过一轮。站内写过Cloudflare按次抓取要不要向AI爬虫收费,那次是内容方给爬取装了闸;这次是索引方给读取装了闸。两件事方向相反,性质一样:免费流通的那层,正在被两头同时收紧。
还有一个容易混的边界。这篇讲的是拿Google的自然结果,不是拿自己站的数据。自己站的收录、展示、点击,后台一直给,而且比任何接口都准,只是有它自己的口径与上限——站内拆过后台那三个数据黑洞怎么用URL分组和阈值过滤绕开。两件事别混着规划。
到9月12日为止,哪些事还没定?
把已知和未知分开摆,免得把推测当结论用。
已经确定的:文档在2026年9月9日更新;端点单一、请求体必须为空;三件前置条件是Cloud项目、API密钥、合作协议绑定的客户端标识;响应里每条结果8个字段、没有位置;单页上限20条;终端用户IP必填;老接口不接新客户、2027年1月1日停服,现有客户的额度是每天100次免费、每千次5美元、每日上限一万次。
还没有答案的:
- 成为合作方的资格条件、审核标准、周期,官方没有任何说明。
- 价格与每日配额上限不在公开文档里,得谈。
- 客户端标识格式里的功能集有哪几档、各档差什么,只知道有一个叫标准档。
- 一月的公告与九月的文档互不引用,Google没有明确说这个接口就是公告里那条全网方案。
- 老接口停服之后,现有客户会不会被自动接到新接口上,没有过渡方案的说明。
- 响应里会不会补上位置、富结果这些字段,文档没有路线图。
这份未知清单里,前两条决定了绝大多数团队根本没法做规划。能做的只有一件事:把要用搜索结果的地方标出来,然后为每一处准备一个不依赖Google官方接口的方案。
顺带说一句,工具链这几年的走向也在帮这件事。现在一个SEO团队要做的很多活,已经能用命令行加脚本自己拼出来,站内聊过CLI加技能正在接管代理工具链的主干。上游收紧的时候,自己动手的那部分能力越强,被卡住的地方就越少。
常见问题解答
这个接口和普通人能申请的Google Cloud接口有什么区别?
普通的Cloud接口在控制台里启用就能用,价目表公开,自己算钱。这个接口除了Cloud项目和API密钥,还要一个与合作协议绑定的客户端标识,格式是partner开头。也就是说,技术上准备齐了也调不通,得先有协议。
它的响应里真的没有排名位置吗?那怎么知道排第几?
真的没有。每条结果只有标题、网址、摘要、MIME类型与文件格式这8个字段,位置只能靠数组顺序推。单页最多20条,要更靠后的结果得用翻页令牌再请求。而且名次本身也不是一个稳定的观察对象,站内做过用像素而不是名次去丈量可见性的尝试,同一个第一名在不同页面里露脸的面积能差很远。所以拿它做排名监测,位置得自己数,而且一次只能看20个。
Custom Search JSON API现在还能申请吗?
不能。官方概览页明确写了此接口不对新客户开放,现有客户的服务在2027年1月1日停止。现有客户的额度是每天100次免费、超出每千次5美元、每日硬上限一万次。
我只是在自己网站上做个站内搜索,会受影响吗?
基本不受影响。站内搜索走Programmable Search Element,最多指定50个域名,这个功能保持免费。只有当你的配置超过50个域名、或者设成了搜索整个网络,才要在2027年1月1日前换方案。
我用的排名工具会不会因为这件事断供或涨价?
短期不会。主流工具都不靠Google这个公共接口取数,每天一万次的上限撑不起任何一家的业务量。长期要看各家上游的授权情况,选型时可以多问一句数据来源是自建爬虫、第三方还是官方授权。
那这套文档为什么现在才公开,之前不存在吗?
能力早就存在。文档里语言与地区参数的取值表,链接指向的是带xml与appendixes的路径,那是Google当年企业搜索产品线的文档结构。所以这更像是把一直卖给企业的接口套上REST与gRPC的新壳,再作为唯一的公开全网通道放出来,而不是从零新建一个服务。
权威参考资料
本文标题:《Google全网搜索API只给合作方,新客户已进不去》
本文链接:https://zhangwenbao.com/google-web-search-service-api-partner-only.html
版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0