入口頁响應慢，是蜘蛛池排查里很容易被忽略的一环。很多人只盯着“連結有没有被提取”“目标URL有没有被抓”，却没注意搜尋蜘蛛每次請求入口頁时，都要在服務器那邊等一段時間。等待時間累积起来，直接影响它對入口頁里那些目标URL的耐心。
先把两個环节分開看
搜尋蜘蛛處理一條鏈路，大致是：抓入口頁 → 解析 HTML 取連結 → 把新 URL 放進待抓队列 → 之後再抓目标URL。入口頁慢，卡住的是前两步；目标站慢，卡住的是最後一步。两者症状相似，排查方向完全不同。判断的时候，先看服務器日誌里入口頁的响應時間，再看目标站的响應時間，別混在一起归因。
入口頁响應慢，具体會带来什么
- 抓取配額被吃掉。蜘蛛在單位時間内的請求數是有限的。如果每次抓入口頁都要等三五秒，本来能抓几十個頁面的時間，只够抓几個。
- 連結可能根本解析不到。等待超過蜘蛛的超时時間，连接會被断開，返回的是不完整内容，里面的連結自然不會被提取。
- 回訪频率下降。如果连續几次抓取都是超时或响應很慢，調度會倾向于降低對這個入口頁的訪問频次，之後再来就隔得更久。
- 目标URL的抓取被延後。發現這一步都做不利索，後面的抓取只能排队，出現“已發現未抓取”停留很久的情况也就不奇怪了。
多慢算慢
没有官方公布的硬阈值，但可以按经驗分档：首字节時間在几百毫秒以内，抓取比較顺畅；超過一两秒，就能感觉到节奏變慢；如果经常到几秒甚至十几秒，超时和断连的概率會明顯上升。這只是判断方向的參考，不是收錄與否的開關。
怎么確認慢在入口頁這一侧
- 翻服務器訪問日誌，找搜尋蜘蛛的 UA，看响應時間字段和狀態碼。5xx、超时和 200 混杂出現，通常是服務器扛不住。
- 用 curl 的耗时參數，或第三方多节点测速，從外部網絡测入口頁，而不是只在本机测。
- 對比同一時間目标站的日誌。如果目标站响應正常、入口頁却拖沓，問题就在入口頁這邊。
- 检查入口頁是不是動態生成、有没有走資料库、有没有引用外部脚本。外鏈资源多、統計脚本多，也會拖慢整頁交付。
常见拖慢原因與調整思路
- 资源不够：共享空間、低配机器上同时跑太多站点。考虑把入口頁放到更稳的节点，或做静態化。
- 頁面太重：入口頁不需要复杂效果，纯 HTML 加連結就够用。减少脚本、字体、大图，能明顯缩短交付時間。
- 没有缓存：同一份内容被反复動態拼装，加一层頁面缓存或直接生成静態文件即可。
- DNS 與回源：如果用了 CDN，確認回源是否稳定；解析环节慢，也會体現為整体變慢。
- 連結一次上太多：頁面變大、請求變多，抓取负担同时上升。分批上线入口頁和連結，比一次性铺開更容易看出效果。
不用過度紧張的部分
短暂的响應波動是正常的，某一次抓取慢几秒，不代表後面的目标URL就抓不到。抓取本身带有概率性质，入口頁稳定、可訪問、連結清晰，才是長期更重要的條件。發現响應确實偏慢，先調整服務器和頁面结构，再观察一到两周日誌變化，比反复改連結形式更有意义。
入口頁的價值是“被稳定地抓到，並把連結交出去”。响應速度是這條鏈路上最容易修、也最容易被忽略的一环。