站点接入 CDN 或反向代理之後，源站日誌里的抓取记錄往往會明顯變少。這不一定意味着搜尋蜘蛛来得少了，更常见的情况是：請求停在了缓存层，没有回源。随之而来的問题是，缓存里儲存的是某個時間点的 HTML 副本，里面的連結、狀態碼、更新時間都可能與源站目前版本不一致。搜尋蜘蛛沿着這份副本走，就可能繼續發現已经下线的 URL，或者迟迟看不到新上线的入口。
缓存副本與源站版本常见的差异
差异通常不會以报错的形式出現，而是藏在细节里。以下几類比較典型：
- 舊連結仍在副本中。栏目改版、列表頁調整之後，缓存里的 HTML 還带着上一版的内鏈结构，搜尋蜘蛛按這些連結繼續發現舊地址。
- 已下线的 URL 仍被指向。頁面合並或刪除後，若入口列表的缓存没有刷新，舊 URL 會持續被带進抓取队列。
- 狀態碼被缓存。某個 URL 短暂返回 404 或 503 时被缓存下来，頁面恢复正常後，缓存层仍返回原来的狀態碼。
- 软 404 頁被缓存成 200。内容已清空但模板仍返回正常狀態碼，缓存和搜尋蜘蛛都會把它当成有效頁面。
- 更新時間與 sitemap 脱节。頁面内容已更新，但缓存副本和 sitemap 里的标记各说各话。
這些差异如果長期存在，URL 發現的方向就會和實际站点结构偏离，抓取路径也會越走越散。
用日誌核對差异是否存在
判断缓存层到底返回了什么，最直接的办法是對照两邊的日誌。
源站日誌與 CDN 日誌對照
源站只记錄回源請求，CDN 日誌记錄全部請求。把同一時間段的抓取记錄放在一起看，如果 CDN 侧的訪問量遠大于源站，說明大部分抓取被缓存接住了。此时要重点關注缓存侧返回的响應体版本，而不是只看回源那几次。
带缓存标识做一次取回
用與搜尋蜘蛛相近的請求头訪問目标 URL，查看返回头中的缓存命中标识和缓存時間。命中時間很早、内容却是舊版，就說明副本该刷新了。
抽样检查入口頁
首頁、主導航、栏目列表頁是 URL 發現的主要来源，優先检查這几類頁面的缓存副本中，連結是否與目前版本一致。這几處一旦落後，影响面最大。
處理顺序建议
發現問题後，不建议一次性清空全部缓存，那样容易在短時間给源站带来集中回源压力。可以按下面的顺序處理：
- 先刷新承担 URL 發現职责的頁面：首頁、導航、栏目列表、HTML 站点地图頁。
- 再刷新近期改版或下线過頁面的目錄，清理副本中的舊連結。
- 修正狀態碼缓存策略，明确哪些狀態碼可以缓存、缓存多久。404、410、503 這類狀態碼通常不宜長時間缓存。
- 把 sitemap 的更新與頁面缓存刷新放在同一批操作里完成，避免两邊時間不一致。
- 最後检查内容更新频繁的詳情頁，為其設定較短的缓存時間或主動刷新机制。
缓存命中不等于抓取變少
有站長看到源站日誌里抓取次數下降，就以為搜尋蜘蛛来得少了，于是加大推送或調整 robots 規則。實际上，缓存命中只是让源站不再處理這部分請求，抓取行為本身可能並没有减少。判断抓取量應以缓存侧日誌為准，源站日誌更适用来观察回源压力與回源内容是否正确。
另一個容易被忽略的点是缓存键。如果缓存键包含完整查询串，同一個頁面的多種參數组合會各自生成副本，副本越多，被搜尋蜘蛛讀到的版本就越难统一。參數類 URL 的收敛工作，最好和缓存策略一起梳理。
缓存负责让頁面更快返回，但它不负责判断内容是否還是最新。抓取路径的正确性，最终要靠刷新机制和狀態碼策略来保證。
把缓存层当成抓取路径上的一個中間环节来管理，定期核對副本内容與源站版本，URL 發現和後續抓取才不會因為一份過期的 HTML 而跑偏。