很多站点运营的注意力都放在内容和内鏈上，直到某天發現蜘蛛来訪次數不少，收錄却没什么動静。翻日誌才看到，大量請求的响應時間在两三秒以上，中間還夹杂着 5xx 和超时。蜘蛛没有無限的耐心，服務器一直让它等，抓取频次自然會往下走。
為什么响應速度會影响抓取
搜尋引擎分配给每個站点的抓取资源是有限的，這個額度既看站点本身的状况，也看服務器扛不扛得住。同一段時間里，如果每個請求都要等很久，能抓完的頁面數量就會變少；如果错誤率偏高，蜘蛛還會主動降速，避免给服務器添麻烦。结果是新頁面排队等，舊頁面的更新也變慢。
几個值得盯的基础指标
- 首字节時間（TTFB）：從發起請求到收到第一個字节的耗时，最直观的信号。
- 狀態碼分布：5xx 占比多少，是不是集中在某几個栏目或某個接口上。
- 超时比例：被服務器主動掐断的請求有多少。
- 並發承载：同一时刻能稳定處理多少請求，超過這個數會不會雪崩。
在日誌里怎么找线索
把蜘蛛的訪問记錄按 URL 归類，再對一下响應時間和狀態碼，通常能看出一些規律：
- 静態頁面快、動態頁面慢，說明瓶颈在後端渲染或資料库。
- 某個栏目整体偏慢，多半是這個栏目的列表查询寫得重。
- 深夜快、白天慢，多半是服務器资源和正常訪客在抢。
- 某段時間 5xx 集中出現，可能是重啟、發版，也可能被采集打了。
常见的拖慢原因
- 頁面每次訪問都查一遍資料库，没有缓存层。
- 模板里同步調用第三方接口，對方慢一点，整頁就卡住。
- 列表頁一次拉出几百條資料，還逐條做關联查询。
- 未压缩的图片和大体积静態文件占满带宽。
- 插件或中間件层层叠加，請求鏈路越走越長。
可执行的自查步骤
- 選一個正常工作日，取一段至少 24 小时的訪問日誌。
- 筛出蜘蛛 UA 的记錄，統計平均响應時間和 5xx 占比。
- 把最慢的 20 個 URL 列出来，逐個確認是内容頁還是功能頁。
- 针對最慢的几類頁面，先加缓存或做静態化，再复测一次。
- 给响應時間和错誤率设一個监控阈值，出問题能第一時間知道。
抓取压力大时怎么處理
如果站点規模大，蜘蛛来訪又密集，可以考虑把内容頁生成静態文件，列表頁做短周期缓存，把資料库压力降下来。也可以在服務器层面做限流，優先保證内容頁可用，牺牲一些次要頁面。需要提醒的是，不要把 crawl-delay 当成萬能药，它只是让蜘蛛慢一点来，並不能解决頁面本身慢的問题；過度依赖它，反而會让新内容更晚被發現。
服務器响應是所有运营動作的地基。内容寫得再好，頁面半天打不開，也很难被好好收錄。
小结
响應速度這件事，不需要一步到位做到极致，但至少要保證内容頁稳定、快速地返回。定期翻一翻日誌，比等到收錄下滑之後再回头排查要省事得多。