做蜘蛛池入口頁时，很多人只盯着“連結有没有被抓”，却忽略了入口頁本身的可用性。入口頁偶尔超时、偶發 5xx，看起来只是几次失敗的請求，但它對搜尋蜘蛛抓取节奏的影响，可能比你想的更大。
搜尋蜘蛛遇到超时和 5xx 會怎么做
搜尋引擎對 5xx 和连接超时的處理逻辑，和 404 完全不同。404 是一個明确的“這個頁面不存在”的答复，蜘蛛记下就結束了；而 5xx、超时、连接被重置属于“服務器暂时答不上来”，搜尋引擎會倾向于把它当作临时問题。
- 會重试。同一個 URL 在後續的抓取周期里可能被再訪問几次。
- 會降频。如果一個入口頁或一個域名反复失敗，抓取調度會主動减少訪問量，把額度挪给更稳定的站点。
- 影响面會外溢。入口頁所在域名整体不稳定时，同域名下的其他 URL 也可能被连带降频。
所以入口頁偶發故障的代價，不只是“這一次没抓到”，而是接下来的抓取节奏可能被压下去，而且恢复需要時間。
先確認問题真的出在入口頁
“蜘蛛没来抓”和“蜘蛛来了但没抓成功”是两件事，必须先用日誌区分開。
- 看入口頁 URL 的响應狀態碼分布。是清一色 200，還是夹杂着 5xx、超时、连接重置的记錄。
- 看失敗是否集中在某些時間段。比如每天固定时段源站压力大，或定时任務把服務器资源打满。
- 看失敗是否集中在某些 URL。個別入口頁引用了異常脚本或外部资源，也可能拖慢整頁响應。
- 看 CDN 或 WAF 的日誌。有时源站正常，是邊缘节点回源失敗或触發了拦截規則。
- 對比蜘蛛 UA 與普通用戶 UA 的响應差异。部分拦截策略只對特定 UA 生效。
三種“看起来是 5xx”的常见情况
1. 返回 200，但頁面其實是错誤頁
服務器出错时返回了一個 200 的错誤提示頁，這属于软错誤。蜘蛛會把它当成正常頁面處理，既不會重试，也拿不到有效連結，等于白白浪費一次抓取。错誤頁就應该老實返回對應的 5xx 狀態碼。
2. CDN 返回 5xx，源站其實正常
回源超时、證书問题、缓存节点故障都會让用戶和蜘蛛看到 5xx。排查时一定要分開看邊缘节点狀態和源站狀態，不要只在源站上找原因。
3. 抓取超时和服務器返回超时不是一回事
蜘蛛有自己的等待上限。如果入口頁首字节時間太長，或者頁面里有阻塞渲染、長時間不返回的請求，蜘蛛可能直接放弃连接，日誌里记成超时，而服務器那邊可能還在慢慢處理。這種情况要從响應速度和资源加载上解决，而不是只改狀態碼。
修复顺序建议
- 先保證狀態碼准确：能正常返回就 200，出错就 5xx，不要用 200 伪装错誤頁。
- 把入口頁做轻：减少不必要的脚本、外部請求和阻塞资源，让首字节尽快返回。
- 控制自身並發：入口頁數量多时，別在同一時間對同一台服務器發起大量請求，主動限速比被動被打满更可控。
- 排查中間层：CDN 缓存規則、WAF 策略、防火墙對蜘蛛 UA 的拦截，都要過一遍。
- 持續监控：對入口頁做可用性和响應時間监控，出問题时第一時間發現，而不是等抓取量掉下来才知道。
入口頁稳定是抓取的前提。連結放得再巧，服務器答不上来，蜘蛛也只能空手而归。
修复之後，抓取量不會立刻回来
搜尋引擎的抓取調度是有惯性的。即使入口頁已经稳定，被抓取频次的下調通常也會持續一段時間，需要靠持續可用的响應慢慢把信任养回来。這段時間里，別频繁改動入口頁结构，也別一味加大 URL 提交量去“催”，稳定比數量更重要。
還要提醒一点：入口頁只是發現連結的通道，它稳定不代表目标頁就會被收錄。把入口頁的可用性做好，是必要條件，不是充分條件。把狀態碼、响應速度和並發這三件事長期维持住，比临时补救更有價值。