頁面不收錄，很多人第一反應是内容质量問题或外鏈不够。但先看一眼服務器日誌常常更有效：蜘蛛可能压根没拿到你的頁面，而是拿到一個失敗的响應。抓取失敗和抓到了但不收錄是两件不同的事，混在一起排查會绕遠路。

先分清：蜘蛛拿到的是頁面還是错誤响應

在日誌里按爬虫 UA 過滤，看這批請求的狀態碼分布。常见的几種情况，處理方向完全不同：

• 200：頁面正常返回，問题在後續环节，比如内容判断、canonical、重复内容。
• 301/302/307：跳轉本身不是問题，但鏈條過長或指向错誤地址會拖慢抓取。
• 403/429：多半是被 WAF、CDN 或限流規則拦下，爬虫身份被誤判。
• 500/502/503/504：服務端自身的問题，影响范围往往是整段路径甚至整站。
• 超时無响應：日誌里可能只留一條连接中断，狀態碼都不完整。

同一批 URL 如果 5xx 比例明顯偏高，先別改内容，先修服務端。

5xx 的连鎖影响比想象中大

偶發的 5xx 問题不大，但如果某個目錄長期不稳定，蜘蛛對该目錄的抓取频次會明顯下降。更需要注意的是两個特殊文件：

• robots.txt 返回 5xx：部分搜尋引擎會在一段時間内暫停對整站的抓取，而不是照常抓取。此时全站不收錄，往往只是抓取被自己掐断了。
• sitemap 返回 5xx 或超时：URL 發現渠道失效，新頁面很难進入队列，老頁面的更新信号也會减弱。

建议把這两個文件加到獨立监控里，返回碼異常时第一時間告警，而不是等收錄資料掉了才回头查。

429 與 403：被拦截的蜘蛛

不少站点上了 CDN 或云 WAF，預設規則會按 UA、請求频率、IP 段做限制。真實爬虫被拦下的表現通常是 403 或 429，日誌里看得到，但很多人只看有没有来，不看来了拿到什么。

處理思路：

• 在日誌中確認爬虫声明的 IP，並做反向解析驗證，不要只看 UA 字符串。
• 對驗證通過的真實爬虫放行，而不是整段 IP 段放開。
• 限流規則里给爬虫留單獨速率，不要和普通訪客共用一套阈值。

UA 可以伪造，IP 反查不能。放行前先確認身份，避免给恶意流量開白名單。

超时與响應慢：不是失敗，效果接近失敗

抓取是有時間预算的。首字节時間過長、頁面体积過大、關键资源加载不出来，都會让蜘蛛提前放弃。常见原因包括：服務器本身负载高、資料库慢查询、頁面里塞了過多同步請求、TTFB 長期在秒級以上。

可以先看一個指标：同一批 URL 的平均响應時間有没有随時間變差。如果只是某几個頁面慢，多半是頁面自身的問题；如果整站都慢，先查基础设施。

建议的排查顺序

1. 拉一段服務器日誌，按爬虫 UA 統計狀態碼分布，确定失敗比例。
2. 單獨驗證 robots.txt 與 sitemap 的可訪問性和返回碼。
3. 检查 WAF、CDN、限流的拦截记錄，区分誤拦和真實恶意流量。
4. 看响應時間分布，找出慢頁面與慢接口。
5. 確認證书、DNS、IPv6 等基础鏈路没有異常。
6. 修复後再观察一段時間的抓取频次與狀態碼變化，而不是立刻看收錄數字。

修复後怎么驗證

先看抓取侧的指标：爬虫請求量、5xx 占比、平均响應時間、robots 與 sitemap 拉取是否恢复。這些稳定之後，再去看 URL 是否進入索引。收錄是结果，抓取是前提，顺序反了容易得出错誤结论。

如果站点同时跑着多個域名或环境，记得先確認蜘蛛訪問的是哪一個，測試环境的拦截規則有时會跟着正式环境一起改。