站点运营里最容易被忽略的，是那些没有明显报错的问题。它们不会让页面打不开，也不会触发监控告警，只是安静地消耗抓取预算、拉低响应速度、让新内容迟迟不被发现。等哪天上线新栏目发现迟迟没有动静，回头去查，往往已经积累了几个月。
与其等出问题再排查，不如把几个关键动作固定成每周一次的巡检。下面这份清单按抓取、索引、承压三层来组织，可以直接照着做。
第一层：抓取侧看蜘蛛有没有正常来
robots.txt 与抓取入口
- 确认 robots.txt 未被误改，特别是 Disallow 规则和 Sitemap 地址。
- 检查是否误封了 CSS、JS 等渲染所需资源，导致页面看起来像空壳。
- 确认首页、栏目页、详情页各自都有一条可正常到达的路径。
日志里的状态码分布
- 统计蜘蛛请求中各状态码的比例，4xx 和 5xx 的绝对数量比百分比更值得关注。
- 看 3xx 是否集中在某些目录，过多重定向会拉长抓取链路。
- 注意是否有大量请求打在参数页、站内搜索页这类低价值地址上。
抓取频次与时间分布
把最近两周的日抓取量拉成一条线，正常情况下应该是相对平稳的波动。如果出现断崖式下跌或突然翻倍，先看服务器响应时间，再看是否有大面积改版或屏蔽规则变动。
第二层：索引侧看抓到的内容被怎么处理
- 用 site 查询做抽样观察，重点是趋势而不是绝对值。索引数量的短期波动很正常，连续多周单向变化才需要查原因。
- 抽查新发布内容的索引状态，尤其是新栏目上线后的前两周。
- 检查 canonical、meta robots 等页面级指令是否与预期一致，避免页面之间互相指认规范地址。
- 确认 sitemap 提交的地址与实际可访问地址一致，没有已经下线的死链长期挂在里面。
第三层：承压侧看服务器撑不撑得住
- 平均响应时间与慢请求比例，重点看高峰时段。
- 5xx 错误的数量与集中出现的时间点，往往和数据库、缓存或发布操作相关。
- 证书有效期、CDN 回源配置、限流规则是否有变动。
- 计划内的维护、重启尽量避开抓取高峰，并提前评估对抓取连续性的影响。
把巡检变成有记录的动作
巡检最容易半途而废的原因是看完就忘。建议每次只记几个字段：日期、抓取总量、4xx 数量、5xx 数量、索引抽样数量、响应时间中位数。用表格记一个月，异常自然浮出来，也方便对比改版前后的差异。
巡检的目的不是每天都有新发现，而是让没有变化这件事本身可被确认。大多数时候记完数据就结束，这才是正常状态。
发现异常后的处理顺序
- 先确认影响范围：是全站，还是某个目录、某个栏目。
- 再看时间点：异常从哪天开始，那天前后做过什么改动。
- 最后动手修复，一次只改一项，改完观察几天再判断效果。
站点运营的很多工作很难有即时反馈，巡检也不例外。它的价值在于把问题暴露在还容易修的时候，而不是等到流量、抓取或索引出现明显变化才被动应对。