google indexing api 只认两类页面：其余的该走哪条路

google indexing api 只收两类页面，其余一概不认。Google 自己的快速入门把规则写成了一句话：它「can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject」。如果你发的是文章、产品页、列表页或文档，这个接口不是它们的快车道 —— 插件写得再顺手也改不了这一条。真正对所有人开放的路有三条，下面列全。

读这篇前

这一节是手册里一件事的边界版。发布之后的常规推送流程写在 页面改完之后怎么推送收录，现实的等待时长写在 google 收录一般要多久。当团队里有人问「插件里那个一键推送 Google 收录为什么不开」，读这一篇。

google indexing api 是给谁用的

两类页面，共同点是天然短命。招聘岗位招到人就作废，直播页第二天就没有价值。这两类的共同问题是：从发布到被抓取的这段时间差，会把页面的价值直接吃掉 —— 这个接口就是为解决这件事存在的。

第二类要逐字读，它比看上去窄。原文写的是 BroadcastEvent 嵌在 VideoObject 里 —— 一个预定直播的页面，而且标记成这个形状。普通视频页不算，没有直播的活动页也不算。这个短语里三个词有两个在起限定作用。

快速入门对「不合规怎么办」也写得很直接：「However, we still recommend submitting a sitemap for coverage of your entire site.」两句连起来读，形状就清楚了 —— 这个接口是一个很窄的补充，网站地图仍然是通用机制（Indexing API quickstart，2026-09-02 访问）。

它支持三个操作，第三个是最常被忘掉的那个。

访问权也不是默认开放的。Google 写明这个接口「provides a default 200 quota for API onboarding and submission testing, and it requires additional approval for usage and resource provisioning」。一个按「接入与测试」尺寸给的默认配额，本身就说明了它是给谁准备的。

带资格规则的接口不是一条排队的快车道。它是另一扇门，而你手上这把钥匙未必打得开。

为什么那么多工具说得不一样

因为这个端点在提交时不检查你的页面类型。任何网址 POST 过去都会拿到响应，而那个响应看起来就是成功。回复里没有一个字说「这一页不合规」，所以插件作者完全可以做出这个功能、看着它返回 200、然后诚实地发布出去。

Google 谈的是后果而不是机制：「All submissions through the Indexing API undergo rigorous spam detection. Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.」这句覆盖的是蓄意滥用配额。它没有描述「一个普通文章网址被误提交一次」会怎样，我们也没有做过这个实验 —— 所以这份风险按未定义处理，不按零处理。

还有一个自己就能验的判据：装插件前后各导出一次网站地图，看 lastmod 有没有跟着发布时间走。多数「一键推送」插件同时会重写网站地图，而那一半是真的在起作用的。把两件事分开看，才知道该保留哪一半。

更靠得住的反驳其实更简单：一个你根本不满足资格的机制，不可能是任何改善的原因。装了这类插件之后如果真的变快了，快的来源是别的东西，通常是它顺手开始更新的那份网站地图。

动手做：资格自测

三步，每一步今天就能验完。做之前先记住一件事：判断资格看的是页面上实际交付的结构化数据，不是页面在你眼里属于哪一类。一个招聘列表页如果没有把 JobPosting 真的写进去，它在这个接口眼里就不是招聘页。

1. 用下面那条命令在交付的 HTML 里找这两个类型。完成标志：你发布的每一种模板，各取一个代表页，都拿到两个计数。
2. 全都是零，就到此为止，走下面那张表里的路线。完成标志：把这个决定写下来，免得三个月后又被翻出来重议。
3. 确实在发招聘页或直播页，就去申请访问权，并且只把接口接到那一种模板上。完成标志：接线接在模板上，不是接在发布钩子上。

# 这些页面带着可用的类型吗？
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/page > page.html
grep -c '"@type" *: *"JobPosting"' page.html
grep -c '"@type" *: *"BroadcastEvent"' page.html

交付物：资格判读表 + 三条真能走的路线

先看哪些页面有资格。左列是你在发的东西，右列是老实话。

再看对所有人开放的三条路线。每条都有写明的行为和写明的限制，没有一条是即时的。

中间那条路的官方说法值得整句引，因为它一次打掉两个常见的期待：「Keep in mind that there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster.」以及「Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all.」（Ask Google to recrawl your URLs，2026-09-02 访问。）同一页给出的等待区间是「anywhere from a few days to a few weeks」，并且把有量的人直接指回网站地图：「If you have large numbers of URLs, submit a sitemap.」

第三条是另一套系统，有自己的一套配置，写在 indexnow 怎么把网址推出去。它触达 Bing 和 Yandex。它不是进 Google 的路，任何把一个按钮写成「一键推送全部搜索引擎」的工具，都是把两个网络说成了一个。

三种常见的做错

最贵的一种是看了一篇教程跑通了，就把这个接口接进通用发布钩子。从此每发一篇文章都会打到一个用不上它的端点，服务账号的提交历史里堆满不合规的网址，而真正该做的网站地图那摊事一直没做。

第一种错还有一个更贵的变体：一个站既发招聘岗位又发普通内容，接线接在站点层而不是模板层，于是文章和岗位走的是同一根管子。岗位那一半本来是合规的，现在提交历史里大部分都不是。接到模板上。

第二种是把 200 响应当成确认。那个回复告诉你的是请求被接收并解析了。它没告诉你这个网址合不合规，也没告诉你任何关于抓取的事 —— 那是这个端点从来不负责回答的问题。

第三种是把「每天 200」当成要优化的天花板。那个配额是给接入和测试用的，真正的招聘站会去申请更多。围着测试额度做队列和限流，是把力气花在了一个不相干的数字上。

这条路到哪儿为止

两条边界，都比上面的流程更要紧。

提交一个不合规的网址到底要付什么代价，我们不知道。Google 写了垃圾检测，也写了配额滥用可能被吊销访问权，对单次误提交只字未提。这个实验我们没跑过，也不会报一个手上没有的数字。该停手的理由不在风险，在于这个机制对你的页面根本不适用 —— 这一条本身就够了。

还有一条对做出海站的人特别值得说：这个接口在中文技术圈的知名度，远高于它实际能覆盖的页面比例。真正卡住一个新站的通常不是「Google 不知道我发了新页面」，而是「Google 知道了、抓了、但没有收」。那是内容与站点结构的问题，催多少次都不会变。判断自己卡在哪一段，比找一个更快的通知渠道重要得多。

三条能走的路线，没有一条产生收录，它们只让发现来得更早。之后 Google 收不收，取决于页面本身；而如果一个页面压根没被抓到过，问题通常更靠上游 —— 是可达性，不是通知。在花力气优化通知管道之前，先确认引擎能取到、读得懂这一页，可以跑一次 QueryWin 的差距检查。

常见问题

google indexing api 能推普通文章吗？

不能。写明的规则限定在带 JobPosting 或带 BroadcastEvent（嵌在 VideoObject 里）的页面上，一篇文章两个都不带。端点不会拦下这种提交，这也是这个误解一直活着的原因。

indexing api 的配额是多少？

Google 的说法是「a default 200 quota for API onboarding and submission testing」，要更多得另外申请。请把它理解成搭接入用的额度，不是每天的发布预算。

WordPress 上那些 indexing api 插件有用吗？

它们能把请求发成功。但请求对一个不在适用范围内的页面类型有没有用，是另一个问题，而文档已经回答了：这个接口只能用于那两类。

合规范围内最快的催收录方式是什么？

所有页面靠一份准确的网站地图，外加对当下最要紧的那一页用网址检查。Google 自己给的等待区间是几天到几周，同一个网址反复提交不会缩短它。

IndexNow 会推给 Google 吗？

IndexNow 触达的是 Bing 和 Yandex，那是另一个网络。为这两个引擎做它本身是值得的，但它替代不了本篇里的任何一条。