蜘蛛来訪时，實际發生的事比想象中机械：先做域名解析和连接，再發請求，然後等服務器把第一個字节吐出来，最後才是讀取内容。前面這几步如果拖太久，後面的内容再規整，蜘蛛也可能已经走了。
响應耗时是蜘蛛看到的第一件事
蜘蛛對單個 URL 的等待是有上限的，各家搜尋引擎的阈值不完全一样，但共同点是：连接超时、讀取超时之後，這次抓取就算失敗。失敗本身不算致命，問题在于它會累积印象——一個入口站長期响應慢、频繁超时，抓取频率通常會被压低。
可以關注两個數：首字节時間（TTFB）和整頁传輸完成時間。前者更多由服務器、資料库、動態程序决定，後者還受頁面体积和带宽影响。入口頁本身是個轻量頁面，正常配置下這两項都不该成為瓶颈；如果日誌里大量出現“连接超时”或抓取耗时明顯偏長，先查服務器，而不是怀疑蜘蛛。
並發與限速：別把蜘蛛挡在门外
有些运营者担心蜘蛛把服務器打满，于是在 Nginx 或防火墙层面限制單 IP 並發。這個動作本身合理，但阈值要留够空間。
- 並發限制過紧，蜘蛛的多线程抓取會被大量拒绝，日誌里出現成片的 429 或 503。
- 返回 503 且不带 Retry-After，蜘蛛只能按自己的策略退避，节奏容易進一步變慢。
- 带宽被其他业務占满时，蜘蛛拿到的是“能连上但很慢”，比直接拒绝更消耗抓取预算。
更稳妥的做法是给入口站單獨留出一份资源，而不是和主站抢同一台机器、同一條带宽。入口頁承载的只是引路的功能，不需要复杂逻辑，静態化或加一层缓存通常就能把响應压到很低。
蜘蛛的来訪是有节奏的
把訪問日誌按小时聚合，多數入口站會看到明顯的波峰波谷。有的蜘蛛集中在夜間，有的全天分布較均匀。這個节奏可以作為調整内容更新、日誌观察和服務器维護窗口的依據。
尽量不要在蜘蛛活跃时段做大規模重啟、迁移或改配置，這段時間失敗率會明顯高于平时，而蜘蛛並不区分“你在维護”和“你的站不稳定”。
一個入口站如果長期在蜘蛛活跃时段掉线或超时，抓取量的下降通常是渐進的，等發現时往往已经過了一两周。
几個容易被忽略的细节
- 重定向鏈太長。一次跳轉就是一次額外請求，多次跳轉叠加起来，耗时會成倍增長。入口頁到目标頁，尽量一跳到位。
- 外部资源拖慢首屏。統計脚本、字体、第三方接口在蜘蛛侧同样會被請求，某一個卡住，整頁完成時間就被拉長。
- 只盯狀態碼。返回 200 但响應時間很長，和返回 200 且很快，對蜘蛛的意义並不相同，前者更容易被降频。
- 日誌不留存。没有日誌就無法判断响應耗时和失敗率的趋势，只能凭感觉調。
可以落地的几條建议
- 把入口頁做成静態或强缓存頁面，减少動態查询。
- 给入口站單獨規划带宽和连接數，不與其他业務混用。
- 在日誌里记錄响應耗时，按周看趋势，而不是只看当天是否正常。
- 限速規則给蜘蛛留出余量，宁可让它抓得慢一点，也不要成片拒绝。
- 遇到異常流量时，先分清是蜘蛛還是采集工具，再决定拦谁。
入口頁的價值是让蜘蛛顺畅地進门並繼續往下走，响應耗时和抓取节奏属于地基层面的事。這部分不出問题，後面讨论連結、内容、URL 形態才有意义；地基不稳，其他優化很容易被浪費掉。