国内做站的同行有个共同的困惑：Google Search Console 里数据看着还行，但百度和必应那边到底什么情况，心里完全没数。等到某天发现某个关键词的流量掉了三成，回头去查，才发现页面早就不在索引里了，而这件事可能已经发生了一个月。

这篇文章不是讲「怎么提交 sitemap」这种一搜一大把的内容，而是讲三个平台的差异在哪、各自能给你什么独家数据、以及一个人维护站点时最省事的检查节奏。我自己的站同时挂着这三家，一周花不到二十分钟。

一、三个平台的性质不一样，别当成同一件事

先建立一个正确的心理模型。Google Search Console 是「数据平台」，它的价值在于告诉你曝光、点击、排名分布、抓取统计和索引状态，报告细到你几乎可以拿它当分析工具用。百度搜索资源平台更偏「提交与反馈平台」，它的核心功能是链接提交、抓取诊断、索引量查询和站点改版，数据颗粒度粗得多，但改版保护和快速收录这两项是 Google 没有的。

必应站长工具（Bing Webmaster Tools）介于两者之间，但有一个别人没有的特色：它支持导入 Google Search Console 的数据和验证，甚至可以直接从 GSC 拉关键词。同时它的 IndexNow 支持是最早也最完整的，我站里的 IndexNow 推送就是主要喂给必应的。

理解这个差异很重要，因为它决定了你的动作分配：Google 那边主要看数据做内容决策，百度那边主要做提交和改版保护，必应那边主要做 IndexNow 与低成本维护。

二、百度资源平台：真正有用的是这四项

百度的界面这些年改过好几轮，功能项很多，但一个人维护站点只需要盯四个地方。

第一是链接提交里的 API 推送。百度的普通收录有三种提交方式：主动推送、sitemap、自动推送。主动推送是唯一能保证「发完立刻知道」的方式，配额按站点权重给，新站往往一天只有几十条。配额少的时候不要浪费在列表页和标签页上，只推当天的新文章和改动过的重要页面。推送接口是普通的 HTTP POST，一条 curl 就能接进发布脚本：

curl -s -H 'Content-Type:text/plain' --data-binary @urls.txt \
  "http://data.zz.baidu.com/urls?site=https://www.example.com&token=你的token"

返回的 JSON 里有 success 和 remain 两个字段，前者是本次成功条数，后者是当日剩余配额。一定要看 remain，配额用完之后接口返回成功但实际不处理的情况我遇到过两次，白白以为提交了。

第二是抓取诊断。输入一个 URL，百度会现场抓一次并告诉你返回码、抓取耗时、页面大小、以及它识别到的正文长度。如果显示的正文长度远小于实际，说明它的正文提取失败了——典型原因是正文被大段 JS 渲染、或者被 <div> 套了太多层。这个诊断比看任何第三方工具都准。

第三是索引量。注意这个数字只是估算，波动很大，不要拿它当 KPI。有价值的是它的趋势方向：如果索引量在两周内掉了三成以上，才值得去查。

第四是站点改版。换域名或者改 URL 结构时，这个功能是保命的。它能让百度知道新旧 URL 的对应关系，减少重新评估的时间。很多人换域名后靠 301 硬扛，其实配合改版工具效果明显更好。

三、必应站长工具：被低估的那一个

必应在国内的份额不大，但它的站长工具在体验上比百度好不少，而且几乎没有额外成本。三个值得用的点：

一是 URL 提交的配额比百度宽松得多，而且 IndexNow 协议是它主推的。IndexNow 的好处是不用注册、不用 token 后台配置，只要在站点根目录放一个以 key 命名的文本文件，然后向 api.indexnow.org POST 一次，Google 之外的多家引擎都能收到。这比逐个平台提交省事太多。

二是 站点扫描（Site Scan），它会主动爬一遍你的站并列出 SEO、性能、可访问性方面的问题。虽然建议偏通用，但作为「有没有明显硬伤」的体检很好用，尤其能发现 canonical 冲突和重复标题这类自己不容易察觉的问题。

三是 关键词研究，直接给搜索量和竞争度，免登录就能看一部分。做长尾选题时比拍脑袋强。

四、三个平台的口径差异：为什么数字永远对不上

新手最容易纠结的一点是：同一个页面，三个平台显示的收录状态不一样。这非常正常，原因有三层。

第一层是「收录」的定义不同。Google 说 Indexed 指的是可以被检索到，百度说「索引量」是估算的入库页面数，必应显示的是「已编入索引」的 URL 数。三者统计口径、更新频率、去重逻辑都不同。

第二层是抓取策略不同。同一个页面，Google 可能已经抓了三次，百度一次没抓，必应抓了但没索引。这和站点权重、服务器响应速度、以及各家的调度策略都有关，不完全受你控制。

第三层是渲染能力不同。三家都能执行一部分 JS，但执行预算差别很大。对服务端渲染的站点影响不大，对纯前端渲染的站点，差异会非常明显。

所以正确的用法是：只在单个平台内部看趋势，不做跨平台对比。把「Google 收录 300 页、百度收录 120 页」当成问题去修，是浪费时间。

五、一个人维护的检查节奏

我自己的做法分三层，都不需要专门坐下来做。

每周一次，五分钟：看百度的抓取诊断有没有新报错、看必应的 Site Scan 有没有新增的高优先级问题。这两项都是「有就处理、没有就关掉」的二元判断，不占脑子。

每月一次，十分钟：把三个平台的索引量趋势各看一眼，只在「单周掉三成以上」时才深入。同时检查一次各家的抓取频次，如果某家抓取量突然归零，往往是 robots.txt 改错了或者服务器对它的 UA 返回了 403。

每季度一次，二十分钟：核对站点验证是否还有效。这一点特别容易忽略——验证方式如果用的是 HTML 文件，某次清理根目录时删掉了，平台会静默失效，你之后所有的数据都是空的。用 DNS TXT 验证最稳，但它依赖域名续费；用 meta 标签验证次之，要保证主题改版时没把它弄丢。

六、几个真实踩过的坑

坑一：sitemap 里塞了 noindex 的页面。三个平台都会因此降低对整份 sitemap 的信任度。提交前先自查一遍：把 sitemap 的 URL 列表和页面的 robots meta 对一遍，两者必须一致。

坑二：百度对 HTTPS 证书链不完整特别敏感。浏览器能容忍中间证书缺失，很多时候会自动补，但百度的抓取器不一定。用 openssl s_client -connect host:443 -servername host 看证书链是否完整，缺中间证书就补上。这个问题的表现是「用户能打开、百度抓不到」。

坑三：必应和百度对 Vary: User-Agent 的处理。如果你为了适配移动端按 UA 返回不同 HTML 而没设置正确的 Vary 头，缓存层可能把移动版页面喂给桌面爬虫，造成「抓到的内容和用户看到的不一致」，直接导致不索引。

坑四：推送配额被列表页吃掉。新站配额少，如果每天自动推送全站 sitemap 里所有 URL，配额很快耗尽，真正的新文章反而推不上去。做法是只推当日新增和当日更新的 URL，改动时间从数据库里取。

七、把这些动作自动化到什么程度

能自动化的部分其实很有限，但性价比最高的三件事值得做：发布后自动推送（百度 API + IndexNow）、每周自动统计各平台索引量并落库、抓取异常的邮件告警。

不能自动化的部分是判断。索引掉了是因为内容质量、还是因为技术故障、还是因为算法调整，这三者的处理方式完全不同，只能人工看。工具的作用是让你在十分钟内看到「有没有异常」，而不是替你做判断。

最后一句：三个平台里，Google 的数据最值得花时间读，百度的提交最值得花时间做，必应的维护成本最低可以顺手带着。这个优先级排清楚，一周二十分钟就够了。