頁面不收錄的原因有很多，服務器响應是最容易被忽略的一類：它不寫在頁面内容里，也不一定在索引报告里直接标红，但蜘蛛每次来訪都吃一次閉门羹，抓取频率和收錄节奏都會跟着受影响。

先分清三種“没抓到”

日誌里顯示的失敗，其實不是一回事，處理方向也不同：

• 连接超时：握手阶段就没连上，常见于防火墙、CDN 回源異常、IP 被拦。
• 响應超时：连上了却迟迟不返回，常见于慢查询、同步調用外部接口。
• 服務端错誤：返回 5xx，頁面本身還在，但当时服務端處理失敗。

還有一種特殊狀態是 429，意思是“請求太多，稍後再来”，属于临时限流，和 5xx 的性质不一样，別混在一起看。

超时和收錄之間是什么關系

被抓取不等于被收錄；反過来，抓取失敗也不等于永久不收錄。但蜘蛛在评估一個站点的抓取体驗时，會參考歷史成功情况。同一批 URL 反复超时，通常的结果是：抓取频率被压低、待抓取队列里排得更靠後、首次收錄時間被拉長。長期大面积失敗的情况下，蜘蛛的来訪次數會减少，新頁面被發現的間隔也随之變長。

判断顺序建议是：先確認蜘蛛是否真的抓取失敗，再確認失敗是全局還是集中在某類 URL，最後才回到頁面内容本身。

從日誌里能看出的几個信号

• 同一批蜘蛛 IP 對同一 URL 的請求，返回的是 200，還是 5xx 與连接中断。
• 失敗是否集中在某個目錄、某類模板頁，比如带篩選參數的列表頁。
• 失敗是否集中在某個時間窗口，比如每天跑批的时段。
• 蜘蛛的抓取總次數是否在下降，而不只是單次失敗。

只有個別 URL 失敗，多半是那一條地址或那個頁面的問题；整站都慢，優先級就要先放到服務端。

常见的几類原因

1. 單次請求做的事太多

一個頁面渲染时要查十几次資料库、調几個外部接口，只要其中一個慢，整頁就慢。超时之後，這次抓取就记為失敗。

2. 静態资源拖住渲染

頁面 HTML 返回很快，但首屏依赖的脚本、样式、接口都很慢，渲染阶段可能拿不到完整内容。對于需要渲染的頁面，這一环同样會影响最终抓到的版本。

3. 防護與限速誤伤

WAF、频率限制、CDN 的机器人規則，有时會把蜘蛛的高频請求当成異常流量，返回 403 或 429。临时限流可以理解，但如果一直触發，蜘蛛同样會降低来訪频率。

4. 服務端资源被占满

连接數、進程數、内存或带宽打满时，最先受影响的就是那些没有會话、没有缓存的陌生請求，蜘蛛恰好属于這一類。

處理顺序建议

1. 先用日誌確認失敗類型與范围，別一上来就改頁面。
2. 复現：對同一條 URL 连續請求多次，看响應時間的分布，而不是只看一次结果。
3. 優先解决 5xx 與超时，再谈收錄。加缓存、把外部接口調用挪出主流程、异步化都是常见手段。
4. 核對蜘蛛 IP 是否被誤拦，必要时加白名單。
5. 修好之後观察一到两周的抓取成功情况與索引报告變化，不要当天就下结论。

几個容易走偏的做法

• 只盯着“内容够不够好”，忽略服務端稳定性。
• 把 429 当成永久错誤，回头去大改頁面结构。
• 為了压住超时，把整類頁面直接 noindex，连抓取需求一起放弃。

收錄是抓取之後的环节，而抓取能顺利完成是它的前提。内容做得再细，如果蜘蛛每次来訪都拿不到响應，收錄這件事就只能一直排队。把响應成功率和响應時間拉回正常区間，往往比反复修改頁面本身更快看到變化。