排查 URL 發現效率时，很多人會把注意力放在連結寫法和 robots 規則上，却忽略了一個更底层的問题：入口頁本身响應得太慢。搜尋蜘蛛抓取一個頁面是“建连—等待响應—讀取内容—解析連結”的完整過程，其中“等待响應”這一段如果被拖長，後面所有环节都會被牵连。

抓取是有成本的，慢會直接占用抓取资源

搜尋引擎分配给一個站点的抓取能力不是無限的。爬虫一般會维持一定數量的並發连接，每個连接在等待服務器返回时都處于占用狀態。如果入口頁的首字节時間（TTFB）是 3 秒而不是 200 毫秒，那么同样一段時間内能抓完的 URL 數量會差出一個量級。

更關键的是，搜尋引擎會观察主机的整体响應表現，並據此調整抓取节奏。長期响應慢、错誤率高的主机，抓取频次和並發會被主動压低。這属于爬虫的自我保護机制，不必理解成某種惩罚。

“慢”和“超时”是两件事，但结果常常相似

• 慢：頁面最终返回 200，只是耗时很長。爬虫能拿到内容，但效率下降。
• 超时：超過爬虫的等待上限仍未讀完，一般按抓取失敗處理，會安排重试，並逐步降低對该主机的抓取强度。
• 连接被重置或中断：常见于防火墙、WAF 或连接數限制，表現上和真實的 5xx 現象接近，但原因完全不同。

各家搜尋引擎的超时阈值並不公開，也不统一，所以不要试图“卡在阈值内”，那没有實际意义。

日誌里可能看到的變化

如果入口頁長期偏慢，你可能會观察到這些現象：

• 同一入口頁的抓取間隔被拉長，從几分钟變成几小时甚至更久。
• 單次訪問中被抓取的 URL 數量减少，連結列表只被解析了一部分就結束。
• 新提交的 URL 被發現的時間明顯推後。
• 部分請求干脆没出現在日誌里，因為连接還没建立就被放弃了。

抓取减少的原因很多，慢只是其中之一。判断之前先排除 robots 規則、狀態碼、連結结构等因素，不要把所有問题都归到速度上。

先定位慢在哪里

1. 用命令行工具或浏览器開發者工具测入口頁的 TTFB，区分是網絡、DNS 還是後端處理慢。
2. 检查入口頁是否每次請求都在查資料库、調用外部接口或讀取遠程文件。
3. 確認是否存在 CDN 回源慢、WAF 拦截，或者同机部署過多入口頁導致的资源争抢。
4. 對比静態 HTML 和動態頁面在同一台机器上的响應時間差距。

可以做的一些實际調整

• 入口頁尽量輸出静態 HTML，或者至少加一层缓存，避免每次請求都完整跑一遍逻辑。
• 去掉不必要的外部請求，尤其是阻塞加载的资源。
• 開啟並合理配置長连接，减少频繁建立连接的開销。
• 如果同一台服務器上放了大量入口頁，考虑拆分到多台机器或多個 IP，避免互相挤占带宽和连接數。
• 定期监控 TTFB 與超时率，把它們当成和狀態碼同等重要的指标。

一個常被忽略的前提

响應快的入口頁，只是让搜尋蜘蛛“更容易把该抓的抓完”，它並不保證 URL 一定被發現，更不保證被收錄。速度解决的是抓取效率問题，内容质量和站点整体可信度是另外的事。把入口頁做得轻、稳、快，属于把基础條件准备好，而不是某種可以取巧的技巧。