IndexNow 的接收方有哪几家，Google 在不在名单里
即时通知类协议只对参与方生效。按官网口径，IndexNow 的支持方是 Microsoft Bing、Naver、Seznam.cz、Yandex、Yep 这几家，Google 不在名单里。这条事实决定了一个常见误解：配好一条通知不等于所有引擎都第一时间知道，没被通知到的引擎仍按自己的抓取节奏发现更新。
即时通知解决的是发现延迟
它做的是「有新内容了，主动说一声」，缩短的是引擎知道更新的时间。它替代的是等待被抓取周期扫到，而不是替代收录本身。通知被受理，也不代表一定收录或怎么展现，那是后面的抓取与索引环节。
接收方名单决定覆盖面
能收到通知的，只有参与这套协议的引擎。
| 通道 | 对谁生效 | 管的是 |
|---|---|---|
| 即时通知 | 名单内的引擎 | 增量新内容的发现速度 |
| 站点地图 | 读地图的引擎 | 全站地址的完整覆盖 |
| 常规抓取 | 所有引擎 | 按各自节奏发现更新 |
名单外的引擎收不到通知，就只能靠站点地图与常规抓取被找到。
没被通知到的引擎走哪条路
对不参与通知的引擎，全量覆盖交给站点地图，增量靠抓取周期。所以不能因为「配了即时通知」就省掉站点地图；也不能因为「有站点地图」就忽略推送在速度上的价值。两条通道的能力不重叠。
站内两条通道同时配的顺序
站内要把百度、Bing 的主动推送和站点地图都配好。先确认伪静态改写后的最终地址是同一口径，推送与地图都指向它；再把增量新内容走推送、全量清单走地图。配好后抽查同一个地址在各通道里是否一致，别出现推送用的地址和地图里的地址写法不同。这里说的「同一口径」，指的是去掉参数差异、指向同一份正式内容的规范地址，而不是字面上随便一种写法。
通知被受理不等于立刻收录
即时通知解决的是发现速度，不改变收录判定。引擎收到通知后仍要抓取、解析、建索引，再决定要不要展现。所以别拿「通知成功」去推断「已收录」，两者中间隔着几个环节，收录情况要回到对应的收录反馈去看。
常见问题
问：Google 收不到通知，是不是就不收录了？ 不是。Google 不参与该协议，它按自己的抓取与站点地图发现更新，收录不受是否配通知影响。
问：只配站点地图够不够？ 覆盖够，但少了增量被尽快发现的加速。新内容多、更新频繁时，推送能补上这段时间差；更新很少时，光靠站点地图也够用。
问：同一地址在多条通道里会不会冲突？ 不会冲突，但要一致。三条通道指的是同一批最终地址，写法不一致反而会让某些地址被某条通道漏掉，抽查时以规范地址为准逐条比对。