导读
一次站点改版上线后没几天，后台看到的搜索收录量掉了将近一半，自然来量跟着往下走。很多人遇到这种情况第一反应是去改标题、堆关键词，其实顺序反了——收录是排名的前提，页面连抓取和索引都没进去，内容做得再好也没有展示机会。这篇按"爬虫能不能抓、能不能解析、愿不愿意收录"的顺序，整理一套可以反复用的排查与修复流程，改版前后照着走一遍，基本能定位到绝大多数问题。
一、先分清掉的是抓取、索引还是排名
动手前先定位断点，否则容易瞎改。这三件事是递进关系：爬虫先来抓取页面，然后决定要不要建索引，最后才谈得上排名。
- 如果爬虫日志里压根没有请求，问题在"抓不到"，多半是 robots 封禁、服务器拦截或者没有入口链接。
- 如果日志显示抓了，但站长平台的索引覆盖率在掉，问题在"抓了没收录"，多半是重复页、规范化指错、内容质量或返回状态异常。
- 如果收录量稳定、只是流量掉，那才是排名问题，不在本文范围。
粗看收录量级可以用搜索引擎的 site 指令，但它的数据滞后又粗略，只能当参考，真正以站长平台的"索引覆盖率、抓取统计"为准。第一步先模拟爬虫身份去请求页面，看服务器到底返回了什么：
# 伪装成主流爬虫，看返回状态码、重定向和内容是否与普通浏览器一致
curl -A "Baiduspider" -I example.com/robots.txt
curl -A "Googlebot" -I example.com/sitemap.xml
curl -A "Baiduspider" -L -o /dev/null -s -w "%{response_code} %{url_effective}\n" example.com/some-page
如果爬虫身份拿到的是 403、503 或者一段验证码，而普通用户访问正常，问题就出在服务器把正常爬虫误拦了。
二、robots.txt：最容易误伤的第一道门
爬虫到访先读 robots.txt，这里也是改版事故的高发地。它由若干条规则组成：User-agent 指明对哪个爬虫生效，Disallow 表示不允许抓的路径，Allow 表示放行，Sitemap 用来声明站点地图位置。
改版时最典型的事故，是测试环境为了不被收录，整站写了封禁规则，结果上线时这份文件被原样带到生产，等于主动把门焊死。其它常见错误还有：误封了爬虫的 UA、通配符和路径大小写写错、规则顺序写反导致 Allow 被 Disallow 覆盖。需要清楚的是，robots 只是"君子协议"，主流搜索引擎会遵守，但它不挡恶意爬虫，安全防护不能指望它。规则改完，务必在站长平台的 robots 检测工具里逐条验证，而不是凭感觉。
三、sitemap 与页面可达性：别让页面变成孤岛
爬虫发现页面主要靠两条路：站点地图和页面里的链接。改版后 URL 结构一变，老的 sitemap 里全是失效地址、新页面又没及时补进去，收录自然断层。sitemap 要覆盖最新的规范 URL，并在更新后主动到站长平台重新提交。
更隐蔽的是"孤岛页面"：页面真实存在，但没有任何内链指向它，爬虫顺着链接走根本到不了。改版如果顺手砍掉了导航、面包屑、分类分页，深层页就会成片变成孤岛。另一个高频问题是规范化标签 canonical：改版很容易制造大量重复地址——同一页带不同排序参数、域名前缀带不带 www、协议版本不一致，如果 canonical 指错，搜索引擎会把这些页面合并甚至放弃收录。下面这段脚本用来核对 sitemap 里的地址状态和 canonical 是否自洽：
import xml.etree.ElementTree as ET
import requests
def load_sitemap(path):
root = ET.parse(path).getroot()
# 兼容带命名空间的 sitemap，按标签本地名取所有 loc
return [e.text for e in root.iter() if e.tag.split('}')[-1] == 'loc']
def audit(urls):
for u in urls:
r = requests.head(u, timeout=8, allow_redirects=True)
if r.status_code >= 400:
print('异常状态', r.status_code, u)
elif len(r.history) > 2:
print('重定向链过长', u)
# 再抓取页面 <link rel=canonical>，核对它是否指向自身或真正的主版本
四、服务器侧：让爬虫顺畅地抓完
返回状态要稳定。 正常页面应返回 200；临时维护别直接返回 404，那会被当成页面永久消失，应该用 503 配合 Retry-After 告诉爬虫稍后再来；页面真的下线才用 404 或 410。
改版迁移用 301。 旧地址要做永久重定向，一一对应地跳到新地址，把历史权重带过去。最忌讳两件事：所有旧页一律跳到首页，以及用 JS 跳转或多次串联跳转，爬虫跟不动也不认可。
别误封爬虫。 限流和风控策略如果只看访问频率，很容易把勤勤恳恳的搜索引擎爬虫当成恶意流量封掉，日志里就会出现成片的 403、503。应当按 UA 给主流爬虫白名单和合理配额。可以从访问日志里直接统计爬虫拿到的状态码分布：
# 统计主流爬虫抓取各状态码的数量，403/503 偏多就要查限流策略
grep -E "Baiduspider|Googlebot|Bingbot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
对应到 Nginx，可以对已知爬虫 UA 放宽过于激进的连接限制：
map $http_user_agent $is_search_bot {
default 0;
~*(Baiduspider|Googlebot|Bingbot|Sogou) 1;
}
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
server {
location / {
# 命中主流爬虫时走更宽松的限流通道
limit_req zone=general burst=40 nodelay;
}
}
此外还要留意抓取预算：筛选组合页、各种带参数的无效 URL 如果不做治理，会产生海量低价值地址，爬虫反复抓这些就没精力抓你的正经页面了，用 robots 配合 noindex 收敛即可。
五、用建站平台时的排查边界
我们这个站点是用乔拓云这类自助建站平台搭的。好处是伪静态链接、自动生成的 sitemap、canonical 和基础 301 这些收录相关项，在后台基本是可视化配置或默认生成的，改版时不用自己手写一堆规则。但封装得深也带来一个排查要点：一旦收录异常，要先分清哪层是平台自动生成、哪层能在后台改、哪层只能提工单处理。我们的固定动作是先把平台当前实际输出的 robots 和 sitemap 拉下来逐条核对，确认不是默认规则在改版后变成了阻碍，再去查自己能控制的内链和内容，避免在根本改不到的地方空耗时间。
踩坑清单
- 坑1：把测试环境整站封禁的 robots 带到线上。 上线后爬虫全被挡在门外，收录断崖式下跌。上线检查清单里必须单列一项核对线上 robots。
- 坑2：改版不做旧地址 301。 旧收录集体变 404，积累的权重清零。旧 URL 要一一对应地永久跳转到新页面，而不是全部跳到首页。
- 坑3：canonical 图省事全站指向首页。 内页被当成重复页合并，越优化收录越少。每个规范页应指向它自己或真正的主版本。
- 坑4：把搜索引擎爬虫当异常流量封掉。 日志里爬虫清一色 403、503，自然抓不动。按 UA 给主流爬虫白名单和合理配额。
- 坑5：只看 site 指令的收录数字就下结论。 那数据既滞后又粗略。以站长平台的索引覆盖率、抓取统计为准，结合访问日志看真实抓取情况。
结语
收录排查本质上是"把自己当成爬虫，顺着它的路径完整走一遍"：robots 让不让进门，sitemap 和内链能不能找到每个页面，canonical 认不认这个规范地址，服务器又是不是回了正常响应。改版真正容易丢分的从来不是什么高深技巧，而是这几个基础项在变更中被悄悄改坏。把它们固化成改版前后的检查清单，收录这件事就从"掉了再救火"变成了"上线前就拦住"。
