蜘蛛抓取頁面时，先建立连接、發送請求，再等待服務器返回第一字节。這個等待時間通常叫 TTFB（Time To First Byte）。它不直接决定收錄，但會明顯影响蜘蛛在一個時間段内能抓多少頁面。如果 TTFB 長期偏高，蜘蛛可能會降低對站点的抓取频率，用戶打開頁面也會變慢。
為什么要把 TTFB 放進日常自查
很多站点运营者习惯看頁面是否打開，却很少记錄服務器响應時間。首頁快不代表全站快，詳情頁、搜尋頁、分頁、列表頁可能因為查询复杂或缓存缺失而變慢。蜘蛛抓取的是全站，不是只抓首頁。
TTFB 偏高通常不是單一原因，可能是網絡鏈路、服務器配置、程序逻辑、資料库查询或第三方接口共同造成的。自查的目的不是追求某個固定數值，而是找出明顯異常，避免让蜘蛛在慢頁面上反复等待。
哪些頁面和环节容易變慢
- 未缓存的詳情頁：每次訪問都查資料库、拼模板，响應自然比缓存頁慢。
- 篩選和搜尋结果頁：组合條件多，查询范围大，如果允许蜘蛛抓取，容易消耗抓取预算。
- 分頁較深的列表頁：翻到後面仍然执行全量統計或排序，耗时增加。
- 依赖外部接口的頁面：第三方接口超时或變慢，會连带拖住整頁响應。
- 服務器资源紧張：CPU、内存、连接數接近上限时，所有請求都會排队。
怎么用简單方式做抽样自查
- 選一批有代表性的 URL：首頁、栏目頁、詳情頁、分頁、标簽頁、搜尋頁各取几個。
- 用浏览器開發者工具的網絡面板，或者 curl 命令，记錄每個 URL 的 TTFB，不要只看頁面完全加载時間。
- 同一 URL 在不同時間段多测几次，区分偶發波動和持續偏慢。
- 把结果按頁面類型归類，看看是全局都慢，還是集中在某類模板或某個栏目。
- 结合服務器日誌，观察蜘蛛抓取這些頁面时返回的狀態碼和响應時間是否異常。
自查时不要只测首頁。首頁常有缓存和 CDN 加持，速度正常不代表詳情頁和列表頁也正常。
發現偏慢後從哪些方向排查
先從最容易確認的地方入手：检查缓存是否命中、CDN 是否回源频繁、資料库慢查询日誌里有没有明顯耗时语句。如果某個頁面模板慢，可以單獨压测這個模板，而不是笼统地说“服務器慢”。
對于篩選參數、站内搜尋结果這類頁面，如果内容质量低且數量大，可以考虑用 robots.txt 或頁面級 noindex 控制抓取，减少不必要的動態請求。分頁較深的列表頁，可以评估是否限制翻頁深度，或者優化查询逻辑。
如果確認是服務器资源不足，再考虑升級配置、調整连接數、拆分服務或增加缓存层。不要一開始就归因于服務器，也不要把所有慢請求都推给蜘蛛。
把响應時間纳入站点运营记錄
可以每周固定抽查一次核心頁面類型，记錄大致区間，和上一周對比。不需要记錄到毫秒級，但要能看出趋势。如果某次改版、上新活動或接入新接口後响應明顯變慢，就回头检查改動点。
TTFB 只是站点健康度的一個侧面。它不能保證收錄，也不能直接提升排名，但一個响應稳定的站点，至少不會让蜘蛛和用戶在门口等太久。把這項自查和日誌分析、缓存检查、連結規范放在一起做，站点运营會更有章法。