蜘蛛抓取頁面时，拿到的往往不是源站直接吐出的内容，而是 CDN 或反向代理缓存下来的副本。這對站点本来是好事：响應更快、源站压力更小。但如果缓存策略没配好，蜘蛛看到的可能是過期頁、错誤頁，甚至把同一個 URL 的内容分裂成好几份，抓取效率反而下降。
一、命中與回源：蜘蛛拿到的到底是谁的内容
缓存命中时，蜘蛛几毫秒就拿到了完整 HTML，抓取自然顺畅；一旦未命中或者缓存被绕過，請求就會回源，源站要重新渲染、查库、拼装頁面，响應時間可能從几十毫秒涨到几百毫秒甚至更久。
這里常见的隐患是：缓存只對普通訪客生效，對蜘蛛的 UA 走了绕過缓存的規則。有些站点為了让蜘蛛看到最新内容，专门给搜尋蜘蛛配置了不缓存或强制回源，结果是抓取請求全部砸在源站上，响應變慢、超时增多，抓取节奏也跟着收缩。除非頁面必须實时，否則没必要做這種区分。
二、缓存键：參數一多，同一個頁面會被缓存很多次
缓存键决定了“什么算同一個頁面”。預設情况下，完整 URL 會被当作缓存键的一部分，于是带追踪參數、排序參數、會话參數的連結，會在缓存里各存一份。對蜘蛛来说，這些 URL 可能被当成不同頁面分別抓取，内容却几乎一样。
- 把無關請求參數從缓存键中剔除，统一按路径缓存；
- 確認剔除參數後不會串内容，例如分頁、篩選這類會改變正文的參數必须保留；
- 對确實需要区分的參數，考虑用規范化後的 URL 對外暴露，而不是让多種寫法同时存在。
缓存键收敛之後，同一份内容只需要缓存一次，回源次數减少，蜘蛛拿到的响應也更快。
三、TTL 與内容更新：新内容多快能被看到
頁面更新後，如果缓存 TTL 設定得很長，訪客和蜘蛛在 TTL 到期前拿到的還是舊版本。這本身不算错誤，但會带来一個判断偏差：你以為新内容已经上线，蜘蛛看到的却是舊頁面。如果正文變化較大，可以對新發布或修改過的 URL 主動刷新缓存，让後續抓取拿到新版。
需要注意的是频率控制。每次改動都全站刷新，等于把回源压力集中释放，反而让响應變慢。按栏目、按更新频率分层次設定 TTL 更稳妥。
四、被缓存下来的狀態碼：404、301、5xx 最难處理
比内容過期更麻烦的是狀態碼被缓存：
- 临时故障返回的 5xx 被缓存，蜘蛛之後再来還是同一個错誤；
- 临时跳轉的 301、302 被長期缓存，後續抓取一直沿着舊路径走；
- 迁移期間誤返回的 404 被缓存，本来有效的 URL 被判定為無效。
處理思路是：错誤狀態尽量短缓存或不缓存，正常内容可以長缓存。同时確認迁移、改版期間缓存被正确清理，避免舊狀態繼續影响抓取判断。
五、一份可落地的检查清單
- 比較“缓存命中”和“回源”两種情况下頁面的响應時間，差距是否過大；
- 確認搜尋蜘蛛的請求同样走缓存，而不是被特殊規則强制回源；
- 检查缓存键是否包含無效參數，能否按路径统一；
- 確認 5xx、404、301 的狀態碼不會被長時間缓存；
- 梳理新内容的缓存刷新方式，別让更新停留在舊副本上；
- 從服務器日誌里筛出回源請求，看是否集中在少數 URL 上。
缓存和抓取的關系很直接：蜘蛛拿到的响應越快越稳定，能走到的 URL 就越多。把缓存键、TTL 和狀態碼這三件事理顺，往往比反复提交 URL 更有用。