很多站点把蜘蛛抓取理解為蜘蛛直接訪問源站，但真實鏈路里往往還有 CDN、反向代理、頁面缓存插件和對象存储。蜘蛛拿到的是缓存层返回的那份响應，而不是你刚改完的源站内容。当抓取表現和後台修改對不上时，先別急着怀疑蜘蛛，先核對缓存层。
為什么缓存层要纳入抓取核對
抓取一致性指的是不同時間、不同节点、不同 UA 拿到同一 URL 时，响應主体與狀態碼基本一致。缓存层一旦让响應出現分叉，就會出現几種典型現象：蜘蛛抓到舊版頁面、抓到的頁面缺少内鏈、同一 URL 在不同邊缘节点返回不同狀態碼。這些都會影响 URL 發現和後續的抓取判断。
常见的缓存分叉场景
1. 缓存過期時間過長，抓取到舊版
發布新内容後源站已经更新，但邊缘节点還在返回几小时前的 HTML。蜘蛛這次抓取拿到的仍是舊内容，内鏈里没有新 URL，新頁面就少了一條發現入口。
2. 按 UA 或 Cookie 分流
有些配置對搜尋引擎 UA 走不同缓存規則或不同回源路径。核對时要注意：同一 URL 用普通 UA 與蜘蛛 UA 請求，返回的狀態碼、正文長度、是否含脚本注入内容是否一致。分叉本身不一定是错，但需要確認它没有屏蔽關键連結。
3. 缓存把错誤响應也缓存下来
源站短暂 5xx 或超时被缓存後，蜘蛛可能在缓存有效期内反复拿到 5xx，看起来像服務器持續不稳定，實际是缓存放大了單次故障。
4. robots.txt 與 Sitemap 的缓存
這两類文件也常被缓存。規則更新或 Sitemap 分片調整後，如果缓存未刷新，蜘蛛讀到的仍是舊版本，URL 發現范围會與预期不符。
核對顺序建议
- 確認目标 URL，分別记錄源站直连與经過 CDN 的响應狀態碼、Content-Length 和响應头。
- 對比两者的正文關键片段，例如标题、正文首段、導航里的連結集合。
- 查看响應头中的缓存命中标记與 Age，判断是命中缓存還是回源。
- 抽查多個邊缘节点或多次請求，確認是否只有部分节点内容滞後。
- 對 robots.txt、Sitemap、關键入口頁單獨做一次刷新與复核。
- 核對完成後再看日誌中的抓取记錄，避免把缓存問题誤判為抓取異常。
日誌與响應头的观察点
- 狀態碼分布：缓存层返回的 200 與源站日誌里的 200 數量是否對得上。
- 回源比例：如果回源次數遠低于抓取次數，說明大量請求被缓存拦截。
- UA 與路径组合：同一路径下不同 UA 的响應差异。
- 時間戳：缓存刷新時間與内容發布時間是否接近。
抓取問题里，缓存层造成的假象很常见。先分清蜘蛛没来和蜘蛛来了但看到的是舊的，再决定要不要動站点结构。
稳定性與刷新节奏
缓存刷新策略不必追求最短，但要與内容更新节奏匹配。入口頁、栏目頁、Sitemap 這類承担 URL 發現职责的頁面，可以設定得更及时；内容頁則按實际更新频率設定。核對的目标是让蜘蛛在不同時間点看到的連結集合與狀態碼保持稳定，而不是把缓存整体關掉。
如果缓存层配置合理，服務器压力會下降，蜘蛛抓取时的响應也更稳定。把缓存层加入抓取核對清單，能减少很多改了但没生效的排查時間。