不少站点在源站日誌里核對蜘蛛抓取量时，會發現數字比预期小很多：Sitemap 提交了几千條 URL，日誌里只有几百條蜘蛛记錄。這时候先別急着判断蜘蛛没来，很可能是請求被 CDN 或反向代理的缓存接走了，压根没落到源站。
蜘蛛的請求不一定落在源站
正常鏈路是：蜘蛛發起請求，DNS 解析到 CDN 节点，节点判断缓存是否命中。命中就直接返回，源站不产生這條訪問日誌；没命中才回源，源站才记下一筆。也就是说，源站日誌里的蜘蛛次數實际上是缓存未命中的次數，它天然小于真實抓取次數，抓取越频繁的頁面，這個偏差越明顯。
情况一：命中缓存，源站日誌缺记錄
這種情况本身不一定是問题，缓存命中反而是好事，能减轻源站压力。麻烦的是把它誤讀成抓取不足，然後去改内鏈、加提交接口，做的都是無用功。
- 看响應头：Age 有值說明来自缓存，X-Cache、CF-Cache-Status 之類的自定义头也能直接标明命中與否。
- 看 CDN 侧日誌：多數 CDN 提供訪問日誌或分析面板，按 Spider 的 User-Agent 過滤，才能拿到接近真實的抓取次數。
- 抽样驗證：用 curl 带上蜘蛛 UA 請求一個已知被抓過的 URL，观察返回头和源站日誌里是否同步出現记錄。
只有把 CDN 日誌和源站日誌叠起来看，抓取覆盖率的核對才站得住脚。
情况二：缓存住舊版 HTML，蜘蛛拿到過期内容
另一類問题更隐蔽：如果 HTML 被設定了很長的缓存時間，蜘蛛每次来拿到的都是同一份舊快照。内容更新了，lastmod 變了，Sitemap 也重新提交了，但蜘蛛讀到的仍是舊版頁面。它顺着舊頁面上已经删掉的内鏈繼續走，新加的入口自然發現不了。
哪些頁面不适合長缓存
- 首頁、栏目頁、列表頁：這些頁面承担 URL 發現职责，缓存時間建议短一些，或采用短周期加回源校驗的方式。
- 新發布的詳情頁：上线初期缓存可以设短一点，或者發布後主動刷新。
- 带登入態或個性化内容的頁面：用 Vary 区分，或者干脆不缓存。
缓存失效的配合動作
發布新内容时主動 purge 對應 URL；把 HTML 的 s-maxage 控制在一個較短区間，而不是和图片、CSS 用同一套長缓存規則；同时保留 ETag 與 Last-Modified，让节点回源校驗时可以走 304，减少實际传輸量。静態资源與頁面用两套策略，是最省心的做法。
核對顺序可以固定下来
- 带蜘蛛 UA 抽样請求目标 URL，先看 Age 和缓存狀態头，確認請求停在哪一层。
- 取同一時間窗，對比 CDN 日誌與源站日誌中的蜘蛛請求數，看差多少、差在哪些目錄。
- 检查 Cache-Control 對 HTML 的設定，確認是否和静態资源混用了同一套規則。
- 發布新内容後，隔一段時間再用蜘蛛 UA 抓一次，確認拿到的版本已经更新。
缓存問题很容易伪装成「蜘蛛不来」，先確認請求到底停在網絡哪一层，再谈内鏈、Sitemap 這些優化，顺序反了會白做很多事。
小结
CDN 缓存和蜘蛛抓取之間有两處容易错位：一處是日誌，缓存命中让源站看不到抓取；一處是内容，長缓存让蜘蛛看到舊頁面。前者靠日誌合並核對解决，後者靠区分頁面與静態资源的缓存策略解决。把這两点理清，再去判断抓取覆盖率和 URL 發現問题，结论會可靠得多。