一个真实的场景：百度收录量一夜掉光
上周有个做工具站的站长找我，说他一个跑了三年的站，百度收录量从 12000 多掉到 300，流量直接腰斩。他第一反应是"被 K 了"，准备删库重做。但我让他把 百度搜索资源平台里的"抓取诊断"跑一遍，结果出来了：他的服务器返回给百度的首页状态码是 403。
问题不在内容，而在他上个月给服务器加的一条 Nginx 规则。为了挡掉某个采集站的爬虫，他写了这么一句：
if ($http_user_agent ~* "Baiduspider") {
return 403;
}他以为 "Baiduspider" 只匹配那个讨厌的采集站，但实际上百度的官方爬虫 UA 就叫 Baiduspider。一句话，把自己最大的流量来源拉黑了。
这件事说明一个常被忽视的事实：搜索引擎优化里，技术层面的"可抓取性"比内容质量更底层。内容再好，爬虫进不来、抓不到、或者抓到的是一堆 5xx，排名都无从谈起。这篇就把"抓取可访问性"这条链路从上到下拆一遍。
第一步：先确认爬虫真的能进来
遇到收录暴跌，别急着改内容，先做"可访问性体检"。按顺序排查四个点：
1. 状态码是否正常
爬虫拿到的必须是 200。任何 4xx/5xx 都是收录杀手。用 curl 模拟一次：
curl -sI -A "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)" \
https://www.example.com/ | head -20重点看返回码，以及有没有 X-Robots-Tag 这种会在 HTTP 头层面阻止索引的指令。有些 CDN 或 WAF 默认会拦截"看起来像机器人"的 UA，这是最常见的隐形杀手。
2. robots.txt 是否误封
很多人写 robots.txt 时随手加了一句 Disallow: / 用于测试环境，结果忘了删。检查：
curl -s https://www.example.com/robots.txt还要注意通配符的坑。Disallow: /*.php$ 会连正常的动态页面一起封掉；Disallow: /search 会把 /search-tools/ 这种正常栏目也一起封掉，因为 robots 的前缀匹配不看目录边界。
3. 页面是不是纯 JS 渲染
百度爬虫对 JavaScript 的执行能力远不如 Google。如果你的正文完全靠前端框架异步加载，爬虫看到的可能是一个空壳 HTML。验证方法：关掉浏览器 JS，或者直接 curl 拿原始 HTML：
curl -s https://www.example.com/article/123 | grep -o '.* '
curl -s https://www.example.com/article/123 | wc -c如果返回的 HTML 里完全没有正文文字，只有一堆 <div id="app"></div>，那就是首屏内容没有服务端渲染。对个人站长而言，最省事的方案是回到服务端渲染，而不是硬啃 SSR 框架。
4. 入口页面是否可达
爬虫靠链接发现页面。如果新文章只存在于 sitemap 却没有任何内链指向，收录会慢很多。至少要做到：首页有新文章入口、栏目页有分页、文章页之间有相关推荐。
第二步：把抓取预算花在刀刃上
爬虫每天在你站上花的抓取次数是有限的，这叫做抓取预算（Crawl Budget）。小站预算小，一旦浪费在无意义页面上，真正重要的文章就排不上号。
常见的预算黑洞有三类：
- 无限组合的筛选参数：
?color=red&size=xl&sort=price这种参数组合能生成上万条 URL，内容却几乎相同。解决办法是在 robots.txt 里屏蔽参数，或给这类页面加noindex。 - 站内搜索结果页：
?s=关键词这种页面会被无限生成。必须屏蔽。 - 失效的分页和归档：日期归档
/2021/03/、标签归档/tag/xxx/如果内容重复严重，建议合并或 noindex。
具体做法：在 robots.txt 里用 Disallow: /*?s=、Disallow: /*?sort=，然后在 sitemap 里只提交真正需要收录的规范化 URL。记住一条原则：sitemap 是你想被收录的清单，robots.txt 是你不希望被浪费的清单，两者要配合使用，不要互相矛盾（比如一个 URL 既在 sitemap 里又被 robots 屏蔽，那纯属浪费）。
第三步：让收录变快的三个实操手段
主动推送而不是等爬
百度有"普通收录"里的 API 推送，Google 有 IndexNow 和 Search Console 的 URL 检查。个人站长最实用的是 IndexNow——它被 Bing、Yandex、Seznam 等共同支持，一次提交多平台可见。发完文章后立刻推送：
curl -X POST "https://api.indexnow.org/indexnow" \
-H "Content-Type: application/json" \
-d '{
"host": "www.example.com",
"key": "你的32位密钥",
"keyLocation": "https://www.example.com/你的32位密钥.txt",
"urlList": ["https://www.example.com/new-post.html"]
}'密钥文件要放在站点根目录，内容就是那串密钥本身。这一步能让新文章从"等几天"变成"几小时内"被感知。
把 sitemap 做对
sitemap 里每个 URL 都应有真实的 <lastmod>，并且这个时间必须是内容实质更新的时间，不是每次构建都刷新。如果 lastmod 天天变，爬虫会认为你在作弊，反而降低信任度。另外单文件 URL 数量不要超过 5 万，超过就拆成 sitemap 索引文件。
用日志验证抓取行为
最可靠的证据在服务器访问日志里。看百度爬虫最近都抓了什么：
grep -i "Baiduspider" /var/log/nginx/access.log | tail -50
grep -i "Baiduspider" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20如果发现爬虫一直在抓那些无意义的参数页，说明预算被浪费；如果最近一周完全没有爬虫记录，说明抓取通路出了问题——这时候回去查第一步的状态码和防火墙。
第四步：排查"抓到了却不收录"的原因
有时候状态码正常、robots 也没问题，但页面就是不收录。这时候要往"内容质量判定"方向查：
- 内容太薄：几百字的页面，搜索引擎倾向于直接不索引。个人站应保证每篇有实质信息量。
- 重复内容：同一篇文章有多个 URL 版本（带 www / 不带 www、http / https、带尾斜杠 / 不带），会被判定重复。用 canonical 标签指明主版本，并做好 301 归一。
- 模板占比过高：如果站内所有页面的正文之外都是同一套导航、侧栏、页脚，正文又很短，容易被判为低质。
- 新站沙盒期：新域名普遍有 1-3 个月的观察期，收录慢是正常的，别乱改。
特别注意 canonical 的写法必须绝对 URL 且自指。比如 https://www.example.com/a.html 的页面上，canonical 就应该写它自己，而不是写首页或栏目页。写成首页是新手最常见的错误，会让搜索引擎放弃索引这篇文章。
第五步：建立一套可重复的收录巡检
排查一次不够，要把这件事变成例行检查。建议每周做一次固定动作：
- 拉取最近 7 天的爬虫日志，统计总抓取次数和抓取的 URL 分布；
- 对比 sitemap 里的 URL 数量与索引量（在搜索资源平台看"索引量"曲线）；
- 抽查 5 篇最新文章的
curl -sI状态码和 title，确认没有异常； - 检查 robots.txt 是否被意外改动（可以用 git 管理它，或者每周 diff 一次备份）。
把这套流程写成一个 shell 脚本挂到 cron 里，出问题时你第一时间就会知道，而不是等流量掉了半个月才发现。这也是个人站长相比大团队唯一能赢的地方——你的站小，所以你能把每个细节都盯住。
小结
收录问题的排查顺序永远是：状态码 → robots → 渲染方式 → 内链入口 → 抓取预算 → 内容质量。前面几项是"能不能抓"，后面几项是"值不值得收"。大多数人一上来就纠结内容，其实前面任何一环出错，内容再好也没用。
回头开头那个例子，那位站长最终只是把那条 403 规则删掉，两周后收录恢复到 9000 多。技术排查的价值就在于此：它不玄学，一行命令就能证伪一个猜测。
补充：移动端适配与收录的关系
还有一类收录问题常被忽略——移动端可访问性。百度有独立的 Baiduspider-mobile 爬虫，Google 则已经全面转向移动优先索引（Mobile-first indexing）。如果你的桌面版正常但移动版布局错乱、弹窗遮挡正文，或者移动端返回了不同的、更薄的 HTML，收录和排名都会直接受影响。
排查方法很简单，用移动端 UA 请求一次，对比返回的 HTML 大小与正文内容：
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15" \
https://www.example.com/article/123 | wc -c如果移动端返回的字节数和桌面端相差巨大，就要检查是不是做了"按 UA 分流"的跳转。移动端和桌面端应该呈现完全一致的内容，只是样式不同。历史上还有过 m. 子域名的做法，现在已不推荐，因为会造成内容重复，需要额外的 canonical 和 alternate 标注来纠正。
另外，移动端首屏加载速度也是排名因素。如果你的站用了未压缩的大图、阻塞渲染的外部字体、或者一堆同步加载的统计脚本，移动端体验会明显下降。建议至少做到：图片用 loading="lazy" 懒加载、CSS 内联首屏关键部分、非关键 JS 加 defer。
补充：HTTPS 与混合内容问题
现在 HTTPS 已是收录的基本门槛，但很多站点存在"部分资源仍是 http 引用"的混合内容（Mixed Content）问题。浏览器会拦截这些资源，导致页面显示不完整；而搜索引擎在渲染时也会看到残缺的页面，从而降低质量判定。
检查方法：用浏览器开发者工具看 Console 面板，或者抓取页面后搜索 http 引用：
curl -s https://www.example.com/article/123 | grep -o 'http://[^"'"'"' ]*' | head -20输出中除了合法的 http://www.w3.org/2001/XMLSchema 这类命名空间声明外，其余的都应该是 https://。修复方式是统一替换为相对协议（//）或直接改成 https，同时确认 CDN 本身支持 HTTPS 回源。