站点抓取出问题时，很多人的第一反应是改 Sitemap、加内链、提交一批 URL。这些动作本身没错，但它们都是在"猜蜘蛛会怎么走"。更稳的做法是先看数据：蜘蛛实际走了哪些路径，在哪个环节停下来。这篇文章讲一个可重复的排查流程——把日志、状态码和内链整理成三张表，然后对着看。
第一步：取一段可比的日志
日志分析最容易犯的错，是拿一段不具代表性的数据下结论。几个基本要求：
- 时间窗要连续，通常取 7 天左右，避开大促、发版当天这类抓取行为异常的时段。
- 先核对身份，不要只看 UA 字符串。用反向 DNS 或已知 IP 段验证，把模拟请求和真蜘蛛分开统计。
- 过滤静态资源，只保留 HTML 文档请求，否则 CDN 上的图片请求会把数据冲淡。
- URL 归一化，统一大小写、末尾斜杠、跟踪参数，把 ?utm_source= 这类噪声去掉，否则同一个页会被算成十几条记录。
做完这四步，你手上才有一份能和上周、下个月对比的基础数据。
第二步：三张表分别看什么
日志表
按目录聚合，看三个指标：抓取总次数、该目录下 URL 的首抓时间分布、以及抓取量在目录之间的比例。重点不是绝对值，而是比例是否和目录的重要程度匹配。
状态码表
统计每个目录下 200、301、404、5xx 的占比。如果某个目录的 5xx 集中在少数几个接口上，问题通常不在链接结构，而在服务端。301 比例过高则说明站内链接还没更新到最终地址，蜘蛛每次都要多走一步。
内链表
对重要 URL 记录：入链数量、入链所在的层级（首页、栏目页、详情页）、以及最近一次被链接的时间。这张表反映的是"你希望蜘蛛走的路"，和日志表对照才有意义。
第三步：交叉核对，识别常见堵点
- 内链多但日志里几乎不出现：多半卡在 robots 规则、canonical 指向了别的地址，或者这些链接是 JS 渲染后才插入的，蜘蛛拿到的初始 HTML 里并没有。
- 日志里只有列表页前几页：分页被"加载更多"按钮取代，或者后页 URL 带上筛选参数后被规则拦下，路径在第 3、4 页就断了。
- 某目录 5xx 集中出现：常见于缓存穿透或慢查询。蜘蛛遇到连续错误会退避，恢复后也不会立刻回到原来的抓取节奏，所以日志上会看到一段明显的空白。
还有一类不容易发现的：抓取次数正常，但抓的都是同一批老 URL，新页面的首抓时间一直往后拖。这通常是站点缺少让蜘蛛判断"有新内容"的信号，比如列表页不更新、Sitemap 的 lastmod 长期不变。
第四步：调整时控制变量
找到堵点后，别一次性把 Sitemap、内链、跳转全部改掉，那样最后无法判断是哪一步起了作用。建议：
- 一次只改一处，记录改动日期。
- 固定同一批 URL 作为观察样本，比较改动前后的抓取次数与首抓时间。
- 给自己留一个抓取周期（通常一到两周）再下结论，中间不要频繁变动。
- 服务端问题优先修，链接结构问题其次——服务器一直报错时，改内链的效果会被完全掩盖。
蜘蛛的抓取路径是结果，不是原因。状态码、内链和清单文件，都只是它读到的输入。
小结
排查抓取问题，与其反复调整清单文件，不如先把日志、状态码、内链三张表整理清楚，找出蜘蛛实际停下的那一段。定位准了，改动往往很小；定位不准，改动越多，越难判断效果。