站点运营里最容易被忽略的，是那些没有明顯报错的問题。它們不會让頁面打不開，也不會触發监控告警，只是安静地消耗抓取预算、拉低响應速度、让新内容迟迟不被發現。等哪天上线新栏目發現迟迟没有動静，回头去查，往往已经积累了几個月。
與其等出問题再排查，不如把几個關键動作固定成每周一次的巡检。下面這份清單按抓取、索引、承压三层来组织，可以直接照着做。
第一层：抓取侧看蜘蛛有没有正常来
robots.txt 與抓取入口
- 確認 robots.txt 未被誤改，特別是 Disallow 規則和 Sitemap 地址。
- 检查是否誤封了 CSS、JS 等渲染所需资源，導致頁面看起来像空壳。
- 確認首頁、栏目頁、詳情頁各自都有一條可正常到達的路径。
日誌里的狀態碼分布
- 統計蜘蛛請求中各狀態碼的比例，4xx 和 5xx 的绝對數量比百分比更值得關注。
- 看 3xx 是否集中在某些目錄，過多重定向會拉長抓取鏈路。
- 注意是否有大量請求打在參數頁、站内搜尋頁這類低價值地址上。
抓取频次與時間分布
把最近两周的日抓取量拉成一條线，正常情况下應该是相對平稳的波動。如果出現断崖式下跌或突然翻倍，先看服務器响應時間，再看是否有大面积改版或屏蔽規則變動。
第二层：索引侧看抓到的内容被怎么處理
- 用 site 查询做抽样观察，重点是趋势而不是绝對值。索引數量的短期波動很正常，连續多周單向變化才需要查原因。
- 抽查新發布内容的索引狀態，尤其是新栏目上线後的前两周。
- 检查 canonical、meta robots 等頁面級指令是否與预期一致，避免頁面之間互相指認規范地址。
- 確認 sitemap 提交的地址與實际可訪問地址一致，没有已经下线的死鏈長期挂在里面。
第三层：承压侧看服務器撑不撑得住
- 平均响應時間與慢請求比例，重点看高峰时段。
- 5xx 错誤的數量與集中出現的時間点，往往和資料库、缓存或發布操作相關。
- 證书有效期、CDN 回源配置、限流規則是否有變動。
- 計划内的维護、重啟尽量避開抓取高峰，並提前评估對抓取连續性的影响。
把巡检變成有记錄的動作
巡检最容易半途而废的原因是看完就忘。建议每次只记几個字段：日期、抓取總量、4xx 數量、5xx 數量、索引抽样數量、响應時間中位數。用表格记一個月，異常自然浮出来，也方便對比改版前後的差异。
巡检的目的不是每天都有新發現，而是让没有變化這件事本身可被確認。大多數时候记完資料就結束，這才是正常狀態。
發現異常後的處理顺序
- 先確認影响范围：是全站，還是某個目錄、某個栏目。
- 再看時間点：異常從哪天開始，那天前後做過什么改動。
- 最後動手修复，一次只改一項，改完观察几天再判断效果。
站点运营的很多工作很难有即时反馈，巡检也不例外。它的價值在于把問题暴露在還容易修的时候，而不是等到流量、抓取或索引出現明顯變化才被動應對。