百度蜘蛛抓取分析：登录百度站长查看抓取日报，发现抓取异常的处理
结论先说：抓取日报只能告诉你百度蜘蛛来了没有、成败如何，真正定位问题要把它和服务器日志对照看。下面用对比的方式，讲清抓取异常的处理顺序。
平台日报和服务器日志：两套证据怎么对照
百度搜索资源平台（原百度站长平台）的入口是 ziyuan.baidu.com，登录后左侧「数据监控」下有抓取频次、抓取异常，工具箱里有抓取诊断。日报通常给出抓取总次数、失败次数以及失败原因分类：DNS 解析失败、连接超时、HTTP 状态码异常、robots 拦截等。
这套数据的优点是直观、按天聚合，缺点是经过采样与统计，存在延迟，也不能当成逐条访问记录。想看清每一次抓取，得回到服务器日志：
tail -f /var/log/nginx/access.log | grep -i baiduspider
awk '{print $9}' access.log | sort | uniq -c | sort -rn # 状态码分布
日志的优势是逐条、实时，能同时看到 UA、真实 IP、响应码和响应耗时；劣势是只记录到达服务器的请求——DNS 解析失败、被防火墙直接丢包的连接，根本不会写进日志。
由此得到对照方法：平台显示失败多、日志里却找不到对应请求，问题大概率在解析或网络层；两边都出现 5xx，问题在应用或后端；平台抓取量下滑、日志里蜘蛛确实来得少，那是入口和权重层面的事，与服务端无关。
抓取失败和抓取量骤降：两条路不要混着走
这两类异常在后台常被放在同一页，但处理路径完全不同。
抓取失败，按原因分头处理：
- DNS 解析失败：用
dig example.com +short和dig example.com NS +short确认解析结果与权威 NS 是否一致，再用nslookup example.com 8.8.8.8换个递归服务器对比，排除局部解析故障。 - 连接超时：检查带宽、并发上限、安全组与 WAF 策略。百度蜘蛛的 IP 段官方有公布，可用反向解析验证：对来访 IP 执行
dig -x IP，结果以 crawl.baidu.com 结尾才算真蜘蛛，确认后把 IP 段加白。 - HTTP 状态码异常：404 对应死链，做 301 或返回 410；5xx 优先查应用日志、数据库连接和回源超时。
- robots 拦截：
curl https://example.com/robots.txt看规则。robots 拦截不等于故障，先确认是不是自己主动写的规则。
抓取量骤降则很少是单点故障。常见诱因是域名或协议切换、全站改版、CDN 更换、模板大改、内链结构变动。处理顺序是：先排除技术故障，再回看近期是否做过上述变更，最后才看内容更新频率与整体收录情况。这一类的恢复周期通常以周计，不是改一行配置就能回来。
服务端侧与服务端之外的排查：先做哪一边
面对异常，先做成本低、见效快的一边。
服务端侧，通常半小时内可确认：状态码分布、响应时间、DNS 与 NS 一致性、robots 规则、CDN 回源是否正常、WAF 是否误拦。这些属于硬故障，修好立刻反映到抓取数据上。
站点结构侧：入口深度、内链密度、sitemap 是否提交并在平台「普通收录」里正常读取、移动端适配、重要内容是否依赖 JS 渲染。这些是慢变量，调整后要等一两个抓取周期才看得到变化。
判断先做哪边的依据很简单：失败率高，先服务端；失败率正常但抓取总量低，先结构侧。
单页诊断与日常监控：手动工具和常态化配置的分工
单页排障用抓取诊断：把 URL 填进去，结果会给出抓取状态码、响应头、正文摘要和抓取来源 IP。IP 可以用来验证是不是真蜘蛛，正文摘要能看出百度拿到的是不是空壳页面——如果渲染后为空，问题多半出在 JS 渲染或反爬脚本。
日常监控则不能靠手动。可落地的做法是：服务器日志按天留存，统计每天蜘蛛请求量、状态码分布、平均响应时间；平台端每天扫一眼抓取异常与抓取频次；给 5xx 占比设一个告警阈值，超过就通知。日志保留周期建议覆盖至少一个季度，便于和流量波动做对照。
两套手段的分工可以这样记：诊断工具回答「这一页怎么了」，监控回答「这段时间站点怎么了」。前者查个案，后者防趋势。