百度搜索资源平台是很多中文站长心里的一根刺：Google Search Console 能给你看抓取、索引、查询词的全套数据，而百度这边接口简陋、文档零散、配额还分三六九等。于是大量站长只做了一个动作——提交 sitemap，然后等着。结果几个月过去，site: 查出来的页面数停在两位数，新文章一篇都不进索引。
这篇把百度收录这件事按「验证 → 主动推送 → 抓取诊断 → 索引量读法 → 排查」的顺序完整走一遍，重点讲那些文档没写清楚、但实际决定成败的细节。所有操作基于百度搜索资源平台（原站长平台）的现行界面与 API。
一、站点验证：三种方式选哪个
百度提供文件验证、HTML 标签验证、CNAME 验证三种方式。个人站长常见的选择困难在这里：
文件验证最稳，把平台给的 baidu_verify_xxxxxxxx.html 放到网站根目录，确认能直接访问到内容（不是 404 页、不是被伪静态改写成首页）。最容易踩的坑是 Nginx 的伪静态规则把不存在的路径全部 rewrite 到入口文件，导致验证文件「看起来能访问」，实际返回的是首页 HTML，验证自然失败。验证前先 curl -I 看一眼状态码和 Content-Length。
HTML 标签验证需要往首页 <head> 里插一行 meta。用 WordPress 或者自己写的模板都容易做，问题是换了主题之后标签会丢，百度会定期复查，一旦复查失败站点就变成「未验证」，之前提交的东西全部失效。如果站点的模板改动比较频繁，不建议用这个。
CNAME 验证适合已经有 DNS 管理权限、且不希望网站目录被塞文件的场景。缺点是验证记录与解析商耦合，换 DNS 服务商时要重新验证。
验证通过之后，第一时间去「站点属性」里把站点从「未备案」之外的几个选项填完整，尤其是「站点领域」和「移动适配」相关设置。这些属性会影响百度给你分配的抓取配额。
二、主动推送：普通收录 API
百度现在的接口分两类：普通收录（原来叫链接提交，含 API 推送、sitemap、手动提交）和快速收录（独立的配额，权限要求更高，通常需要站点有较好的历史表现才能开通）。对新站来说，能用的主要是普通收录里的 API 推送。
推送接口是一个 POST，URL 形如：
http://data.zz.baidu.com/urls?site=https://www.example.com&token=你的TOKEN请求体是每行一个完整 URL，一次最多 1000 条（实际建议控制在 100 条以内，避免整批失败）。返回 JSON，关键字段是 success、remain、not_same_site、not_valid。配额每天零点重置，用完就得等。
一个可以长期跑的推送脚本，重点在于「去重」和「只推新 URL」：
#!/bin/bash
# /opt/seo/baidu_push.sh
set -euo pipefail
SITE="https://www.example.com"
TOKEN="你的TOKEN"
STATE="/var/lib/seo/pushed.txt"
touch "$STATE"
# 1. 从数据库取最近 200 篇，只取已发布
mysql -N -B -uroot -p"$MYSQL_PW" blog -e \
"SELECT CONCAT('$SITE/', cid, '.html') FROM contents
WHERE type='post' AND status='publish'
ORDER BY cid DESC LIMIT 200" > /tmp/baidu_all.txt
# 2. 差集：还没推过的
comm -23 <(sort -u /tmp/baidu_all.txt) <(sort -u "$STATE") > /tmp/baidu_new.txt
# 3. 限制每次 100 条
head -100 /tmp/baidu_new.txt > /tmp/baidu_batch.txt
[ -s /tmp/baidu_batch.txt ] || { echo "no new url"; exit 0; }
# 4. 推送
RESP=$(curl -s -H 'Content-Type: text/plain' \
--data-binary @/tmp/baidu_batch.txt \
"http://data.zz.baidu.com/urls?site=$SITE&token=$TOKEN")
echo "$(date +%F_%T) $RESP" >> /var/log/seo/baidu_push.log
# 5. 只有推送成功的才记账（success 为 0 时不记账，下次重试）
SUCC=$(echo "$RESP" | python3 -c 'import sys,json;print(json.load(sys.stdin).get("success",0))')
if [ "$SUCC" -gt 0 ]; then
cat /tmp/baidu_batch.txt >> "$STATE"
sort -u "$STATE" -o "$STATE"
fi这段脚本有几个设计上的取舍值得说明。为什么用本地状态文件而不是每次全量推送？因为百度对重复推同一批 URL 的行为并不友好，长期重复推送会降低配额的有效利用率。为什么只有 success>0 才记账？因为 not_same_site、not_valid 的 URL 根本没有被接收，记进去以后就永远不会再推了，等于永久漏掉。为什么要限 100 条？因为整批里只要有一条格式非法（比如带中文未编码、带 # 锚点、带 UTM 参数造成重复），可能整批返回失败，小批量能把故障影响面压到最小。
三、sitemap 与 API 的关系：别只做一个
很多人以为「有 API 就不需要 sitemap 了」，这是个误解。两者在百度体系里分工不同：API 推送是「立刻告诉你在哪」，sitemap 是「周期性地让你自己来抓」。API 有日配额、有瞬时失败，sitemap 没有条目限制但抓取频率由百度决定。
正确做法是两个都做，而且要让 sitemap 保持「干净」：
其一，sitemap 里只放 200 状态码、canonical 指向自身的 URL。被 301 的旧地址、带参数的重复页、分页列表页都该排除。其二，<lastmod> 只在内容真的变更时更新，不要每次生成都写当前时间——这是最容易被判定为「作弊」的操作之一。其三，站点地图文件不要超过 50000 条、不要超过 10MB，超了就拆成索引文件。
另外「手动提交」这个入口在小站上其实很有用：新文章发出去，先在手动提交里填一次，比等 sitemap 抓取快很多。缺点是每天有条数限制，只适合最重要的几篇。
四、抓取诊断：判断「没收录」的真正原因
收录量上不去，绝大多数站长第一反应是「我的内容不够好」。但真正的原因往往在抓取层。百度搜索资源平台的「抓取诊断」工具就是用来区分这两件事的：它会让百度的蜘蛛实际来抓一次你指定的 URL，然后返回状态码、抓取耗时、页面大小、下载的 HTML 片段。
看诊断结果时按这个顺序判断：
状态码不是 200：蜘蛛被挡了。常见原因是 CDN 或 WAF 对百度蜘蛛 UA 做了限制、robots.txt 里误写了 Disallow: /、或者站点对境外 IP 做了地域封禁（百度蜘蛛的出口 IP 段在平台上有公开列表，可以核对）。
状态码 200 但抓取到的 HTML 是空的或只有骨架：说明页面依赖 JS 渲染，而百度对 JS 的执行能力有限。这种站要么做服务端渲染，要么补一份静态内容。
抓取耗时极长、显示超时：服务器响应慢，蜘蛛会降低抓取频次。这条经常被忽略——一个 TTFB 3 秒的站，不可能有好的收录。
状态码 200、内容正常，但就是不收录：这才轮到内容判断。此时要看的是「这个 URL 是否有独特性」——如果站点的文章是同一模板批量生成的近似文本，百度会把它归入低质，不收录也不报错。
五、索引量、抓取频次、抓取异常三个数字怎么读
「索引量」是指当前被百度索引的页面数，它和 site: 查询出来的数字不是一回事，前者更准（平台数据），后者波动很大。「抓取频次」是百度蜘蛛每天来访的次数，这个数字是最灵敏的健康指标——如果一个站的抓取频次长期在个位数，说明蜘蛛已经放弃了这个站，此时推多少 URL 都没用，要先解决可达性和更新频率的问题。
「抓取异常」页面会列出一段时间内出现的 404、403、5xx、连接超时、DNS 错误。这里面 404 占比高通常是站点自己删了页面但没做 301，5xx 占比高则是服务器不稳。两者都会直接降低抓取配额，而配额降下来之后想恢复很慢，通常要稳定运行两三周。
关于「移动适配」：如果站点是响应式的（同一套 HTML 适配所有设备），在平台上声明自适应即可，不需要单独做移动适配规则。如果用的是 m. 独立域名，那就必须提交适配关系，否则移动端搜索流量基本拿不到。
六、和 Google 那边怎么分工
同时做百度和 Google 的站，不要在两边用同一套策略。Google 侧用 sitemap + IndexNow（必应）+ GSC 的 URL 检查就足够，重点在内容和内链；百度侧则要额外处理三件事：服务器在国内的可达性（境外服务器经常抓取不稳）、主动推送的配额管理、以及抓取频次的培养。IndexNow 协议百度不参与，别把必应的推送结果当成百度的。
另外提醒一个实操细节：百度的 API token 是绑定 site 参数的，包括协议和是否带 www。example.com 和 www.example.com 是两个不同的站点，token 不通用，推错了会全部返回 not_same_site。这个错误在返回 JSON 里非常明确，但很多人只看 success=0 就开始怀疑配额。
七、一个可执行的每周节奏
把上面所有东西落成一个固定的例行操作，比零散地「想起来就提交一次」有效得多：
每天：新文章发布后 10 分钟内跑一次推送脚本，同时手动提交当天最重要的一篇。
每周：看一次抓取频次和抓取异常，把 404 列表里的 URL 逐条决定是 301 还是保留；看一次索引量环比，如果连续两周下降，去检查是否有大量页面被 301 或返回 5xx。
每月：重新核对一次 robots.txt 与 sitemap 的一致性（sitemap 里的 URL 不能是 robots 屏蔽的），清理 sitemap 里已下线的页面，确认站点验证仍然有效。
最后一条经验：百度收录这件事，服务器稳定性对结果的影响往往大于内容质量。一个 TTFB 800ms、常年 200 的站，即使文章普通，收录也会稳步增长；反过来，内容再好但服务器三天两头 502，抓取频次会一路掉到个位数，之后做什么都事倍功半。所以如果你现在收录很惨，先去看服务器，再去看内容。