AI 跨境增长站
← AI SEO

Google Content API 关停了：不迁到 Merchant API，你的商品流 9 月起开始报错

product-feed technical-seo google-shopping google-merchant-center google-ads

报错是渐进的，所以你到现在可能还没察觉

Content API for Shopping 已经在 2026 年 8 月 18 日关停。从 9 月 1 日起，打过去的请求开始渐进式报错。

“渐进式”这三个字是这件事最麻烦的地方。一部分请求开始失败，失败的比例往上走。你的 ERP 或者 feed 工具这几天大概率还在正常同步大部分商品，只有零星几条超时或者报错，运维看一眼觉得是网络抖动，重试一下过去了，就没人往下追。

等到失败比例大到能被察觉的时候，Merchant Center 里那批没更新上的商品已经躺了一阵子了。Merchant Center 的商品数据有 30 天的有效期，从最后一次刷新算起，超过 30 天没有新的更新推进来就会过期下架。也就是说 9 月 1 日开始悄悄失败的那批 SKU，10 月上旬开始从各个展示位掉出去。

这里有一个缓冲你可能用得上。Google 会定期抓你的网站，商品数据能校验得上的话会自动帮你刷新，比如靠页面上的 schema.org 结构化数据。所以站点结构化数据做得干净的店，掉得会比上面这个时间表慢一些。但这条路只兜得住能从页面上读到的字段，价格和库存状态这类变动频繁的东西，仍然要靠 feed 推。别把它当成不用迁移的理由。

中间这一个月是白过的。9 月 1 日开始报错你察觉不到，等 10 月上旬商品从展示位掉下去的时候，处理窗口已经用完了。

所以先确认自己到底在不在受影响范围里，再谈排期。有的店根本不走 API，忙活半天是白忙。有的店的 feed 工具今年已经迁完了，店主自己不知道，也就没必要再排人手进去。

谁在用旧 API：半小时能查清楚

受影响的是所有用程序往 Google 推商品数据的人。自己写脚本的、用 Feedonomics 或者 Channable 这类 feed 工具的、ERP 里带 Google 渠道模块的、Shopify 装了第三方 Google 同步应用的，都算。

查起来从三个地方入手。一是问对接方，直接跟你的 feed 工具或者 ERP 供应商要一句准话：你们现在调的是 Content API for Shopping 还是 Merchant API。这是最快的一条路，很多工具商今年已经完成迁移了，你可能什么都不用做。

二是翻 Google Cloud Console 的 API 用量。看你的项目里启用的是哪个服务、最近的调用量曲线和错误率。如果 Content API for Shopping 那一栏还在跑量，或者错误率从 9 月初开始往上翘，答案就出来了。

三是直接搜代码。自研脚本就在仓库里 grep 两个串：shoppingcontent.googleapis.com 这个主机名，和 content/v2.1 这个路径片段。Content API 的每一个 REST 地址都是 https://shoppingcontent.googleapis.com/content/v2.1/ 开头的，命中就是旧 API。用官方客户端库的情况下主机名可能拼不出来，那就搜库名里带 content 的那个依赖。

顺带说一句，一般来说手动上传文件、定时抓取和 Google Sheets 这几种 feed 方式在 API 关停之后仍然可用，它们本来就不走 API。所以纯手动或者纯定时抓取的店，这次基本不受影响，先确认自己属不属于这一类，省得白忙。

流断了之后，哪些地方会黑掉

商品流停更的影响不只在购物广告一处，几个渠道是连着的。

渠道商品过期后的结果
免费购物列表商品从 Shopping 标签页里消失，自然曝光归零
Performance Max商品组里没有可投的商品，这部分预算跑不出去
标准购物广告对应 SKU 停投
AI Mode 里的商品展示依赖 Merchant Center 的商品数据，数据过期就不再被取用
本地库存门店可售信息停更，线上线下不同步

最容易被低估的是 Performance Max 那一行。它不会报”没有商品”这种明显的错，只是安安静静地把预算往其他资产上挪，或者干脆跑不满。你在报表里看到的是转化下滑，很容易归因到竞价环境变了、旺季还没到，没人会往商品流断了这个方向去查。

AI Mode 里的商品展示这一块也说一下。这条链路取的就是 Merchant Center 的数据，商品过期之后会直接从候选集里掉出去，不是排名靠后那种可以慢慢修的情况。现在越来越多的购物决策发生在这类界面上，断掉的代价比一年前大。

判断自己中没中招，最快的一个指标是 Merchant Center 里的”有效商品数”。把这个数字跟一个月前对一下，掉了就说明有 SKU 在过期。这个数字每天看一眼，比等广告报表出现异常早一个月。

Merchant API 接管了哪些活

Merchant API 就是 Content API for Shopping 的替代品，原来那些事全在它这儿：上传商品、管理库存、管理 Merchant Center 账号、把库存跟 Google Ads 打通。功能范围对得上，所以这次迁移的工作量集中在把现有调用改到新端点上，业务逻辑那部分基本不用重写。

迁移的顺序建议这么排。先在测试账号上把新端点跑通一条商品的上传和更新，确认认证和字段映射都对；再把全量商品在新旧两套上并行推一段时间，对一下 Merchant Center 里的商品数和差异；确认数字对得上之后再把旧的调用关掉。别一次性切，商品数对不上的时候你需要一个能回退的状态。

要重点核的是字段映射。商品 ID、库存状态、价格、配送这几组字段在新接口里的结构跟旧的未必完全一致，映射错了不会立刻报错，而是商品进了 Merchant Center 但被判成不合规，在后台的”商品”页面里挂着警告。迁完之后去 Merchant Center 的诊断页面把警告和拒登逐条看一遍，比看接口返回的 200 有用。

用第三方工具的店主，这一段的工作量主要是催和验。催供应商给出迁移时间表，验它迁完之后你后台的商品数和状态跟迁移前一致。别只听一句”我们已经迁好了”就结束。

延期表单：来不及的时候那个急救开关

Google 留了一张延期申请表单。提交之后是即时批准的，前提是你填的 Google Cloud 项目 ID 填对了。

项目 ID 填对这件事值得多花两分钟。填错了这次申请就是白提交，而你多半要等到下次报错才发现没生效。去 Cloud Console 里把项目 ID 复制出来，注意是项目 ID 不是项目名称，两者经常不一样。如果你有多个项目在调这个 API，每个都要填进去，漏一个那个项目就继续报错。

这张表单是给排期实在腾不出来的团队用的缓冲。拿到延期之后要做的第一件事是把迁移排进日程，这事别就此从待办里划掉。上面那套并行验证的流程该走还得走，只是你现在有时间从容走完。

如果你已经开始掉量了，处理顺序是：先提交延期表单恢复旧 API 的调用，把商品流接上；再回头查 Merchant Center 里哪些商品已经过期、重新推一遍；最后才是排迁移的排期和人手。

Read this article in English: Google Shut Down the Content API: Migrate to Merchant API or Your Feed Starts Erroring in September

相关文章

Cloudflare 9 月 15 日改了默认值：帮顾客下单的 AI 代理可能进不来了

Cloudflare 7 月把原来那个拦 AI bot 的单一开关拆成了 Search、Agent、Training 三类，各管各的。9 月 15 日起新接入的域名拿到新默认值：带广告的页面上，归到 Training 或 Agent 的 bot 被拦，Search 照常放行。这篇讲拆分后各类分别管什么、新默认值具体影响谁，以及店主进后台该看哪几处。

ai-search-visibility technical-seo geo