蜘蛛来過，但頁面没有被完整抓取，這種情况在蜘蛛池运营里很常见。很多人的第一反應是“是不是被识別了”，但實际排查下来，原因往往更朴素：服務器返回了错誤、頁面响應太慢，或者同一時間涌進来的請求把资源挤爆了。按狀態碼、超时、並發這三個层面依次看，通常能定位到大部分問题。
第一层：先看狀態碼，別急着改策略
訪問日誌里最直接的线索就是狀態碼。把一段時間内的记錄按狀態碼分组，各段占比一眼就能看出問题集中在哪。
- 200 但正文為空或只有模板壳：後端渲染失敗、接口超时被吞掉，日誌里却顯示成功。這類問题最隐蔽，需要用頁面快照或抽样抓取来核對，而不是只看狀態碼。
- 3xx 跳轉鏈過長：入口頁到落地頁跳三四次以上，每次都要重新建连，抓取效率會被明顯拖低。
- 403 與 429：前者多半是 WAF 規則誤伤，後者是限流阈值设得太低。两者表現相似，但處理方式完全不同，需要结合請求头判断。
- 500 / 502 / 504：網關或後端的問题，属于硬失敗。這類失敗比例一旦升高，先修服務，不要先怀疑蜘蛛。
- 软 404：頁面返回 200，内容却是“已刪除”“内容不存在”。長期存在會持續消耗這個站点的抓取信任度。
第二层：超时與响應速度
狀態碼正常，也不代表抓取一定成功。蜘蛛對等待時間是有上限的，超過之後它會断開连接，日誌里可能只留下一條不完整的记錄。
優先看 TTFB，也就是從請求發出到收到第一個字节的時間。這個指标比頁面完整加载時間更能反映服務端狀態。常见的拖慢因素有几個：DNS 解析慢、TLS 握手反复重建、後端同步調用外部接口、資料库慢查询。這些都能在服務端监控里看到對應曲线。
實践中的一個參考区間是，把 TTFB 压到几百毫秒以内，超时類失敗會明顯减少。如果做不到，至少不要让响應時間出現大幅抖動，忽快忽慢比稳定偏慢更麻烦。
第三层：並發與排队
入口頁數量上去之後，同一秒可能出現几十甚至上百個請求。這时候瓶颈通常不在代碼，而在连接數、带宽和 CPU 上。
並發問题的典型特征是間歇性：闲时一切正常，忙时集中出現 5xx 或超时。如果日誌里能看到這種時間上的聚集，基本可以判断是资源排队而不是识別問题。
限流和排队机制要有，但要给搜尋蜘蛛留出通道。比較稳妥的做法是分队列處理，把普通訪問和蜘蛛訪問分開，避免高峰期互相抢占。具体阈值需要结合自己服務器的實测承载能力来定，別人的數字直接照搬意义不大。
一個可执行的排查顺序
- 按狀態碼分组，先確認失敗集中在哪一類。
- 拉出响應時間分布，看 P95、P99 是否明顯偏离日常水平。
- 對照同一時間段的並發峰值和服務器负载曲线。
- 以上都正常，再去检查 robots、跳轉鏈和頁面内容本身。
- 最後才考虑訪問来源和识別层面的因素。
按這個顺序走，多數問题在前两步就能收敛，不必一上来就大改配置。
几個容易被誤判的地方
抓取失敗不等于站点被處理，抓取量下降也不等于内容质量出了問题。很多时候只是某個入口頁被下掉、某次改版改了跳轉，或者服務器在某個时段扛不住。
- 單次失敗不必大動干戈，先看是不是偶發。
- 抓取量下降要先核對入口頁數量有没有變化，再看目标頁。
- 把“失敗率”單獨作為一個指标長期观察趋势，比盯着某一天的绝對值更有意义。
把抓取失敗当成一個可以量化的問题来處理，比反复猜测要省力得多。日誌、响應時間、並發這三份資料摆在一起，大部分疑問都能得到解释。真正需要長期投入的，是让這套观察持續下去，而不是每次出問题才临时翻一遍记錄。