很多人排查收錄問题，习惯從内容、連結、标簽入手，却忽略了一個更底层的前提：蜘蛛能不能顺利、稳定地把頁面拿回去。如果服務器响應慢、频繁超时，前面做的優化可能還没轮到被评估，頁面就已经被判定為“不值得再花時間”了。
為什么响應速度會影响收錄
搜尋引擎抓取是分批進行的，每個站点在單位時間内能分到的抓取量有限。頁面响應越慢，同样的時間能抓的 URL 就越少；如果慢到超时，這次抓取就是白白消耗，還不會留下有用的结果。
响應慢不一定直接導致不收錄，但它會拉長“發現—抓取—入库”的整條鏈路，让頁面在同样的時間里更难被完整處理。
先分清：是慢，還是不稳定
- 整体慢：所有頁面 TTFB 都在 1 秒以上，說明服務端處理或資料库查询有瓶颈。
- 偶發超时：平时正常，高峰期或整点批量任務时出現 5xx，常见于定时任務、缓存穿透。
- 個別 URL 慢：某個篩選頁或其他參數组合拖垮响應，往往還伴随被抓取量偏高。
- 地区差异：源站到不同地区节点速度不一致，跨境抓取时更容易超时。
在哪些資料里能看到线索
不要凭感觉判断，可以按下面的顺序自查：
- 看服務器訪問日誌里搜尋引擎 IP 的响應碼分布，5xx 和超时断開的占比有多少。
- 看抓取統計报告里的平均响應時間和抓取請求總量，和改版前、上线新功能前做對比。
- 看“已發現但未编入索引”的 URL 數量，是否在响應變慢的同期明顯上升。
- 抽样實测：用抓取工具模拟蜘蛛 UA 請求核心頁面，记錄從连接建立到首字节的時間。
修复顺序：先让它稳定，再让它快
顺序比细节更重要。稳定優先，因為它决定抓取會不會中断；速度其次，因為它决定抓取效率。
- 先堵異常：把频繁 5xx 的接口和頁面找出来，加缓存、加限流，把耗时查询挪到异步执行。
- 再压 TTFB：静態资源與頁面分离，開啟合理缓存，减少首屏依赖的外部調用。
- 控制被浪費的抓取：组合參數頁、站内搜尋结果頁處理清楚，別让蜘蛛把算力花在低價值 URL 上。
- 降低單次响應体积：過大的 HTML、内联脚本、未压缩资源都會拖慢抓取與解析。
几個容易被忽略的点
第一，改版、大促上线、迁移服務器這些時間点，要提前观察抓取日誌，異常往往集中在這几天。第二，別只盯首頁，栏目頁和深层詳情頁才是被拖累的重灾区。第三，如果用了 CDN 或防護产品，確認它對搜尋引擎 UA 的返回是否正常，有些預設策略會把抓取請求拦成驗證頁。
收錄問题的排查顺序，通常應该是：能訪問 → 响應稳定 → 内容可解析 → 有價值 → 再谈提交與加速。跳過前两步，後面的動作很难见效。