很多站長把服務器稳定性理解成“源站別挂”，但蜘蛛實际连上的往往不是源站，而是 CDN 的邊缘节点。蜘蛛拿到的是一份缓存副本，副本新不新、對不對，直接决定它對站点的判断。抓取異常时，先確認蜘蛛站在哪一层，比急着改内鏈更有意义。
蜘蛛的請求落在哪一层
用戶和蜘蛛訪問同一個 URL，請求都會先到最近的 CDN 节点。命中缓存就直接返回，没命中才回源。對抓取来说，這條鏈路上有两個關键變量：拿到的是不是最新版本，以及返回的狀態碼是不是站点真正想表達的那個。两者只要有一個不對，後續關于 URL 發現、内鏈權重的分析都會建立在错誤前提上。
缓存副本常见的两個坑
頁面已经更新，蜘蛛仍讀到舊内容
HTML 缓存時間设得太長，源站改版、改标题、改正文之後，邊缘节点還在吐舊文件。蜘蛛按自己的节奏来訪，看到的還是上一版；站長在浏览器里刷新（可能绕過缓存或已過期）觉得一切正常，两邊看到的東西並不一致，排查时很容易互相“扯皮”。
错誤頁被缓存下来
更麻烦的是 404、5xx 或维護頁被当成正常响應缓存。源站短暂抖動一次，CDN 把错誤頁存了几個小时，這期間所有来訪者（包括蜘蛛）拿到的都是错誤内容。抓取日誌里會出現一批莫名其妙的失敗，而源站监控却是绿的。
缓存头里需要關注的字段
- Cache-Control 與 s-maxage：决定邊缘节点存多久。HTML 建议短一些，给内容更新留出余地；带指纹的图片、CSS、JS 可以放長。
- stale-while-revalidate：允许先返回舊副本再後台更新，能降低回源压力，但舊副本仍然會被蜘蛛讀到。
- Vary：如果按 User-Agent 或 Cookie 分版本，缓存會被切成多份，蜘蛛可能拿到與你预期不同的那一份。
- Set-Cookie：每次請求都下發 Cookie，容易拉低缓存命中率，回源次數随之上升。
给蜘蛛單獨放行要谨慎
有些站点會在 CDN 上按 User-Agent 判断，让蜘蛛绕過缓存直接回源。這样能保證看到最新内容，但有两個風險：一是回源压力集中在蜘蛛身上，源站不稳时它更容易拿到 5xx；二是 UA 規則寫错，把正常流量或蜘蛛本身誤拦成 403，抓取會直接断掉。真要做，先確認判断規則和回源容量，再小范围驗證。
命中率也影响等待時間
缓存命中高，TTFB 低，蜘蛛等待時間短，同样的抓取額度能覆盖更多 URL；反過来，每次都回源且源站响應慢，超时和重试的比例就會上升，抓取队列被無效請求占满。缓存配置不只影响用戶体驗，也影响抓取效率。
一份自查清單
- 用服務器日誌和 CDN 日誌對照，看蜘蛛請求的命中狀態、返回碼和缓存年龄。
- 在 CDN 控制台確認错誤狀態碼不被缓存，或設定很短的 TTL。
- 改版後主動刷新相關 URL 的缓存，再观察蜘蛛下一次抓取拿到什么。
- 確認没有對蜘蛛 UA 返回驗證頁、JS 挑战頁或空白頁。
抓取問题不總是出在 HTML 里。先確認蜘蛛站在哪一层、拿到了哪一份文件，再谈内鏈和 Sitemap 才有效。
把缓存策略和抓取节奏對齐，让蜘蛛看到的版本與用戶看到的一致，後續 URL 發現、抓取路径和 Sitemap 的判断才不會跑偏。