頁面明明已经更新，蜘蛛抓到的却還是三周前的版本；後台換了标题，结果里還是老标题；栏目停更了，CDN 還在按老規則一直返回缓存内容。這類問题多數不是蜘蛛的問题，而是缓存层級没理清。
先分清缓存發生在哪一层
同一個 URL 的响應，可能经過好几层缓存。排查时不要一上来就清 CDN，先定位是哪一层在“扣留”舊内容。
- 浏览器缓存：由 Cache-Control、Expires、ETag 等响應头控制，主要影响真實用戶。它對蜘蛛的影响有限，但會干扰你自己的測試判断。
- CDN 邊缘缓存：缓存节点按缓存键存副本，命中後不回源。這是很多“蜘蛛看到舊頁面”的真正原因。
- 源站頁面缓存與對象缓存：插件、框架、反向代理生成的静態副本。後台更新了資料，缓存层没被清掉，對外就還是舊的。
自查时重点看這几項
- 抓一次文章頁，用命令行看响應头里的 Age、X-Cache、CF-Cache-Status 之類字段，判断這次是命中還是回源。
- 對比源站直连的结果和走 CDN 的结果。两邊不一致，說明缓存层没同步。
- 检查 HTML 文档的缓存時間。内容型頁面通常适合几分钟到几小时的短缓存，可以配上允许使用陈舊副本的策略；图片、样式這類静態资源才适合長缓存加文件指纹。
- 確認發布流程里有没有“主動刷新受影响地址”這一步，而不是干等過期。
- 核對缓存键。带參數、带地区、带设备区分的規則，容易让同一個頁面产生多份副本，也可能让更新只覆盖了其中一份。
容易被忽略的两個细节
缓存键里带了不该带的參數
如果缓存键包含所有查询參數，一個頁面能裂成几十份副本，刷新时很难全部覆盖；如果缓存键忽略了本该区分的參數，不同内容又會互相串頁。規則要寫清楚：哪些參數參與区分，哪些直接忽略。
更新後的驗證方式
發布完不要只看自己那個浏览器。先用無痕窗口或直接請求一次，再观察蜘蛛下一次抓取时拿到的是哪個版本。也可以在訪問日誌里留意同一個 URL 连續抓取返回的字节數是否發生變化。
缓存不是越短越好。缓存時間压得太短，源站压力上来了，抓取速度反而可能變慢。關键是把“更新後能及时失效”做成流程，而不是靠碰运气。
把缓存纳入日常运维
建议在發布清單里固定三步：發布後主動刷新受影响的地址、抽查两到三個頁面的响應头、观察一两天日誌里的抓取版本。遇到改版或批量更新，先小范围驗證再全量推。缓存本身是好事，它让蜘蛛抓得更快、源站更稳，出問题的只是失效机制没跟上内容變化。